Meetings That Should Have Been a Pull Request

Posted on June 29, 2026  •  11 minutes  • 2310 words

There’s an unwritten rule in our profession that says: if a technical decision can be made by reading 10 lines of code and leaving a comment on a pull request, the responsible thing to do is lock ten people in a poorly ventilated room for an hour to talk about it.

If there’s PowerPoint involved, that’s considered governance.

This isn’t an exaggeration. In many teams, the meeting is the smallest unit of visible work: if you’re not on a video call, you’re not working.

If the decision didn’t go through a room, it wasn’t a real decision. It doesn’t matter if the problem is solved, if the code is better, or if the person who knows the most about the topic sent a three-line message that made everything perfectly clear.

What matters is the process: the blocked calendar slot, the ten avatars online, the meeting summary nobody will ever read.

Let me tell you what that looks like from the inside, because we’ve all been there.

The Enum Meeting

A random Tuesday, 4:00 PM. Your brain is already fried, but there it is on the calendar: a gem titled “API v2 Design Meeting.” You tell yourself: “Well, maybe today we’ll actually decide something important.”

You join the video call. Ten people. Two cameras on, eight avatars, a silence as heavy as a state funeral.

Five minutes in, you realize that “API v2” is actually about deciding whether an endpoint should return "status": "active" or "status": "ENABLED".

You’ve been coding for 10 years, and here you are, about to spend an hour debating an enum name with half the company.

And it happens. The debate starts. You start hearing things like:

• “I think ACTIVE communicates the intent better.”
• “Sure, but ENABLED is more consistent with other services.”
• “We could do a mapping on the frontend…”
• “This is going to impact the data team, we should bring them in too.”

Then someone walks in with the title “Head of Something” who has never so much as looked at the codebase and says: “I’d really like to get this decided today.” Like they’re brokering the Peace of Westphalia.

And you think: “This could have been decided three days ago in a PR that already exists, but you shot it down to turn this into an episode of The Real Housewives.”

The funniest part is that when the meeting wraps up, the conclusions are: someone needs to open a document to collect options, someone needs to write up a final proposal, and in the end we’ll settle it in a PR.

In other words: one hour of your life to end up exactly where you would have been if someone had just opened a pull request from the start, explained the decision in three paragraphs, and let the people who actually know what they’re talking about comment when they got around to it.

But of course, then there would have been no meeting. And without a meeting, it’s like nothing actually happened.

The Religion of “We Need to Talk About This”

The meeting is usually the first instinct, not the last resort.

There’s an unspoken dogma that goes something like: “if we haven’t talked about this with at least seven people, we can’t move forward.”

It doesn’t matter whether the topic is renaming a column, picking between two logging libraries, or deciding whether to call a service billing or invoicing.

A meeting gets called. There’s always a “just in case” ready to go: what if it impacts other teams, what if there are risks we haven’t seen, what if… well, just in case.

“Just in case” is the modern version of “because I said so.”

And there you are, stuck in a one-hour video call where, at best, three people are actually talking, another three are multitasking with their email, two have been muted since minute one because they forgot the meeting was happening, and one only showed up because it said “architecture” in the title and figured they should make an appearance.

Meanwhile, the code is right where it was. And so is the actual problem.

The Perfect Asymmetry: Everyone Talks, One Person Ships

There’s something almost poetic about these meetings: how the work gets divided.

Ten people give their opinion. One person — usually the one who knows the most about the subject and has said the least during the meeting — gets saddled with building it all afterward.

During the video call, ideas get thrown around with remarkable ease.

Someone proposes saving a version for every change. Another person mentions it would be nice to make it configurable. A third suggests future-proofing it for multitenancy, just in case.

Everything sounds reasonable when you say it out loud with no keyboard in front of you.

But then someone — you — has to go back to their editor and turn that “would be nice” into hours of code, tests, refactors, migrations. That part doesn’t get much discussion. That part doesn’t make it into the meeting summary.

I’ve thought many times that the most honest thing anyone could say before starting would be: “Everything that comes out of this meeting, you’re going to be the one building it — so make sure we don’t go completely off the rails.”

That would change the tone real quick.

Meetings Without Context: Where Opinions Are Free

Another classic: you get invited to a meeting about a technical decision you’ve never heard of.

No prior document. No link to code. Nothing. Just a vague title like “Caching Strategy Review.”

You join, everyone says hi, someone shares their screen with a diagram they drew in Miro 10 minutes ago, and you’re asked for your opinion.

Your opinion.

On a system you’ve never touched, with requirements you know nothing about, and implications nobody’s had time to explain to you.

Sure, you can give your opinion. We can all give our opinion on anything. But what comes out of that is just noise.

There are entire studies on how important technical decisions discussed in large groups without any preparation just devolve into pointless brainstorming. You don’t need a scientific paper to know: three years of stand-ups and you can see it coming from a mile away.

What actually works is simple: you write something first.

One page. Two, if you’re feeling ambitious. A lightweight RFC , documenting the problem, the proposal, the alternatives you considered and why you ruled them out.

You send it a couple of days ahead. Let people read it when they can. Show up to the meeting — if there even needs to be one — to work through the parts where there’s genuine disagreement.

But that requires writing. And writing requires thinking. And thinking, in a lot of company cultures, doesn’t count as work unless you’re on a video call.

