Decision Room Carry: Why Your Best Decisions Disappear on Monday
A cross-functional team can make what seems like a solid Friday decision, captured in minutes and agreed to in the room. Only then nothing moves on Monday.
Drawing on Agnes Carroll’s observation that “no one is carrying it,” this episode looks at why that happens and why better documentation or decision-management tools don't necessarily solve the problem.
The issue isn't always whether the right person was assigned to make the decision. It's whether the people who have to execute it were actually part of the thinking that produced it.
That distinction becomes particularly important in product development, where decisions about design, manufacturing, quality, reliability, and customer needs often have consequences that don't become visible until much later.
The Decision Room Carry Problem
We've all been there. It's Friday afternoon, and a cross-functional team is working through an important decision. Design, engineering, quality, manufacturing, sales, or customer success may all be represented.
The team discusses the options and trade-offs. Someone captures the decision in the meeting minutes. Everyone agrees, and the team leaves the room thinking they're aligned.
Then Monday comes, and the decision doesn't seem to have moved. People may question it, reinterpret it, or begin working around it. The decision exists in the documentation, but it doesn't seem to have made its way into the work.
Agnes Carroll described this idea as the problem of “no one carrying it.” That phrase caught my attention because it describes something I have seen in product development for a long time.
We often assume that once a decision has been made and documented, the next step is execution. But there is a step in between that we don't always pay enough attention to: getting the people who will execute the decision to understand and participate in the reasoning behind it.
An Assigned Decision Isn't the Same as an Authored Decision
Carroll makes an important distinction between assigning a decision and having people author that decision.
A decision can have a clearly identified decision-maker. Someone can have the authority to choose between alternatives, and the organization can document who is accountable. But that doesn't necessarily mean the people who have to carry out the decision feel ownership of it.
Think about some common product development decisions:
- Manufacturing may be asked to work with a tolerance stack that was determined by engineering.
- Quality may be asked to work toward a reliability target that was established without their involvement.
- Sales may be given a feature set that they then have to explain to customers.
In each case, the decision may have been perfectly legitimate. The problem is that the people who have to make the decision work in practice may have inherited it rather than helped develop it.
That difference matters because people don't just need to know what was decided. They often need to understand the reasoning that led to the decision, the alternatives that were considered, and the trade-offs the team accepted.
That's what makes it possible to carry the decision forward.
Why Tools Don't Necessarily Close the Gap
There are plenty of tools available to help teams manage decisions. Decision matrices, project-management systems, AI-assisted tools, and other approaches can help identify decision-makers, document rationale, assign actions, and track accountability.
Those things can be useful. But they don't necessarily address the problem we're talking about here.
The gap is cognitive.
If the person who will have to execute a decision wasn't really involved in the reasoning when the decision was made, adding more information to the decision record doesn't necessarily change that.
They may have been sitting in the room. They may have even agreed with the decision. But did they have an opportunity to say, “Here's what this means from my function's perspective”?
Did they have an opportunity to challenge an assumption, help work through the consequences, or take part in developing the trade-off?
Those are the interactions that create understanding and, ultimately, authorship.
Design for Manufacturing Is a Good Example
I think about this particularly easily through design-for-manufacturing.
Coming from a process engineering background, I've heard the frustration that can come when manufacturing receives a design after important decisions have already been made.
Why does this tolerance need to be two thousandths of an inch?
Why are we using this process?
Why did we design it this way when it's going to be so difficult or expensive to manufacture?
Those questions aren't necessarily signs that manufacturing is resisting the design. They can be signs that manufacturing wasn't part of the reasoning when the design direction was being developed.
There's a very different conversation when manufacturing is involved earlier.
Instead of reviewing an almost-finished design and pointing out problems, manufacturing can help the team explore what will work at scale. Engineering can understand those constraints while the concept is still changing. Quality can bring in concerns about failure modes and reliability while there are still multiple options available.
The team is doing the thinking together rather than passing the thinking from one function to another.
This Is What ADEPT Is Designed to Do
This is one way I think about Pierce the Design Fog and the ADEPT framework.
ADEPT stands for Align, Discover, Examine, Prioritize, and Teamwork.
The framework is designed around the idea that early product development needs more than a sequence of functional handoffs. The people involved need opportunities to think together while the direction is still being developed.
Align
The Align phase is about establishing what the team is trying to accomplish. This isn't simply a kickoff meeting or a requirements handoff. The team is working together to understand the problem, the desired outcomes, and what success should look like.
Different functions will naturally see different aspects of the problem.
- Engineering may be thinking about technical constraints.
- Manufacturing, about scalability.
- Quality thinks about failure risks.
- Sales may be thinking about what customers actually expect.
Getting those perspectives into the conversation early gives the team a much stronger foundation for everything that follows.
I have found that this part can take longer than teams initially expect. Preparation can help people arrive ready to work, but sending information ahead of time isn't a substitute for doing the alignment work together. The value comes from the co-working.
Discover and Examine
Discover and Examine are where the team explores the concept space and examines the possibilities.
This is another place where cross-functional participation matters. Quality isn't simply waiting for a specification to review. Manufacturing isn't waiting for a design-for-manufacturing review. Each function is contributing its knowledge while the team is still exploring what the product could become.
This also helps address a common problem in early design: teams tend to converge too quickly. Once a promising idea appears, it's easy to start optimizing that idea rather than continuing to explore whether it's actually the best direction.
The Concept Space Model in Pierce the Design Fog is intended to help teams spend more time in that space between having an initial idea and committing to a particular direction.
Prioritize
Eventually, the team has to make choices. There will be trade-offs. Some things will be prioritized and others won't.
But if the team has done the earlier work together, the people involved have had an opportunity to reason through those trade-offs.
- Manufacturing understands why a particular design choice was made.
- Quality understands what risk the team accepted.
- Engineering understands what manufacturing needs in order to produce the design.
The decision isn't simply something that was handed to each function. It is something they participated in creating.
That doesn't mean everyone gets everything they want. It means everyone understands the reasoning behind what the team ultimately chose.
Teamwork
The Teamwork phase is where that shared understanding has to translate into execution.
When people have been part of the thinking, they have a better foundation for carrying the decision into their own work. They know what the team was trying to accomplish. They know what trade-offs were made. They understand the consequences and the reasons behind them.
That is very different from receiving a decision after the fact and being asked to make it work.
The Extra Time Is an Investment in Execution
Working this way isn't necessarily faster in the beginning. It takes time to bring the right people together and to let them work through the problem before the team commits to a direction. It's tempting to skip that work because it feels like slowing down the project.
But the alternative is often to move quickly into a direction that later has to be revisited. The cost shows up as rework, late design changes, functional disagreements, workarounds, and slow execution rather than as time spent in an early concept-development session.
This becomes especially important when the consequences of a poor decision are significant. In medical devices, safety-critical systems, and other high-consequence products, a decision that doesn't carry into execution can create much larger problems later.
A Simple Way to Look for This in Your Own Team
You don't need to change your entire product development process to start noticing the problem.
The next time your team makes an important design or concept decision, pay attention to what happens after the meeting.
- Does the decision actually move into the work? Are the people representing different functions able to explain why the decision was made?
- Or do you start hearing questions and objections that suggest some of the reasoning never made it across the functional boundaries?
Then ask a slightly different question:
Were the people who need to carry this decision part of the thinking when it was made?
If they were only consulted after the direction was largely established, that may explain why the decision isn't carrying as well as expected.
Where to Start
If this problem sounds familiar, the first step may simply be to look more closely at how your team makes decisions during early product development.
The Design and Quality Snapshot is one way I help teams do that. It's a diagnostic audit that looks at how design and quality decisions are being made, where gaps exist, and where those gaps may be contributing to rework or execution problems. Learn more about the Design and Quality Snapshot → Services
The goal isn't better documentation for its own sake.
It's to help teams do the thinking together early enough that the decisions they make can actually carry into the work.
About Agnes Carroll
Agnes Carroll, Decision Architect for Complexity, Loomworx Studio.
Article: "The Decision the Room Will Not Carry" https://www.linkedin.com/pulse/decision-room-carry-agnes-carroll-2sasc/
Studio: https://loomworxstudio.com
Other Quality during Design podcast episodes or blog posts you might like
Improving Communication and the Workplace with Meagan Pollock (A Chat with Cross-Functional Experts)