Bridgework Doesn’t Move at the Speed of KPIs
Why do we keep breaking people instead of systems?
This question has echoed through every phase of my work, and nowhere louder than inside organizations built to prioritize speed over sustainability.
Most orgs are structured to move at the pace of commerce: quarterly planning, sprint cycles, launches, market shifts. They demand fast clarity, focused roles, and tight alignment. The systems that house us were not built for integration. They were built for efficiency.
But Bridgework doesn’t move at that speed.
It lives in the spaces in-between, between departments, between disciplines, between human need and business demand. It is essential for transformation, but it doesn’t fit in a Gantt chart. It doesn’t offer instant ROI.
This mismatch isn’t personal. It’s structural.
Pace Layering and Misaligned Systems
There’s a concept from systems theory called pace layering, coined by Stewart Brand, which describes how complex systems evolve. It breaks systems into layers, each moving at its own speed:
Nature – slowest (human needs, neurobiology, the body)
Culture – slow (values, beliefs, shared norms)
Governance – medium (laws, org policies)
Infrastructure – medium-fast (tools, workflows)
Commerce – fast (markets, KPIs)
Fashion – fastest (trends, memes)
The problem? Most of our work is evaluated at the pace of commerce, but the real value of Bridgework, trust, translation, care, alignment, lives in the slower layers.
And the tension between those layers creates confusion, misinterpretation, and pressure.
When I defined the role of UX Engineer, I wasn’t just bridging design and engineering. I was:
Translating user needs (culture)
Into design solutions (infrastructure)
That supported product delivery (commerce)
This was pace-layer translation work. And it wasn’t measurable by quarterly OKRs.
Why Bridgework Feels Invisible (But Isn’t)
Bridgework often lives in:
One-on-one conversations that resolve tension before it escalates
Pattern recognition across functions that prevents redundancy
Translating high-level goals into cross-functional workflows
Advocating for users and teammates across disciplines
But because it doesn’t look like “output,” it gets deprioritized, or worse, penalized.
This is why bridges get burned out.
You’re doing invisible labor. You’re patching broken processes. You’re preventing conflict others never even notice happened.
And the faster the system moves, the harder it becomes to see this work as essential, because its value accumulates slowly, relationally, systemically.
The Collapse of the Single-Layer Role
Bridgework becomes unsustainable when people are expected to operate in a single layer, or to pretend their value only exists at the layer their title suggests.
This shows up as:
A designer who’s not allowed to question business goals
A product manager told to stop "getting too in the weeds"
An engineer discouraged from thinking about user experience
We fracture people’s contributions in the name of focus. And then we wonder why innovation stalls.
Bridgework refuses that collapse.
It asks:
What becomes possible when we stop designing roles to fit systems, and start designing systems to honor the full dimensionality of people?
The Misuse of Iteration in Leadership
We talk a big game in business about "iteration." But often, that gets applied to products, not people. Not processes. Not roles. Not power.
I was once in a leadership workshop where the facilitator said being a product manager meant sacrificing your personal life. That it was a 60+-hour-a-week role if you wanted to succeed.
Years later, I saw that same person post online about how the product discipline had become too fragmented, with roles like "product owner" diluting the craft.
But maybe it’s not fragmentation. Maybe it’s refinement. Maybe we’re finally iterating on the work itself so more people can do it without breaking.
Why is it more acceptable to burn out one person doing three jobs than to create three roles where people can actually thrive?
Iteration as a Leadership Skill
Bridgework is slow. Relational. Iterative. And that’s the point.
Iteration in software means releasing, reflecting, adjusting. Iteration in leadership means noticing what no longer serves and being willing to change it.
We’re not static products built once and deployed forever. We are living systems. Iterating.
And those of us who’ve spent years bending to fit roles, managing up, doing the invisible labor of integration, we already know how to do this. We just need systems that recognize it.
So let’s start here: If you’ve ever felt like you’re solving deeper problems than your title suggests... If you’ve ever found yourself bridging gaps no one else noticed... If you’ve been told you’re "too strategic" for one team and "too operational" for another...
You’re not confused. You’re a bridge.
And your value doesn’t need to be justified by velocity.
It needs to be recognized by depth.