career bridge
The second team
Take the design into a use case it was not drawn for and let it be wrong in public. This is where architectures die.
Your architecture works for the use case it was drawn for. Then a second team arrives with something adjacent, slightly different, and entirely reasonable. This is the moment most architectures quietly die, and handling it well is the actual job rather than a complication of it.
What you do
Take the design into a use case it was not built for and let it be wrong in public. Find a genuinely different second case, another team, a different data shape, a tighter latency need, a stricter compliance requirement, and walk your contract through it end to end. Write down every place it does not fit. Then classify each gap honestly into three kinds: the ones where the second team should adapt, the ones where the architecture has to change, and the ones where a real exception is the right answer. That third kind matters and people avoid it, because an architecture permitting no exceptions does not prevent divergence, it produces a shadow estate of teams doing it their own way and not telling you. Make the exception a documented, time-bound decision instead. For the changes, work out how to make them without breaking the first team: version the contract, support both for a stated period, and write the deprecation date at the moment you introduce the replacement rather than later. Then run the whole thing past both teams together. If they disagree in front of you, that is the meeting working.
Done when
- A genuinely different second use case has been walked through the contract end to end.
- Every misfit is classified: the team adapts, the architecture changes, or a documented exception applies.
- At least one permitted exception exists, time-bound and written down.
- Changes are versioned, both versions supported for a stated period, deprecation dated on introduction.
- Both teams have reviewed the result together rather than separately.
What you end up with
A revised architecture showing what the second use case broke, what changed, what was granted as a time-bound exception, and the deprecation dates you set.
If you get stuck
The common failure is refusing every exception on principle, which does not prevent divergence, it only stops you hearing about it. Grant them, bound them, record them. The other failure is changing the contract without versioning it, which teaches the first team that depending on you is unsafe. That lesson is remarkably hard to unteach, and you will need those teams again.