Skip to content

Not so S.M.A.R.T

The orginal requirement for S.M.A.R.T. objectives

The original requirement for S.M.A.R.T. objectives

I’ve been managing technical people since 1989 (currently at Conductor). It’s surprising how challenging and entertaining it remains. You would think by now I had it all figured out. After 20 years I should have written a book on the subject with a catchy title like “Who Moved My Submit Button?” or “The Seven Habits of ADD Engineers”.

But no, gross generalizations about managing people that can be effectively applied to real-world situations elude me. I’ve developed a lot of my own theories and tested out quite a few of the more popular ones on unsuspecting victims but when it comes to helping individual contributors succeed my mileage still varies.  Like the seemly well thought out instructions for assembling IKEA furniture the map is not the territory.

My message to you here is that management is an art–not a science. It requires a lot of empathy, experience, and thickness of skin on both the part of the manager and the managed to get something useful out of the relationship. Servant Leadership, Situational Leadership, MBOs, and the OODA Loop all get chucked out the window when you’re sitting down with a real person at performance review time and really and truly want to help.

One particularly pernicious management tool is the so-called S.M.A.R.T objective. It’s a seductive idea that seems to make perfect sense. Like mom, apple pie, and Bruno, S.M.A.R.T objectives are one thing we can all agree on. After all who wants to write vague, assay-required, guesstimatable, unparalleled, eternal (V.A.G.U.E) objectives?

If management technique can be expressed as an actual word–beware! Did the author rig the technique to fit the word? If the English word for “smart” was spelled “snort” would objectives be Smart, Normalized, Obvious, Relevant, and Time-bound?

I have the suspicion that SMART objectives predate the Internet. Back in the days when the day had an end, distribution took time, and distance mattered, every activity of value had a physical manifestation. SMART objectives seem to want to be very “specific” things that actually get finished. In this Internet-age nothing is finished! The goal is to get it out before it is “done” so you can get comments and feedback. Is Microsoft Windows or WSJ.com ever “done”? Nope. No software or service is “Time-bound”. Heraclitus would have loved SaaS.

“Measurable” is good. It’s nice when you can tie a number to something. Take page hits and clicks. They seem like nice concrete numbers to measure success on the web. Talk to an engineer who knows something about HTTP, about fraud, and about packet loss and pages hits turn into very soft abstractions while every click becomes suspect. The fact is that measurable things require a judge. In today’s empowered self-managed work force there are no judges—just collaborators. Even your boss is a collaborator.

Don’t get me started with “attainable”. Even 20 years ago I realized that if goal is to be challenging it can’t be obviously attainable. Why bother? Don’t tell me a goal can be both challenging and attainable. That’s a Jedi Mind Trick! Like Jumbo Shrimp or Conservative Investor. (OK, an oxymoron.) I’m not paying you for the attainable. That’s already on the market.

The only tool in the SMART objective toolbox that survives critical thinking is “relevant”. After all you would not want to confuse the employee with irrelevant objectives like meet your deadlines while standing on your head. But that’s kind of insulting to the manager. I mean if you have to tell me to make my objective relevant you should also remind be to have them be rational or not stupid. I bet relevant is there because SMART has an R in it.

So how should you write up objectives? If it makes sense for the situation by all means write up SMART objectives! On the other hand, your employees (collaborators really) might benefit from VAUGE objectives. Especially if they are smarter than you… You did hire people smarter than you?

The ideas behind VAGUE objectives:

  • Vague: You don’t know exactly what to do. The employee has to find out. You job is to point in the right direction not draw the line down the road. The answer is off-road.
  • Assay-required: Don’t measure—experiment. It’s the only path to reliable knowledge.
  • Guesstimatable: I don’t know if you can do it. I think you can but there is some risk of failure. This keeps you from feeling dead inside.
  • Unparalleled: If goals should be realistic then nothing impossible would get done: Landing on the Moon, electing black men president, creating a popular phone without a keypad.
  • Eternal: Nothing is ever finished. Keep refining, iterating, upgrading…

Always Start with the Face

Very rough layout--subject to change!

The hardest part of creating a Flash game, after figuring out the idea behind it, is to figure out what it will look like. Once you have those two tasks out of the way the actual coding is easy: The design tells you what to code.

But first -> Inspiration!

Since this game will feature multi-player interaction I’m going to borrow from the greatest of all multi-player games: World of Warcraft. In WoW you get to battle monsters and other players rendered in an epic 3D virtual world. Sweet! In my little game you’ll do the same, only with dots instead of the epic 3D. A lot of WoW-play boils down to a  race between DSP (damage per second) and HSP (healing per second). So that’s what my game will do: Let players discover who can keep their little team of dots alive while killing the other guy’s dots.

Like the game the UI will be inspired by Blizzard’s magnum opus as well. On the left will be unit frames that display the health, mana, and experience of your team. On the right will be unit frames that display your opponent’s stats. In the center will be an animated dot-view of the action. Across the bottom will be command frames: Click these guys and you can target and attack bad dots or help your good dots. Lose and you hang your head in humiliation. Win and you gain experience to progress to the next level. Maybe even some loot will drop!

