The Importance of Asking Questions in Approval Meetings — Stopping Irreversible Decisions

I recently attended an architecture approval meeting for a system development project.

The proposal was to fork an existing product and develop an OEM version. The discussion was focused on the technology stack, but something felt off to me.

I had this nagging sense that the more fundamental questions hadn't been addressed yet.

There Are Questions That Come Before the Tech Stack

Forking a product for OEM development means splitting the codebase in two. Will features and fixes added to the mainline be merged into the OEM branch? What about the other direction?

I believe proceeding without a clear plan for how to manage this is a significant risk.

So I asked this question in the meeting:

"I assume most of the development will branch off from the mainline repository. Is the plan to absorb new features and bug fixes from one side into the other? The policy on this directly impacts development costs, so I'm asking from the perspective of how much risk has actually been accounted for in this decision."

It was a question from a step back — broader than the technology stack.

In fork-based development, "codebase divergence" is one of the heaviest costs over the medium to long term. Keeping both in sync means double maintenance. Not syncing means growing divergence, making future integration and bug fixes increasingly difficult. Without clear criteria for these decisions, you're heading toward a situation that's very hard to recover from.

That's why I felt it had to be said during the approval meeting — not after.

What Really Becomes an Issue in OEM System Development

Since the topic came up, let me organize the structural issues that tend to arise in OEM development.

Codebase Management Strategy (the Heaviest Concern)

Fork vs. configuration/plugin-based branching
How to manage synchronization with the mainline
How to estimate convergence costs when divergence grows

Who Owns What

IP ownership: Who owns the code modified by the OEM partner?
Licensing: Does the mainline license permit OEM distribution?
Data: Rights over data generated on the OEM side

Customization Scope and Governance

How far can the OEM partner customize? (UI only, or business logic too?)
Criteria for incorporating OEM-side requests into the mainline

Release and Version Management

Synchronizing release cycles between the mainline and OEM side
How to handle obligations for applying security patches

When organized along a time axis, it looks like this:

graph LR
    A[Short-term costs] --> B[Customization scope & testing responsibility]
    C[Medium-term costs] --> D[Codebase divergence & version management]
    E[Long-term risks] --> F[IP ownership, competitive conflicts & contract termination]

In this particular approval meeting, the discussion of medium- to long-term risks was missing.

The Problem with a "Subcontractor Mentality"

What I felt throughout the meeting was that the development team might be operating with a "subcontractor mentality" in response to business-side demands.

The business side has the intent: "We want to expand through OEM." But when it comes to what actually happens during implementation, the development side is the only one who can concretely envision the consequences.

When the side that knows the risks stays silent, the risks effectively cease to exist.

That's the structural problem.

Rather than simply saying "we can build it" or "we can't," the real role is to ask: "If we do it this way, here's what happens down the line — are we still going ahead?"

Short-Term Integrity vs. Long-Term Integrity

Here's where it gets complicated.

Engineers who believe that responding quickly to business demands is fulfilling their responsibility are genuinely sincere. There's no bad intent. In fact, they're taking their role seriously.

But the question remains: is that sincerity still sincere when viewed from a medium- to long-term perspective?

Short-term integrity and long-term integrity sometimes contradict each other.

Executing requests quickly and accurately is sincere in the short term. But when that leads to major costs or problems later, was it truly sincere toward the team and the product?

True integrity, I believe, includes saying the things that are hard to say.

"Irreversibility" as a Decision-Making Criterion

I spoke up in the meeting because I felt that proceeding without addressing this concern was heading toward something that couldn't be recovered from later.

Things that can be undone can be fixed later. But architectural direction and fork decisions carry extremely high costs to reverse.

That's why it had to be said at the approval meeting — the timing mattered.

After the meeting, several people told me, "I was thinking the same thing about that point." There were likely others who felt the same way but didn't speak up.

The reasons vary — feeling it wasn't their role, not wanting the responsibility of stopping the conversation, and so on.

But perhaps the reason it stayed at just "I was wondering about that" was that they hadn't fully recognized it as a risk heading toward an irreversible outcome.

What It Means to Ask Questions in an Approval Meeting

Rather than directly pointing out problems and stopping things, I believe the role of questions in an approval meeting is to make people think through the act of questioning.

When a question lingers in the room, engineers realize, "We needed that perspective." Next time, they start thinking about it on their own. The quality of the meetings themselves improves over time.

It's better to embed the intent behind the question within the question itself. In this case, I included it in phrases like "directly impacts development costs" and "how much risk has been accounted for."

When the reasoning behind a question is visible, the next person can carry that same perspective forward.

The accumulation of these kinds of questions in these settings is what gradually shifts what an organization considers "normal." It doesn't change overnight. But it definitely takes effect over time.