Copy the Reasoning, Not the Architecture

"We should use this."

"Why?"

"Because we used it in a previous life. Also, BigCorp uses it."

If you've worked in software for long enough, you've probably been in some version of this meeting.

A technical direction is proposed. Someone asks for the reasoning. Instead of a discussion about constraints, trade-offs, failure modes, operational burden, or team capability, the answer is some variation of: I have seen this before, this is how we did it at my last company, or large successful organisations already use this, so clearly it is the right approach.

On the surface, that sounds reasonable. Experience matters. Learning from other organisations matters. Nobody wants to rediscover every lesson from first principles like some sort of software engineering caveman.

But there is a line where experience stops being evidence and starts becoming a trump card.

Once that happens, architectural discussion stops being a search for the best answer and becomes a performance of authority. The strongest argument in the room is no longer the clearest reasoning. It is the biggest company name someone can invoke.

And that is where teams get into trouble.

Experience Is Evidence, Not Proof

I want to be very clear about something: prior experience is valuable.

In fact, it is one of the main things senior engineers and technical leaders bring to a team. Experience helps you spot patterns early. It gives you a library of failure modes. It lets you say, "I've seen this shape of problem before, and here are the things that tend to go wrong."

That is incredibly useful.

The problem starts when experience is treated as the conclusion rather than as input into the discussion.

There is a massive difference between saying:

"At my previous company, we used this approach because we had thousands of services, strict regulatory requirements, and a dedicated platform team to operate it. Looking at our situation, I think some of those constraints apply here, but some don't. Let's work through that."

and saying:

"We did this at BigBank, so this is what we should do here."

The first version invites scrutiny. It explains the context. It gives people something to reason about.

The second version shuts the conversation down.

It asks the team to trust the speaker's memory, judgement, and prestige rather than engaging with the actual merits of the proposal. Worse, it creates an environment where disagreement starts to feel like insubordination rather than engineering.

That is not technical leadership. That is architecture by anecdote.

Big Companies Solve Big Company Problems

One of the most common mistakes I see in architecture discussions is assuming that because a large, successful company uses a particular technology or pattern, that technology or pattern must be generally good.

But large companies often have very specific constraints.

A bank with 20,000 engineers, decades of legacy systems, strict audit requirements, regional compliance obligations, internal platform teams, formal change-control processes, and enough budget to absorb staggering amounts of complexity is playing a very different game from a product team of eight engineers trying to ship quickly.

What looks like architectural excellence from the outside may actually be a local optimum inside a very strange environment.

Sometimes BigCorp uses a technology because it genuinely is the best tool for the job. Sometimes it uses it because they had no better option ten years ago. Sometimes it uses it because an internal platform team built a golden path around it. Sometimes it uses it because migration would be too expensive. Sometimes it uses it because a vendor relationship, compliance interpretation, or organisational boundary made it the least bad option.

From the outside, all of those look the same:

"They use X."

But the reason matters enormously.

A huge organisation can survive architectural complexity that would crush a smaller team. They can throw people at problems. They can build internal tooling. They can have dedicated SRE teams, security teams, compliance teams, platform teams, and support rotations around systems that a smaller company would simply drown in.

Copying the visible technology without copying the surrounding organisation is how you inherit the cost without inheriting the capability.

Copying Vocabulary Instead of Architecture

This becomes especially dangerous when teams copy technologies they do not deeply understand.

Take something like SPIFFE/SPIRE as an example. Workload identity is a genuinely important problem, and SPIFFE/SPIRE can be an excellent solution in the right context. If you operate a large distributed system with many services, dynamic workloads, and a need for strong service-to-service identity, it is absolutely worth understanding.

But it is not enough to say:

"BigCorp uses SPIFFE for authentication, so we should use SPIFFE too."

That sentence barely scratches the surface of the problem.

The real architecture lives in the details:

• How are workloads attested?
• What is the root of trust?
• How are trust bundles distributed?
• How are identities bootstrapped?
• How are certificates rotated?
• What happens when a workload is compromised?
• How are identities revoked?
• How is authentication translated into authorisation?
• Which assumptions does the original environment make that ours does not?
• Who operates the system when it breaks at 2am?

Those are not implementation trivia. Those are the architecture.

Two teams can draw the same boxes on a whiteboard and end up with radically different security properties. One implementation might be robust, well-attested, properly rotated, observable, and integrated into a broader zero-trust model. Another might be a collection of certificates and sidecars that gives everyone a warm feeling while quietly introducing new attack paths.

In that scenario, you have not copied BigCorp's architecture.

You have copied its nouns.

And copying nouns is dangerous because it gives the illusion of sophistication without the substance. You get the vocabulary of a mature platform without the operational understanding that made it safe.

The Whiteboard Lies

Architecture diagrams are useful, but they are also liars.

They compress messy reality into boxes and arrows. They hide the ugly bits: the bootstrap process, the migration plan, the operational procedures, the observability gaps, the weird edge cases, the emergency runbooks, the human workflows, the organisational assumptions.

This is why "Company X uses this architecture" is such a weak argument on its own. What does that actually mean?

Do they use the same technology with the same scale characteristics? The same team topology? The same threat model? The same deployment model? The same tolerance for operational overhead? The same regulatory environment? The same level of internal expertise?

Usually, no.

