(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, November 24, 2006
  What is managing software development?

Here’s a very simple question: What does it mean to manage software development?

This question is important, because many times different people have very different answers. And if one of them is accountable to the other, there is bound to be trouble.

In this brief essay, I will give my own personal definition. It is certainly not a universal definition, and I’m not suggesting it is necessary to agree with this definition to be successful in your career or on your project. However, I suggest that thinking about the answer to this question and being in agreement with everyone else on your team and in your organisation will help you succeed.

The fundamental definition: “Management” is accountability for results, authority over resources, and making decisions based on judgement.

Accountability for Results

You are accountable for something (even if you’re working alone on a personal project, you’re holding yourself accountable). Now, what are you accountable for?

If you’re accountable for adhering to a specific process or plan or following directions, you are not managing. You’re administering. With any luck the plan is in writing. This is true even if you wrote the plan yourself. Ask yourself this simple question: is your job following the plan or developing software?

If you are managing software development, you must be accountable for the results of the development: you must be accountable for the software itself. Good management is based on measurement: being able to measure success in an objective way. You might now ‘own’ the metric for success: someone else might declare that success is hitting a certain date, meeting certain requirements, or even shipping with a certain feature list. But whatever the metric is, if you are accountable for results, you must understand and endorse the metric.

If you don’t understand the metric for success, you’re guessing, not managing. And if you don’t endorse it, you’re subverting, not managing.

Authority over Resources

Everyone has resources. For a programmer, resources are a development system, a compiler, an editor, and so forth. For a team leader, resources include other developers. Now, do you or don’t you have authority over those resources? If someone else tells them what to do, if they come and go at someone else’s discretion, if someone else dictates what you’ll use and how you’ll use it, you don’t have authority over your resources and you aren’t managing.

Authority over resources means:

Making Decisions

You must have the freedom to “trim in flight:” if you wrote a plan, you must have the freedom to change the plan. If you don’t have the personal confidence and approval of your organisation to make decisions during the life of the project, you are not managing the project.

Accountability and authority are necessary but not sufficient conditions for management. You must employ your authority to achieve results by making decisions.

Furthermore, your decisions must be based on judgement. Many people use the word “decision” to describe the act of articulating the course of action for a team. Lots of people with the word “manager” in their title tell their reports what to do. But they aren’t making decisions if they are told what to say by their manager, or by the plan, or even by an essay they read on the Internet.

A decision is when there are two or more options, each of which has some merit, and you choose the option to pursue based on your own judgement.

A final thought: Courage

Finally, I want to emphasise the element of courage. If one course of action is obviously superior to all the others, articulate things and move on. But the act of management occurs when you have two or more meritorious options in front of you. It is especially difficult when the stakes are high and your decision could lead to success or disaster. That is when you are managing: when you exercise your courage.

There you are: you are being held accountable for results. So if your decision leads to poor results, you’ll take the blame without whining that you “followed the plan.” You have the authority to carry out your decision: you cannot later complain that “you had the right idea, but the team failed to follow through.” And you had several reasonable options, so you know that hindsight will reveal other options available to you.

But you have the courage, and you manage: you accept responsibility, you exercise authority, and you make a decision. That’s management.

(This originally appeared on my web site in 2002)

Comments on “What is managing software development?:
Nice. And bang-on. And one of the conundrums I have seen with "self managed teams." They want to "manage" themselves, without stepping up to the accountability & etc.
Better yet, try managing globally distributed development teams. I have guys in India and the Ukraine. Sure you can build a plan, sure you can assign tasks. But when in weekly review, I try to figure out what they've been doing and how far we've progressed, I feel like they are nodding their heads no, while telling me yes. Then who gets chewed when delivery is overdue? Me thats who. Very frustrating. How do you hold those guys accountable???

<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /