Staff turnover vs career portfolios

The May/June 2020 issue of IEEE Software has Darja Šmite and colleagues writing about the problem of staff turnover in software development projects, particularly when employing offshore firms based in developing countries. Šmite and colleagues write from the point of view of companies who’d like developers to stay on board for many years so as to avoid the cost of recruiting and training new developers. Yet the idea of occupying the same role for years on end seems to conflict with trendy modern advice that we’ll have multiple careers over a lifetime—Šmite and colleagues even suggest that companies take specific action to screen out “job-hoppers” when recruiting—not to mention employer demands in other contexts for “flexible” workforces that can be grown and shrunk as necessary.

Šmite and colleagues give some figures for the unproductivity of new team members that I find extraordinary. One of the organisations that they studied reported that offshore developers were unproductive for 52% of the time over a five-year period; even in the fifth year of the project the developers were spending 25% of their time being unproductive. This seems to be because it took two years for the onshore developers (as a whole) to get up to speed on the project and three years for the offshore developers. Šmite and colleagues put the first two years down to high “technical debt” (sub-optimal design accumulated over many years of changes) and the extra year down to high turnover amongst the offshore developers.

If these figures are representative of what happens in software projects in general, they would give a lot of pause to the thought that we could or should enjoy portfolio careers flitting from one project to the next as the mood takes us or the economy demands. If it takes five years for a team to become barely competent on a single software project, let alone to master a whole discipline, we could hope to master maybe four or five projects across the course of our working lives, and changing disciplines entirely would be a daunting task indeed.

Perhaps that project was a particularly dreadful one; I’ve worked on projects on which I felt competent to perform day-to-day tasks within a month or two, and had learned more or less everything there was to know about the software after about a year. But whatever the learning curve might be, the point is that developing in-depth expertise on any one project, or within any one organisation, sits in opposition to building a portfolio of careers. For that matter, so do traditional employee concerns for job security.

Šmite and colleagues make a number of recommendations intended to reduce or mitigate turnover, some of which are at least approximately compatible with the idea of a portfolio career: provide opportunities for learning, advancement and intellectual challenges; onboard new staff so as to bring them up to speed as quickly as possible; and (in a more complementary vein) offer good working conditions and a sense of belonging. But others, such as the aforementioned one to avoid job-hoppers, seem directly opposed to career flexibility.

I suspect that portfolio careers are one of those things, like lifelong learning and creative destruction, that sound innovative and exciting in the abstract but cease to seem so appealing when someone on the ground has to undertake training or go through a redundancy. No doubt there’s some balancing to be performed: a job-hopper who spent only a month or two on any one project might neither learn nor produce very much. Perhaps some of Šmite and colleagues’ advice heads towards a compromise of sorts, even if the article is framed in a way that makes changing jobs look like poor form.

Leave a Reply