Monthly Archives: April 2007

Where the Real Power Is

I am a manager for a team of developers. One might think that they work for me and I have power over them. I have a boss and so on. But if the real goal is to deliver the product or service of the organization, then the real power is with the people who do the work.

I learned from my father that the real power in an organization is the organization chart turned upside down, at least as far as “power” means actually producing something. It seems obvious when one thinks about it: boxes (people) on the organization chart connected to lots of other boxes are too busy maintaining those connections to do anything else.

So a rational organization rewards maangers that enable their direct reports to do their job better. In other words, my job as a manager is to serve my developers.

I serve them by making sure their computers work and that their chairs are comfortable and that they have the text editor they like and that they get lunch if I ask them to work through the day.

I serve them by making sure they understand their goals and restrictions and priorities. I serve them by removing obstacles from their way. I serve them by keeping my bosses away; my job is to answer their questions and make sure the rest of the company knows what we are doing.

Tech managers do not have to motivate or control staff. Developers want to work, and they want to deliver, and they love seeing their work in use. Managers need to get them on stage in front of the right audience and let them shine.

It Works On MY Machine

Joel’s 12-Point list, points 2 and 3 talk about building the application cleanly and regularly. He is talking about building it on a build machine. I emphasis this because, as a manager, I have to gently remind my happy minions that “it works on my machine” is more of a problem than an explanation.

If the coder is working on several different projects, they might find that some library for project A has a namespace collision with a library B. VMWare or the like is often a good solution: each project has their own environment. As the software is running on the same “machine”, installing it into each virtual environment seems like an ethical choice.

More likely, the coder has to solve the problem by making their development machine as stark and drear as the build machine, which inspires one to ask: Why did the coder tart up their machine? Most likely, the developer updated their libraries, either to the most recent version (so the build machine needs and update) or to a beta version (so the developer needs to Not Do That Anymore).

  • Plan and confirm updates to software and libraries across the whole development team, and don’t forget the build machines and the occasional coders (e.g. managers).
  • Name and version your internal libraries like you were selling and supporting them, because you will do the latter no matter what.
  • Embed as much application and library version information into your application’s bug reporting protocol (you do have one, right?) as you can.

Decoding Bug Reports

Defect Status Translations

What They Say What They Mean
Can Not Reproduce You’re an idiot
Duplicate You’re a lazy idiot
Reopened Dev testing is something that happens to other people, right?
As Designed You don’t understand the product
Test Case Error You don’t understand how to use the product
Redesign You have no human friends, do you?
Deferred It’s a stupid idea

Other Terminology

What They Say What They Mean
Thank you for your input Go Away
What I hear you saying is…. What I want you to say is…
No work on your part I’ve already committed you
I have tables and charts to back me up The truth is depressing
No more layoffs Attrition
We have full confidence in your judgement We haven’t found a replacement for you yet
Go as far as you can with this We have found a replacement for you
We’re all on board waaaay behind you
Can you live with this schedule? You do not have a choice either
I want to be fair We’re all screwed