Strata suggested I forward this to you folks as well...

[Richard Threadgill <richardt@midgard.net>]

Giving good report, 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 think
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.

  o 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. 	
	    
  o 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.     

  o 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?' 

  o 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 managers 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.

  o 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
	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 potential 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.

  o 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.
	     
  o 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.

  o 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.

  o 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).

  o 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 document'
	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.

  o 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.
 
Yours in service,
RichardT