In the previous post, How to Sabotage a Technology Company From the Inside, I suggested that the fastest way to destroy value is to make engineering increasingly sophisticated while gradually disconnecting it from the needs of the business.
The satire works because none of those behaviours require bad intentions. Most are the result of sensible instincts applied without enough context, discipline or experience.
The alternative is surprisingly straightforward.
Good technical leadership is often less exciting.
It is mostly about making sensible bets, understanding trade-offs, preserving optionality and directing engineering effort toward things customers and the business care about.
Here is what that looks like.
1. Start with the problem, not the technology
Technology decisions should begin with a sentence that contains no technology.
For example:
“Customers are abandoning onboarding because setup takes too long.”
“We cannot release safely more than once a week.”
“Our infrastructure cost is growing faster than revenue.”
“Our support team cannot diagnose customer problems.”
Only after agreeing on the problem should technology enter the conversation.
This prevents a surprisingly common failure mode where somebody discovers an interesting technology and then searches for a sufficiently important problem to justify using it.
Technology should be pulled into the organisation by problems.
It should not be pushed into the organisation by enthusiasm.
2. Prefer boring technology
Boring technology is underrated.
It has documentation.
It has Stack Overflow answers.
It has known failure modes.
People know how to hire engineers who understand it.
Someone has already discovered most of the catastrophic mistakes you can make with it.
This does not mean never adopting new technology.
Boring does not mean old. It means understood.
It means the burden of proof should sit with the new technology.
If PostgreSQL works, use PostgreSQL.
If a Rails monolith comfortably handles the business, keep the Rails monolith.
If a managed service solves the problem, strongly consider paying somebody else to operate it.
Complexity is not free.
Every technology you introduce becomes something the organisation must understand, monitor, secure, upgrade and eventually replace.
3. Demand a meaningful improvement before replacing something
Replacing existing infrastructure has an enormous hidden cost.
Migration.
Retraining.
Production risk.
Lost delivery time.
New operational knowledge.
New monitoring.
New failure modes.
For that reason, replacing something that is 90 or 95% good with something theoretically better is rarely worthwhile.
A useful heuristic is:
Don’t migrate because something else is slightly better. Migrate because the existing thing has become materially unacceptable.
The improvement should be obvious.
The improvement should comfortably exceed the cost and risk of changing.
Five-percent improvements usually disappear inside migration costs.
4. Experiment where failure is cheap
New technology is valuable.
So is experimentation.
But experiments should be designed so that being wrong is inexpensive.
Want to explore an agentic AI architecture?
Good.
Give it a constrained workflow.
Define the outcome.
Measure its performance.
Put human oversight around it.
Understand the failure modes.
Then gradually increase the blast radius as the organisation earns confidence.
The rule is simple:
Uncertainty should be inversely proportional to blast radius.
The less certain you are, the smaller the bet should be.
5. Buy or rent commodity capability. Build differentiation.
Engineering teams routinely convince themselves that relatively standard infrastructure is strategically unique.
Usually it isn’t.
Authentication is rarely your competitive advantage.
Container orchestration probably isn’t.
Workflow engines probably aren’t.
Observability probably isn’t.
CI systems probably aren’t.
Your product, customer experience, proprietary data or domain knowledge might be.
Spend engineering effort there.
Every hour spent rebuilding commodity infrastructure is an hour not spent creating something customers might pay for.
Sometimes building is correct.
But “we can build it” and “we should build it” are completely different statements.
6. Match architecture to the company you actually have
Architecture should solve today’s constraints while preserving sensible options for tomorrow.
A startup serving tens of thousands of customers does not need infrastructure designed for hundreds of millions.
It needs infrastructure capable of serving its current customers reliably while allowing the next stage of growth without catastrophic rework.
This distinction matters.
Over-engineering is not future-proofing.
Often it simply exchanges a hypothetical future problem for a guaranteed current one.
The best architecture is not the architecture capable of supporting the largest theoretical company.
It is the simplest architecture capable of supporting the company’s foreseeable trajectory.
7. Put competent people near high-blast-radius decisions
Some technical decisions are easily reversed.
Others can shape a company for years.
The more consequential the decision, the more domain competence matters.
This sounds obvious, yet organisations routinely allow confidence to masquerade as expertise.
A good technical leader knows where their knowledge ends.
When operating outside their expertise, they narrow the experiment, find somebody who has done it before or both.
The correct phrase is often:
“I haven’t operated this at scale before. Let’s find somebody who has.”
That sentence is not weakness.
It is one of the clearest signals of seniority.
8. Make architecture serve business outcomes
Engineering exists to create leverage for the business.
That does not mean every technical task requires an immediate revenue number attached to it.
Reliability matters.
Security matters.
Maintainability matters.
Developer productivity matters.
But ultimately these things matter because they enable something the company values.
Better reliability protects retention.
Faster CI improves delivery speed.
Better observability reduces incident duration.
Simpler architecture reduces cognitive load.
Good security protects customers and enterprise value.
Every significant technical investment should have a visible line of sight to a business or customer outcome.
If nobody can explain why an initiative matters to the company, reconsider whether it should exist.
9. Preserve reversibility
The best engineering organisations are not organisations that never make bad decisions.
They are organisations where bad decisions are inexpensive.
They achieve this through small bets.
Feature flags.
Incremental migrations.
Parallel implementations.
Clear interfaces.
Short feedback loops.
Measurable outcomes.
Safe roll-forward paths, and rollback where practical.
Before making a technical decision, ask:
If we’re wrong, how painful is it to change our mind?
This is one of the most useful architecture questions available.
Reversible decisions can be made quickly.
Irreversible decisions deserve considerably more evidence.
10. Optimise for organisational capability, not individual indispensability
A healthy engineering organisation should become stronger when talented people join it.
It should not become dependent on them.
Systems should have multiple maintainers.
Decisions should be documented.
Infrastructure should be understandable.
Knowledge should spread.
Senior engineers should create leverage by increasing the capability of everyone around them.
The objective is not:
“Nobody can operate this without me.”
It is:
“Almost anyone on this team can operate this because I helped build a system and organisation that makes that possible.”
That is actual technical leadership.
The boring technology test
Before introducing something significant, ask six questions:
- What problem are we solving?
- What measurable outcome should improve?
- Why is the existing approach insufficient?
- What is the smallest experiment we can run?
- What happens if we’re wrong?
- Do we have the competence to operate this?
If those questions have good answers, proceed.
If they don’t, another architecture diagram probably won’t help.
There is a strange paradox in technology companies.
The strongest engineering organisations often appear relatively boring from the outside.
Their infrastructure is understandable.
Their architecture changes incrementally.
Their engineers spend more time talking about customers than frameworks.
They experiment constantly, but rarely gamble the company.
And when they adopt sophisticated technology, they do it because the sophistication buys them something meaningful.
Not because sophistication itself was the goal.
The job of engineering leadership isn’t to build the most impressive technology organisation possible.
It is to build the technology organisation the business actually needs.
Everything else is just expensive entertainment.
If your architecture diagram needs a second monitor, talk to us.