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:

• You own the metric for measuring their success. If the resources are people, you evaluate their performance. And not just that, you decide how to evaluate their performance. If Human Resources decides, for example, that attendance in the office during certain hours is how someone earns a bonus, you are not managing those people. And if the resources are systems, you decide whether those systems are worthwhile. If your Information Technology department chooses systems for developers based on “corporate standards,” you are not managing those systems.


• You direct the activities of the resources. In biblical terms, “You stay to one man, ‘come,’ and he cometh. You say to another, ‘go,’ and he goeth.” Of course, you may choose more indirect ways of directing activities, such as changing metrics for success, mentoring, or delegating. But if you’re managing development, you must have authority over the resources needed to develop software. And that means directing those resources.

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)  ¶ 3:25 PM