Multiplitaxion Inc; a consultancy services organization I worked at years ago was an organization where Managers sat in ivory towers and gave strange; unclear instructions to engineers. Then when you started working; they would score a foul by emailing you about a completely disconnected topic; turning you from a programmer to a multi-tasking joker.
A classic example of unclear instructions happened at a project where we were building device drivers for a multi-functional device. This is when two young engineers fresh out of college were asked to --- 'map device codes to device names' halfway down the project.
What followed; as I watched in horror; was a long tale of errors and confusion; as these two young engineers; too scared to ask and get an intimidating response back from their managers; fumbled through the project document repository in an attempt to find the document that contained master device codes; device names and their mapping. Turns out; the repository had no such document.
After a couple of days of fumbling when the engineers asked for the device codes they were sent an email containing all the device codes that could exist in the system; leaving them to ask for all the device names and the mapping information between the two.
The entire cycle took three days of emailing back and forth after which they finally had everything they needed. It took more than five emails back and forth. One email had device codes; the other hand device names and three others had 'business logic' on how they could map device names to device codes.
My exposure to prickdom however; came when I needed additional specifications of the device and asked for the information I needed. Turns out; the manager was being bogged down with meetings and was too busy to respond to my email. What I got in response of the email I sent was an attachment. It was excel file containing device codes; names; the device specifications and the mapping between the three pieces of information.
As I scrolled through the email trail that had been forwarded to me; I learnt that the file had been sent by the client a couple of months ago.
A Gazillion questions filled my head as I glanced through the file:
- Why did the manager not upload the file on the project repository and let everyone know?
- Why did he not send the file to the two young and budding engineers when giving them their assignment?
- Why did he actually take the pain to extract information out of the file; paste it in an email and send out only partial information over to the engineers; even when they explicitly asked for the information?
While this may sound like an extreme example of prickdom; I have seen managers around the world holding on to information and being highly reluctant to share it out; almost as if their job depends on what they know and what no-one else in the project team knows. Others spam the team with random information that the team does not need in the first place.
Joel Spolsky provides sound advice to young and budding managers when talking about the topic to human task switching. He explains:
On the individual level -- have you ever noticed that you can assign one job to one person, and they'll do a great job, but if you assign two jobs to that person, they won't really get anything done? They'll either do one job well and neglect the other, or they'll do both jobs so slowly you feel like slugs have more zip. That's because programming tasks take so long to task switch. I feel like when I have two programming projects on my plate at once, the task switch time is something like 6 hours. In an 8-hour day, that means multitasking reduces my productivity to 2 hours per day. Pretty dismal.
As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they're going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done. When emergencies come up, think about whether you can handle it yourself before you delegate it to a programmer who is deeply submersed in a project.
At the end of the day it is not just about multitasking. If you call yourself a manager; a leader or whatever-it-is-that-you-call-yourself; it is your responsibility to see to it; that your fellow programmers have precise; compact and concise information to act on the tasks that you expect them to work on.
Do not start parallel threads of work; don't make them starve or look for information when it is readily available with you; and don't bombard them with more information than what is necessary.
If you are not comfortable leading from the front; the least you can do as a manager; dear reader; is get down from your ivory tower; develop a strong bonding with your team; show some empathy; stick around as a helper as they slog; and when they need information make the information available to them; without making them beg for it; or bogging them down with too much data or information that they do not need.
If you can just do that; you have probably taken your first step towards fearless project management without a lot of insecurity.
I wish you good luck on your way ahead.
Remember; if they are confused and lost as they develop; it probably is your fault.
Comments are closed.