As a company owner or hiring manager, attracting software developers into your organisation is one challenge. You have to hook them in with a job specification and then sell your company to them in an interview as-well as gauge their technical abilities.

But once a developer starts at your company, you then have to retain them. The jobs market is quite vibrant at the moment and developers have a plentiful choice of companies to go to as a permanent or contractor developers.

Retaining Software Developers in Your Company
Retaining Software Developers in Your Company

On-boarding and training up a new developer is quite a large commitment to a company in terms of time and costs, so how do you keep a developer engaged and wanting to stay so they can be productive and give a return on your investment.

In this short article I want to share some of my thoughts and view on this, but what I would really like to happen is for you to comment on this article and give your opinion either as a developer or as a companies hiring manager.

Has your company done something else to retain staff, if so what and how well did it work? Did they try something and it didn’t work?

Salary and Benefits Package

This goes without saying so I won’t spend long on this. A developer should be paid a fair amount for their skills. If they are underpaid compared to the local market, they will eventually move on. Some companies offer bonuses, some even actually pay them, but in my opinion you shouldn’t base employment choices off of a non-contractual bonus.

Provided the Proper Tools for the Job

If you are paying money for a developer then you should make sure they have all the tools they need to get the job done. This means a decent desktop computer with a couple of decent sized screens, or a good spec laptop that can cope with the development environment and potentially hosting virtual environment.

You should also make sure they have all the software they need, like Visual Studio for .NET developers etc. If it is an industry norm to provide tools like Resharper or Code Rush, then you should provide these tools as they are becoming common place and developers expect them. I still find it amazing that some companies won’t pay for resharper even though the tools will pay back dividends in increased productivity and higher quality code.

It really is a false economy to skimp on tools when you are paying for someone’s time. If they don’t have the best tools for the job, then they won’t be as productive as they should be. Would you expect a mechanic to repair your car and not have a decent box of spanners? Of course you wouldn’t.

Decent Sized Desk

When working for a company, you are going to be spending a lot of your time sat at a desk, so you want it to be a good sized desk that you can make your own. You will want to put books and family photos etc there and make it feel like a small home away from home. I have worked at one company before where I was given a tiny desk where everything felt cramped and very uncomfortable. This does not make you productive or happy.

Clean and Light Working Environment

A work environment should be well lit with natural light if possible and clean. There is nothing worse than working in a dull, untidy office. Sometimes a window seat isn’t possible, but the office lighting should ideally use flicker free natural-light balanced lighting.

Allowed to Wear Headphones

Developers like to block out the world around them and focus. This may be by listening to their favourite music, or it might be listening to music specifically designed for coding too like Carl Franklins latest music album. I have one developer on my team who has brought a new pair of Bose QC-25 noise cancelling headphones and listened to ambient background sounds like coffitivity to focus. And boy do those Bose headphones work well!! I personally like to listen to film soundtracks / scores when I am getting in the zone.

Interesting and Complex Problems to Solve

Developers spend a lot of time at work, so they want to feel interested in the work that you are doing. The best companies from my experience are those that have you working on interesting projects, or products. If you are just spending your time writing CRUD applications then you will get bored pretty quickly, but if you are working on something that feels innovative, complex and has variety, then you will remain engaged and interested in the company.

Pushing Technical Boundaries and not Just Legacy Maintenance

Following on from the previous example, to keep an developer interested will want to be pushing technical boundaries and keep up-to date with modern technologies. It may not be practical or wise to stay on the absolute bleeding edge, but keeping reasonably up-to date will keep a developer interested in what they are doing. What is very demotivating is if developers have to maintain a creaking old legacy system, especially if it is like an old VB6 application that you have on life support. Sometimes you can’t avoid having to keep these running, but try to balance it with new and interesting work, otherwise developers will just get bored and leave.

A Learning Culture

