Years ago, one of my mentor gave me a piece of advice that sounded oddly simplistic at the time:
“Give ’em the bones, and they’ll play with it.”
I laughed when I first heard it.
Back then, I interpreted it as a shortcut mindset. A way of saying “just throw something out there”
Over the years, working across enterprise programs, modernization initiatives, and high pressure delivery environments, I realized it meant something far more practical.
It was never about lowering standards.
It was about understanding how organizations react to uncertainty.
As architects, we operate in an uncomfortable middle layer:
- Business wants certainty.
- Engineering wants clarity.
- Delivery wants predictability.
- Leadership wants progress.
The problem is that large programs rarely begin with any of those fully available.
There are always moving parts:
- incomplete requirements,
- shifting priorities,
- vendor dependencies,
- legacy constraints,
- evolving timelines,
- and decisions waiting on other decisions.
Early in my career, I believed my responsibility was to present complete thinking. I would hold back architecture artifacts until everything felt coherent:
- diagrams polished,
- assumptions validated,
- edge cases analyzed,
- integration flows reviewed,
- technical risks mapped properly.
Technically, it felt responsible.
Operationally, it was a mistake.
Because while I was refining the solution, everyone else was reacting to silence.
And silence inside enterprise delivery creates anxiety very quickly.
I learned this lesson during a large modernization program involving multiple integration platforms, external vendors, and internal engineering teams spread across regions. We were redesigning several legacy workflows while simultaneously introducing new APIs and shared platform capabilities.
The architecture itself was progressing well, at least from my perspective.
But I kept delaying broader walkthroughs because I wanted the flows to be cleaner and more complete before presenting them.
Within days, the situation around the project started changing:
- delivery managers started raising risk concerns,
- program leadership questioned alignment,
- developers began making implementation assumptions,
- business stakeholders assumed engineering was blocked.
The irony was painful.
A large portion of the thinking already existed.
Whiteboards were full.
Draft flows existed.
Dependencies were mapped.
Half the difficult decisions were already made.
But none of it was visible enough for the organization to feel progress.
That experience fundamentally changed how I approach architecture communication.
Today, I share the skeleton early.
Not the polished cathedral.
Just enough structure for people to engage with.
Sometimes that means:
- a rough system context diagram,
- a draft API contract,
- an incomplete sequence flow,
- a dependency matrix with open questions,
- or even screenshots from a whiteboard session.
Not because the work is finished.
But because visible progress changes organizational behavior.
The moment people can see something tangible, the conversation becomes more grounded.
Stakeholders stop imagining worst-case scenarios.
Teams stop filling gaps with assumptions.
Feedback becomes more actionable.
Escalation pressure drops significantly.
Most people are not actually waiting for perfection.
They are waiting for reassurance that momentum exists.
That is what “the bones” really are.
The bones are:
- enough structure to create alignment,
- enough visibility to build confidence,
- enough progress to reduce uncertainty.
Over time, I realized architecture is not only about designing systems.
It is also about managing confidence across teams operating under pressure.
Strong architects do not just create technical direction.
They continuously reduce ambiguity for the organization around them.
That requires exposing thinking earlier than most technical people are comfortable with.
Of course, there is a balance to this.
“Giving the bones” does not mean manufacturing fake progress or pushing unfinished work irresponsibly. Visibility without substance eventually collapses under scrutiny.
The bones still need to become a real system.
But experienced delivery leaders understand another important truth:
waiting too long for perfection often creates more organizational damage than sharing an imperfect draft early.
Because in enterprise environments, uncertainty spreads faster than flaws.
And once people have something concrete in front of them, their energy shifts naturally from escalation toward collaboration.
The conversation changes from:
“Is anything happening?”
to:
“Can we improve this?”
That shift matters more than most teams realize.
Some of the best enterprise initiatives I’ve worked on did not begin with polished architecture decks or perfect certainty. They began with evolving diagrams, incomplete assumptions, and transparent iteration.
What made them successful was not perfection from day one.
It was visible momentum.
That old advice from my manager makes far more sense to me now than it did years ago.
In complex delivery environments, people rarely demand perfection first.
They demand evidence that progress is real.
So don’t disappear trying to perfect everything before anyone sees it.
Give ’em the bones.
They’ll play with it.
