Today we’re breaking down the three pillars of a strong developer-driven culture.

You can have the smartest developers in the world, and they’re going to produce mediocre work if they’re mired in a bad development culture. CEOs all over the world have tried to remedy this by installing foosball tables and beer taps, but it goes a lot deeper than that; if you could just throw money and toys at the problem, it wouldn’t be a problem. Today we’re talking about what developers need if they’re going to do their best work, and how you can go about giving it to them.

Focus on Results

Micromanagement and monitoring have proven themselves incredibly counterproductive; engineers who lack autonomy are going to lack motivation. If they feel watched and powerless, they’re not going to do what’s best for the project, they’re going to do what they think the boss wants them to do.

There are going to be cases where it’s necessary to limit their autonomy for the good of the project (“99% of the codebase and every other engineer is using Laravel, so no, you can’t write in FRACTRAN”) but generally speaking the more control engineers have over their process, the better.

What this means is to scrap the monitoring software, to avoid micromanagement, and to use results as your primary metric of success. Does the code work? Is the codebase well-written and clear for the next engineer? Are you and the team happy with the job they did?

Many companies have also had a lot of success allowing for more flexible hours. If the job gets done and the engineer participated in all the required meetings, does it matter whether they arrive at 9am and leave at 5pm? More and more business owners are switching to having “core hours” where all staff are required onsite for meetings (usually 11am to 2pm) and then let staff choose their own hours outside of that. Major Silicon Valley companies like Netflix are talking about scrapping the entire of “work hours” altogether and focussing solely on output.

The old method of thinking was that exerting control over your engineers allowed them to get better results, but modern management thinking is pushing back against that—it means they’re in the office more, but it doesn’t mean they’re working more and it really, really doesn’t mean they’re working better.

“How do you know they’re doing the work, then?”
Well, you focus on results. Trust your engineers, and treat them like adults. If they abuse that trust then you can rein them in, but starting with the reins on day 1 is only going to demotivate them and create a toxic work environment.

Promote Professional Development

Engineers like problems and they like challenges. If denied them, they’re not going to burn the building down, but they’re not going to give you their best work either. There’s also a flipside to that: if they’re given work far above their capability, they’re going to get tired of slamming their head against the wall and their motivation is going to crater.

It’s a balancing act, but it’s also only a small part of the equation: good professional development needs to be active. It’s not enough to just give them challenging work, you need a structured system of development that they are aware of and understand. Many companies will reserve specific days of the month for PD days, where the devs are given more freedom to work on personal projects, ask questions, and generally upskill. Not only will this help break deadlocks in their work and make them feel more in control, it sometimes ends up generating great products.

It’s also important to make sure they have the right support. Your junior developers need access to senior developers, which is balanced against the senior developers’ need to actually do their jobs instead of spending all day answering questions. Making sure your staff know when and how they can get help is extremely important if you want them to upskill effectively.

Why Are You Doing This?

I’ve said it before: one of the most important things a company can do is to distill their purpose down to a single sentence, then print that sentence and hang it over the door. It’s a simple, low-tech way to remind people that they’re there for a reason. There is nothing more poisonous to motivation than feeling like your work is pointless. That poison will spread throughout the company if not checked. If your engineers are constantly asking why are we doing this? then you’ve done something wrong.

If somebody’s work actually is pointless then that’s just bad management, but it’s also a huge problem if there is a point but they’re just not being properly briefed on it.

Which is part of why you put your mantra over the door: it’s an easy way to remind people why they’re in the building. Printing it out and putting it up there with tape is a little jokey on my part, but you get the point: have the words on display.

It’s also useful in hiring: if you know what you’re about, it’s easier to find staff who are on the same wavelength. If you’re trying to design an app that helps rock climbers find the best spots, then your engineers are going to do a better job if they’re into rock climbing—they know the audience’s needs better and they care more about the product. Hiring people who care in the first place is going to do a huge amount of work to ensure they know why they’re there and why they care.

Where to Go From Here

Creating a good developer culture is about, well, creating a culture. It’s not about physical things like foosball tables, it’s about the attitude, conduct and motivation of your staff.  That starts with management: it starts with treating your engineers like capable adults, and giving them support and purpose.

Our Company, CodeClouds, offers affordable offshore developers from our four global offices. If you want to hire front end developers, then you’re in the right place. Drop us a line today and see how our developers can make your next project amazing.