How to Create a Great Engineering Culture ✨
A thorough guide about what great culture looks like, and how to make it happen.
We hear that all the time: we have to create a great engineering culture for our team.
This statement always sounds smart, but it doesn’t mean much. Anything you do is about culture — which makes culture one of those intangibles that is easier to acknowledge ex-post (”look! *That* is great culture”) rather than address it upfront.
I get many questions about this from readers, which are usually variations of three big ones:
What is culture, really?
What does great culture look like?
How do you make culture happen?
I wrote several articles about this in the past, which today I am consolidating into a full, longer guide, to answer exactly these questions.
I want this guide to be extremely practical. Most things you can find online about culture are fluffy: they may be inspirational, but not very actionable.
Instead, I want you to leave this article thinking: “ok, now I can do this and that”. This is always the goal of our pieces: give you practical ideas to apply on your team, backed by solid first principles.
So, here is our agenda today:
📖 What is Culture? — A quick intro to get on the same page with definitions.
4️⃣ The Four Pillars — The four elements you need to get right in modern engineering teams:
🏅 Ownership — driving impact and autonomy with broad responsibilities.
💬 Communication — optimizing for crafters and getting remote right.
✨ Simplicity — writing code like a toddler.
🏎️ Speed — shipping fast and often.
🏗️ How to Build Culture — Once you know how you want your team to behave, how do you make it happen?
Let’s dive in!
There exist plenty of inspirational, quotable answers to this question, like: culture is the behavior you reward, or, as a leader, culture is the example you give through your actions, and more.
There will never be a perfect answer and, frankly, it doesn’t matter, because I don’t find the question particularly useful.
Instead of nitpicking on what culture is and is not, let’s agree on a simple mental model where, in any team, there is work and meta-work:
Work — is the stuff you need to accomplish.
Meta-work — is how you do work: processes, procedures, principles, etc.
Culture is about meta-work.
Meta-work matters because sure, every team has their own way of doing things and that's great. But there exist a handful of key principles and strategies which we are starting to agree on, and which today are in the arsenal of most of the teams who are really nailing it.
In three years, by writing this newsletter, I have talked with countless tech leaders and read hundreds of articles and case studies about how engineering teams work. My opinionated take is that, whenever you look at a great team, one of those that always seem to fire from all cylinders, shipping valuable stuff everyday multiple times a day, they are very likely nailing four things:
🏅 Ownership
💬 Communication
✨ Simplicity
🏎️ Speed
Ownership and communication are about working together, while simplicity and speed are about your technical strategy. Let’s look at each of these items.
🏅 Ownership
In his bestseller book Drive, Daniel Pink argues our motivation is driven by three factors:
Autonomy — the desire to be self-directed. We get motivation and joy by having control over our lives.
Mastery — the desire to improve our craft. We get satisfaction by getting better at what we do.
Impact — the desire to have a positive impact on the world. We are empowered by work that serves a higher purpose.
I love this framework and I quote it all the time. In my experience, however, the three elements have different weights for different people.
I have met engineers who were extremely driven by impact, and others who cared more about mastering their craft. Engineers who wanted maximum agency, and others who were happy to fit in a tight process.
These are not rigid categories. It is a spectrum, and everyone falls somewhere on it.
Since teams are, basically, just groups of people, this is true for teams as well. And for companies: companies inherit their founders’ traits, because founders hire people who are similar to themselves.
Now, I have found that the best engineering cultures are driven by impact. Impact is about what the business needs to achieve: if people are aligned and motivated to go after it, everything else follows.
On the contrary, a strong culture of technical mastery that is not also hungry for impact, may end up in bureaucracy and overly complicated tech.
That is not to say technical prowess doesn’t matter: it does, but the three elements work like a Maslow’s Hierarchy of Culture: without alignment on impact you can’t have safe autonomy, and, without autonomy, you can’t get healthy mastery.
This shift towards impact and autonomy, in engineering, is leading to more and more engineering roles being identified by their area of impact — e.g. product engineer, customer success engineer — rather than their technical platform (mastery) — e.g. frontend engineer, backend engineer.
Out of these, the product engineer role is probably the most representative of the trend and has become a staple in modern successful companies like Stripe, Intercom, Atlassian, and more. We recently wrote about it in this piece.
💬 Communication
Once you empower engineers with autonomy, and you trust such autonomy to point in the right direction, you should create a structure that enables them to do their best work.
This is where one of the biggest feuds in engineering is fought — the one between Sync and Async companies.
This feud has always kind of existed. Recently, though, it was made worse by 1) the acceleration of remote work with Covid, plus 2) the strong opinions of some tech personalities — e.g. Elon on remote workers: “go pretend working somewhere else”.
It is true that there exist many examples of extremely inefficient remote / hybrid setups. In many cases, these are from companies who were, almost overnight, forced into this transition, so you can’t 100% blame them.
The result, though, is that in many circles, bad examples have created a backlash against remote work. This backlash is in turn baffling for productive remote companies, who have been doing their thing for years, and blame bad managers and hustle culture for the push back.
I believe that, at its core, this conversation shouldn’t be about remote — it should be about how communication and collaboration happens.
Today, in 2024, we should all agree on three ideas: