Yesterday I spouted off about the problem of "sharing the artifacts of decisions but not the decisions themselves" — it got me thinking about the 'why' underlying that common pattern, and riffing on conversations we've been having recently with clients.

In a nutshell: Why *don't* more teams capture and share key decisions that underly the things they create? This applies equally to UX, product priorities, visual design and branding, content modeling, technical architecture…

More and more I've come to believe that articulating the _assumptions and choices_ that underly most decisions is unfamiliar territory for a lot of practitioners, rarely practiced outside of high-stakes confrontations, and often hampered by balkanized language.

"Why are Industries a content type, not a tag?" "Why hide the toolbar when users are onboarding?" "Why put the author's profile pic on the article card?"

Often these are only asked when there's disagreement or opposition. "Justify yourself!" rather than "Expound on that…"

Compounding the problem: those kinds of decisions are often made inside of discipline-specific teams, and the language used to talk through pros and cons and options is often unfamiliar to those who'll "consume" the decisions.

When those two factors collide, it's particularly difficult. Explaining the "why" can often feel like giving a crash course in your area of expertise to a hostile audience — far easier to just specify the outcome and hand it off as a to-do.

So, if that's WHY it often happens, and we know that it's likely to produce poor outcomes WHEN it happens… how do we ensure the underlying whys for decisions and specifications are understood across a whole team?

Frustratingly there is no silver bullet and I have no magic process with a catchy initialism. But as a couple of people have already chimed in to note (hat-tip @thebestsophist), facilitated collaboration between the different organizational silos BEFORE handoffs is critical.

It's not just a matter of "peeking behind the curtain" or "giving team A an earlier opportunity to object to a bad idea." It's about developing a better understanding of what questions different teams are accustomed to asking. Developing familiarity with how they talk about them.

Developing respect across team boundaries for unfamiliar areas of expertise is also a biggie. It can seem trite and fluffy, but especially in large orgs where teams are often pitted against each other for resources during, and credit or blame after, a big project?

Recognizing what kinds of issues different disciplines are most concerned with and focused on can help their decisions make more sense as well.

These things don't automatically result in well-documented decisions making processes. But they help build an environment where decisions *can* be articulated and documented more effectively.