How to get the most out of developers

What gets developers motivated?

Before talking about what motivates developers, I want to talk about money. Money is the universal token of success and everybody seeks it as a means of validation. However, I see money as something that, if I don’t have it, I may want try to find it somewhere else, rather than something that’s going to actually drive me to pour my soul into a problem and get it solved.

This is what actually drives developers:

Accountability and opportunity to make decisions

Many organizations cultivate a “we’re all responsible” culture and it sure has its merits. But make sure that every step in the development process, every project and sub-project has a responsible. Everything should have a clear person to blame in case things go under, but that’s also the person to give credit to, in case of success. Developers will have a stronger feeling of importance and give the best of themselves if they feel accountable. Also, it’s common for organizations to centralize decisions to an extent that will discourage developers to even come up with solutions. Don’t do it. Encourage decision making, encourage developers to feel like if they spend the night thinking on the solution of a problem, that they’ll be heard and be rewarded.

Opportunity to continue learning

Developers have chosen this career path because they’re passionate about it, at least the best ones. The best developers will always be driven by curiosity and drawn to an environment where they can explore and learn new technologies. They don’t want to be forever stuck in the past.

“But we can’t keep changing the front-end libraries every three years, that’s insane”. Correct, but you can do that at least outside the “core product”. There’re always new libraries, tools and small side-projects being developed, where the risk is low. Use these as an opportunity to allow the developers to explore with their favorite languages and frameworks.

Encourage a laboratory and it will eventually pay off. Developers are twice as productive when they’re doing it the way they want and with the tools they’ve chosen.

A strong belief in the product, the decision-makers and the other teams

I can hardly think of anything worse for productivity than disbelief, and it spreads like a disease. Disbelief occurs normally towards the decision-making teams, and it’s quite common when it’s not clear why things are being done the way they are. Are there cases in which the decision makers are actually incompetent? Yes, but I bet in most of the cases it’s just a communication breakdown (It’s always the same). Here’s what you can do:

1. Bring the developers closer to the customers. Let them feel their pain and understand the way they think.
2. Encourage transparency and recurrent inter-team meetings. Bridge the gap between the business an the technology team. The tech team will always be more up-to-date with the trends (UX, Bootstrap 4, responsive-design, monochromatic vectorial icons, font-awesome…) and the business team will always know better what the customer pain points are. Communication and teamwork is crucial here.

A peaceful working environment that allows developers to think and have some privacy

Open-offices are trendy now in the developed world and it has always been that way in the developing world, because of cost. Well, that sucks and should be avoided. But if you can’t afford a different office layout, there’s still something you can do: Cultivate a culture of silence. Encourage people to avoid hallway talks, make more use of meeting rooms and ultimately keep their voices down. You don’t solve a complex algorithm with someone talking out-loud in the phone right next to you. I actually think this can be detrimental to your mental health. Coding is a labor of concentration. Let’s keep it quiet.

Last but not least, let the developers have some privacy. Don’t make them feel like they’re been eavesdropped all the time. Give them fresh air and a sentiment of trust.

A productive codebase

People are talking about User Experience all around but there’s also something called Developer Experience. Codebases get clunky over time, full of workarounds and difficult to work with and maintain. In order to keep your source code pleasant to work with, make sure part of the capacity is always dedicated to fix technical debt. You’ll not only contain the constant appreciation of story-points, but you’ll also improve the morale of the developers.

Up-to-date hardware and tools

I love it when the tools I use get an update. I’m an avid “release notes” reader and I love exploring what I can do now that I couldn’t before. Developers are like kids, give them the “toys” they want and they’ll be more productive. Also, make sure their hardware can handle the load. Often it pays off to give developers the best tools money can buy.

Hackathons

I’ve never seen a better example of self-organization and dedication as I’ve seen in hackathons. Developers often know of better and more modern ways of solving some problems but they aren’t always able to do it because “it’s not in the roadmap”. Hackathons are the best way for them to explore their creativity and do what they want, the way they want. It’s also an opportunity for developers to show their true potential and stand out. The results are often great and the business team will often be like “Great idea, why didn’t we think of it before?”. If you don’t promote hackathons already, it’s time to start.

Open-sourcing

Most organizations are often too concerned about their intellectual property to even consider open-sourcing. They are wrong. Here are some benefits:

1. It will help you attract the best talents in the industry. Developers love working on open-source projects because that’s a chance for them to do something that will transcend the company. This is something they’ll be able to put on their resumes; Something for which they’ll be remembered even after they leave the company (if they do); Something they’ll be proud of and possibly willing to work on for free out of the office.
2. Developers love creating tools for developers, like UI components, generic CLI tools and so forth. They’ll do it for free. If you don’t open-source, chances are someone will do it, and they’ll become the industry-standard and out of a sudden your “intellectual property” will be worth nothing.
3. Marketing. Your organization name will now be on GitHub and lots of review articles. If that doesn’t reach your final customers, it will at least make it easier for you to find great developers.
4. It will attract outside contributors. I know this is a double-edged sword because maintaining an open-source project will also come at a cost. But often the outside contributions will make up for the maintenance (This may not happen though, be aware).
5. It’s a way of giving back to the community, from which we took so much.

I’m not saying you should open-source everything, especially your core business. That would be insane. That’s what pays the bills. Here’s a small framework to help you decide what to open-source:

1. How close this project is to our core-business and how much advantage would the competition have if we made this publicly available?
2. How generic and useful is this to others? If we open-sourced it, how many other teams would actually benefit from it? Or even be interested in contributing?
3. If we don’t open-source it, what is the chance that someone else will?

Conclusion

In order to make developers productive, it’s important to understand what they want and what makes them happy. I hope this article helped shedding some light on the topic. Also, be sure to read The Joel Test: 12 Steps to better code. Awesome read.

Happy hacking!

To learn more about me, please visit http://andrerpena.me