Without a captain

…or how to make clear progress without getting marooned

Trouble ahead

The signs can be all too clear:

• different teams working on the same projects
• multiple standards (or none at all)
• kludgy solutions to everyday tasks
• problems that are slow to resolve and keep re-occurring

The first thing to bear in mind is to remember that people aren’t generally malicious — they aren’t trying to solve problems slowly, just busy, or prioritising the wrong problem.

If multiple teams are working on the same area, it goes without saying that they should be working together, not independently. In this way knowledge is shared, time saved — which can be spent turning kludgy solutions into beautiful ones, tackling core problems and solving them for multiple teams.

Why bother solving problems for other teams use cases rather than just your own? The chances are that you will hit the same problems — just maybe next week rather than this week. Solving the problems for both teams now builds co-operation and saves time. Additionally working with the other team can often produce a better, more general and elegant solution.

Whilst in a perfect world all teams would be in perfect harmony, standards set in stone and flawless, most of the time this utopia is quite some distance away.

The key I believe that sets the course towards nirvana is ownership.

Ownership

Ownership (noun): an attitude of accepting responsibility for something and taking control of how it develops.

When a group or person is given ownership of something (a project, naming standards, security, infrastructure component, a team) this should not be just an honorific title.

I believe that it’s better to have an individual owner rather than a group — not only is this more inspiring than being part of what could be called a “committee”, it also avoids deadlocks when opinions differ. The owner should absolutely involve other people as this will help build a rounded solution and fosters good relationships.

Owners must be able to make changes and others should respect the decisions — even if they disagree. As people aren’t perfect some decisions will be wrong — and that’s okay. What we are looking for here is not perfection but an iterative process where over time we improve the area in question. Sometimes mistakes will be made, other times an experiment will show the way forward.

There isn’t anything to prevent a hierarchy — e.g CTO delegating responsibility to different owners and those being further subdivided. This also allows a natural way to “override” a decision if it’s particularly problematic. I’d argue that overriding is best avoided unless absolutely critical. Normally it’s an opportunity to improve that owner’s understanding of other aspects — or perhaps of a critical mistake they are about to make (for example “if you migrate the database like that then it will cause a 30min outage on the website”). If it’s not a critical mistake, it can be best to let people learn through experience - even if this causes some minor problems.

An owner shouldn’t adopt an arrogant approach with others. This is especially important given the likelihood that currently the situation is a bit of a mess. Instead, nudge people towards it — “here’s our new, common approach — it’s not perfect yet, but it’s better than what we had, we are here if you have any problems”. A carrot rather than a stick.

Responsibilities

Standards are key to efficiency in many walks of life, no more so than in computing. Ever had a program fail due to the wrong alphabetical case in a configuration file? Consistency can eliminate not just these failures, but save you needing to check each one. Automation also benefits when names can be worked out programatically rather than hand-coding each instance (and amending for each new project).

One of the core responsibilities of an owner is to communicate with others. I’m a huge fan of wiki’s — easily searchable and more importantly easily updatable (by anyone) — they can rapidly become an indispensable source of knowledge.

The wiki should have information about the area of ownership and who owns it. Standards and guidance should be easily found (you should be able to point people to a document/git repo with all the information they need). This isn’t to say you shouldn’t walk people through face-to-face, far from it, but that users should find a useful reference at least online — whenever they need it.

A roadmap is immensely useful as this shows people what to expect (and can answer questions such as “why aren’t we doing …” as it can show the required work). I find a changelog very beneficial in showing not just how much progress has been made, but the historical reasons why the situation now is as it is.

If appropriate, code repositories and issue trackers should be referenced — this way people can find existing problems and even fix them to the benefit of all.

Summary

• Find areas that are floundering and need ownership to provide focus and direction
• Assign an owner — ideally this will be a volunteer who wants to push things forward (help them to fix their frustration)
• Ensure that they feel empowered — if they are being ignored, find out why

Owners should:

• Set documented standards — preferably roadmaps, changelogs as well
• Be the authoritative source of information (they don’t have to be the expert — just know who the experts are in the various fields)
• Track problems and fix them
• Plan for the future, handle improvement requests
• Create an atmosphere where people are confident that this area is well managed and under control