What Engineering Excellence Actually Means (And Why Most Teams Miss It)

---

Every few months, a new engineering blog post goes viral about the right way to structure your codebase, the test coverage target your team should be chasing, or the architectural pattern that will solve your scaling problems. Engineers share it, bookmark it, and sometimes even build internal initiatives around it. Six months later, the codebase looks the same, delivery timelines haven't improved, and the next blog post has replaced the previous one in everyone's Slack bookmarks.

This is the cycle most engineering excellence initiatives live and die in. Not because the ideas are wrong, but because they start from the wrong definition of what excellence actually is.

I've spent fifteen years working with engineering teams across India and Europe — from ten-person startups in Bangalore building their first product, to enterprise teams in Germany maintaining a codebase older than some of their engineers. I've conducted over a thousand technical interviews. And in that time, I've watched the same pattern play out: teams that achieve genuinely excellent outcomes don't do it by rigidly following best practices. They do it by building shared understanding of what they're optimizing for, and then making consistent, principled trade-offs in service of that understanding.

Let me give you a definition you can actually use.

The Wrong Definition (And Why It Persists)

Ask ten engineers what engineering excellence looks like, and you'll get answers that cluster around the same few things: clean code, high test coverage, adherence to SOLID principles, low technical debt, good documentation. These aren't wrong — they're real signals of quality. But they're proxies, not outcomes. And when you optimize for proxies, you get teams that pass code review but can't ship, or teams that have 85% coverage across code that nobody cares about testing.

The wrong definition persists because it's easy to measure. Test coverage is a number. Cyclomatic complexity is a number. PR merge time is a number. These numbers are tractable — you can run a report, put them in a dashboard, and declare victory. The harder work is measuring whether your team is actually getting better at delivering value reliably, which requires you to look at outcomes rather than inputs.

There's also a social dynamic at play. In most engineering cultures, the people who write the cleanest code get the most respect. The people who make the hard system-level decisions that prevent future disasters are invisible, because the disasters never happen. This creates an incentive structure that rewards individual craft while systematically under-rewarding systemic thinking — which is exactly backwards from what produces team-level excellence.

A Working Definition

Engineering excellence is the sustained ability of a team to deliver the right things reliably, safely, and at speed — over months and years, not just in the next sprint.

Every word in that sentence matters.

Sustained means it compounds over time, not just this quarter. A team that ships impressively for six months and then burns out, or ships fast by accumulating debt that makes them slow in year two, hasn't achieved excellence. Excellence is a durable capability.

The right things means the team has enough context and product judgment to spend their engineering effort on problems that matter. Technical brilliance in service of the wrong problem isn't excellence.

Reliably means outcomes are predictable. Estimates are credible. Features work when they ship. Incidents are infrequent and, when they happen, are resolved quickly.

Safely means change doesn't introduce risk that exceeds the value it creates. The team can deploy without fear. Rollbacks are possible. Blast radius is understood before deployment, not discovered after.

At speed means the team isn't constantly fighting their own infrastructure, their own codebase, or their own process to get things done.

The Four Dimensions of Excellence

This definition maps onto four measurable dimensions, which I've borrowed and adapted from the DORA research that underlies Google's Accelerate book. The four dimensions aren't abstract — each has practical proxies you can observe.

Speed is about lead time and deployment frequency. Lead time is the time from a code commit to that code running in production. Deployment frequency is how often you successfully release. High-performing teams deploy multiple times per day. Median teams deploy somewhere between once per week and once per month. The difference isn't magic — it's the accumulation of practices that make deployments safe and cheap: feature flags, automated testing, incremental delivery.

Quality shows up as change failure rate (the percentage of deployments that cause a degraded service incident or require a hotfix) and defect rate (how many bugs reach production per sprint). A team with low change failure rate isn't necessarily writing more careful code — they have better automated test coverage, better code review practices, and smaller, less risky deployments.

Safety is about how the team behaves when things go wrong, which they always do eventually. Mean time to recovery (MTTR) is the most useful metric here. A team with excellent operational safety can get from "the service is degraded" to "normal service restored" in under an hour, even for complex incidents. That requires good observability, runbooks, and a culture where engineers don't fear taking action under pressure.

Sustainability is the hardest dimension to measure and the one most often sacrificed to improve the others in the short term. It shows up as developer wellbeing, team retention, codebase health (how easy is it to onboard a new engineer?), and the degree to which the team has capacity for improvement work as well as delivery work.

The trap most teams fall into is optimizing one dimension at the expense of the others. You can dramatically improve speed by cutting code review and skipping tests — but quality collapses. You can improve quality by requiring extensive review and staging environments — but speed suffers. You can improve safety by adding approvals and manual gates — but sustainability suffers, because nobody enjoys working through bureaucracy. Excellence is the ability to make progress on all four dimensions simultaneously, which requires trade-offs to be made explicitly rather than accidentally.

