Developer Ownership and Taking Responsibility - The Basics

Many CTOs I meet have the challenge that they need to micromanage developers. Developers always need a push. Developers do the minimal thing but nothing else. There are obvious things that need to be done, but developers don’t do them—they don’t see them. They create bugs and shrug their shoulders. They don’t own things and don’t feel responsible. Perhaps they have a motivation problem.

Responsibilities and Ownership is what engineering managers want. They reduce management overhead and are the basis for scaling. They enable managers to work on the right things instead of the need for micro managing.

What is the difference between Responsibilities and Ownership?

Responsibilities: Things someone is responsible for to do or that they are done or not. More explicit. “Last on turns off the light” is a responsibility.
Ownership is one level up. When you own something, you decide everything about that thing.

How do you make developers take responsibility and ownership?

The first step ist to express your expectations. Without expressing your expectations, no one can fulfill them. Express those expectations in clear words “You own …” and “You are responsible for …”. Do not sugar coat them, wrap them, or use too many words. Start with individual ownership, when you have a great culture of ownership, move to team ownership and responsibilities.

Write those expectations down in role descriptions. A role description has four parts:

Why - why does the role exist?
Responsible - what is the role responsible for?
Ownership - what does the role own?
Success - how success is measured Writing expectations down cuts through the talk and makes it easy for developers to know what is important and what is not. Writing them down helps people who were hired or promoted to be successful.

After writing down role descriptions for everyone (and rolling them out - the hard part!), move on to a vision and a strategy. The vision is the goal that you want to achieve with the team in several years. If the vision can be achieved next year, it’s not ambitious enough. Have a strategy as a plan with steps and milestones on how to reach the vision. A vision and strategy give guidance on what to do and where to move. This makes developers take on responsibilities.

After establishing a vision and a strategy, establish an engineering culture. Do not make the mistake of culture-by-committee. Decide what the culture should look like and roll it out. Put “Responsibility and Ownership” in the culture. Refer to the culture in meetings and decisions, steer people back to the culture to make and keep it relevant. Culture is not a poster on the wall.

Next give up decisions. Move decisions to the people with the best knowledge to make them. Developers will feel ownership and responsibility for things they can decide. If you decide everything and push decisions on developers, they won’t own things. Push decisions to the people who need to do the work. Have a vision, strategy, and culture in place so people make the right decisions.

Positive behavior:

Praise people for what they have done right
Shift from an approval-heavy culture to one that rewards informed decision-making.
Encourage developers to present solutions rather than asking for step-by-step approval
Make it clear who is responsible for what by defining specific areas of ownership within projects - especially for overlapping areas
If possible, let people choose to own what they feel passionate about
Visibility into a developer’s progress and achievements helps reinforce ownership
Reward those who display exemplary ownership and responsibility. Seeing their peers rewarded can be a strong motivator for others
Show ownership yourself, your own behavior is a strong influence on everyone

Sabotaging Ownership

If you feel something isn’t done but should be done, ask “Who is responsible” and “Who owns this?” DON’T fill in for developers, don’t do the things developers don’t do. Find someone who is responsible or who can own the thing. Don’t take on ownership yourself.

Negative behavior:

Go around your leads to talk to developers directly
Make decisions on things other owns
Force decisions on people with which they don’t agree to
Tell people what to do
Claiming credit for other peoples achievements
Shifting blame on people
Setting unrealistic deadlines and expectations
Failing to recognize contributions
Breaking promises necessary to carry out tasks
Undermining autonomy

If something someone owns doesn’t go the way you think it should, be careful. Don’t parachute in. “You should do” … DON’T. Responsibilities and Ownership are a soap bubble. It takes effort to build it—one touch it is done. It takes effort to build a culture of ownership, it takes months to build up. Then something doesn’t go fast enough, and you jump in and take away responsibility for a minor thing. BANG. Developers will no longer feel responsible and your back to the start. Help people along the way to act according to the things they own and are responsible for. Remind them about their ownership and explain how you think it does not work. If you disagree on the way they do things they own, value the solution by itself; how could it solve the problem, not how it matches the imaginative solution in your head.

Change takes time. But with these changes you can create a culture of ownership and taking responsibility in six months. With these changes your job becomes much easier, and you can focus on the important things, instead of micromanaging your department and filling gaps in ownership yourself. s