My Philosophy on Delivery: The 'Why' Behind Engineering
As a leader, I'm often asked about my management philosophy or what I expect from an engineering team. Over many years of leading teams at companies like Spotify and Datadog, and now as a co-founder, I've found it helpful to distill this down to a single, core concept: Delivery.
It may sound obvious, but understanding what "Delivery" truly means, in all its dimensions, has been the most effective tool I've found for managing teams, justifying decisions, and building a sustainable, high-performing engineering culture.
This essay outlines that philosophy. It's the "coat hanger" I use to frame my thoughts, and I hope it gives you a clear insight into how I think about engineering leadership.
The Raison d'être of Engineering
Years ago, I asked myself a simple question: "What is the fundamental reason an engineering team exists?"
My conclusion: We are here to deliver.
This isn't just about shipping code. It's about a professional commitment to move things from "idea" to "done" in a predictable and sustainable way. This simple framing helps cut through ambiguity and focus on what matters. It's the standard I use to evaluate decisions.
The Three Dimensions of Delivery
Just saying "we deliver" isn't enough. "Delivery" is not a single point; it's a balance of three critical dimensions. The goal isn't to maximize one but to find the right balance for every situation.
- Timeliness
- Quality
- Sustainability
These three aspects are interconnected. You can't change one without affecting the others. If you rush to maximize timeliness, you will almost certainly sacrifice quality and sustainability. If you aim for 100% "perfect" quality, your timeliness will stretch to infinity.
The key is to understand the trade-offs and make them consciously.
1. Timeliness: Delivery as an Agreement
Timeliness is not "as fast as possible." It is about delivering according to an agreement between an engineering team and its stakeholders.
This agreement is a two-way street that requires professionalism from both sides:
- The Stakeholder's Role: To define what needs to be built and why.
- Engineering's Role: To define how it will be built and how much effort it will take.
Fixing both the scope and the deadline without engineering input is a classic recipe for failure. Engineers need to provide realistic estimates, explain capacity, and be transparent about what is possible.
A simple illustration:
Imagine a team has capacity for one substantial project this quarter, but two stakeholders each need theirs delivered.
"We need Project A done this quarter."
"We can do that. But with the same team and scope, it means Project B has to wait."
"But we need Project B, too."
That isn't a problem an engineer can solve by making a more optimistic promise. It requires a choice: change the scope, change the timing, or decide which outcome matters more.
Making that trade-off visible gives stakeholders meaningful control over priorities, without asking the team to commit to work it cannot realistically finish.
2. Quality: A Deliberate Standard
Quality starts with an agreed baseline: code that works, meets the team's coding standards, is well-tested (automated or manual), and is architected soundly.
But "quality" is also a dial, not a switch. Sometimes, the right business decision is to hack something together—a "quick and dirty" solution—to get it out the door and validate an idea. Other times, for foundational services, we must invest heavily in quality because we know the code will last for years.
The key is to be intentional about this. Teams need to discuss how far to take quality for any given project, without compromising essential safety, security, or correctness.
3. Sustainability: Managing Tech Debt
Sustainability is distinct from quality. It's about the long-term health and longevity of systems and people. How sustainable is this delivery? Will this code be a maintainable asset or a liability in six months? Is the team burning out to meet deadlines?
When we make a conscious decision to sacrifice quality for timeliness (that "quick and dirty" fix), we are taking on technical debt. This is a perfectly valid and often smart business decision.
The mistake is forgetting we did it.
My recommendation is to track the corners you cut. When a team makes a conscious trade-off against quality or sustainability, it should:
- Acknowledge it during the planning phase.
- Document it clearly.
- Create a ticket for the tech debt and put it in a backlog.
This makes the accumulating debt visible and creates an opportunity to plan repayment, rather than being surprised by a wall of maintenance work later.
The Leader's Role: Creating the Environment
If the team's raison d'être is Delivery, then my raison d'être as a leader is to create an environment where delivery happens and continuously increases across all three dimensions.
If we could (hypothetically) quantify "Delivery" with a single metric, my entire job is to make that number go up over time.
How do we do that? We grow our people.
How We Grow Delivery
Growing delivery isn't about pushing people to work harder. It's about removing friction and investing in a team's capabilities, autonomy, and well-being.
- Leverage Strengths: I firmly believe that people are most effective and happiest when they are leveraging their strengths, not just mitigating their weaknesses. People are good at things they like, and they like things they're good at. My job is to find what you excel at and give you challenging work that lets you do more of it.
- Autonomy and Agency: The best solutions come from the people closest to the problem. I want to foster an environment where engineers have a strong voice in how things are built and the autonomy to choose the work they are best suited for.
- Transparency and Feedback: We need a culture where feedback flows freely—between peers, to managers, and from managers. This requires a high-trust environment where people feel safe to speak up and know how to both give and receive feedback constructively.
- A Safe and Inclusive Workplace: This is non-negotiable. Delivery plummets when people don't feel safe, heard, or respected. I am a huge proponent of diversity and inclusion. A diverse team brings a wealth of different experiences and views, leading to richer discussions and better products. We must actively foster a safe environment, which is why I'm a big believer in things like Employee Resource Groups (ERGs) that provide a community for minorities and a safe space to connect.
- Removing Friction: Finally, we grow delivery by removing the small, daily frictions that get in the way. This is why you see tech companies provide perks like great healthcare, food, and other benefits. It's not just to be competitive. It's a pragmatic investment. If we can remove worries or frictions from your daily life, you will be more focused, effective, and capable of doing your best work.
Every leadership decision, from architecture to people practices, can be measured against this one standard: "Does this help create a better environment for delivery?"