Why Most Excellence Initiatives Fail

When an organization decides to "invest in engineering excellence," it usually takes one of a few forms: a new linting standard, a test coverage target, a design review process, a new framework. These aren't bad investments. But they share a failure mode: they're imposed rather than owned.

An engineer who adds tests because a CI check will fail if they don't is not building a testing culture. An engineer who writes tests because they've internalized that untested code is incomplete — that the tests are part of the feature, not extra work done after — is building a testing culture. The behavior looks identical in a commit. The outcomes diverge over twelve months, as the first engineer finds ways to game the metric and the second engineer builds an instinct for testable design.

The deeper failure of most excellence initiatives is that they focus on symptoms rather than the system. You can't mandate your way to excellent code review by adding a policy document. You get excellent code review by creating conditions where genuine engagement is the path of least resistance: small PRs that are easy to review, a culture where feedback is expected and welcomed, reviewers who have time in their schedule, and a shared vocabulary about what good looks like.

This is why excellence initiatives fail when they're owned by a "platform team" or "engineering effectiveness team" and not by the engineers doing the work. Those teams can build infrastructure that enables excellence, but they can't create the values that make excellence happen. That's a team culture problem, not a tooling problem.

The Excellence Baseline

What does the top quartile of engineering teams look like in practice? Based on what I've observed across many teams, a few specific, observable practices distinguish high performers from median performers.

They deploy small changes frequently, rather than large changes infrequently. Not because they move faster, but because small changes are safe changes. When something goes wrong (and it will), there are ten lines to investigate rather than ten thousand.

They write tests before or during development, not as an afterthought. Not because they've been told to, but because they understand that a function without tests is a function you can't safely change later — and every function will need to change later.

They have runbooks for their most common operational scenarios. Not because management required it, but because 2 AM is a terrible time to learn how to do something for the first time.

They spend time every sprint on improvement work: refactoring, reducing tech debt, updating dependencies, improving CI speed. Not as a luxury when delivery is light, but as a consistent practice that keeps the maintenance burden manageable.

They conduct blameless post-mortems on incidents and near-misses, and they actually change behavior based on the learnings. Not the same learnings-from-incidents slide deck that's been updated since 2019 without ever changing the on-call runbook.

And critically: these teams have engineers who actually care about the craft, not just the paycheck. Which brings us to what is arguably the most important — and least discussed — dimension.

The Psychology of Craft

There is a measurable difference in the code produced by engineers who care about what they build and engineers who are simply completing assigned work. I've seen this at every level — junior engineers in their first job, senior architects with twenty years of experience. The quality of your engineering culture is fundamentally a function of how many people on your team are internally motivated to produce excellent work.

You cannot hire your way to this. Every engineer you bring in will calibrate their standards to the team's observed norms within the first two months. An excellent engineer joining a mediocre team doesn't raise the team's median — they adapt to it, or they leave. A mediocre engineer joining an excellent team will gradually raise their standards — or they'll be conspicuously out of step.

This is the broken windows effect, translated from criminology to codebases. When the codebase has obvious quality compromises — functions that are too long, tests that are clearly fakes, dead code that nobody has cleaned up in years — it signals that compromise is acceptable here. It lowers the implicit bar for new work. Each small compromise makes the next one easier. This is how a good codebase becomes a bad one: not in a single event, but by the gradual accumulation of signals that say "we don't care."

Conversely, a team that visibly cares — that comments on the craftsmanship of a particularly elegant solution in code review, that celebrates a PR that reduces complexity rather than adding features, that treats a well-written incident post-mortem as genuinely valuable — creates a social reinforcement loop that elevates standards over time.

This is not abstract. In concrete terms, it means that how your team talks about code quality in reviews, in retrospectives, and in casual conversation matters enormously. The vocabulary and norms you set in those interactions are the flywheel of engineering culture.

Starting From Where You Are

The last thing I want to leave you with is a practical starting point, because "build a culture of excellence" is not something you can do this week. But you can, right now, assess where your team stands.

Ask yourself these four questions, and be honest with the answers:

What is our lead time from commit to production? If you don't know, that's your first finding. Teams that don't measure this tend to underestimate it significantly. The actual number usually surprises people.

What is our change failure rate in the last quarter? What percentage of deployments caused incidents or required hotfixes? If you don't have this data, you don't have visibility into your production safety.

When was the last time an engineer on our team proactively improved something without being asked? And was it celebrated, or just expected? The answer tells you a lot about the culture.

If a new engineer joined tomorrow and had a question, how long would it take them to find the answer without interrupting a colleague? Good documentation and runbooks are a proxy for the team's investment in sustainability.

Wherever you are on those four dimensions today, that's your baseline. Excellence isn't a destination — it's the direction you're traveling and the speed at which you're moving. What matters is whether the practices you run this week will make your team measurably better in six months.

That's the question this pathway is built to help you answer.