← Back

Technical Excellence Is Defined by Your Weakest Link

September 4, 2026

As engineering organizations grow, technical excellence becomes harder to maintain.

Not necessarily because the best engineers become worse. In fact, you can have individual teams that continue to operate at an extremely high level.

The problem is that the quality of the organization as a whole becomes increasingly determined by its weakest links.

One unreliable service can make an entire product unreliable.

One team that consistently creates operational problems can consume the attention of five other teams.

One poorly designed integration can force everyone around it to build workarounds.

One person whose work repeatedly needs to be fixed by others can quietly reduce the effectiveness of an entire team.

You can have pockets of technical excellence.

But your users do not experience pockets.

They experience the complete system.

And the complete system is often only as strong as the weakest part everyone else is forced to depend on.

Growth creates more weak links

This problem becomes more pronounced as organizations grow.

A small engineering organization has relatively few boundaries. People know each other. Context travels quickly. Standards are often implicit because many engineers share roughly the same understanding of what good looks like.

As the organization grows, you introduce more teams, services, handovers, dependencies and management layers.

Every new boundary creates another place where quality can be lost.

Eventually, you may also become part of an even larger organization.

Now you are no longer only dealing with engineering decisions made inside your own team.

You inherit platforms, processes, architectural decisions, security requirements, infrastructure standards and organizational policies created elsewhere.

Some of those things will make you better.

Others won't.

And this is where maintaining technical excellence can become surprisingly political.

It is tempting to simply accept whatever the larger organization considers its standard.

After all, standardization has real advantages.

Shared platforms can reduce duplication.

Common processes can make collaboration easier.

Centralized capabilities can be much stronger than what every team could build independently.

But standardization around a lower bar is still lowering the bar.

If a shared platform makes your system less reliable, a mandated process dramatically slows your engineers, or an organizational standard materially reduces the quality of your product, engineering leadership has a responsibility to challenge it.

Sometimes protecting technical excellence means being inconvenient.

Raise the floor, not only the ceiling

Engineering organizations spend a lot of time thinking about how to raise the ceiling.

Hire exceptional engineers.

Introduce better tools.

Adopt better architecture.

Improve developer experience.

Use AI.

All of those things matter.

But I think we underestimate the importance of raising the floor.

A few exceptional engineers cannot indefinitely compensate for an organization where other parts consistently operate below the required standard.

The strongest engineers will compensate for a while.

They will review more pull requests.

Fix incidents they did not cause.

Rewrite poor implementations.

Explain the same concepts repeatedly.

Take ownership when nobody else does.

Add another workaround around the same unreliable system.

And because the organization keeps functioning, it can look like everything is fine.

It isn't.

You are consuming your strongest people to subsidize your weakest links.

There is a hidden compensation tax.

A task still gets completed, but somebody else spent two hours fixing it.

An incident still gets resolved, but the same three engineers once again dropped everything to investigate it.

A service stays online, but only because someone knows the undocumented ritual required when it breaks.

A weak integration remains in place because every consumer has learned how to work around it.

Individually, these costs can look small.

Together, they become permanent organizational overhead.

And because capable people are good at compensating, the true cost can remain hidden for years.

Eventually, either quality drops or your strongest people become frustrated.

Usually both.

Weakness is inevitable. Propagation is not.

The goal is not to create an organization with no weaknesses.

That is impossible.

Not every service will be equally elegant.

Not every team will be equally experienced.

Not every engineer will have the same strengths.

There will always be legacy systems, mistakes, temporary compromises and areas that need improvement.

The more important question is whether those weaknesses are contained.

A mediocre internal system with a small blast radius may be perfectly acceptable.

A fragile service that every important workflow depends on is not.

Good architecture does more than make systems clean.

It stops weaknesses from propagating.

Clear interfaces help.

Isolation helps.

Ownership helps.

Graceful degradation helps.

Good defaults help.

Reducing unnecessary dependencies helps.

Technical excellence therefore isn't only about making every component excellent.

It is also about ensuring that one weak component cannot quietly lower the quality of everything around it.

Technical excellence requires capable people

There is no process that can completely compensate for a lack of expertise.

Good tooling helps.

Documentation helps.

Code reviews help.

Automated testing helps.

Architecture guidelines help.

AI will increasingly help.

But none of these things remove the need for engineers who understand what they are doing.

For me, technical excellence means having people who can take real ownership of their work.

They understand the systems they change.

They think about what happens in production.

They investigate when something breaks.

They care about maintainability rather than only completing the immediate task.

They understand that their decisions affect people outside their own team.

And importantly, they continue learning.

That does not mean everyone needs to be the best engineer in the company.

Nor does everyone need the same strengths.

Some engineers are exceptional at architecture.

Others at debugging.

Infrastructure.

Product thinking.

Communication.

Or turning complicated problems into simple systems.

But everyone needs to meet the bar required by their role and by the organization around them.

Technical excellence cannot exist only in the top 10 percent of the engineering organization.

It has to be distributed.

A weak link is not always a weak person

This distinction matters.

Before concluding that someone is the weak link, make sure the organization has not designed a system that makes them one.

