Judging by the actions of a few companies I’ve encountered over the ten and a half years of my full-time, professional programming career, many companies would like to quickly lose their most talented people, preferably to their competitors and preferably for easily and cheaply avoidable reasons. Towards this end, I’d like to offer a list of suggestions of ways to make absolutely certain that your development staff is interested in greener pastures, no matter how much barbed wire they have to climb to get to them. Here are my suggestions for how to achieve near perfect turnover (except for sadists) within a three to four year period.

1. Make sure to have someone carefully watching, to make sure all team members are in the office by 8:00 on the dot and never leave before 5:00, no exceptions. It’s an important part of your day to make sure that no one is even a minute late, even if they are software developers who are never in a position to talk to a client or even other people within the organization without a project manager present. It’s important to enforce hours and make sure that everyone is in their seats when they are supposed to be. In fact, it’s practically second to productivity in importance. Besides, if you aren’t giving them at least 8.5 hours worth of solid work (plus meetings and “team-building”) a day, then it looks bad on you.
2. Make sure that developers who just developed a major application for the company are consigned to maintaining that application forever. Whatever you do, don’t allow them to actually learn something new. It’s even better if they can see a couple of folks who have loyally stayed with the company, maintaining old apps get downsized once the app in question is finally sent to the scrap yard.
3. Have as much process as possible around everything. Sure, you’re under HIPAA/FCRA/PCI/Sarbox/whatever and regulatory compliance is absolutely necessary. But go the extra mile. Be sure that there isn’t sufficiently trained support for your production servers and that any problems there will require troubleshooting by developers who aren’t allowed to actually interact with the server to get useful information. Better yet, be sure that you have an extensive ticketing system with dozens and dozens of fields that must be filled out, simply to patch a misspelling on a webpage somewhere, preferably including testing and rollback plans. For bonus points, be sure that your QA/Testing/Staging environments are radically different than production. Be sure, for instance, that if you are using load balancing, old versions of database servers, tighter firewall and file system rules, and live hardware (instead of VMs) for your production environment that your testing environment does not reflect that.
4. Don’t pay for training ever. Don’t ever send developers to conferences, ever. Be sure that your developers know that improving their skillset and actually being able to keep a roof over their heads five years from now is entirely their responsibility, and can only be done after work hours.
5. Never ever listen to legitimate engineering concerns about how your applications will perform under load, perform when a critical service is acting up or offline, or how the implementation stores, retrieves, or transmits data in a funky way. Never listen, but be sure that your developers are in a position to listen at 3:00 in the morning when something falls over. For added benefit, make sure that those same developers are expected to still put in a full workday after this happens, because, after all, the failure is their fault. For additional bonus points, place engineering concerns about stability behind sales concerns (especially when they’ve told a client that the system will do something it has never done without asking anyone why that was added).
6. Ask for estimates on how long things will take to complete, then cut the team size, add additional work, and hold the team to the original estimate after changing everything. After all, if they do pull it off, they’ll feel like they are the best in the business and can probably write their own check anywhere. Be sure never to account for 10 or more hours of meetings, filling out various things in the ticketing system, and “fun” company outings without beer in them as things that might derail the project. After all, if the developers were any good, they’d attend your meeting or corporate yak shaving event on their own time.
7. As a development process, be sure that it can best be described using the words “agile, but”. After all, “agile, but” is easy to achieve. You can leave out daily scrums, use waterfall methodology to plan things and have loads of meetings that accomplish nothing and still be “agile, but”. Combine this with #6 for best effect.
8. Make sure your developers who are working on active development of a project are also responsible for maintaining one or more projects that are currently in operation. Do not account for how long this will take in the project schedule, but assume that every developer will be coding on your project 40 or more hours a week. Accuse any who aren’t able to both maintain old projects that are being mishandled by another department and put in a full 40 hours on the current project of not being team players. Also, be certain that whomever manages those other projects is allowed to interrupt developers at any time, looking for help with something that is in the documentation, and then make the developer stay after hours to catch up on whatever was hopelessly and needlessly interrupted. For bonus points, when the overworked developer’s family life falls apart as a result of always being in the office, the phrase “suck it up, buttercup” is useful for bonus points.
9. Be sure that raises track with the reported rate of government inflation, rather than the actual rate (aka, use the rate exclusive of food, housing, healthcare, education and fuel costs). This is one is particularly effective because it’s a bit of an open secret that our government (regardless of who is in charge) fudges the numbers to make them look good. If you base raises off of this, your employees’ effective salary will drop several percentage points a year, all while you give raises just large enough to not look like scrooge. It has the added benefit of making your employees wonder whether you were dumb enough to buy the government fudging of the numbers yourself, or whether you assume that they are dumb enough to do so. And the nice thing about this is that the salaries of new hires tend to rise along the line of what the actual inflation rate is, rather than the reported one, so recruiters will get those nasty WOW-playing neckbeards out of your office in no time, all without you having to lift a finger.
10. Be sure that the work environment is unpleasant. Try to make sure that loud meetings happen right next to the developers’ workstations as often as possible. Better yet, put sales or customer support right beside the developers and make sure their speaker phones work. Have an open floorplan where everyone can see everyone else’s screen and where no one can wear headphones to drown out the noise (or they can risk a heart attack every time someone taps them on the shoulder). Install a system for public announcements and be sure the secretary uses it seven times an hour to call for various people, none of whom are in the department. For added benefit, sure that the room is too hot, too cold, or has uncomfortable lighting. For bonus points on this one, be sure the developers are given slow machines, locked down so that they can’t actually look at non-Microsoft documentation on anything, and give them insufficient permissions on the machine to actually be able to do their jobs.

I hope by now everyone reading this realizes that I offered these points in jest. These ideas are all atrocious, destructive of productivity, and frequently make development departments feel like the absolute last priority of anyone with any power. That said, if you are having a problem with lots of turnover in your department, you might want to look over the list and make sure you aren’t doing any of these. Nobody sets out to do this stuff from the start (well, at least no one normal does), but for many companies, one or more of these things happen organically over time, usually without anyone other than the developers noticing. I’ve seen it happen before (here I would parenthetically note which I’ve noticed the most often, but it’s pretty much all of them) and it did NOT happen because someone intentionally set out to create a non-productive, turn-over prone work environment intentionally. Rather, it crept in incrementally, through large numbers of small decisions that seemed like a good idea at the time. If you’re experiencing this in your environment, look over the list and see if you are doing any of these. Odds are good that you both are doing these things and that you truly don’t intend to be. Managers have a hard job (especially middle management, which I’m fairly happy that I washed out of), and quite frankly, this stuff slips up on you. I could (and may) write a similar article for developers about how they are ensuring that they are going to be switching jobs on a regular basis. None of these things above are a big deal, so long as you recognize it when you are doing it, communicate clearly to the team, and then actually take steps to counteract the problem. And most of this stuff is pretty cheap to fix. Some may not be politically expedient, but much of it is possible to fix without spending a lot of money (“a lot” being determined subjectively by comparison to how much it costs to find a replacement programmer, train them, and deal with problems in the interim).