One of the first thoughts when you have a change where you have more money than you can currently spend, but less time than you currently need, is often to expand the team.
This can be a big mistake.
If the current team aren’t performing as well as they ought to be, adding more people will seldom fix the problem. Quite a lot of reasons for poor performance by a team of contributors will only be worsened by additional people. I’m most familiar with technology-enabled changes, so let’s take a few examples from that space.
If you’re having trouble getting the build to be stable, adding more developers – and letting them code new code – will not make the build more stable. You’ll get more new code through, perhaps, with a proportion of mistakes – Erasse humanum est (Seneca?). If you aren’t using automated testing (why not?), adding additional testers will increase the complexity of coordination between them, eat up time while they become familiar with the product and test scripts, and differing judgements may well alter the things identified as bugs (often: upwards). More architects do not result in a quicker architecture (quite the reverse). More designers do not result in faster design results. More creatives … well actually, sometimes more creatives really does improve things – and I’ll come back to that in a bit. If your team just isn’t performing with the velocity you expect (whether on Agile or waterfall or some other variation), adding extra people isn’t going to fix anything by itself.
You have to understand the problem you are solving by bringing in extra people. If those people can start work without interrupting those who are already working, be productive entirely independently of the existing people, and deliver product to at least the same quality, extra people can help. So many things we do in technology changes – and in many other spaces – are strongly interdependent, however, that many hands do NOT make light work, and it is rather a case of too many cooks spoil the broth.
Sometimes, the problem of speed is better solved by taking people away.
Now I know there are times when the person everyone wants to take away is the change leader – project manager, programme manager, scrummaster, whatever. If they are serving the team/project/programme/organisation well, they aren’t harassing for pointless updates. Sometimes, the only thing has been to go and get the coffees, teas, doughnuts or whatever, and if that’s all I can do: good enough. Sometimes the thing I do which helps the team to get things done is intercept all the people who are trying to find out when the widget will be finished, and lead them away. That’s definitely a valuable service.
Sometimes, though, it’s not as nice a job as that; because sometimes the right thing to do to allow the team to speed up is to remove someone from the team.
I’ve liked a lot of people I’ve worked with; and not all of them have been good at their job. One of the difficult tasks in Change Leadership is spotting when someone is having a negative impact on the Change you need to bring about, and removing them from the position where they are able to cause a problem.
I had a pair of programmers pair-programming in a series of sprints. One of the programmers was a rock star – not a prima donna – but extremely quick, very accurate, very effective. (He’s also my go-to example for why asking for a number of years of experience is a bad metric of quality – after 9 months of Java programming he was without doubt the finest Java programmer I’ve ever come across. He still is, years later). The programmer he was paired with had, nominally, more experience. He was also Mr Slow. He was not stupid, and I don’t think he was lazy; but he had no drive for programming, and his attention wandered constantly. Adding an extra pair of programmers would have meant slowing down while they got up to speed, and wouldn’t have solved the real problem.
The urgent problem wasn’t even the velocity of the project. I could handle the customers well enough that we were fine with that, as it happened. The real problem was the velocity of the rock star programmer. It was painful to watch him have to shift mental gears to try to keep coaching the other programming, bringing him on board, helping him understand what had been coded, and then letting him have a contribution. It was even MORE painful to watch the frustration and itchy fingers when Mr Slow ‘drove’ the keyboard. I needed to resolve this problem so that I didn’t lose an outstanding programmer for the sake of being merciful to a far less exciting one. Or to prevent a murder.
If you’re kind, you can often find something for the person who isn’t working out to do which is more to their skillset and preferences, and makes better use of them – which, after all, is good for them and good for the company. He made a perfectly acceptable project manager in the end.
If you’re leading a change, and there’s money on the table to help you speed up, think hard about whether extra people will give you what you need, or whether there’s another underlying problem. Remember that just because someone is offering you what they think will help you doesn’t mean you have to take it.