How many developers do I need? Such a question is one that many leaders are asking, particularly with macroeconomic challenges creating pressure on budgets. However, determining the right size of your technology team isn’t straightforward. Even if instinct tells you that expanding — or downsizing — is the correct approach, it’s important to dive deeper into the role that development work is playing inside your organization and how it interacts and supports other teams and value streams.
Doing this will help you to gain confidence that not only are your technology teams oriented towards organizational goals, but also that they are well-equipped and supported to work effectively. To get to this point, it’s important to ask the right questions that address technology impact and engineering effectiveness. Sometimes that requires us to completely rethink the questions we want to ask; at other times, those questions just need qualification and clarification. In any case, what matters is that they help you to better align developer activity with organizational goals.
Question #1: Do we have enough developers?
Asking whether you have enough developers is a question many organizations are likely to have asked at some point in the last decade — especially those that have undergone significant digital transformation. Although it’s an understandable anxiety, it’s the wrong place to begin an investigation or discussion. This is because it immediately frames the problem in terms of numbers. In turn, this could lead to unnecessary hiring decisions. This not only has serious financial implications, it can also disrupt existing organizational effectiveness. As Josh Bersin notes in the article we’ve linked to, when you hire new people they inevitably need to be trained and onboarded. Even the most productive and effective teams need to make adjustments and shifts to integrate new team members in ways which undermine their effectiveness.
Instead of asking if you have enough developers, you will find more productive results if you reframe the problem. Ask, for example:
Are current development teams meeting the desired business outcome effectively?
To be more effective, are there additional levers that can help us improve these metrics, without adding additional developers?
These levers are anything that helps development teams do more with less. One option is to focus on improving the efficiency of development processes. Are there, for example, alternative ways of working that could ensure that decisions can be made at a faster cadence? Could you reshape team structures to ensure that information is more effectively cascaded to teams, giving them the context and focus they need? Another option is tooling. An internal developer platform, for instance, can eliminate repetitive and non-value adding tasks.
Question #2: Are we paying more than we need to for our development efforts?
Leadership teams should always pay close attention to ROI — that’s their responsibility. However, it’s important that concerns about ROI don’t lapse into unhelpful discussions about whether people are simply being paid too much. Technical talent — especially senior technical talent — is scarce. Churn can be costly; layoffs won’t fix this problem for you. A culture of distrust will only push talented people elsewhere, compounding the issues that you were trying to solve.
So, what’s really being asked here? It might be helpful here to take the issue of cost out of the equation for a moment and instead focus on the question of speed of delivery and waste. With that in mind, consider reframing the initial question in two different ways:
Where is waste happening across our software engineering processes and operations? How could that waste be reduced?
Are development teams empowered to add value autonomously and prioritize their own work?
As above, considering existing processes and systems is a useful starting point. While this can be done in a top-down way, there are also benefits to starting from the experience of developers themselves. You might find that many are fighting against operational complexity or a lack of clarity around the vision and intent behind a piece of work. If those sorts of issues appear, it’s essential that leadership teams work with developers to restore autonomy and to empower them to go and solve problems on their own, rather than await edicts from a centralized management function.
Question #3: Why isn’t the software our developers are creating delivering the outcome we wanted to see?
Even in the most agile organization, building and delivering software can take time. When it doesn’t appear to have the intended or expected impact, it can be disheartening. When this happens it’s important to refrain from the impulse to blame those closest to the product. This is because the reasons for failure are always multifaceted and complex. There are often multiple causes or explanations, ranging from strategic alignment to internal communication.
With this in mind, it’s important to dig deeper. Ask questions like:
To what extent did we focus the needs of users?
How well did we understand those needs and could we have done anything differently?
If we believe it does address those needs, are we communicating its benefits effectively? Have we given the right level of attention to onboarding and adoption?
These questions acknowledge that development work is situated in an intricate — and dynamic — web of organizational practices and external user needs that all contribute and shape the success of a given initiative. With this in mind, it’s important to pay attention to the supporting functions and roles that surround development teams. Explore what can be done to ensure that those involved in initiatives are able to work in ways that are both truly collaborative and iterative.
Question #4: Can we wind down or repurpose the number of developers maintaining some of our internal and legacy software capabilities?
Often, only a small part of the development work that happens inside an organization is focused on new (“greenfield”) and customer-facing software. Much more is taken up by things like managing the technical debt of existing systems or supporting internal software. This can be a blind spot when it comes to right-sizing your technology team — it is all too easy to focus on outputs where value-add is particularly visible.
It’s important, then, to attend to the hidden value of different types of development work. However, this certainly doesn’t mean that work here needs to be ring-fenced — asking how this work can be done more effectively (again, how teams can do more with less) is just as relevant here as it is in more product-oriented development projects.
In other words, ask questions like:
How could our internal software drive more value for the organization?
Could it make us more collaborative or help us make better decisions?
How could we evolve legacy software to make it easier to maintain? Does it contain value we’ve failed to unlock?
The shift that you are making in asking these sorts of questions is one where you are neither simply dismissing the importance of maintenance-related work or treating it as something inevitable or untouchable.
There are always other ways of doing things. Internal software is a necessary part of every company’s day-to-day functioning, but it’s a product problem not unlike the ones you’re trying to address for external users. Similarly, technical debt needs to be paid but you can be thoughtful in how you want to go about it.
Question #5: Why is the value of our software falling?
Software’s value typically coincides with the attention it has been given. If you notice that it’s starting to decline, focusing on attention — both the quantity and quality of it — is a good place to start to put things right. That’s not to say that you shouldn’t ask why the value of your software is falling; it’s just that that particular question is implicitly focusing on explanation rather than solutions.
Instead, you need to reframe the question in a way that helps you better understand gaps in attention:
How have user needs changed? Has the market changed? If it has, why haven’t we been able to recognise this? What can we do differently?
How can we improve feedback loops between customers, product and design and software development?
Is this an issue we can solve with tactical moves or does it require a broader strategic shift?
Not only do questions like these allow you to attack the problem in a more comprehensive manner, they’re also oriented towards fixes. Ultimately, if you want to ensure your developers are effective, you also need to be effective in identifying and solving strategic challenges — that gives technologists a foundation from which they can be confident they are adding value.
Ask new questions to find better solutions
There’s no simple solution to the question of right-sizing technology teams. But that doesn’t mean it cannot be answered. By engaging with the challenges your technology teams face and carefully considering how they’re aligned with organizational goals, you can help to ensure that you’re getting the most from your developers.
Doing this starts with the questions you ask — and how effective they are at uncovering solutions that improve developer effectiveness. When done well, you can be confident that you have not only the right size but also the right shape technology workforce in place to deliver consistent results.
