If you are unfamiliar with the subculture of Dungeons and Dragons, allow me to enlighten you with one of the rituals of the game. Role playing games are part narrative where the “Dungeon Master” who is the emcee of the game plays referee as well as storyteller. Another part of the game besides narrative is rules based where inflection points such as combat between your brave virtual heroes and monsters is decided by chance with the roll of the dice. When you first start a battle “round” you have to roll initiative. Usually this is a standard six sided die that is thrown both by the Dungeon Master (on behalf of a monster) and the player character. Whoever gets the highest value gets to attack first. This is important because if you are against a tough opponent, dealing a mighty, mortal blow first will likely benefit you due to your foe reeling from your righteous onslaught.
Hold this concept in your mind as we now turn to a team setting in the office.
If you are a manager, then likely you have a team of people who are at various stages of development in their career. What typically happens with junior developers is a cycle of work where you the manager fill the employee’s work queue based on prioritization driven from business needs or internal business owner lobbying. The junior developers will pick a task up, work it, and when they are finished come back to the queue and ask for the next task (or even better just grab the next task off the queue and start).
What do you suppose happens when something comes up, such as a pet project from an executive that appears, usually in the context of a “drive by”? Nine times out of ten the developer will immediately stop and ask the manager, “Which one do you want me to do?” What ensues is a painful back-and-forth that might go like this:
“How much more work will the existing project in flight take to finish?”
“How long will the pet project take to knock out?”
Seasoned developers should know better than to engage in this banter. They should proactively negotiate a deal with their manager. If the new task takes a few hours to knock out, then it should be done so that the team scores a quick win with management and then the developer can context switch back to the original task. Nobody is asking you to multitask, we want you to preemptively multitask. This is computer-speak for pausing on the original task, devoting a time-slice to a new task, and then switching back.
Now that’s one version of initiative that seems to be in scarce supply. A second type I want to discuss is one that separates employees from “goto guys”. A “goto guy” is someone you go to when you want something done. Goto guys anticipate needs and already can tell you three ways to implement it. Goto guys think holistically and recognize an opportunity in the code / the business / the business funnel / etc and they speak up. They come to your desk and tell you about an idea they have they want to work on. EVEN BETTER – they have already done a prototype instead of working on their Facebook likes and they want to show it to you like an eager child showing a parent their finger painting from art class.
What is the environment that would be conducive to this behavior? What can we do as managers to encourage and reward employees that bring this attitude to work with them? I don’t know but I wish I could figure it out. Sometimes it seems people get worn down by the corporate grind and lose that edge that motivates and pushes us. If I see this second kind of initiative I will laud the employee and remember it come bonus or review time.