Why throwing more people at the problem isn’t always the answer.

Get insights in your inbox

When it comes to driving up development team productivity, solving persistent problems or delivering products faster, adding more people isn’t always the right solution. Often, it only exacerbates the issues – particularly if you’re behind schedule. It’s counter intuitive, perhaps. But it’s also true. Let’s look at why.

First off, as we all know, software development is a complex, interconnected endeavour. It takes time for new team members to get up to speed and become meaningfully productive. Even an experienced developer can take up to four weeks to fully ramp up and understand all the workstreams that have preceded them.

Neither does acquiring the necessary know-how and becoming fully orientated happen in a vacuum. The existing team is likely to have to dedicate time to onboarding people – taking focus away from the job in hand.

If the new people don’t have the right skillsets, the issues increase. They could easily end up (unintentionally) making negative contributions – like introducing bugs – that will take up yet more time to fix. And, of course, introducing new personalities into a team can, at times, disrupt working relationships and impact productivity.

It’s also worth remembering that the bigger the team gets, the harder it is to manage. Lines of communication get stretched, coordinating the ‘right’ work becomes a challenge and oversight harder. This is certainly the case if capability is spread across the world. While today’s post-COVID, remote-first environment has certainly levelled the playing field, time zones and multiple hand off points still have the potential to cause problems.

New call-to-action

Understanding the problem – is productivity really the issue?

It’s a tough thing to do, but sitting back and applying some cool analytical thinking to what’s actually going on, and why, will help determine what the actual problem is. In many cases, this means distinguishing between symptoms and causes to pinpoint what’s actually responsible for the delay.

This process should include evaluating whether a slippage is real – or whether perceptions of progress need to be recalibrated because the original expectation was overly optimistic.

Teams tend to know a lot more after they get started and build momentum, so assessing expectations regularly can avoid negative perceptions.

Similarly, a failure to transparently report on individual deliverables and communicate effectively across organisational boundaries can result in negative perceptions arising around timeframes.

Forecasting a reliable timeframe for a project’s completion and correcting the schedule will go a long way to boosting better and more open collaboration with business sponsors. Ensuring that everyone’s expectations are captured and realistically managed.

Lack of communication can also contribute to misperceptions. There’s often a lot of incremental work getting done. In the press of daily work though, it’s all too easy to forget to keep sponsors and stakeholders appraised. Similarly, articulating the ‘invisible’ work that’s critical to success can be challenging too. And developers may not always be the right people to do it. The value of having a ‘translation layer’ – someone able to explain the process in clear business terms to less technical leaders – should not be underestimated.

Finally, if your dev teams are working flat out but still struggling to get code into production, the issue may be the delivery mechanism itself. Without the right tools and technologies, teams will spend an inordinate amount of time wrestling with inefficient processes and frameworks that inhibit – rather than enable – productivity.

3 ways to bring projects back under control

1. Diagnose the blockers, then break through

The issue could be inefficiencies in the production pipeline or backlogs needing better hygiene. But if you don’t know, throwing more engineering horsepower won’t help. Identify the root causes and bring in specialist support to give your existing teams the skills to address them. That way, you’ll break down the immediate barriers and build higher performing teams for the future.

2. Create new teams, not bigger ones

You may have determined that people with more specific skillsets will speed things up. If so, aim to create new, smaller, discrete teams with clearly defined roles and tasks. Avoid breaking up or adding to existing teams. As mentioned above, this could impact the dynamic and slow things down.

3. Build the right organisational structure, and clear domain boundaries

Check to see if your systems and processes empower your people or create artificial boundaries. With the right structures in place, your teams will be more efficient right off the bat. They’ll be happier too.

By necessity, we’ve taken a rather simplistic view of a complex issue. In some cases, you’ll want to rethink how you’ve implemented processes like CI/CD to unblock production pipelines and clear the pathway for project teams to perform. In other scenarios, you may need a very specialist skillset to solve a particularly niche problem. And that may indeed require additional capability.

Ultimately, however, a teams perceived inability to deliver or the lack of developer productivity are more likely to be symptoms of a wider issue. Get to the root of that first and you may find you won’t have to throw people at the problem…as you’ve sorted it already.

We hope that this blog has raised some salient points for you to think about. Should you wish to discuss any of these in further detail, please get in touch here.