Let’s face it. Developer experience is a buzzword. That means it gets talked about a lot in general terms, with very little substance or definition.
That’s why I was inspired to start the Dev-X Project - an initiative to bring more texture and definition to the developer experience discussion. In each “episode” I ask an industry leader 10 questions about developer experience to gather their insights and opinions on these specific topics. I then publish these discussions and share them with the community.
With nearly 20 interviews under my belt, there’s now enough material to start aggregating it in useful ways, and uncover some interesting trends and repeating themes.
This is the ultimate guide to creating a great engineering culture. One of the questions I’ve asked in the DevX Project interviews is “what are the key ingredients to a great engineering culture”.
It’s an important question because at the end of the day everything in your company will be impacted - for better of for worse - by the culture you’ve created. As Liran Haimovitch put it: “culture eats strategy for breakfast, because culture allows your teams to act in predictable ways in unpredictable circumstances.”
So, what is culture exactly? Good question. I deliberately left that part open to interpretation, and the responses were equally wide-ranging. Some interviewees focused on the developers themselves. Others focused on companies and company policy. Some gave technical or professional advice while others offered interpersonal relationship and communication tips.
And this is the first and perhaps the most important point of all. A truly great engineering culture needs to balance multiple items in parallel.
The specifics may vary per organization and per situation, but the common denominator is the need for a three-dimensional culture-building approach.
So I hope you enjoy this developer experience guide to building a great engineering culture, collected and adapted from The DevX Project interviews.
Several DevX Project features echoed the importance of creating a culture of freedom and autonomy for developers.
As Seif Lotfy from Axiom put it: “I think it really leans on to what Dan pink talks about in his book “Drive - The surprising truth about what motivates us”. He introduces autonomy, mastery, and purpose as key motivation factors. So when you give developers the autonomy to master their craft, they also develop a purpose that creates a great culture… And don’t force tools on engineers. I think you should let your engineers choose their own tools. Empower them with autonomy and ownership.”
Viktor Farcic added: “The most important thing to me is the freedom to make decisions. Many companies, I believe, are treating engineers as if they are children - holding their hands, telling them what to do. Now you can cross the street, now you need to stop. Now you move left now you go right. To me, this can be really crushing to any creativity and any ability to learn among developers. This is devastating because I believe that most of our job as developers is thinking and figuring things out. Writing code is easy. Once you know what to write and assuming that you have at least a basic understanding of syntax and stuff like that, writing code is the easiest part of the process. Figuring out what to write and how to write it - that’s the complex part. And if we do not provide sufficient freedom to people to figure this stuff out, then we end up with the results we didn’t want - stuff doesn’t work because the developers were just robots who did exactly what you told them to without any thought or creativity of their own.”
The benefits of developer autonomy aren’t limited to technical decisions. It can also help foster better interpersonal relationships among team members. Seif Lotfy emphasized the benefits of creating authentic relationships and he explained that “Beyond the super-professional relationship, give the team the freedom to move around and be themselves and appreciate each other for who they are.”
Autonomy means letting people be the best, authentic versions of themselves. And when this happens, it often yields positive results for the team and the company.
It also helps, as Barak Schoster said, if you can “hire smart people who are fun to work with”.
Giving developers autonomy dovetails with the need for developers to take proactive ownership and accountability for their work.
According to Liran Haimovitch, ownership and accountability are two of the most important elements in any great culture.
Shawn “Swyx” Wang emphasized that this ownership should be “proactive ownership”: “Item #9 on Amazon’s list of 16 leadership principles - “a bias for action”. I feel like that’s important in this context, because a lot of things don’t get done if you don’t take proactive ownership over them. So this is really important for a healthy, engineering culture.”
Seif Lotfy reflected that it’s important for developers to communicate and ask why: “Make sure you understand the thought that went into other people approaches and decisions. That way, even if you disagree, you can take everything into consideration and try to find the best possible path forward.
Amir Shevat added that this shouldn’t depend on someone asking for an explanation. You should build a culture that offers the “why” up front:
“Share your knowledge and explain why you went with x and not y. That way people can learn from you and adopt your best practices and your unique line of thinking in their day-to-day as well.”
A similar and no less important value is transparency.
Amir Shevat explained: “Transparency is very important. This means creating an environment in which engineers can see the bigger picture - where we’re going, why we’re doing what we’re doing. Creating this type of environment for developers will enable them to create better code.”
When communication and transparency are properly maintained, you also gain another key culture ingredient in “Integrity”. As Amir put it: “If you think something is not right - speak up. Processes can and should change and evolve for the better.”
Shem Magnezi from Wilco offered a similar perspective: “The key is to always think about what we can improve: in our system, processes, product, code style, monitoring tools and what not. There are countless aspects to building a system and it will never be perfect—but we should always look for ways to improve.” This is a way that communication, transparency and integrity manifest themselves in a good engineering culture.
Swyx And Jason Bosco both suggested that a blameless feedback and post-mortem culture is critical.
In Swyx’s words: “When you ship stuff and you’re maintaining things in production, remember that things will always break. So having a blameless post-mortem culture is important too.”
This was also echoed by Amir Shevat who added that everyone on the team should be open to receiving feedback: “As a general rule, engineers that are open to feedback from each other are much better at doing their job.
And how can you achieve a zero-blame culture? According to Seif Lotfy, it starts by working on your underlying assumptions: “It’s mportant to develop an underlying assumption that everyone means well. This is particularly important with distributed teams who are on different time zones and schedules.”
If everyone assumes that everyone else means well, and each team member is open to feedback without blame - the team will be well positioned to get things done effectively.
Adam Gordon Bell from Earthly.dev put it this way: “A great culture is based trust and understanding. Both of those build over time based on shared experiences.”
Not surprisingly, collaboration as a key ingredient to engineering culture was a message that echoed throughout several of our interviews.
As Hila Fish from Wix put it: “You need to collaborate with others to surface the best solutions, and to make sure the end goal is achieved.”
And Amir Shevat explained: ”I think that a team of people who are collaborative will always outperform a less collaborative team, even when that less collaborative team is filled with “amazing” individual engineers. I’ve personally been part of engineering teams that were not so collaborative. They had awesome, amazing engineers, but they didn’t really share what they were doing. It’s far more beneficial when people start to collaborate, share, provide feedback and talk about the interfaces between what each person is working on.”
A passion for the craft and the product
Tom Snelling from Norhflank said: “I think the best thing a team can have is genuine passion for the product that they are building. Having worked on projects that I both have and have not been invested in, the difference in morale (and thus output) is amazing. When engineers really care about what they’re working on, I think culture improves tenfold. Hire smart people that want to work on your project.”
Amir Shevat emphasized the importance of professionalism in creating a great engineering culture: “Always think about the company’s needs. This should apply to every aspect of your work… And while being technical is great and even necessary, training your business mindset would really help create a culture where preference is not given to only the most technical solutions, but rather to the solutions that help achieve the best outcome for the company.”
Gil Tayar from Roundforest agreed: “To me, the key ingredients to a great engineering culture are: Nice people. Not a lot of ego. Professionalism and pride in the craft. These elements establish a creative environment and without these ingredients, it’s hard to create a positive, productive culture.”
From a more technical perspective, Swyx advised that teams place on emphasis on their documentation: “A good documentation or design doc culture is pretty important as well. In other words, before you implement something, you should obviously try to design it and think through the propositions and agree on the high-level stuff with everybody. But a good culture takes this one step further. It means that everybody actually reads the doc when they receive it. And that’s quite rare. So a good documentation culture means good writing and also good reading so you catch design issues and mismatched expectations sooner rather than later.”
Amir Shevat highlighted the value of a healthy delivery cadence: “Having a healthy cadence of delivery is also very important to engineering culture because when a team continues to deliver, they are able to regularly reap the benefits of happiness and satisfaction from their work.”
Barak Shoester similarly encouraged teams to “optimize for iteration speed”.
And Jason Bosco said: “Some of the key ingredients for me are: Reducing the time it takes between an engineer writing code and users using it, paired with effortless rollbacks…”
While this came up in some form or another in many of our interviews, Sunil Sandhu from Circut and In Plain English put it well: “Humility ranks high for me and that’s not just for engineering, but work cultures in general. Team members should be willing and ready to help others, nurturing an environment where nobody feels that a question is too stupid to ask.”
I think there are a lot of cliche answers I could give here and, to some extent, I feel that there are many more experienced developers who could answer this better. So one final thing I’ll put forward is that when a team is mission-orientated, and that team are all singing from the same hymn sheet, amazing things can happen.
And in the words of Gil Tayar: “To me, the key ingredients to a great engineering culture are: Nice people. Not a lot of ego. Professionalism and pride in the craft.”
Obviously, a good engineer needs to have a certain baseline of technical capability. But when building and managing a team, it’s these additional factors that will ensure that they hold each other to high standards, stay curious, remain positive, and continuously strive to improve.
And that’s what a great engineering culture is all about.
Like what you see here? Want to get featured? Check out our DevX Project for other great features and to apply to share your own developer experience wisdom.
Also published here.