Power to the Developers
I never understod why companies are building a strong management driven culture and destroy the creativity of the developers. We need freedom to build awesome software with great quality fast. That’s why some people see us as the prima donnas in a company. When our management gives us the freedom of choosing our own tools and processes we have to turn that trust into productivity and quality. We have to find a great development culture that we live and breathe every day. Culture is so important:
“Culture eats strategy for breakfast”
These are my 7 points how to build a great development culture and give the power back to the developers. It may not be complete but things can’t go really bad if you can follow these things:
1. Find a way to deal with customers
Customers suck! They find all the bugs and call you in the middle of a great pair programming session and destroy your mojo. It’s not a good solution to let just the support or some product managers deal with customers. Try to send developers to your users. Let them see how the tool is used that they are creating day in and day out. It’s not easy to find the right balance between “Getting things done” and learning the needs of the business. But your culture should make this absolutely clear: Everybody has to be at the front line and know what’s going on in the real world. Do daily stand ups and discuss customer requests. Meet customers frequently. This gives us the power to build the best software from a technical and a usability stand point.
2. Don’t be evil to your software (and don’t let other people tell you to be)
We all had this situation: Your boss or your customer asks you to do a quick hack. Just a small change that will drain your quality or it will just look bad. We want to please the people that are responsible for our payment. BUT: We have standards. We have to deal later with the technical dept. We have problems with scaling the software. Stay true to your principles. Say: NO! ..and at the same time try to educate your boss or your customer why this is a bad idea and why it’s important to hold your software development values high.
3. Show people why they are important
Why do people go to work every day? Yes, to earn money. But this kind of motivation is losing more and more traction nowadays. If you earn a certain amount of money, rewards doesn’t motivate you to be more productive in the long term. People want to get appreciated by humans for what they are doing. Not just once a year when you have your yearly conversation with your manager. Do it whenever you think: “Cool, that was great”. I had a great experience when I’ve send one guy from the team to the customer just to see how they use our software. He came back and said: “They really are productive using our stuff. They love it”.
4. Do your own thing
There are so many good ideas out there in the world. Don’t follow all of them. You should just pick those, that makes sense for your team. Don’t try to implement Scrum by the books. See what works, what doesn’t, get your own ideas and try them out! Don’t follow blindly another Guru that is trying to teach you the right way.
Developers should have the right to decide what works best for the team. But we’ve been studying for years, we fix problems every day and can’t decide how we work best? Developers should be treated like grown ups, not like 13 year old school boys. If we think a tool makes us more productive, let’s buy it!
5. Learning is everybody’s own responsibility
The company can send you to conferences or workshops and they can buy you books. But lets face it: You won’t learn anything from a 45 minute talk or if a book is just laying in the shelf. You have to take action! Nobody can help you with that, it’s your own responsibility. And we have to learn if we want to know what’s going on. Yes, there are some things to do together like coding katas or brown bags. But also here: It’s still the decision of each employee to take that power and use it for something good.
6. Change is the only constant
Do I have to say more? Think constantly about what sucks in your software development and change it! Don’t be afraid of new things or to pull the plugs on things, that have just currently been implemented but really doesn’t work out. Change and improve constantly.
7. Focus on quality and dev speed
Depending on the product you’re developing one or the other is a little bit more important. It’s sometimes hard to find the balance: If you put too much effort in quality, your deliver speed will slow down. If you’re delivering like a maniac, your quality will drain from that (you will see it in the long run). It is really important to always keep thinking about these two factors and to talk about them in your development team.
Credits for the pictures:
Couple designed by Jens Tärning from The Noun Project
Electrical Shock Warning designed by Travis Yunis from The Noun Project
Blindfold designed by Luis Prado from The Noun Project
Approve from The Noun Project
Interchange designed by Laurent Patain from The Noun Project
Speedometer designed by Olivier Guin from The Noun Project