Excellence is never an accident. It is always the result of high intention, sincere effort, and intelligent execution; it represents the wise choice of many alternatives - choice, not chance, determines your destiny.
– Aristotle
A common question for any engineering leader is what great engineering culture looks like. It’s an important question, albeit not an easy one. I wanted to write down my answer and I expect it to change continuously as I learn and gain new perspectives.
Principles 🔗
Process is important, but it’s an implementation detail. It’s great talent guided by principles that drive excellence.
We are empowered engineers.
Marty Cagan talks about empowered engineers as the most important thing for a successful product team, and I wholeheartedly agree. The best engineers are those who deeply care about the user and the strategic context within which they operate. Armed with care and context, engineers leverage their craftsmanship to solve problems worth solving and generate impact.
For a deep dive into what behaviors to look for in an engineer, I recommend Addy Osmani’s book Leading Effective Engineering Teams.
We build it, we own it.
Coined by Alex Ewerlöf, as an evolution of Werner Vogels’ (CTO of Amazon) quote you build it, you run it. We own the work end-to-end, including testing, the delivery pipeline, and product ownership. If our software doesn’t meet the expectations, i.e., there is an incident, it’s our top priority to fix it.
This is sometimes called shifting left and must be done mindfully to avoid exploding the cognitive load of engineers. Depending on the context, shifting left must be accompanied by effective platform engineering, intentional investment in upskilling, and careful staffing.
Quality and time are constants, scope is variable.
This is a powerful mindset that’s obvious among many engineers, but I’ve also seen cases where it isn’t, and what an unlock it can be once people get behind it. There is a common notion in engineering that deadlines are stupid, estimation is impossible, and therefore everyone should accept that things will take the time they take. I exaggerate a bit, but I’m sure some can relate.
It’s unfortunate that we, as an industry, have managed to create such a strong coupling between estimates and time. Estimation is not all evil, but endless discussions around improving estimations are. Time, however, is a powerful constraint (Parkinson’s law is real), and we can leverage it by changing our planning from being based on how long we think something will take to how much time we’re willing to invest (also, see appetite from Shape Up).
There are, of course, nuances to this, but when this mindset is fully embraced, it provides a simple decision-making framework that empowers teams and enables them to move with high urgency.
Software engineering is a socio-technical endeavor.
Software engineering is built by groups of people (for now). How those people work together is fundamental to the quality of the output. Subscribing to this principle means embracing team topologies (remember Conway’s law), promote practices like Architectural Decision Records (ADRs), pair and mob programming, do hackathons, ensure a sustainable pace, make sure engineers regularly talk to users, and being radically candid. Also, don’t forget to have a bit of fun.
Improvement is the goal.
The best teams are those that achieve elite improvement, not necessarily elite performance.
Software engineering, technology, and business are always evolving. There is no final destination. What truly matters is how quickly we learn as a collective. Continuous delivery is the way to ship. Retrospectives and post-mortems are musts.
Waste is the enemy.
We must be obsessed with reducing waste, otherwise, it will kill us. Adopt an SRE mindset and invest in developer experience.
Data is a first-class citizen.
Data is part of the definition of done. Invest in instrumentation, data models, and contracts. Dogfood teams with data to build analytics and improve the product. Make operations an input to design with observability.
Choose good design over bad design.
The alternative to good design is always bad design. There is no such thing as no design.
– Adam Judge
Effective design is a non-negotiable, and it’s achieved with good habits. Good design is primarily about making software do what it’s supposed to do while ensuring it’s easy to change. This is important because change is inevitable and a key cost driver in software engineering.
Practice continuous refactoring, tidying, applying the Boy Scout Rule, test-driven development (TDD), and domain-driven design (DDD).