Redesign work
around real commitments.
Most organizations are asking modern, cross-functional, fast-changing work to run through operating logic built for slower, more predictable environments. The result is familiar: invisible labor, blurred decision rights, brittle accountability, and teams that route around the org chart to keep moving.
Planning, delivery, docs, support, mentoring — implied, uneven, invisible.
Legacy structure breaks under modern work.
The problem is not just that roles are outdated. Role ambiguity, hidden decision rights, invisible labor, and reorgs-as-the-only-lever erode trust precisely where modern work needs clarity most.
Job descriptions try to predict future work. When reality shifts, the role stays still and people absorb the mismatch informally.
People are told to own outcomes without clear authority. The real decider becomes visible only after conflict, delay, or rework.
Coordination, documentation, mentoring, and support keep work moving — but title-centered systems rarely make that labor visible or rewardable.
Adaptation should happen at the team level, not through enterprise upheaval that takes a year to settle.
Six principles. One operating model.
Design constraints that keep the framework from collapsing into generic matrix management, transparency theater, or vague language about agility. Principles, not slogans.
Make work legible
If a commitment can't be seen, it can't be staffed, improved, or rewarded fairly. Delivery, maintenance, coordination, and support all need to be named.
Separate contribution from title
Titles still help with craft identity and pay bands, but they can't be the main lens for assigning work or reading value. Contribution travels wider than the chart.
Let structure follow the task
Stable teams matter, but they aren't the default answer to every priority. Use the lightest structure that can carry the work without losing accountability or context.
Keep stewardship explicit
Autonomy is not the same as ambiguity. Every commitment still needs clear decision rights, a review rhythm, and a path for escalation when tradeoffs conflict.
Make invisible work count
Documentation, mentoring, handoff coordination, onboarding, and repair work keep the system alive. Treat them as visible, distributable, and rewardable.
Build learning into the work
Learning happens through stretch tasks, teaching, documented decisions, and safe-to-fail experiments — not through programs bolted on the side.
The principles are evaluation criteria.
If a proposed implementation makes work harder to read, hides decision logic, weakens stewardship, or pushes maintenance back into the shadows, it's drifting away from the framework — even if the vocabulary still sounds right.
Open the full principles page
Each principle paired with the tension it manages — freedom and reliability, autonomy and stewardship.
Three scenarios that test whether the framework actually holds.
Concept work should show behavior under pressure, not just list benefits. These scenarios test whether the model improves clarity, ownership, and follow-through when the work is messy and contested.
Launching a feature with blurred decision rights
A customer-facing release crosses product, engineering, analytics, support, and legal. Without explicit decision rights, scope creeps, launch readiness slips, and rework starts. The framework names the accountable team for each outcome — scope, readiness, rollout — and makes the meetings that don't need to exist visible.
Read the breakdownResponding to a customer-impacting incident
Recovery, communication, logging, and remediation all need named owners. The technical fix is only part of the work — the framework makes the surrounding labor as visible as the code change, so nothing important quietly falls to whoever is most reliable at 2am.
Read the breakdownRunning onboarding and internal support
Onboarding, documentation, meeting prep, and relationship maintenance usually live as invisible glue — done by whoever notices, rewarded by no one. The framework promotes that work to visible operating commitments, with owners, cadences, and recovery paths.
Read the breakdownRead the long-form argument.
The full explanation of the framework, its mechanics, and the assumptions it depends on — plus the diagnostics and worked examples behind every principle. Free to read, free to share.