14 lessons for helping people make good software
By: Emile Silvis
Tags: Scrum, Software Engineering, Software Development, Agile

I’ve spent the last year as a software engineering manager for teams building a new product. Our tribe (the group of teams) is part of a larger organisation. Here are 14 things I learned:

As an engineering manager, you have only one goal: create a space where people can make good software, all the time. Everything else you do should be subservient to this goal. Everything that doesn’t contribute to this goal is a distraction. As one of the principles of the Agile Manifesto puts it: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done” (thanks for the reference Tim.) Your tribe’s attention is valuable, and you should actively protect it. A simple way to do this is to treat any outside request for work in the same way as you treat all your other work (for example, as a story on a board, in a sprint). This might be difficult, especially if the request comes from a screaming customer or boss. But being consistent will pay off. It forces your tribe to prioritise the work against their existing workload (or even better: to say no if it’s not important). This role is all about pragmatism. Humans are abstract thinkers, and we profited from this evolutionary. But it also leads to a tendency to optimise things prematurely, resulting in lots of wasted time. A good litmus test: will this affect the tribe’s ability to do their day-to-day work in the next four weeks? If the answer is “no”, it’s probably not a problem. You should also encourage your tribe to adopt this mindset. Pragmatism should become a value. A group of people making software is a system full of balancing feedback loops. This system is in equilibrium, and will attempt to maintain it. When you try to change a part of the system, it will push back. The most effective way I’ve found to change a system is to add or remove feedback loops. Here are some examples: • Splitting a team and having them sit at two different physical locations. This removes a feedback loop that was detrimental to focus. • Agreeing that all teams will do a sprint review together. This adds a feedback loop that prevents teams from working in silos. Accept the fact that the market which you hope to sell your software to is in constant flux. Also accept the fact that people are not robots that can churn out software without rest or reason. These two facts are in tension with each other. You have to find a balance between agility and sustainable software development. It can’t be one or the other, it has to be both. Forget your lofty ideals about fairness or transparency. You will have to work with people who are neither fair nor transparent. I’m not advocating tolerating toxic behaviour — if it hurts you, then you should leave. But at this level, a large part of the role is dealing with “difficult personalities”. Don’t worry about having a “good culture” — culture is a side effect of more concrete things. How you treat people. What you tolerate and what you don’t. How good a role model you are. If you focus on the small things, you will have a good culture. Being able to make decisions (even wrong ones) is more effective than following a process. To be able to make decisions on the spot is what it means to be agile. This is what ‘psychological safety’ boils down to: make it possible for people to make decisions. Be explicit about the internal quality of your software. Internal quality is invisible to users using your product, but it makes developers slower when it’s bad and faster when it’s good. Our current practices for making software do not emphasise internal quality per se. For example, Scrum puts a lot of infrastructure in place to deal with the “what” (product owners, backlogs, review) but nothing for the “how”. We should treat and mange internal quality like a first-class citizen. People have different levels of competence and confidence — this should determine how you deal with them. There’s no such thing as one-size-fits-all management. Make all the work visible. Everything you need to do to get working software into customers’ hands. Especially focus on the early stuff that’s usually kept invisible (like discovery and refinement). Trust your gut and fight for what you believe in. You’ll regret not fighting for your convictions later on. Don’t underestimate the value of relationships. Allow people to socialise with others, especially outside their usual boundaries. Making software is a social activity. Sleep matters. Make sure you get enough of it.