The Quiet Pull Request That Would Have Saved Everyone’s Time

The saddest part of all this is that, in many cases, when someone finally opens a pull request with the solution, that PR ends up being the only useful discussion there is on the subject.

In the PR, you can actually see the real code. See the impact on tests. See how it affects other modules. And leave inline comments — direct, on the code itself.

I’ve seen decisions that had been debated for weeks in meetings get settled in three comments on a PR. Three. “Hey, this should go here instead — otherwise it blows up in this case.” Done.

It’s hard not to think that if we’d started there, we could have skipped at least half a dozen “brainstorming” sessions that had neither brains nor storms.

A well-structured pull request is, at its core, a mini-RFC: you have context, a proposal, and a diff.

And it stays on record right there in the repository. You can come back to it six months later when someone asks “why was this done this way?” — instead of digging through meeting notes that nobody can find, or that were never written in the first place.

Documentation Doesn’t Mean Writing a Report Nobody Will Read

There’s a certain allergy to the word “documentation” because it conjures up endless manuals in Confluence that nobody reads. But that’s not what we’re talking about here. We’re talking about something much smaller: decisions.

Most important technical decisions fit on one page. You don’t even need a formal structure. You just need to explain what the problem was, what options were on the table, what was chosen, and what the trade-offs are.

That, in a docs/decisions folder or in an ADR (Architectural Decision Records) system, is gold.

It lets you come back six months later and see that you made that call because of constraints that existed at the time — and no others. It saves you from that feeling of “this seems wrong, but I might be forgetting why we did it.”

When there’s no record, all that’s left is word of mouth. And in tech companies, word of mouth works like the telephone game: “this was done because X asked for it,” “no, no, it was Y’s call,” “I think it was for compatibility, but honestly I might be making that up.” Mystery for the ages.

And of course, where written context is missing, meetings multiply.

Because every time someone thinks about changing something, you have to call another meeting with half the company to piece the history back together out of vague, half-remembered opinions.

The Meeting That Actually Deserves to Exist (Spoiler: It’s Short and Has Conflict)

I’m not saying every meeting is the devil.

Useful ones do exist, but they have something in common: they happen after something has already been written, people have actually read it, and there are still real disagreements that are better worked out face to face. Not when someone calls a meeting because “we need to align.”

It also matters who’s in the room. If nobody can actually make a decision on their own, the meeting ends with a “well, this needs to go up to the architecture committee and they’ll let us know” — which is just another way of saying we’re exactly where we started.

And there has to be a clear question to answer. “Do we go with option A or B?” “Do we accept this trade-off or not?”

Not that wishy-washy “let’s just see how it goes” kind of meeting where nobody knows if it’s over or ongoing, or what “closing the topic” even means.

The truth is, when you take writing things down seriously and let PRs and RFCs do their job, those meetings become fewer, shorter, and less exhausting.

And where you used to have an hour of ten people generating noise, now you might have twenty minutes of four people resolving one specific conflict.

One is theater. The other is work.

The Hidden Cost of Meeting-itis

There’s something you don’t see on the calendar: the mental toll this culture takes.

It’s not just the hour. It’s the time it takes to get back into the code afterward, the energy you leave behind in conversations that go nowhere, and the feeling that you’re making fewer decisions than you should be.

You end the day with a calendar full of blocks, a head full of noise, and the code more or less where it was in the morning. That kind of day, repeated week after week, burns you out. Not because you’ve been working too hard, but because of the constant feeling of being incredibly busy without having done anything that actually matters.

When you start pushing through more well-described PRs, more focused async discussions, more lightweight RFCs, something interesting happens: there are fewer meetings, yes, but also fewer surprises, less “I had no idea about that,” fewer decisions made in back-room conversations.

It’s harder to play dumb when there’s a document or a diff with your name on it.

The Next Time Someone Invites You to an Hour-Long Meeting to Discuss an if

You don’t have to suddenly become an anti-meeting crusader. But there’s one small move that changes the whole game: the next time you see a meeting on the calendar about something clearly scoped enough to handle in writing, try saying: “Hey, what if we start with a PR or a short doc and go from there to see if we actually need to talk about it?”

Maybe they’ll look at you funny. Maybe someone will say “this is too important, we need to talk about it.”

It might not work the first time. But if you do it a couple of times and show that a well-written doc and a decent PR get to a decision faster and better, by the third time people might start asking for it themselves.

In the end, it comes down to one simple question: do you want to spend your time writing code and making decisions with context, or do you prefer going to meetings where ten people argue over an enum name and end up, inevitably, waiting to see what the pull request says?

I’ve made up my mind.

My calendar is working on it.

Sources and references

Because some things are easier to understand by reading them than by listening to them on a video call.

• The Science of Why Brainstorming in Groups Doesn’t Work — Melissa Schilling, Inc. Why group idea-generation sessions consistently produce worse results than individual work.
• Scaling Engineering Teams via RFCs: Writing Things Down — Gergely Orosz, The Pragmatic Engineer. How to use RFCs to scale technical decision-making without multiplying meetings.
• Architecture Decision Record — Martin Fowler. What an ADR is, why it matters, and how to structure one in a repository.
• Meeting Statistics: 50 Data Points on Time, Cost and Productivity — Flowtrace. Data on the real impact of meetings on productivity, including Gloria Mark’s research on recovery time after interruptions.