On a slide deck, two systems can look almost identical. In production, one is boring and reliable while the other is a constant source of pain. The difference is rarely in the boxes. It is in the details between them.

How do failures propagate? What retries? What times out? What is cached? What is eventually consistent? What is manually recovered? What is automated? What is observable? What is secure by design versus secure by convention?

These questions do not fit neatly on a diagram, but they determine whether the architecture actually works.

The Trust Cost

The technical cost of this kind of decision-making is obvious enough: you may choose the wrong tool, underestimate complexity, or introduce risks you do not understand.

But the cultural cost is just as damaging.

When engineers realise that architectural discussions are not really discussions, they stop engaging honestly.

They learn that asking "why?" will be interpreted as obstruction. They learn that alternatives will be dismissed not because they are weak, but because they do not come with the right pedigree. They learn that the meeting is less about evaluating options and more about being brought along to a decision that has already been made.

Eventually, the room gets quieter.

People stop challenging assumptions. They stop offering alternatives. They stop trying to improve the design because they no longer believe the design is up for debate.

This is how trust in technical leadership erodes.

Not necessarily through one catastrophic decision. Often it happens slowly, through repeated small moments where authority wins over reasoning. A proposal is accepted because of where it came from. A concern is brushed aside because someone has "seen this before". A legitimate trade-off discussion is short-circuited by a reference to a previous employer.

Over time, engineers start to conclude that technical merit is not what drives decisions.

Once that belief takes hold, it is very hard to undo.

Good Technical Leadership Makes Reasoning Visible

The best technical leaders I have worked with do not ask to be trusted blindly.

They make their reasoning visible.

They might still draw heavily on prior experience, but they unpack it. They explain what they saw before, why it worked, what conditions made it work, what went wrong, and which parts they believe apply to the current situation.

They say things like:

"I've used this pattern before, and it worked well when the main problem was cross-team ownership of shared infrastructure. I'm not sure we have that problem yet, so maybe this is premature."

Or:

"At my last company this approach solved our auditability problem, but it came with a heavy operational cost. If we choose it here, we need to be honest about who will own that cost."

That kind of experience is gold.

It does not shut down discussion. It makes discussion better.

A senior engineer should have more context, more scars, and more pattern recognition than a junior engineer. But seniority should improve the quality of the argument, not replace the need for one.

If a junior engineer asks a simple question that exposes a flaw in the design, the right response is not "trust me". The right response is to take the question seriously.

The healthiest engineering organisations optimise for reasoning, not hierarchy.

A Better Way to Import Ideas

So how should teams learn from other companies?

Not by copying their architecture wholesale, but by importing their reasoning.

When someone proposes an approach because they have seen it work elsewhere, the discussion should move quickly into questions like:

• What specific problem did this solve in that environment?
• Which constraints made it the right choice there?
• Do we have those same constraints?
• What capabilities did that organisation have that we do not?
• What operational burden came with it?
• What failure modes did they encounter?
• What alternatives did they reject, and why?
• What would make this the wrong choice for us?

That last question is particularly important.

A good architectural proposal should be falsifiable. There should be some condition under which the team would say, "Actually, given this information, we should not do this."

If no such condition exists, you are no longer discussing architecture. You are defending a preference.

This is also why lightweight decision records can be so valuable. Not because every decision needs bureaucratic ceremony, but because writing things down forces clarity. What problem are we solving? What options did we consider? What assumptions are we making? What are we explicitly not solving? What would cause us to revisit the decision?

The act of writing exposes hand-wavy reasoning very quickly.

The Detail Is the Design

There is a tempting fantasy in software architecture that the big decisions are the architectural decisions and the details are merely implementation.

Choose Kubernetes. Choose Kafka. Choose SPIFFE. Choose event sourcing. Choose microservices. Choose a service mesh.

But in practice, the detail is the design.

Anyone can say "we will use Kafka". The important questions are about partitioning, ordering guarantees, replay semantics, consumer lag, schema evolution, poison messages, operational ownership, retention, observability, and what happens when downstream systems are broken.

Anyone can say "we will use Kubernetes". The important questions are about deployment patterns, resource limits, network policies, cluster ownership, secrets management, upgrades, multi-tenancy, observability, and whether the team actually knows how to debug it when the abstraction leaks.

Anyone can say "we will use SPIFFE". The important questions are about attestation, trust domains, certificate lifecycle, authorisation boundaries, compromise recovery, and operational maturity.

The label is not the architecture.

The architecture is the set of decisions, trade-offs, assumptions, and operational practices that make the label meaningful.

Without those, you are just collecting impressive words.

Final Thoughts

I am not arguing that teams should ignore what successful companies do. That would be absurd. We should absolutely study them. We should learn from their successes and failures. We should pay attention to the patterns that emerge across mature engineering organisations.

But we need to be careful about what we copy.

Do not copy the diagram without the context. Do not copy the technology without the operating model. Do not copy the vocabulary without the understanding. Do not copy the conclusion without the reasoning.

The value of experience is not that it gives you a list of answers to impose on every new environment.

The value of experience is that it teaches you which questions to ask.

And if your architectural decision cannot survive those questions, it probably was not as mature as it sounded.

—

Have you worked in teams where previous-company experience was used well, or where it became a substitute for reasoning? How do you keep architecture discussions grounded in context rather than authority?