The Goldilocks approach to managing software developers

This is a guest post from Jamie McHale, a freelance business consultant, developer, and good friend. Jamie runs Telaco and is the organiser and host of the EdinburghJS meetup.

Managing a team of software developers can be hard. The success of your business depends on developers’ output, but it can be difficult to understand the technical pressures they are under and how well they are performing. You want to get the best out of your team but are unsure how to do it. Some people try to solve this by digging into technical details and taking a hands-on approach. Others prefer to set the product specifications, let the developers manage their own work, and hope for the best. There are risks to both of these approaches that could mean you are blind-sided by poor implementation of your product vision. Let's take a look at why approaches at either end of the spectrum might fail and how you can find a "Goldilocks approach" that works just right.

When you want to dig in

When working with a team of developers, it is very tempting to try to understand all the technical details of what they are working on. You assume that the more you know, the better! You can help your team make decisions! You feel you are in control!

But is this involvement helping or hindering your team? Are they spending their time working on software problems, or are they spending it explaining details to you?

There are a few risks here:

• You lose sight of the "big picture"” getting lost in the details

• You start making technical decisions for the team with incomplete or incorrect understanding. Your team might be "dumbing down" for you, but you don't realise it.

• You focus too much on technical performance for its own sake

• Offhand comments about your preference for a particular technology choice or approach might seem like concrete decisions to your team, particularly if you are "the boss."

• You will undermine expertise, potentially damaging morale

To avoid falling into these traps, there are two questions you can ask of your management process: 1) what benefits is this producing for the end-user of the product, and 2) does this help us build in response to change faster and more accurately? This is because without user insight, there is no point in what you are building, and without a process to build, you will be unable to respond to changes, including an improved understanding of what your users want. After you speak with developers, figure out how much time you spent talking in the context of these two questions and how much time was in the nitty-gritty details of the code.

The code should serve the company. The company should not serve the code.

You should ensure that technical decisions are documented with reasoning and that items added to the backlog are well-detailed. It can be as simple as: "We are building this to help the users do X" or "We are changing this to make our build process faster." You should prioritise with input from the development team. If you can't explain the reasoning, you shouldn't be making the decision. Set the terms, and let the experts decide.

When you go hands-off

If you don't have a technical background, it's easy to be overwhelmed with detail. Software developers are speaking a foreign language. Many people go hands-off, presenting product specifications and insisting, "Just build this," usually paired with "and tell me exactly how long it will take you." You might even tell yourself that you are empowering your team to just get on with it.

The risk of this approach is:

• You might not understand technical limitations that may come back to bite you. For example, the software might be slow due to a particular technology choice. Speed wasn't added to the specification; it's only when you realise it's too slow that it becomes an issue.

• You don't understand the "size" of the changes you are requesting, how complicated they are, and how they might impact delivery timelines.

• You might miss where the developers have a different understanding of how the product or business process should work than what you have.

So how to avoid this?  

Firstly, learn the basics. Understand the "parts" of the system, but don't get bogged down in the detail of how each bit works.

Second, focus on the user perspective, not just on how things look, but on how things work. This should include performance criteria like speed, accessibility, and what the most-used parts of the software might be.

Third, understand how your team is modelling the real-life problem you are trying to solve, and ensure that the model is consistent with your vision and understanding of how things work. You should create a shared framework of understanding, the naming of parts of the system with your team, and how data flows between processes.

Without a shared understanding of the software model and how that corresponds to reality, you will end up working at odds with your team and likely also with your customer.

In Conclusion

Effectively managing a team of software developers can be a daunting task. Striking the right balance between a hands-on and hands-off approach is difficult. Get the balance wrong, and your development efforts will become unsustainable.

The "Goldilocks approach" recognises the risks at each end of the spectrum and tries to mitigate them. This approach involves understanding the technologies in play without being consumed by their intricacies. By focusing on the user's perspective and understanding how your team is modelling the problem, you can maintain a meaningful dialogue with the team, with the customer, and with the reality of the problems you are trying to solve. Creating a shared language around the system's components facilitates better communication and mutual understanding.

Are we building to solve a problem, or are we building for the sake of building? Ultimately, only a balanced team gives the right answer to the question.