Hey — quick follow-up from yesterday's alignment meeting. Can we tell customers the feature will be ready in September?
My team still has a lot of uncertainty. We haven't made a decision on the architecture and backend yet.
We also need to finish agreeing what we're actually building. Yesterday we looked at a few different versions of the feature.
Growth can bring the usage data from the current flow. It points to a different first cohort than the one Sales mentioned.
The prototypes are useful, but they aren't a scope decision yet. We still need to agree what goes into the first version.
Okay, but what should I say to the customers who are waiting for an answer?
I'll set up another meeting for Friday so we can decide what we can actually commit to.
The alignment meeting had happened yesterday. This was the Slack conversation the day after, when Sales needed to turn a room full of context into one sentence for a customer.
The room itself had been perfectly reasonable. Product had explained the problem they were trying to solve. Engineering had described the permissions work and the parts that were still uncertain. Growth had brought usage data from the current flow. Design had shown two prototypes. Sales had shared what customers were asking for.
Everyone had contributed. Nobody had decided what to do with what they now knew: where to move next, or what each team needed from the others to keep moving.
Maya had closed the meeting with “I think we have what we need to keep moving.” It was an optimistic sentence. It was also doing a lot of unpaid work.
The picture became clearer. The decision did not.
The morning-after problem
The problem was not that yesterday’s meeting had been useless. It had done exactly what many teams ask an alignment meeting to do: it had made the surrounding context visible.
Sales brought the customer pressure. Engineering brought uncertainty about the architecture and backend. Growth brought a different reading of the current user behaviour. Product explained the problem and the shape they were considering. Design showed prototypes that made the idea easier to discuss.
That is real progress. It is also not a decision.
The next step required more than knowing what everyone thought. It required deciding what to do with the information: which direction to take, what to leave out, what each team needed from the others and what could safely be said to customers.
Nobody had designed that part of the meeting.
So the information sat in the room together, looking almost like a plan.
This is how alignment becomes a hiding place. It can mean agreement, shared understanding, permission, commitment, awareness or simply the temporary absence of visible disagreement. Those are not interchangeable states.
A team can understand a problem and still disagree about the next move. It can collect evidence without agreeing which evidence matters most. It can leave a meeting feeling productive because every function was heard, then discover the next morning that nobody knows what to do.
What other people say
Atlassian’s DACI framework gives teams a useful vocabulary for separating the Driver, Approver, Contributors and Informed people. The valuable part is not remembering the acronym. It is making the difference between having a voice and having final authority visible before the meeting begins.
Amazon’s 2016 shareholder letter describes “disagree and commit” as a way to keep decisions moving when sincere disagreement remains. The phrase is often used as a shortcut for “stop arguing”. Its more demanding meaning is that disagreement is heard honestly, the decision is made by someone accountable, and commitment is real after the choice.
Martin Fowler’s explanation of Architecture Decision Records offers a related habit: write down the decision, its context and its consequences. Product teams can use the same idea without pretending every product choice is a software architecture decision. The record does not need a transcript. It needs enough reasoning that the next person does not have to summon the original meeting from the dead.
These ideas point in the same direction: decision design comes before meeting design. A good meeting is not one where every person leaves equally delighted. It is one where the necessary evidence has been heard, the authority is clear and the people affected know what happens next.
The meeting after the meeting
Friday’s meeting would need to do something different. It could not be another tour of the same context. Sales already knew what customers wanted. Engineering already knew the architecture was uncertain. Growth already had a different point of view. Product and Design already had material to react to.
The missing work was to make the trade-off visible.
If September mattered, what could be delivered by then? If the first cohort had to be smaller, which customers belonged in it? If the feature needed a different backend, what was the smallest useful version? If Growth’s evidence pointed away from Sales’ preferred cohort, which risk were they choosing to accept?
Those are decision questions. They ask the group to choose, not simply to contribute.
The distinction sounds small, but it changes the preparation. A context meeting needs good contributions. A decision meeting needs options, a decider, a deadline and a clear statement of what will happen after the choice.
Without those things, teams often schedule a second meeting as if more time will somehow turn information into movement.
My take
I like alignment when it means people can explain the decision, the reasoning and their role in carrying it forward. I distrust alignment when it becomes a polite request to collect every context before anyone is allowed to choose.
The uncomfortable question is not “How do we get everyone aligned?” It is what needs to happen with the alignment we already have? If the answer is informed, send the document. If the answer is input, invite the people with distinct evidence. If the answer is a decision, name the approver and give them a real deadline.
There is no prize for making a decision feel unanimous when it is not. There is a cost, though, to leaving a room full of intelligent people unsure what their contribution changed.
Design the decision first. Then decide whether the meeting is the right place to make it.
There is also a quieter cost to badly designed alignment. People learn what kind of participation is rewarded. If the person who speaks with the most confidence becomes the accidental approver, others stop bringing inconvenient evidence. If every decision returns to the full group, specialists learn that their work is not trusted until it has been translated into a room-wide feeling.
That is how alignment debt accumulates. Nothing looks broken in a single meeting. The cost appears later as repeated questions, cautious ownership and decisions that need a second audience before they feel official. A team can spend more time explaining why it is allowed to act than actually acting.
The cure is not fewer people in every meeting. Sometimes a broad group is exactly right: a decision may affect pricing, reliability, customer promises and a public launch at the same time. The useful question is whether each person is there for a reason that can be named. “They should know” is different from “they need to contribute before we decide”. Both may be legitimate, but they should not create the same meeting shape.
In practice, Maya’s next brief would need to do three small but important things. It would need to make the options comparable, show what each team needed in order to move and state what Sales could safely say before the final decision. The document would not replace the conversation. It would make the conversation more honest.
This is why a written decision can feel strangely more personal than another meeting. The author has to choose verbs. “The team aligned on…” hides the work still left to do. “We chose option A, Product owns the scope, Engineering will validate the backend, and Sales can promise X” is less elegant, but much more useful.
The same principle applies when the decision goes badly. A clear record does not make a choice correct. It makes the learning legible. Without a record, the post-mortem begins with archaeology: who said what, in which meeting, while everyone was multitasking?
Good product work is full of uncertainty. The goal is not to arrange the uncertainty into a room where nobody feels it. The goal is to make the uncertainty visible enough that the right person can choose a sensible next step.
That next step does not always need to be a launch decision. It might be a short investigation, a smaller prototype, a customer conversation or a technical spike. What matters is that the team names the move instead of treating shared understanding as the move.
This is the part that is easy to miss because context feels generous. People leave with more empathy for one another’s constraints, which is valuable. But empathy is not ownership, and a room can become more understanding without becoming more coordinated. The work after the meeting is to turn that understanding into a sequence: first this, then that, owned by someone, with a reason to revisit it.
By Friday, the team might still decide not to promise September. That would be a useful outcome. A clear “not yet” gives Sales something honest to say, gives Engineering room to resolve the backend uncertainty and gives Growth and Product a chance to test whether the proposed first cohort makes sense. A date is not the only thing a meeting can decide. It just needs to decide something real.