Giving good report for system and math geeks

Richard Threadgill, Feb 2001

or: I keep doing work, why do they keep yelling at me?

Lots of techies give really lousy progress reports, and are basically hell on their managers for no good reason. This is particularly bad for sysadmin types, systems programmers, and other people who love math too much. I spent several hours with a coworker last week discussing "how not to be an employee of doom," and these are my notes from that conversation.

First an aside - these notes offer advice both for techies in general, who often have a pretty sucky model for the pressures on, and motivations of, their management, and advice for systems and math people in particular. Math people have two classes of problems: trivial problems, which merely need typing at, or the identification of the existing solution; and unsolved problems, which require thinking, hypothesis, and potentially experimentation. This leads them to often front-load their work, going through the list of their tasks and performing the "hard" tasks first because the others are "just work." Systems people have a strong tendency to be moderately ADD as well, because its a really useful trait in a high-interrupt environment where you need to context-switch pretty completely.

Unfortunately, it leads to some work habits which make their behavior (our behavior) really unpredictable. Management can tell how often they're getting complained to about things we haven't gotten done, and how often you're reporting finishing tasks which they cared a lot about personally, and that's about it. This makes writing job req justifications basically impossible. And that sucks, because it means you get fewer raises and spend all of your time being overworked. It also means that development managers basically can't deal with you in any constructive way, because your behavior is inexplicable and unpredictable.

Finally, this document is designed for people who have a soft handle on how much time they spend on tasks, because they thing about tasks from the perspective of difficulty rather than from the perspective of expected time-to-accomplish.

So, some rules for being easier to manage.

• First and foremost, NEVER go radio silent. This is your manager's worst nightmare - they don't know what you're doing, they can't defend spending their resources on it, and they don't know when you'll finish. So, if you are about to embark upon a task which may cause you to go quiet for a while, discuss it with your manager first. Be prepared for them to direct you to attack a different problem first, so that they (and you) can build some capital to defend you while you're silent. Think of this as you giving your manager a good answer to the question "what has that employee done for you lately?" when they get asked by their peers and their management. This makes their life easier.
• Give status early and often. This makes your manager's life easier. Most of the rest of this document will talk about how you can order your work and reporting to make your work more predictable and thereby more obviously valuable.
• Attempt to show consistent levels of output. This creates a perception of predictability, and changes the conversation your boss has with his boss from "Has Dave gone silent again? Do we know what he's working on this time?" to "How's the really huge project we asked Dave to deal with coming? Are we interrupting him with too many other little tasks?"
• Order your tasks so that you generate useable, partial, visible results ofte. This allows other people to get leverage from your work quickly, and makes your manager's life easier. This hurtles headlong into the math-geek work-ordering, which tends to start with "do the hard bits, because we don't know if those are possible, and that's the most important thing to learn before we get into this too deeply." Unfortunately, this behavior gets interpreted by a lot of manager as "Dave just wants to do the fun bits and never does the actual work." So while it will make your teeth itch, gang, when you do your task breakdown, plan to do a bunch of the simple ones in parallel with the hard, thinking about bits. I know this will sometimes mean you run down a rathole building trivial bits of a non-tractable task. You'll be showing progress while you lose, which is vastly better than not-showing progress while you lose more quickly. Your manager will almost never get points for you finding out that a solution is intractable faster than you might have. Check - if that's actually your job, much of this document is not for you.
• When beginning a project, make a list of tasks. Then make a list of questions which must be answered to perform those tasks, including who needs to answer those questions. Note which ones you have already answered. I know it sounds crazy, work with me on this one. Now, in another document, note what those answers are that you already have. Do not spend time trying to determine new answers at this stage - either you have already have the answer, or it should be listed as a "collect somewhow" question. Send a copy to your manager, this makes their life easier, and forward selected portions of the list to each answerer. This gets answering your questions into their task queue. Each one of those "collect answer" questions should be treated as a task. Now begin performing tasks.
• Make daily logs. All ADD people who aren't stupid get parts of many more tasks done every day than anyone else expects. Don't expect to remember what you've been doing, write it down as you work on things so that you can forward it at regular intervals. Its easier for your manager to throw away data (if you've organized it well for them) than it is for them to extract it from you if you can't remember things. BTW, this is one of the skills which makes admins really love a manager - this near-psychic ability to figure out what their staff are actually working on, even though their staff aren't very communicative, which comes from lots of domain experience. They used to be admins themselves, and they're good at interpreting those reticent grunts you give out when you're slogging through a lame nameservice problem for the fourth day in a row, but you're still making progress, so you're not at the "just firebomb the vendor and get it over with" stage.
• If you are hit with inspiration, work on that task until you run out of steam. Take good notes while you're doing so. Then complete a trivial task.
• Do not work on more than one complex task per day, unless you have a) finished a complex task, or b) you are inspired. Don't let a unit-of-time go by without finishing at least one task.
• Try to make your list of tasks contain tasks of comparable amounts of temporal effort. Perform those tasks by strictly alternating trivial tasks and complex tasks within a unit-of-time (day/week/whatever).
• Once per mega-unit-of-time, ask people who you need information from (see the task listing task above) to answer the questions you need them to answer. Getting information from someone is a (not always trivial) task. Do not attempt to get information from more than one person/day - keep trying to get info from different people until someone gives you at least one answer, but stop when you've succeeded with one of them. If other people send you answers, that's gravy, but you don't want to go radio silent because you're spending days on end appearing to block while you're trying to extract information from other people. If someone answers "Go find the information in a named location," that should be construed as an answer for the purposes of this discussion, although it creates a "collect information from a known docuement" task. "I don't know" is not an answer, but changes your list of people to ask. If you get an answer or an "I don't know," write down the answer in your answers list.

Finally, let me reiterate the cardinal rule: Silence is bad. Management cannot differentiate between someone who's gone off the deep end and is over their head, someone who is malingering, someone who's trying to solve an intractable problem, and someone who is making progress on a hard design issue. You'll note that almost all of those options are bad. If you don't tell your manager what you're doing in a way that they can easily communicate to their peers, you're creating a lot of new work for your manager in two ways: first, by creating a need for them to defend you to their peers, and secondly by making it actually difficult for them to do so. Good managers will review and evaluate their own focus and resource allocation continually. Making it easy for them do to so is good for both of you.