If you have been in a tech leadership role at any point in your career, chances are at some point you have been faced with the challenge of scaling your tech team. There are various challenges you will likely encounter during the process ranging from assessing the competence of a limited talent pool to misplaced motivations for hiring. Having hired tens of developers throughout my career, I’ve started to think that hiring often leads to more problems than it solves and I’ll always favour a small but mighty team. I follow the progress of lots of solopreneurs so I know exactly what can be achieved with one person doing everything - including everything outside of tech - and with Sam Altman predicting the first billion dollar solo enterprise, you do need to question whether it is still really necessary to have a large tech team.

Why hire?

The first question that not enough teams ask themselves is why are they hiring in the first place? If the answer to that question is to deliver faster then just forgot about it. Software development does not have a direct correlation of input to output. There are times as recently as last week where I’ve spent time on a changeset, only to abandon it and start over. That is perfectly healthy and leads to better solutions, but if the metric we were optimising for was velocity then that would have been committed, built upon and it would probably have become technical debt.

In my experience hiring for faster is usually a red flag to a broken delivery process. If you’re operating continuous delivery then you will likely already be shipping multiple times per day - how much faster do you need?! So, what people really mean when they talk about faster is that they can’t/won’t prioritise their backlog of features and therefore want concurrent workstreams. If you think about the reasons why you might need multiple concurrent workstreams then none of them tell a particularly pretty story - usually you’ve either committed to multiple customer deadlines or you haven’t validated your roadmap with customers and therefore everything is being treated with equal import.

If the former then committing to a deadline was your first problem, as software is unestimable, and chances are you just need some temporary additional resource to get you out of a hole. The latter I’ve seen so many times I’ve lost count. Most of the time it stems from a list of sales objections which have become a backlog, but just because a customer clings to an objection as a reason not to buy it doesn’t mean that they or any of your other customers actually want/need the thing in question. The vast majority of the time customers buy your core proposition and additional features are not pivotal to the buying decision.

So, the question you should be asking before you even begin the process is not “how to build”, and it definitely isn’t “how quickly to build”, but instead it should always start with “what to build”. Once you’ve got to the bottom of that question and aligned it all strategically with go to market, and you still feel you have a tech resource deficiency then it might be time to add to the team 😊

Diminishing returns

The first thing to note is you’re probably going to see diminishing returns after each additional hire. Even if subsequent hires are more competent than the first tech hire. Sometimes in that scenario the diminishing returns are more pronounced as they’re having to get to grips with technical debt, spelunking their way through an uncharted codebase where every decision has been made in isolation. For several months there’ll be lots of chat about how/why/where as your new hire tries to get up to speed. All of that takes time away from your existing resource in the short term - yet another reason why hiring rarely leaders to faster.

Then, chances are that once they are up to speed they will start to identify technical debt that needs to be addressed, better ways of tackling certain problems, different ways of working - all of which is positive and beneficial in the longer term but those issues aren’t necessarily the issues you wanted to prioritise when making the hire. Those diminishing returns tend to continue with each further hire as the communication overhead becomes ever greater, more forward planning is needed to keep the whole team busy and informed - and that’s assuming you can find and attract the talent in the first place.

Some of the biggest businesses in the world, such as Amazon, have long since identified that anything bigger than a Two-Pizza Team is too large to be productive - and given the appetites of most of the teams I’ve worked in that’s probably a maximum team size of 4! Typically each of those teams will be working in isolation of each other with a single-threaded focus. That isolation is usually achieved through a microservices architecture where teams don’t have direct dependencies on each other, so when you get to scaling past your two-pizza team you may well need to think about whether your architecture will support multiple teams working concurrently, if you have a non-modular monolith then this could be a significant challenge. What tends to happen in those organisations instead is that teams start dividing by discipline but this presents its own set of problems. If, for example, front-end developers aren’t working on the same problems as back-end developers then you may start to see problems being dealt with inefficiently as each team stays within its lane. Got a really slow API endpoint? Cache it in Redux rather than simply improve the endpoint performance!

Busy work

So, you’ve hired your additional developer(s), you’re willing to accept the diminishing returns and now the real challenge comes - what are they going to work on? If everybody on the team is mobbing on the same issue that is one thing, and in my mind that is the optimal way to work, but given most of the time the motivations for hiring are to scale output what tends to happen is that multiple workstreams are created. So, you end up with Person A working on one thing, Person B working on another and Person C now having to plan/design/manage both workstreams. Person C cannot necessarily scale their output and they’re already focused on the thing Person A is working on. So what is Person B doing? Invariably, busy work as one thing that no company likes is expensive development resource sitting on the sidelines. Fix this small bug, pick up this item that’s been on the backlog for 6 months, change the text on this button - we’ve all seen it. Lots of small backlog items bubbling to the surface while the real priorities get all of the attention. Pretty demotivating for the person doing the work, a knowledge silo created over at Person A and dysfunction begins to set in.

Don’t worry though, Person B will get up to speed with what Person A is doing via an asynchronous code review, right? They don’t have any context as to what the feature is doing but they’ve statically analysed the code so what can go wrong? Plus Person B will eventually be busy on their own priority feature and the delivery timescales will line up perfectly after that so by the time Person A is ready for the next priority there’ll be no need for further busy work. Let’s be honest, it just doesn’t happen in reality and the whole process leads to fairly poor DX, a disappointing output for the business and unnecessary additional complexity in both the product and the process.

I would even go so far as to say that having multiple concurrent workstreams can lead to a worse product. Every time you deliver new value to a product it needs time for customers to discover it, interact with it and feedback on it. The more you deliver concurrently, the less like that is to happen. The more forward planning you have to do on your product, the lower your agility to react to anything being returned by the feedback loop. The problems aren’t just product related either - if you’re adding value to your product, it should lead to commercial value for the business, otherwise why build it? Having a multi-threaded focus will make it harder to communicate your product’s merits to prospective customers as well as current ones, meaning you can end up building features that people never even hear about!

Final thoughts

So, the next time you think about hiring developers make sure you think about the whole picture.

• Why are we hiring?
• What will they build?
• Can the system architecture support extra people?
• Am I hiring for the medium to long term rather than the short term?
• Can supporting functions in the business handle the extra throughput?
• Will those extra features I seek make us more money?

And the most important question of all - do I need to scale the team or do I just need to prioritise better? I’d love to hear any other perspectives on this. Have you successfully scaled your tech teams and not encountered any of the above issues? Drop me a message as I’d love to know what I’m missing. Thanks for reading!