(DISCLAIMER: I’m not presenting original ideas here. I apologize for any missing attributions and welcome any/all suggestions to appropriately attribute any ideas)
Do you want to maximize productivity of your software development team? Most people* would say yes, if they have anything to do with a software development team. If you say yes, another question to ask is “can I increase my team productivity more by 1) adding more programmers or 2) by improving training, tools, facilities, work environment, face-to-face time, development lifecycle process, and other intrinsic motivators.” If your organization’s instinct is to respond with 1) then you are falling into the headcount fallacy.
To give an example, say you have a distributed team of 8 people working on a software product. If their mean salary is $100,000, that means you have a budget of $800,000. Assume your company spends $10,000 per team member per year on equipment, training, travel for team building and offsite work sessions, etc. Say your business wants to increase its rate of feature development by, say, 20%.
Plan A would be to hire four more team members for a team size of 12. This would increase the annual budget by $440,000. With a team of 12, and no other changes, a 20% increase might be possible†, especially if your company hasn’t succumbed to the headcount fallacy to get where it is today.
Plan B would be to hire 2 more team members for a team size of 10, but use the extra $220,000 each year (increasing budget to $32,000/mo each) for better equipment, training, vacations, some face-to-face offsite meetings, etc. Unless your team already has the best equipment, training, and productivity enhancing accouterments already, this would almost certainly have a bigger than 20% increase impact on productivity. Certainly it would improve team performance more than adding 4 more folks who are immediately stretched to the limit.
The above scenario is oversimplified to make a point (we are ignoring full costs of employing people, for example), but if you consider costs of turnover in your staff, the scale tips much more towards Plan B, since you are lowering your risk of losing hard-to-replace staff (both their skills and tribal knowledge).
For ideas on how to spend extra dollars on team productivity instead of headcount for a development team, I suggest reading Dan Pink’s book Drive‡. It shows the motivators for information workers. For other teams the ways to increase productivity and reduce turnover will probably be different but the same headcount fallacy applies to all kinds of work.
* I have had discussions with managers in the past where they did not agree with this goal. Instead, their focus was on individual productivity. If that’s the case for you, then skip the rest of this post :)
No comments:
Post a Comment