8 principles for building a strong and explicit engineering culture

Thriving development teams have one thing in common: A strong and explicit engineering culture. It’s the guidebook by which they go about building, deploying, and operating amazing digital products, working as a team.

Here’s my own definition for what an engineering culture is: A set of principles upon which an organization or a team aligns its vision and its decisions regarding its engineering practices—both human and technical. In this post we provide an engineering culture example, sharing our own principles.

What does a strong and explicit engineering culture do?

A strong and explicit engineering culture clearly answers two essential questions: “How are we going to do this?” and “Why are we doing it this way?” Don’t define your engineering culture and it may come to define you. In smaller teams, culture may form implicitly—but as things evolve and the team grows, culture risks becoming just a habit—“We’ve always done it this way!,” rather than a deliberate intent to fulfill a common vision.

Explicit vs. implicit

No mind reading is involved in an explicit culture. The culture has been written down and is being openly discussed, never ceasing to be challenged, to match technological evolution and current best practices.

Abstract values vs. concrete principles

Everyone wants quality and performance. The real deal is what needs to be done to get there as a team. To resonate in the day-to-day life of developers, the culture needs to be expressed in concrete, applicable principles.

An engineering culture example

At Mirego, we’ve been thinking about and working on our engineering culture for several years.  We came up with this set of 8 core principles that help lead to better results, better craft, better processes and, in the end, better digital products.

1.   The importance of milestones.

Writing code is awesome. Pressing that “merge button” on GitHub is gratifying. The product may be the destination, but milestones along the way deserve to be celebrated. Being mindful of milestones breaks down a formidable project into smaller, more manageable chunks. Why miss out on the satisfaction and confidence that come from knowing we’re making good progress. 

2.   The importance of recipe.

Great teams do not try reinvent the wheel—but they always try to improve it. Even the best recipe is perfectible. We seek to constantly improve frameworks and tools, but we do it deliberately. Not every new trend is worth chasing. Trying new things also implies mitigating the risk of failure. Give it time, don’t change everything in the recipe at once, and be ready to lose some to learn some.  

3.    The importance of autonomy.

Larger, geographically spread teams face this conundrum: How to promote autonomy while also preserving a common vision? The answer lies in the difference between rules and guidelines. Guidelines provide the most flexibility. They will apply 90% of the time, while 10% of the time, they may be worth challenging. An example: Most of the time, we use Elasticsearch to build a search tool for our products—but at some point, there may be a good reason to consider another tool, we just need to make it clear what it is.  Setting guidelines simplifies decision-making while leaving enough room for making the best decisions.

4.   The importance of ownership.

This one is about striking the perfect balance between individual and collective ownership. It takes a village to raise good code (as the famous saying goes). But when does code stop being mine to become ours? At code review. Code review at Mirego is not about finding fault with someone else’s code, it’s about collectively coming up with ideas to make that code even better. It’s all about helping each other and sharing our best knowledge. That’s when it becomes “our” code.

5.   The importance of consistency.

Writing code makes you feel powerful. It’s real magic to see the stuff become a useful product. But it’s sobering to consider that 100% of the time, your code will be read and extended by more people than it took to write it in the first place (one: you). You’ll soon forget why you wrote the code in a certain way and others will scratch their head trying to figure it out. “Avoid clever code” are three words to live by, for the sake of productivity. Fortunately, it’s easier today to keep code clean and consistent, using easy-to-implement tools.

6.   The importance of patience.

Writing new code is the best part of the job. Taking the time to build a strong blueprint and thinking about it as a team can be a drag. But having to ditch fantastic code because it was (hastily) written based on the wrong assumptions sucks even more. Doing your homework first, rooting out any foreseeable issue and learning from teams who worked out similar problems makes for more confident coding—and breezy code review.

7.   The importance of communities.

Developers don’t have to work from scratch. We typically leverage a range of open-source technologies such as Elixir, React, GraphQL, Kotlin Multiplatform, and Kubernetes. Open-source technologies are supported by amazing communities, providing much more than code: best practices, production recipes, and battle-tested code samples that are production-ready. We embrace community contributions because they serve an important purpose: they standardize workflows across teams, facilitating the onboarding of team members. It’s a gift that keeps on giving. We contribute back to the community by sharing our own expertise working with these tools, for example library code, sample projects, and documentation contributions.

8.   The importance of the craft.

This last one encapsulates all the previous principles. It’s a mindset to grow by as a team. We’re not just writing lines of code, we’re crafting something bigger using this code. So, we might as well take the time to think it through and embrace every step of the way. The most trivial technical detail may turn out to be decisive in shifting from a good product to an excellent one. There is pride and value in seeking to create a stronger product.

This is just an example of principles which foster, in our opinion, a strong and explicit engineering culture—they’ve been working for us along the years and I think they can help your own team too!