A good developer loves to learn. Technologies moves at such a pace these days that you are forced to learn all the time, and a company should support and embrace this. There are many ways a company can do this. First, a company should allow time for learning and research. This could be an afternoon a week, or a time boxed period each day. A company should also provide training resources for developers to use.

In my experience, residential off site training is quite expensive so doesn’t tend to happen very often, but with companies like Pluralsight who offer very affordable training on demand, there really is no excuse. The benefits a company can get from these sorts of training sites will pay dividends as developers keep their skills up-to date. OK, I am a little biased with Pluralsight as I design courses for them, but there are other alternatives too like Udemy, etc.

I also think it is very beneficial to provide access to book libraries like Safari Books Online as they are great learning and research tools. I haven’t bought a technical book in years because I make extensive use of my Safari subscription both to read book, and to use them as a research tool by searching through multiple books.

Easy Access to White Boards

I believe plenty of whiteboards are essential. You can not under-estimate a group of developers trying to solve a complex problem by huddling around a whiteboard. They make brainstorming in a group very effective. You can either get the large boards that screw to the wall or mobile boards on wheels.

Free Tea and Coffee

This goes without saying, but developers generally like their tea and coffee, so why not provide it for free or at-least offer a discounted coffee bar. The company I work for has 2 on-site Starbucks and a Costa Coffee, and these are great social meeting points for developers who can go for a drink to take a break between coding sessions.

What Else?