A strong engineer can become ineffective because they own too much.

Because nobody gave them the necessary context.

Because the architecture is fighting them.

Because responsibilities are unclear.

Because management repeatedly rewards short-term delivery over long-term quality.

Because they inherited a system nobody understands.

Because they are placed in a role that does not match their strengths.

Performance problems are not always individual problems.

Sometimes the right fix is better leadership.

Sometimes it is clearer expectations.

Better onboarding.

Different team boundaries.

More support.

A better platform.

Less unnecessary complexity.

But the opposite is also true.

A good process cannot indefinitely hide a persistent capability problem.

Leadership needs to know the difference.

Guardrails make excellence scalable

Technical excellence should not depend entirely on individual heroics either.

As organizations grow, it needs guardrails.

Make the good path the easy path.

Provide sensible defaults.

Automate the things that should not depend on somebody remembering them.

Have strong CI/CD pipelines.

Make observability standard.

Make security controls part of the platform.

Create clear ownership.

Make incidents visible.

Make architectural decisions understandable.

Build tooling that allows engineers to do the right thing without constantly fighting the organization.

Good guardrails raise the minimum quality of what the organization produces.

They also reduce how much expertise is required for every individual decision.

An engineer should not need to be an expert in TLS, Kubernetes, authentication, observability and database backups just to ship a normal product change safely.

The organization should provide good foundations.

But guardrails have a limit.

They can prevent many mistakes.

They cannot create judgment.

At some point, someone still has to understand the problem, make a trade-off and take responsibility for the result.

What you tolerate becomes the standard

Organizations have written standards and actual standards.

The written standard might say that services need monitoring, ownership and tests.

The actual standard is what happens when a service has none of those things.

The written standard might say that engineers are responsible for production.

The actual standard is what happens when somebody repeatedly ships problems and other people quietly clean them up.

The written standard might say reliability matters.

The actual standard is what happens when deadlines conflict with reliability.

People learn very quickly which standards are real.

That means technical excellence is shaped as much by what leaders tolerate as by what they say.

If exceptions become permanent, they are no longer exceptions.

They are the new standard.

This also applies to performance.

If someone consistently cannot meet the required standard, you have to deal with it.

The first response should obviously not be termination.

Expectations need to be clear.

People need honest feedback.

They need the opportunity to improve.

Perhaps they need mentoring, different responsibilities, more context or a role that better matches their strengths.

And the organization should examine whether it created the problem itself.

But there comes a point where protecting one individual from a difficult decision means transferring the cost to everyone else.

Other engineers compensate.

Managers compensate.

The product compensates.

Eventually, customers compensate.

If someone repeatedly cannot operate at the level the team requires despite clear expectations, meaningful support and genuine attempts to help them succeed, keeping the situation unchanged indefinitely is not fair to the rest of the organization.

Leadership sometimes means making that decision.

The same applies to teams and systems.

If one team repeatedly produces systems everyone else must work around, the answer cannot permanently be that the rest of the organization gets better at compensating.

You have to fix the source of the problem.

Protect your boundaries

The same principle applies when your team becomes part of a larger organization.

You need to understand which things you are willing to standardize and which things are worth protecting.

Not every difference is worth fighting over.

Local optimization can easily become arrogance.

"This is how we have always done it" is no better an argument than "this is how the organization does it."

Sometimes another team genuinely has a better way of doing things.

Sometimes a shared platform is better than your local solution.

Sometimes accepting a slightly less elegant solution creates a much larger benefit for the organization as a whole.

Technical excellence does not mean refusing compromise.

But neither should standardization automatically end the discussion.

There should be a reason.

If adopting something reduces reliability, engineering velocity, security or product quality, challenge it.

Bring data.

Explain the trade-off.

Offer alternatives.

Run experiments.

Escalate when necessary.

Fight differences that materially affect outcomes.

Do not waste political capital fighting over preference.

Technical leadership is partly about knowing which battles actually matter.

Because once a lower standard becomes normal, raising it again is much harder.

Technical excellence does not maintain itself

Technical excellence naturally decays if nobody actively protects it.

Shortcuts accumulate.

Systems become more complicated.

Temporary exceptions become permanent.

New dependencies create new failure modes.

Knowledge gets diluted.

People leave.

Standards that were once obvious become tribal knowledge and eventually disappear.

A system that was beautifully designed five years ago does not remain beautifully designed simply because nobody deliberately ruined it.

Complexity grows.

Understanding does not automatically grow with it.

Without deliberate pressure in the opposite direction, quality drifts downward.

That is why technical excellence cannot just be something written in company values.

It has to show up in hiring.

In onboarding.

In performance management.

In architecture.

In tooling.

In incident handling.

In which shortcuts get repaid.

In which standards are enforced.

In how weaknesses are isolated.

In what leaders tolerate.

And occasionally, in what leaders are willing to fight for.

Your best team demonstrates what your organization can achieve.

Your weakest critical dependency determines what your organization can reliably deliver.

So keep raising the ceiling.

But spend at least as much energy raising, protecting and enforcing the floor.