At this point I have a rough idea and a very rough UI design. I like to work it that way. I’ve found it’s a big waste of time to spend hours designing something what will just end up trashed as the concept evolves. It’s time to code…

I’ll need four major classes: An application class to manage everything, A view class to display stuff to the player, a state machine class to track what is happening to who, and a game engine class to control all the action. (This architecture is called Model View Controller (MVC) and is at the heart of almost any well written GUI application.)

Questrian Flash Project Files

I’d like to use a hash map to store the current state of my objects in the game. I don’t really need the efficiency of a hash map. But my ideas are very rough right now and things are going to change. Store keyword-value pairs will make managing change easier than hard coding properties into ActionScript classes. The Adobe documentation suggests I use the Object class to create a fake hash map (associative array) or use the flash.utils.Dictionary class. But I won’t get cool Java-like collection interface convenience functions 🙁

Luckily I found: AS3 Data Structures For Game Developers by Michael Baczynski. Thanks Michael! This library includes Hash Maps, Queues, Trees, and Stacks and more. Hard to believe ActionScript 3.0 doesn’t include them by default.

Getting Back Into Flash!

My Flash Environment

It’s been a couple of years now since I wrote a Flash game. They’re fun and easy to write and don’t take much time. For me the fun is in the design and programming. The result of the process might be a playable game–but I make no promises.

I’ve taken down all my old work, since it was out of date and I barely functioned anymore. That’s the problem with programming: The platforms keep changing. The Flash CS 4 of today is a whole new ballgame and I need to get up to speed quickly so turned to my favorite Flash platform how-to author: Colin Moock. I think I have every book he has written on ActionScript that is published by O’Reilly. Since beginning of the 21st century Mr. Moock has exhibited genius when writing about Flash programming.

Moock’s current Flash programming book is Essential ActionScript 3.0 from 2007 which is old by Internet standards. But I’m a couple of years behind the times and EAS3 got me up to date quickly: Subclass Sprite and Shape not MovieClip, how to use events, how to animate, how load resources, how to redraw the stage intelligently. Nice stuff that is scattered all over Adobe’s support site. Apparently there is more Internet info on Flash and its buddies ActionScript, Flex, MXML, and Air then on the Mac OS X APIs!

One technology I want to use in my game is Moock’s Union Platform. It looks like a quick and elegant way to incorporate multiple users into my game. We talk a lot about the power of social networking and data mining but under all that talk is the power of multi-user applications. I remember years ago when I worked at Apple asking Kurt Piersol what comes next after OpenDoc (the hot technology of 1997) and he said MUDs: Multi-User Dungeons. And I said Huh? Isn’t that a buch of guys fooling around in a fantasy world online? Yep, he replied and smiled mysteriously.

12 years later I get it. Any with Moock’s help I’ll put MUD goodness into my little Flash project 🙂

Sorting is the most important thing you can do right now!

You need to stop reading this blog post and do some sorting. I don’t mean later today, when you have spare time, I mean right now. Don’t worry, I’ll wait.

OK, did you do it? If you did leave me a comment about what you sorted (prioritized, categorized, arranged, screened, rated, grouped, graded…). If you didn’t leave me a comment about why you didn’t.

Enough with the homework.

It took me a long time to figure out that sorting is the most important thing to be done.

If it didn’t take you as long as me to figure it out gratz! You are winning the game of life.

But if you need more hints here are my reasons (in order of importance) why sorting is the first thing you do at in the morning and the last thing you do at night.

  1. If you don’t sort the odds are that you won’t do the most important thing first. You’ll most likely do the most urgent thing first. There are wickedly huge differences between urgent and important. Ask Keen PDA if you don’t know the difference.
  2. You have to do a lot of sorting to get good at it. Putting your priorities in order is actually hard work (I think that’s why most people don’t do it). You need to become an elite performer in sorting and that takes practice–lots and lots of it.
  3. Not everything you want or should do is going to get done in your life time. You have to make choices. I know, making choices sucks. But that’s the way it is for us mortals.

I have this great book, The Order of Things (There is one other, more important book, by the same title and you should read it first). I bought TOOT back in 1999 from the discount bin of a bookstore in Palo Alto. I was working at a startup, BitLocker, and we thought we might want to create an online database with most of the world of things already represented. The big problem with databases, after you have the right schema, is data entry. Its boring, easy to screw up, and not fun to double-check. So I wanted to pre-populate the BitLocker with all the bits that a consumer might want to track–All the CDs ever released, all the comic books ever published, all the automobiles ever manufactured. Then when you wanted to track your collection of comix it was just a matter of search and selection (something that is actually fun and easy).

I thought TOOT might help me design the UI of BitLocker and prioritize the search results so that the bits would appear in a natural order that the majority of users would find sensible to navigate. But I was doing things for BitLocker in the wrong order. What we needed first was a good business model. Instead we build a cool Java-based online object database with an early version of an AJAX UI.

Naturally BitLocker’s bubble burst along with the rest of the dot coms. So stop reading this and go sort your to-do list!