Building Your Dev Culture
Key values to create the foundation for your culture
Creating an amazing dev culture is critical to the success of your company. As your team grows, you need to make sure that everyone is on the same page has holds the same values as you do. How can you hire people that are the right fit if you don’t even know what that fit is?
Building a dev culture from scratch is hard, and pin-pointing and naming the qualities that you value can be even harder. Here is a list of core principles that make up a great dev culture for developers to work in.
Communication
Communication shows up on every management list imaginable, but it’s for good reason. Tribal knowledge will slow down your delivery, create bottlenecks within the development team, and will cause technical debt within the project to rise drastically.
When your team isn’t communicating with each other, each developer has their own understanding of the system. They might not know about a utility class that another developer created, so they roll their own. Another might not understand the implications of adding a package, so the build size for the application increases drastically.
Developers should talk with their peers. Facilitating this communication can be difficult, but make sure team members are confident in their understanding of the product or system they are working on. In agile, teams often to daily stand-ups where the purpose is to share knowledge, but often, teams treat it as a simple daily roll-call and rarely go into any actual shared understanding. Get teams to share details and ask questions during those stand-ups.
Senior developers should make sure to share knowledge and understanding with their team. I’ve seen all too often senior developers not sharing their knowledge of systems or code since “it’s too complicated for the junior members to understand.” What ends up happening is that senior member hoards knowledge and now whenever a change impacts that system, there is only one developer with enough knowledge on that system to implement the change. The team has created a bottleneck to product delivery by not communicating.
Of course, communication goes both ways. You and your team members have to be willing to listen to each other. The best way to communicate with others is to listen to what they have to say.
- Make sure developers have a shared understanding of the systems they work on
- Write down and share tribal knowledge
- Listen
Take Responsibility
Everyone in development should aim to take responsibility for the work that they do. This includes responsibility for quality code, code reviews, communication, bug fixes, and feature delivery. If your team does sprints, they should take the sprint commitment seriously and work with the product owner and scrum master to set realistic expectations.
But, sometimes a feature will take way longer than originally planned. Sometimes bugs impact much more than originally thought. Or the architecture that is currently being used needs to be completely rebuilt. Rather than making excuses, developers should provide options. That is part of taking responsibility as a developer.
In order for developers to take responsibility though, the environment they work is must be functional. Teams must communicate, build trust, and have healthy arguments. Otherwise they will fall into the trap outlined in The Five Dysfunctions of a Team: they will fear committing to responsibilities.
- Take responsibility
- Provide options
- Don’t make excuses
Always Be Improving
There is a Boy Scout principle titled: “Leave No Trace.” While that might be a good principle with forests and nature, with programming and development, I prefer:
“Leave this world a little better than you found it“
— Robert Baden-Powell
Developers should be actively working to improve their code base. When a change is introduced to a system, that system has become more complex. The only way to combat this is to continuously clean and refactor code.
You can think of this as Software Entropy. The technical debt of a project is always increasing. To combat this, you must instill in the dev culture the need for developers to always work to improve the code base. This mindset is outlined beautifully in The Pragmatic Programmer.
This also applies to the developers themselves. Each developer should strive always be improving. Every day, developers should make a little progress, even if that just means updating documentation, or adding testing code coverage to a module.
“…you have to move forward every day” — Joel on Software
- Technical debt is always increasing
- Leave your code better than you found it
- Strive to improve yourself
Ensure Quality At Every Stage
Imagine a team that doesn’t ensure quality at every step. At first, the team will appear extremely productive. The team is taking tickets and releasing them as soon as they are done. The developers do not waste any time with architectural discussions, coding best-practices, or code reviews. They ship features quickly and deploy manually. When end-users begin using the software, they start finding and reporting bugs (or worse, the end-users simply leave and never come back).
The team begins working on bugs as soon as they get them, but without any tests, they fear that they may break other features. The team starts to slow down. They are now taking on more bugs and technical debt stories than they are features. The developers begin to fear deployments since they have no confidence that they haven’t caused regressions. Deployments themselves become error-prone since they weren’t automated. Slowly, the team will barely deliver any features, and when they do, the delivery will be later and later.
Often, an agile team at this point will start extending sprints, making cycle times longer and longer so that the team can deliver “on-time.” It’s a viscous cycle outlined in The Phoenix Project.
To combat this, developers should aim to ensure quality at every stage of the software delivery cycle. Quality stories. Quality architecture. Quality code. Quality testing. Quality delivery. By introspecting their code and their processes, the team can begin to ensure that at each point of work, the product is getting better.
The benefits are two-fold: first, end-users will get a quality product. They will experience fewer defects since the developers helped ensure quality stories and quality testing. Users will get updates faster since the team no longer has to waste cycles fixing bugs for features long after the software was delivered.
Second, with the team focusing on quality of architecture and code, the technical debt of the work done will be minimized. The developers can focus more on features, and less on technical debt.
- Build a culture that values quality
- Focus on quality at every stage of the software delivery cycle
Conclusion
The dev culture qualities all build upon each other. It’s tough to continuously improve if no one is taking responsibility, and it’s hard to take responsibility if no one is communicating. Similarly, if the team is not onboard with constantly improving, then it’s very hard to have the team ensure the quality of software at every stage of the software delivery process.
By instilling these cultural values, teams will be able to work consistently and effectively. They will have shared understanding of the problems they are working on and will help each other improve. By talking and building trust, developers will not fear commitment and responsibilities.
Ivan Montiel is the UI Architect at Nextiva and the founder and CEO of Clarity Hub.
