Dear Software Development Managers,

I’ve been lucky enough to work with a fair few development teams over the years, both here and in Canada (you’d have to ask them if that feeling is reciprocated). As well as getting involved with some good projects and taking part in a multitude of technical discussions, I’ve also been on the listening end of a lot of venting and complaints.

Since this has come up a few times in discussion recently, I thought it’d be useful to write down some of the issues that I hear time and time again so that, as a manager, you have an opportunity to make some changes.

Bear in mind, this is very much from a developer’s viewpoint. My management skills and experience don’t really extend beyond being senior developer/technical lead on projects.

So, that said – why are your developers miserable?

You expect them to work without proper requirements

There’s a reason this one kicks off the list – this is by far the complaint I’ve heard most frequently. As developers, your team are interested in solving problems. But, to solve a problem, there needs to be some definition of what is acceptable as a solution.

Fully fleshed-out requirements mean that everyone knows what they’re building and what the end targets look like. If you have a different idea in your head than your dev team, you need to get those ideas out of your head and onto paper.

You also need a definition of done. If your devs think that they’ve finished work but you know there’s still documentation to be completed, that’s going to lead to a bit of friction and frustration. Sort these things out the the start of the project – get everyone in a room, present the project, and then break it down for questions and analysis.

You set unrealistic deadlines

Hopefully you are already involving the dev team heavily when estimating the time for projects (if not, you are a terrible person). If those estimates don’t tie in with what the client needs or their budget then it’s your job to manage and prioritise (with the client’s input) the requirements to see what can be done within the time.

Telling your team to either work faster or cut corners is just going to lead to misery and problems in the long run.

Incompetence is the norm

If, when something goes wrong in a project, the general response is “typical [insert company name here]” then you have big problems.

This is very similar to the broken windows theory: you need to make sure that quality is being maintained or it will start to slip. And it’ll slip quickly.

It’s not a simple task to create solid code with detailed documentation and full test coverage. It’s much simpler to cut corners and hack something together. If doing the bare minimum becomes the norm for your team, the quality of code is going to suffer and the bugs will creep in. As that happens, developers will get frustrated and start to get itchy feet. Nobody wants to work on BBoM projects.

Your IT department won’t fork out for good hardware

You’ve employed your developers for (probably) a fair chunk of money to build software. £70 for an SSD or RAM upgrade for their machine is nothing in the grand scheme of things.

When they’re using memory hogging software like Visual Studio and Photoshop, good hardware makes a big difference. Push for that extra bit of budget and get them machines that start up and run much more quickly.

Your IT department has locked down the internet

Some developers, when faced with a problem they’ve never seen before and are unsure how to proceed, will just start hacking away at code to see what makes sense. Others will go online and research what others have done with similar problems, what tools they’ve built, and work out the best approach from there.

You want to encourage this latter group. They’re the ones who are going to save you time and money by not meandering down a bunch of wrong paths looking for a solution.

So, when the IT department block NPM, NuGet and such, it stops your devs getting access to this and they’re forced into workarounds (NPM via Fiddler anyone?).

With individual blocked websites, you also need to treat your team as adults. When one of your developers works through lunch then decides to grab a quick sandwich at her desk at 2pm, goes to Reddit and discovers it’s been blocked, that trust suffers.

Your IT department has locked down their machines

There are a bunch of tools out there that make life easier for development. There is also a huge amount of malware and dodgy content. If someone on your team of professional software developers can’t tell the difference, you may want to review your hiring policy.

Blocking someone from installing PNGGauntlet, Inkscape or such just limits their productivity.

You don’t tell them what’s going on

As a manager, you’re privy to the latest news about projects coming in, structure changes, and other things that affect the team. Your team need to be kept in the loop about the big picture. It helps them feel part of the larger group and can give them an idea of where their career can take them with your company.

You don’t need to go into every bit of detail about the grand scheme of things but make sure that the team feel part of it.

You only give them feedback when stuff goes wrong

When your team hits a deadline, produces a solid piece of work that a client is delighted with, or just solves some internal problem, let them know. Managers can sometimes only give feedback when a bug has been found or budget is running out. This is terrible for morale.

So take your team for an end of project lunch and a couple of beers to say thanks for doing a good job.

Your company has no flexible working pattern

Everyone has responsibilities outside of work. Whether that’s taking a child to the doctor or waiting for an Amazon delivery, giving your team flexible working hours (or days) is a huge perk. You can still do this with the addition of core hours (where everyone has to be in say 10-12 and 2-4) but flexitime and remote working at another company could be enough to temp your valuable devs away.

Software development is also typical of any creative job – you need to be in the right frame of mind to create. Sometimes that creativity strikes at 8am, sometimes it’s 10pm after a pizza. If you’re running a strict 9-5, you’re probably not getting the best from your team.

Your company doesn’t have a casual dress code

Suits and ties, I am pretty sure, have never been directly linked to an increase in productivity, quality of code, or morale.

They don’t have scope to learn

Developers (good ones) like to learn. If you’re putting a big emphasis on time/chargeability then you’re reducing the opportunity for them to learn new skills while on the job. Giving your team the okay to go and learn new technology and techniques is going to widen their knowledge and give you more tools for tackling future projects.

Subscriptions to Pluralsight, industry magazines, and a budget for training/conferences is going to keep your team up-to-date and happy.

Knowing that, as soon as they’ve finished rushing out the current back-breaking project, there’s an equally horrendous one straight after, is not going to make your team excel.

There’s no variety to their work

Everyone (probably) likes variety to their work so keeping the same few people on the same project for years at a time is going to be tedious. Letting your team members move around to where they feel they are most beneficial or can learn the most gives them variety while reducing your project’s bus factor.

Your projects are horrible to work on

If your projects are mainly made up of legacy code, you’re going to struggle to keep a hold of your team. Devs want to use new and interesting software, not make tweaks to that WebForms project for 2009.

You don’t have to agree to doing a full rewrite of your systems every time a new piece of technology comes out, just be open to suggestions for upgrades and improvements from your team.

You don’t ask them what the company could do better

The Agile process includes iterating over what works and doesn’t work to improve the overall process. Your developers will have ideas about what would make their lives and your life better so make sure to ask them.

There’s no team

Do your developers work individually in silence? If so, you need to build that team spirit. Encourage them to run brown bag sessions, go to tech meetups together, organise pizza for a Channel9 viewing and just encourage them to chat.

You want to encourage a collaborative, friendly atmosphere. This is where good developers thrive.

So…

Hopefully that will give you some insight into what’s going on in the brain behind those sad eyes you see peering above that tiny monitor that IT have provided. Give them a smile.

Yours sincerely,

K