How to Make a Working Group Actually Work

At some point in the life of any sufficiently large technology organization, you hit a decision that can’t be made quickly, can’t be made by one person, and can’t be made well without dedicated research and investigation. The kind of decision where the stakes are high enough that getting it wrong is expensive, but the complexity is high enough that getting it right requires expertise you don’t have concentrated in any single role.

These decisions tend to get made badly. Not because the people involved aren’t capable, but because the organization reaches for the wrong tool:

• A series of meetings.

• A consultant who isn’t familiar with the unwritten history of decisions.

• A proof of concept that one team builds in a sandbox and presents as evidence.

• A decision made in a boardroom by people who are three levels removed from the technical reality.

A properly structured working group is a better tool. But “working group” is one of those phrases that can mean almost anything! In practice, it often means a committee that meets every other week, produces a slide deck, and dissolves without anyone being quite sure what was decided or why. Or what action to take.

The version I want to describe is different.

It’s a focused, time-bounded, expert-led investigation with a clear mandate, protected from interruption, and designed to produce actionable advice rather than political consensus.

To make this concrete: while working at Jumbo Supermarkten (a major Dutch supermarket chain running a multi-million euro ecommerce operation serving millions of customers) we faced exactly this kind of decision.

The question was whether to move the mobile app from native development (separate iOS and Android codebases) to a full hybrid approach.

The stakes were significant. Millions of users were relying on the app. Native mobile development was becoming harder to resource: good native developers were scarce, and the mobile teams were struggling to keep pace with the deployment velocity that had become normal on the web side.

A hybrid approach might solve both problems. Or it might introduce a different set of problems at scale. We genuinely didn’t know.

This wasn’t a decision that could be made by a product owner with a preference or even an architect. It needed structured investigation across multiple domains simultaneously: technical feasibility, team ownership, deployment architecture, feature parity, capability gaps. Each of those areas required someone who actually knew what they were talking about. And involving those people early has a secondary benefit that's easy to overlook.

A decision shaped by the people who will live with it daily lands very differently than one handed down from above.

So we formed a working group.

Before getting into how to do this well, it’s worth being honest about why the format so often disappoints.

The most common failure mode is stakeholder interference before the investigation is complete. I’ll say that again, for the people in the back:

The most common failure is stakeholder interference.

Business priorities leak in. Someone in the group develops a preference early and the group starts unconsciously building a case for it rather than genuinely investigating. The working group stops being an investigation and becomes an exercise in ratification.

The second failure mode is unclear ownership. Work doesn't need to be distributed equally. In practice, most working groups run alongside daily responsibilities, and contribution will naturally vary based on what each person can afford. That's fine. What isn't fine is ambiguity about who owns what. When responsibility isn't explicitly assigned, important questions go unanswered not because nobody had time, but because everybody assumed someone else was handling it.

The third is no clear goals or scope. A working group can have the right people, explicit ownership, and a fixed deadline, and still produce output that doesn't answer the questions decision makers actually needed answered. This happens when the objectives are set too loosely. Or not set at all, leaving it to the group to define them as they go. Investigation without a defined scope tends to go wide rather than deep, and the output ends up interesting but not actionable.

The fourth is no protected time. People are assigned to the working group but remain fully accountable for their normal workload. The investigation gets done in the gaps, which means it doesn’t really get done. The output reflects the time that was actually available, not the time the decision deserved.

And the final one is no clear endpoint. Working groups that don’t have a fixed runtime tend to drift. Without a deadline, the investigation expands to fill available ambiguity, focus starts to widen into secondary areas, decisions get deferred, and momentum collapses.

Each of these failure modes has a structural solution. That’s what the rest of this article is about.

A working group that produces advice looks different than that from a committee. It has a fixed lifespan, a specific mandate, experts who genuinely own their areas, and is freed from the organizational pressure that would otherwise distort the findings.

At Jumbo, the working group was given a set of clearly defined research objectives upfront: what would the impact of switching look like? How would team collaboration change? How could individual product teams own their mobile domain without requiring native development expertise? What would the deployment process look like? How much of the existing web feature set could be reused? What capability gaps existed and how could they be addressed?

These weren’t vague asks. They were the specific questions that decision makers needed answered in order to make the decision responsibly. The working group didn’t set the questions, but owned the investigation into answering them.

That distinction matters. Setting the questions is a leadership responsibility. Answering them is the working group’s.

The first decision is “who’s in it”. The answer is almost always “the people closest to the problem, not the people with the most seniority.”

For the Jumbo investigation, we pulled experts from each of the domains the decision would affect: mobile developers who understood the constraints of the existing native setup, web developers who understood the hybrid frameworks under consideration, a DevOps engineer who could assess the deployment implications, and someone with enough cross-team view to think about how ownership would work across product teams.

No one was included because of their title. Everyone was included because of what they knew.