There’s a particular kind of meeting that happens in every company that has ever shipped software. It has a name like “Product Direction,” “Architecture Review,” or “Solution Alignment.” The calendar invite contains no engineers. The agenda contains words like “scalability,” “platform,” and “data model.” And by the time the meeting ends, someone has made a technical decision. Except they haven’t. They have made a business decision wearing a technical costume, and the costume is made of slideware.
This is not a rant about engineers being smarter than everyone else. It is a systems observation. When a technical decision is made without the people who will implement, operate, and debug the system, the decision is not technical. It is a requirement with a confidence problem. It looks like an architecture choice, but it behaves like a blocking call: the system waits, the team stalls, and the real decision gets made later, in a code review, at 11 p.m., by someone who was never in the room.
This article is for engineering leads, product managers, and the occasional VP who has wondered why the “decided” architecture keeps changing. It is about the gap between stated engineering values and actual team behavior, and how that gap shows up in operational signals: deployment frequency, code review latency, incident response patterns, and documentation freshness. If you have ever sat in a meeting where a non-engineer said “we just need a simple API,” this is for you.
The Meeting Is a Legacy System
Let’s debug the meeting itself. A meeting without engineers is a legacy system: it was designed for a different context, it has accumulated cruft, and nobody wants to refactor it because it “works.” The meeting produces a decision document. The document gets circulated. Engineers read it and experience a race condition: the document says one thing, the codebase says another, and the team’s mental model is stuck in a deadlock.
The core problem is not that non-engineers have opinions about technology. The problem is that the meeting treats technical decisions as preferences rather than constraints. A product manager can say “we need to support 10,000 concurrent users.” That is a requirement. A product manager cannot say “so we’ll use a NoSQL database” and call it a technical decision. That is a guess with a title.
When the guess is wrong, the cost is not visible in the meeting. It shows up later as code review latency, because engineers are arguing about a decision that was never really made. It shows up as documentation freshness, because the docs describe a system that exists only in a slide deck. It shows up as incident response patterns, because the on-call engineer is debugging a system that was designed by someone who has never seen a stack trace.
What a Technical Decision Actually Is
A technical decision is a commitment to a set of tradeoffs. It is not a preference for a tool. It is not a diagram with arrows. It is a statement that says: given these constraints, we will accept these costs, and we will own these consequences. That statement can only be made by someone who will feel the consequences.
Here is a simple test. Ask the person who made the decision: What happens when this fails? If the answer is “we’ll handle it,” that is not a technical decision. If the answer is “we’ll get paged at 3 a.m., and here is the runbook,” that is a technical decision. The difference is operational ownership.
This is why the phrase “technical decision made in a meeting without engineers” is an oxymoron. The meeting can produce a business decision, a product decision, or a strategic direction. But the technical decision is the part that happens when someone has to make the thing work. And that someone is an engineer.
The Operational Signals That Expose the Gap
You do not need to sit in the meeting to know it happened. You can read the operational signals. These are the metrics that engineering teams already collect, but rarely connect to the meeting culture that produced them.
Deployment Frequency
When technical decisions are made without engineers, deployment frequency drops. Not because engineers are slow, but because they are re-deciding the decision every sprint. The team spends its time reconciling the slide deck with reality. The result is a deployment queue that looks like a traffic jam caused by a meeting that ended three weeks ago.
I once worked with a team that had a “decided” architecture for a new feature. The decision was made in a two-hour meeting with zero engineers. The feature was supposed to ship in six weeks. It shipped in four months. The deployment frequency for that team dropped by 40% during that period. The cause was not technical complexity. It was decision debt: the team had to pay interest on a decision they never made.
Code Review Latency
Code review latency is a beautiful signal because it is a proxy for trust. When engineers trust the decisions that shaped the code, reviews are fast. When they do not, reviews become architecture debates in disguise. A pull request that should take 20 minutes takes three days, because the reviewer is asking “why are we doing it this way?” and the author is saying “I don’t know, the meeting said so.”
That phrase — “the meeting said so” — is a deadlock detector. It means the team has stopped owning the decision. They are just executing a document. And execution without ownership is how you get legacy code that nobody understands, written by people who are still on the team.
Incident Response Patterns
Incidents are the most honest part of any software system. When a technical decision was made without engineers, the incident response pattern is predictable: the on-call engineer discovers a design assumption that was never validated. The assumption was in the meeting notes. It was not in the code. The incident is not a bug. It is a meeting artifact that escaped into production.
I have seen this happen with a caching layer that was “decided” by a product team. The product team wanted faster page loads. They decided to add a cache. They did not decide what to do when the cache was stale. That decision was made at 2 a.m. by an engineer who was not in the meeting. The incident report said “cache invalidation.” The real cause was “meeting without engineers.”
Documentation Freshness
Documentation freshness is the canary in the coal mine. When docs are stale, it means the system is changing faster than the team can describe it. That is normal. But when docs are stale and the team is not shipping, something else is happening. The team is documenting a system that does not exist, because the real system is being built in the gaps between meetings.
I once audited a team’s documentation and found a 40-page architecture document that described a system that had never been built. The document was the output of a series of meetings without engineers. The actual system was a collection of scripts and a database that someone had hacked together. The documentation was fresh. The system was not. That is the gap.
The Meeting Is a Blocking Call
In software, a blocking call is a function that stops the entire program until it returns. A meeting without engineers is a blocking call on the engineering team. The team cannot proceed until the meeting returns a decision. But the decision is null. So the team blocks. Then someone writes a workaround. Then the workaround becomes the system. Then the meeting produces another decision. And the cycle repeats.
The fix is not to invite engineers to every meeting. That would be a denial-of-service attack on the engineering team. The fix is to recognize that technical decisions are made by the people who will own the consequences. If those people are not in the room, the room is not making a technical decision. It is making a wish.
Wishes are fine. Product teams should wish for things. But a wish is not a decision. A decision is a commitment with a cost. And the cost is paid in deployment frequency, code review latency, incident response, and documentation freshness. Those are the operational signals that tell you whether your team is making decisions or just having meetings.
How to Debug the Meeting Culture
If you are an engineering lead, you can debug this. Start by treating the meeting as a system component. It has inputs, outputs, and side effects. The input is a business need. The output is a decision document. The side effect is decision debt.
Step 1: Name the Decision Type
Before the meeting, ask: Is this a business decision, a product decision, or a technical decision? If it is a technical decision, the meeting must include the people who will implement it. If it cannot include them, the meeting must produce a requirement, not a decision. A requirement says “we need X.” A decision says “we will do Y.” The difference is ownership.
Step 2: Track Decision Debt
Decision debt is the gap between the decision document and the actual system. You can measure it by asking engineers: How much of this document describes the system as it actually is? If the answer is less than 50%, you have decision debt. Treat it like technical debt: it accrues interest, it slows down the team, and it eventually causes an incident.
Step 3: Move the Decision to the Code Review
The code review is where technical decisions actually get made. That is where the tradeoffs become visible. If you want better technical decisions, make the code review the decision point, not the meeting. The meeting can set the direction. The code review makes the decision. That is how you get deployment frequency back up and code review latency back down.
The Cost of Pretending
The cost of pretending that a meeting without engineers made a technical decision is not just wasted time. It is erosion of trust. Engineers learn that their expertise is not needed for decisions that will shape their work. They stop owning the system. They start treating the codebase as a legacy system that someone else designed. And they start looking for a team where the meetings include the people who will get paged at 3 a.m.
This is not a culture problem. It is a systems problem. The meeting is a component. The decision document is a component. The code review is a component. When the components are misaligned, the system produces decision debt. And decision debt is the most expensive kind of debt, because it is invisible until the incident happens.
So the next time you are in a meeting and someone says “we’ve decided to use a microservices architecture,” ask one question: Who in this room will be on call when it breaks? If the answer is “nobody,” then you have not made a technical decision. You have made a wish with a slide deck. And wishes do not deploy.
FAQ
What is the difference between a technical decision and a business decision?
A business decision is about what to build and why. A technical decision is about how to build it and what tradeoffs to accept. A business decision can be made by product leaders. A technical decision must be made by the people who will implement, operate, and debug the system. When a business decision is presented as a technical decision, the team inherits decision debt that shows up as slow deployments, long code reviews, and confusing incidents.
How can I tell if my team is suffering from decision debt?
Look at your operational signals. If deployment frequency is dropping while code review latency is rising, you likely have decision debt. If documentation describes a system that does not match the codebase, you have decision debt. If incident postmortems keep pointing to “design assumptions” that were never validated, you have decision debt. The common thread is a gap between what was decided in a meeting and what was actually built.
Should engineers be invited to every meeting where technical topics are discussed?
No. That would be a denial-of-service attack on the engineering team. The goal is not to put engineers in every meeting. The goal is to make sure that when a meeting produces a technical decision, the people who will own the consequences are in the room. If they cannot be in the room, the meeting should produce a requirement, not a decision. The actual technical decision should be made in the code review, where the tradeoffs are visible and the ownership is clear.
What is the fastest way to fix a meeting culture that makes technical decisions without engineers?
Start by naming the decision type at the beginning of every meeting. If it is a technical decision, ask who in the room will be on call when it breaks. If the answer is “nobody,” the meeting is not making a technical decision. Then move the decision to the code review, where engineers can see the tradeoffs and commit to the consequences. This one change will reduce decision debt and improve deployment frequency faster than any tool or process framework.
Next up on fritz-hut.com: “The Code Review Is a Negotiation, Not a Gate” — how to stop treating pull requests as a bottleneck and start treating them as the place where technical decisions actually get made.
