Software Development Turnover

I recently met with a company having around 30 employees/generating between $5-$10 million in annual revenue that had just launched a new software application into production. They seemed generally pleased with the work their software development vendor had done and were satisfied with the price they had paid. So after listening to them for a while including seeing a demo of their current application, I asked what the problem was or in other words–Why am I here? Their response was not uncommon and is something I’ve heard time and time again. They were concerned that if something happened to their current vendor and they needed support or new development, that they would be left in a lurch.

I was impressed with how proactive and strategic they were attempting to be to mitigate the risk that most organizations often let happen to them before realizing they have a problem. It can be very disruptive not to mention stressful to find yourself without immediate support of an application that your business depends on when your current developer is no longer available to work on your software. The concerns this particular company had was that their current vendor was small and perhaps in some financial difficulty and that they might not be in a position to provide support in a timely manner or at all. Their solution? They wanted to find a large firm that had numerous developers that could be plugged in if the current assigned developer was unavailable. As always, it sounded good in principle.

There are a number of ways to buy some insurance against losing a developer.
-Hire a full-time/W2 developer: This provides you with some (perhaps false) sense of permanency and if you are able to hire multiple developers, you spread your risk over a larger group. Budget may be an issue for this approach with some firms. Having the capacity to properly evaluate candidates at both a soft-skill and technical level is important for this strategy.

-Hire an independent contractor: Similar to the W2 approach but you aren’t bound as employer and employee as the arrangement takes on more of a business feel. One of the ideas with this play is that an independent contractor is in business to satisfy clients and therefore will be ready when a client needs him. But what if the independent satisfies too many clients and is sometimes too busy to be available when you need him?

-Outsource to a consulting/contracting firm with a larger pool of developers: This seems to be the obvious play to spread the risk–especially if budget is less of a concern. The theory is that the vendor assigns a developer to you and you use that developer as needed. If (when) the developer is unavailable because they’ve moved on or been assigned to other projects, the client simply calls the vendor and asks for another developer, feeling that the vendor understands their needs and can simply drop another developer in the chair to continue where the previous developer left off.

Now the above isn’t meant to be an exhaustive list of strategies to mitigate the issue of developer turnover and there are nuances that overlap between the approaches that can provide a combination that works for some organizations. The point in all of this is that the best way to address this concern is to have as many developers familiar (meaning they have worked on at least parts of it) with your software as you can afford, to have your business documented to the extent it’s understandable for purposes of developers translating business rules/goals into working code and having a development approach that is as clear as possible making the technical part of transitions easier.

Companies sometimes feel that if they simply hire a vendor with multiple developers on staff (or with the capacity to quickly find/hire developers as is the case with good recruiting firms) that some sort of shared understanding of their business and the software that supports it exists. That’s not the case. When a new developer (meaning a developer that is not familiar with your business, with your people or with the software running your business) starts working on your software they have a lot to learn about your business and your software. Whether they are an independent contractor, come from a firm employing 100s of developers or are a full-time/W2 employee, they all have to get up to speed and that speed will vary.

My advice for this company? First, document your business (major entities, workflow, interesting business rules, etc.). Nothing formal–in most cases you don’t need to be a professional modeler or business analyst–just the exercise alone will generate ideas and clarify assumptions among your functional groups. Artifacts you generate will go a long way toward new developers understanding your business and in particular how the software needs to support it. Second, if you are going to outsource (vs. W2) your software development, get multiple contractors to work on at least parts of your system and have them do it together. Even if they are from different firms and/or a mix of independents, pay to have them work side by side on one or two features now and then. This gives multiple developers the best understanding of what you’re software does and how it’s designed; creates great development ideas as different developers collaborate; and gives you the coverage you’re looking for. Last, if your core competence is not in managing software development projects (from requirements through development) then hire someone who has that expertise, even on a part-time basis to perhaps coach you or someone in your organization on how to effectively run a project.