This hasn’t been an exhaustive list of ways to engage and retain developers, but is just an initial brain dump. What would be really good is to hear from you all about what you or you companies do to retain developers. What works and also as important, what doesn’t work? If you have a view on this, then please do leave a comment for this post below.


  1. I used to work for a company who had a pool table. Unfortunately they were in the top floor of a very small unit and the pool table was right behind me. Fine for those who wanted to play pool, but not great for me when I’d have an arse or cue in the back of my head at least twice a day, plus the racket of clacking balls – so while you might think you’re doing something really cool, make sure it’s cool for everyone and be careful about the execution…

    Pool is an example of something that is quite cool (if it’s IN A DIFFERENT ROOM) and manages time effectively – you can commit to having a game or two games before getting back to the grindstone.

    Games consoles are probably way higher on the cool scale but not so great for time management. If your dudes are playing singleplayer games, it’s VERY easy for them to get sucked in and lose track of time. If they’re playing multiplayer against one another it’s even worse if they’re similarly matched. They could be there all day trying to get one up on each other.

    That said, I’ve worked at two small-ish companies where we used to game on our PCs. In the first, in around 2000-2001, we used to play HalfLife DeathMatch during our lunch hours. It’s a good compartmentalised period and it keeps the team close. You can fit a few games into an hour and probably only overrun by 5-10 minutes in the worst case (normally) – any sore losers only have to wait til tomorrow to have another go at their nemesis. In the second, in about 2008-2009, we would play Stalker DeathMatch at the end of the day. This was normally outside of working hours, but if we all agreed we’d had a pretty crazy week and really needed to unwind, we’d sometimes start early on a Friday evening. The interesting thing here is that both were DeathMatch games – every man for himself. We’ve been working as a team for the rest of the day, but in the end it just feels good to go round blasting each others heads off.

    None of this will go a long way to someone making a decision between staying and leaving, but it definitely goes towards helping people feel like work is a fun place to be.

    1. Thats a good set of points. When I worked at Egg, we had a separate breakout room with a pool table, table football and a load of playstations. It was a good way to let of a little steam every now and again. I agree it is not a key determinate, but its the little things I think that go a long way.

  2. Here is a comment by fellow Pluralsight author Eric Burke from our authors discussion group. This is posted with Eric’s permission.

    0. Do everything in your power to remove friction. Next 4 points extend that.

    1. Proper management. Make sure the devs have enough freedom to grow but enough oversight that they aren’t set up to fail. Shield devs from upper management. Have a lot of 1:1’s. Communicate everything down to the dev no matter what. Listen to all devs, even the junior ones — you hired them for a reason.

    2. Telecommute. Allow people to WFH whenever they want. They will prove whether or not they can do it. Manage them through it. Help them grow.

    3. Proper project and product management. Nothing kills spirit like tons of last minute scope changes or a project whose schedule is not managed properly (and communicated upward).

    4. Proper software development process. (See #3) Find what works for the org to run smoothly.

    In my experience, it’s rarely the desk/food/headphones that makes or breaks a developer’s happiness; rather, it’s the ability of the organization to build things smoothly and effectively and help the dev succeed and grow. Most devs I know are extremely loyal to managers and organizations that they feel are looking out for them.

  3. This comment is by Julie Yack, a fellow Pluralsight author, over on the author mailing list.

    Provide them work that challenges their intellect, but always have back-burner items that are easy for when they need a brain break. I like my devs just outside their comfort zone, always learning.

    Get them involved in their professional community (user groups is a good start). Reward community involvement.

  4. I wrote a post several years back called, “How to Keep Your Best Programmers” and it led me to some interesting research. My take-away was that compensation is important, but only up to a point — the point at which most needs/wants are met. After that, comp is really only important for retention in terms of how valued it makes people feel (for instance, a developer making well more than industry average might become disgruntled upon learning that his peers at the company are all paid more than him).

    The core drivers for happiness and productivity can be categorized as mastery (are you getting better at whatever it is you’re doing), autonomy (do you have creative freedom to solve the problems in front of you as you see fit), and purpose (are you working toward what you perceive to be a worthwhile goal). Your bullet points, “learning culture” and the two that precede it definitely drive at that.

    There’s a pretty fascinating video on this subject here:

  5. One of the best ways to retain programming staff is to wholeheartedly adopt lean/agile principles. That is, it’s the organizational culture that’s important, not the superficial stuff like desks. There’s a tension between traditional management practice and workplace quality, and the only way to resolve that tension is by changing management practice. The things you list are, to my mind, things that will emerge naturally as the result of a cultural change, and without that cultural change, will have little or no impact. I’ve seen companies that go the superficial route (that is, they have the big desks, free food, good salaries) loose literally half their staff when they encouraged everybody to learn about agile (to the point of bringing in trainers), but then couldn’t make the management and cultural changes necessary for agile to work. People moved on to greener pastures.

  6. I’m going to *TRY* and keep this short, but I’ve campaigned about thinks like this for a few years now.

    Of course, the hard part is where to actually start, because there is just so much wrong with the way our industry is run, and the way it’s perceived.

    The biggest issues I find are because of the disconnect between management and I.T, don’t get me wrong here, I’m not saying that all management should understand what we do (If they did they wouldn’t need developers right?) but, it wouldn’t hurt many of them to at least have a working knowledge.

    One of my favorite programs when I get the chance to watch TV is a program called “Undercover Boss”. The upshot is that the boss of a given corporation, don’s a disguise and goes back to the shop floor for a given period of time.

    Very, Very often said boss actually gets a bit of a wake up call, and for the better usually goes back and vastly improves things.

    When I worked for Orange as an engineer, this was actually quite a common thing, we’d often get upper management coming back down the chain and spending the day doing the regular work, but in all fairness most of the management team used to actually be technical and engineering staff.

    The point I’m trying to make however was that life was good, the workers where appreciated and Orange as a company at the time where major industry leaders.

    About a year before I left, France Telecom bought the company, and within a very short space of time it was clear things where going downhill rapidly. Most of the senior management team who we came to know well, either left of where “Politically moved”, most of my team and the teams around me came under control of new managers, all of whom where from a business and non technical based background.

    I’m not going to list all the changes, but some of the decisions that where made where nothing short of ludicrous, decisions that where made simply to save what amounted to pennies per year, all so profits, bonuses and investor returns could be maximized.

    I Left in 2008 after seeing a company I loved working for slowly bit by bit get disassembled from the inside out, and today I see just a shell of what was once an amazing and vibrant place to work.

    One of my biggest criticisms however was the actual attitude by the management. We (The Technical Directorate) repeatedly tried to explain the results that would come from their actions, we tried to educate them, we didn’t want or need them to know how to do our jobs, we just needed them to have enough of a working knowledge to realize the consequences of their decisions.

    In software development, this seems to be a growing mantra. As you’ve pointed out elsewhere Stephen, developers get treat very much like factory workers, who’s job it is to just produce code.

    There’s an even more dangerous element to it in software development however, and that’s business knowledge. I’ve lost count of the amount of upper management types that will absolutely not even consider taking even just 5 minutes to understand even a tiny fraction of what I do, but the second I don’t understand how thier business orientated brain thinks, I’m immediately ordered to go on a business course that will “Improve My Business Productivity” and open my eyes to the challenges they have to deal with.

    Just as I don’t expect you to be trained to do my job, I fail to understand how forcing me to be trained to do your job helps.

    Don’t get me wrong, I need to have a working knowledge of how your business operates, especially if I’m writing software which your business relies on to operate correctly, but I don’t need to become a full blown business man to do it,

    My belief with this approach is that like many areas of the business mind, the business types believe if they can bend something they don’t understand into something they do understand the rest will just follow but still maintain it’s role.

    Iv’e seen so many amazing developers pushed into things like MBA courses, only to never touch a compiler or IDE ever again, really talented people who’ve had this uniquely creative mind twisted and contorted into something that no longer allows them to think in a manner required to develop great software.

    The bottom line is this, yes there’s an amazing amount of things out there that will inspire your staff and keep them at your company, but if you try to mold them to fit your vision, not only will you loose them, but the I.T industry in general will too!!!

    Learn to work with them, learn to trust your I.T staff, listen to their input. When they tell you somethings not going to work, it’s usually a very fair bet to assume there correct, I.T workers are not robots, there insanely creative, clever and vibrant people who given even just a small chance will shine way better than you ever could imagine, destroy that free thinking and creativity however, and there’s no future for anyone.

    1. Great points here.

      Firstly, I was just having a brief discussion with a colleague about how the guy straight out of Uni is doing “the same job” for a third of my salary. On paper you see “Senior Developer” and “Junior Developer”, and if you don’t understand that “Senior” means more than “Been here for a while” then you might not get the difference in roles.

      Secondly, trust. I’ve had issues with feeling “untrusted” before. I had an “incident” with someone calling me every day. Sometimes more than once a day. Asking to come and sit with me so he can see what I’m doing and understand the process. That man has been promoted to a decent business position, but he still has a sheepish look in his face when he approaches me. Unfortunately not everyone has the resistance to deal with those people, or the managers who can tell them where to stick it (thanks, Steve)

      Thirdly, and combining both, we – as developers – have a great deal of creativity and are “mechanically minded” people. If you’ve got a model of small car and say to your engineers “We want to put a 10 litre truck engine in there” and they say “That’ll bend the axles,” you’d better listen to them. Instead, make use of their experience and creativity. Present them with the challenge and ask them for the solution. They’ll appreciate it and feel appreciated and valued, and you’ll get a better answer than asking Dave from Accounts to put something together in Excel that looks about right. It won’t be right, and Dave’s emotional investment in his papier-mâché model will just cause friction when he refuses to back down on the impracticality and proven errors.

      1. More good points. This is turning into a very interesting subject. And btw, I can still tell them to stick if for you, if you like, even though I don’t work there any more 😉

  7. “Allowed to Wear Headphones”?!

    That seems a very poor response on the company’s part, to the glaring need to not use open plan offices – a room with a door helps programmers think. Wearing earphones is a poor substitute!

    1. I completely agree. In my organisation though, open plan is baked into their culture so it not something we could change without reconfiguring a building that houses nearly 4000 people. Noise cancelling is the next best thing. I’m sure this is a common theme across many large companies. It’s much easier to manage in a smaller company.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: