How to look after your development team

It’s not easy being the boss. You might have an awesome development team at your disposal, but if the coding they love is constantly interrupted by meetings, bug fixes and distractions, they’re going to get pretty unhappy, pretty fast. Fear not. We’re here with eight great ways to keep your tech talent happy, motivated and super productive. Let’s take a look…

Jumping between projects all day isn’t a good use of anyone’s time. It takes a few minutes to remember where you’d got to, find what you need and get your head back into a job. That might not sound long, but those minutes really add up. And all that juggling will really frustrate your dev team, who just want to get stuck into their code.

The answer? Wherever you can, assign team members to a project for a whole day. Give them the space and time to focus – and power on. It won’t always work out, but if the intention’s there and you work hard to stick to it, your dev team will really appreciate it.

You can also put simple things in place to make some inevitable juggling feel less brain-crunching. Encourage your team to use visual cues or colour coding to organise their work so it’s easier to jump in and out, see everything clearly and get on with the job faster.

Like we said, what most developers really want is to be able to focus. They’ll write their best, most beautiful code when you can protect them from interruptions and distractions. Which means they’ll be happier, you’ll be happier and your clients will be happier too. Bingo.

Trouble is, most of us work in open-plan offices, filled with phone calls, impromptu desk meetings and urgent requests. And while that might make it easier for some people to work together, it’s not great for your coding pros, who just want to immerse themselves in the task at hand.

If that’s just not an option, establish some studio etiquette around when it’s ok to interrupt someone who’s got their head down working. You could give your dev team headphones and ask people not to disturb them when the headphones are on – or introduce a traffic light system, so developers can turn on a red light if they don’t want to be disturbed, and a green one if it’s ok.

Meetings are an important part of agency life, getting your best brains together to plan big projects. But they’re also a huge time and resource drain, dragging your team away from the creative, revenue-earning work they’d rather do. So if your development team groans every time you schedule a meeting, what’s the best fix?

Long, unfocused meetings are the worst, and scrum meetings are a pretty powerful alternative. They’re an agile working technique where your whole dev team gets together at the start of every day to catch up on what’s been happening, what’s coming up and what might cause problems.

The key thing here is, keep everyone on their toes. Literally. Making it a stand-up meeting will encourage people to have their say quickly so they can get back to their comfy chair. And setting a maximum 15 minute timeframe for the whole scrum will also push people to make their point fast. There are three key things to ask each person:

• What have you got done since the last scrum?
• What will you be doing before the next scrum?
• Is anything standing in your way?

You can even take this further and map progress on a scrum board. Have a ticket for each job that needs doing, and a series of stages mapped out so tickets can be moved on as work is done – for example from ‘awaiting brief’ to ‘signed off’. It’s a quick, visual way to see what’s happening and celebrate progress.

On the other hand, you might feel more meetings are the last thing you need. You could try a more stripped-back approach, sending fewer team members to fewer meetings and being a lot more picky about what you say yes to. It might be nice to have the whole team plan a project – but as lead developer you might be able to do it just as well on your own, and save lots of coding hours.

There’s always pressure to dive in and crack on with new projects, but for developers, a bit of breathing space makes a big difference. Invite your team to plan their code on paper, building a clear mental picture before they hit the keyboard. It’s a great way to change pace, focus on the problem and get things right from the start, rather than going in, all guns blazing.

The nine to five isn’t for everyone. Some of your developers might be early birds, keen to get in and get on. Others might be night owls who work their best coding magic well after dark. Some might have different things to juggle – a family, a side hustle, a PhD – and some might even be working in different time zones. People are different. But what they’ll all appreciate is flexibility.

Think about whether you really need everyone to be sitting next to each other for exactly the same hours every day. Yes, it can be great for teamwork, but lots of collaborative tools can help you keep discussions going, even when people aren’t side by side – such as Basecamp.

You could even set core hours in the middle of the day when you expect the whole development team to be in – or available online – and let people choose when they make up the rest of their contracted time. It shows you trust and value them, which again helps to make them happy.

When the rest of the agency sees what a phenomenal amount of work your team can do under pressure, they might start seeing it as the norm, and expecting it every week. And that’s not fair. When your developers burn the midnight oil to get something done for you, they deserve a little slack the next day, or a little flexibility when they ask for it. It’s your job to make sure your clients and accounts team understand this – and to protect your people from burnout.

When you’re busy juggling projects, it’s hard to find time to keep up with new technologies and approaches. But these are just the kind of things developers thrive on. Unlike a lot of people, they’re almost always keen to dive in, explore what’s out there and keep at the cutting edge.

That’s a great thing, and it’s important to encourage it. Yes, time pressures make it tough, but try to carve out dedicated learning time for your development team so they can try new things and investigate new trends. Think of it as an investment in your agency. With all these new tricks up their sleeves, your dev team will have a whole lot more to offer your clients. 

It’s also an investment in retaining your talent. If you force developers to keep working with tired technologies because you can’t find time to try what’s new… well, either your developers will lose their brilliant sense of curiosity, or they’ll leave you for an agency that’s braver, bolder and probably about to steal a few of your clients too.

There’s a saying in development circles. You’ve probably heard it. But we like it, so indulge us: “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.” Right? Right! 

What it boils down to is that code is meant to be understood. To be useable, workable, readable stuff that actually helps people further down the line. So encourage your development team to adopt this mindset. To write code that could be quickly understood a year later, by someone who’s barely interested – and in a massive hurry. Really clear. Super clear. Clear clear. 

Once that’s in place, everyone in your team should be able to pick up projects part-way through, fix unexpected problems and feel confident working with each other’s code. Pretty useful.

This last one might just save your development team a whole heap of headaches. In fact, there’s no might about it. Give it a go. You’ll be helping your team get bugs fixed faster, and get back to the coding they love.

To blitz through bugs, developers need clear, specific information. So invest an hour and put together a report form that gets those answers that includes:

• Make sure only one bug is reported on each form, so things can be tackled and taken off your team’s To Do list faster. 
• Encourage reports with descriptive titles, like ‘Login failed due to lost user account’.
• Tell people to write clearly and focus on the facts, rather than guessing.
• Make sure your report form asks what the filler-in expected to happen, as well as what actually happened. This gives you a great insight into user behaviour.
• Encourage people to add screenshots – these can be really useful clues.
• Ask whether the problem has happened more than once. 
• Ask people to describe very specifically what they did. It might help to give them an example to follow, like this: ‘I was on [page url] and I tried to log in with my username, which is [username] but instead it took me to [page url], and said my username couldn’t be found.’ That way, your team have a better chance of reproducing the problem – and fixing it.