Growing a software development team

For the last few years I’ve been working at a software startup we founded in 2012. During that time we’ve had periods of financial feast as well as financial famine. During the feast periods there is a pressure to recruit more developers, during the famine a pressure to halt all recruitment. This set me to musing on my approach to growing a software development team.

Why grow?

Before embarking on the time consuming path of growing a software development team it is worth reflecting on why you want to do so. There are a number of disadvantages to larger teams:

large teams are less efficient in terms of feature development per developer. There is an increased communications overhead. A team of six can just agree what to do over an impromptu coffee, a team of six hundred needs more organising.
as a consequence of the increased organisation in large teams, individuals have less freedom. Whilst many appreciate being told what to do next, the sort of person who thrives in a small informal team is unlikely to enjoy the reduced autonomy. That lack of enjoyment will result in less passion for, and involvement with, the work.

But even if you keep the team size small, efficiency will reduce as time passes. As the code base grows so there are more inter-dependencies which need to be considered, more consequences to a simple change. If commercial success has required commitments to supporting older versions of the product then those too will require effort, reducing the efficiency of new development.

What sort of developer?

There is often pressure to lower the quality threshold when looking for developers, particularly in an environment with a formal head count requisition approach to recruitment: if you don’t take this person today, the requisition may be revoked and you get no one.

This is counter-productive. There is extensive research ¹ that shows that the productivity of a good developer far exceeds that of an average one. But we know that increasing head count creates barriers to communication and an environment that’s not interesting for good developers to work in so they leave. Fred Brooks ² wrote:

The conclusion is simple: if a 200-man project has 25 managers who are the most competent and experienced programmers, fire the 175 troops and put the managers back to programming.

In addition to developer quality there is a decision to be made as to the experience level required. Recent graduates command a lower salary than more experienced staff and can be targeted at university career fairs. They will take longer to become productive than some one with domain knowledge.

Approaches to growth

There are two approaches to acquiring individual developers: recruit them one by one or go out and acquire an existing development team.

Piecemeal

Recruiting on an individual basis is an expensive business, both in time and money. Expensive in money as almost all candidates come through recruitment agencies who typically charge 25% of the first year’s salary. Additionally there will be adverts and career fairs to pay for.

Expensive in time as typically you get swamped with inappropriate CVs to sift through. This can be mitigated to some extent, in exchange for money, by outsourcing the recruitment process, a contractor then performs the initial review of CVs handing on the most appropriate. Then there are the interviews; typically we conduct a video interview to check for general suitability and interest, then get the candidate to come in for an afternoon’s grilling.

The advantage of this approach is that you can attempt to assess how well the candidate will fit in to the existing team, looking for matches beyond a purely technical fit.

Because of the time involved in sifting CVs, interviewing and then ultimately assimilating someone into the development team there is a natural limit to the growth rate through this approach; it is probably no more than about 30% increase in headcount per year, often less.

Acquisition

Unlike piecemeal growth, growing through acquisition bypasses the rate limits, growth is now constrained only by the size of your bank balance. But there are significant drawbacks.

The main rate limits for piecemeal growth were finding good developers and integrating them in to the team. In an acquisition you are forfeiting control over both of those tasks. On acquiring a company you don’t get to pick and choose the developers. Instead you have to hope that the acquired company has had a similarly picky approach to recruitment.

The problem of integration is very significant; an existing group of developers will have their own culture and process. In an ideal world you can take the best bits from the acquired company and both sides benefit, but it is rarely like that. If the acquired company can be co-located with the existing one it may be possible to combine cultures but this becomes significantly harder if multiple locations are involved.

I’ve been acquired three times and been close to three other acquisitions. One was an outstanding success, one an abject failure whilst the others produced product and made money but never really integrated. That is not an encouraging track record.

Don’t go backwards

Whilst trying to grow, it is important not to be losing any of your hard won developers. A lot of retention is down to the culture of the team; if people are working with others that they respect and get on with then they’re less likely to go looking elsewhere. Environment is important too — if you can’t get the tools you feel that you need to do your job then frustration will rise and job searches ensue. But that is a whole other conversation.

Footnotes:

See for example: Boehm “Software Engineering Economics”, ISBN:0-138-22122-7, 1981. For a less academic approach, have a read of Paul Graham’s “Great hackers” essay: http://www.paulgraham.com/gh.html

Brooks, “The Mythical Man Month”, ISBN 0-201-00650-2, p.30, 1982