Reading 01
Power lives at the crossings
The silo's power sits at the border posts: access, deploys, schemas, exceptions. Keep the border rules. Get rid of the border theater by turning routine policy into automation.
Org Transformation / Data operating model — decision sheet
Neutralize the monopoly, not the people.
How to take delivery power away from a dysfunctional data silo without turning the fix into a punishment.
DocumentSILO-01
RevisionB
DateAug 2026
StatusFor review
Bottom line
Your instinct is half right. Pull the routine requests into a real service desk, and put your strong data people inside product teams. But do not sort people into a permanent builder class and a ticket class. Split the work by type and risk, remove the blanket veto, and handle weak performance the way you would handle it anywhere: directly, one person at a time.
01 / Diagnosis
It looks like a people problem. It is mostly a wiring problem.
The bad behavior may be real. But the org handed one group the platform, the risk calls, the access, and the only road to production — all at once. Give any team that much gate-keeping and you get a monopoly, whether or not the people are any good.
Solid / how the work flows
Dashed amber / the loop that feeds itself
The backlog is not just overload. Left alone, it is the machine that rebuilds the silo every quarter.
Reading 02
Governance without a budget becomes control
They were told to guarantee quality and compliance, but never got the tooling or the named owners. Reviewing everything by hand is what that job looks like when it is unfunded.
Reading 03
"We review it" became "we decide it"
Ordinary implementation choices got relabeled as enterprise risk. That is how a checkpoint quietly turns into a throne.
Reading 04
Two kinds of work, one queue
Urgent requests and long-term builds cannot share a queue. The interrupts eat the roadmap, and the missing roadmap creates more interrupts.
Reading 05
Repeat tickets are missing features
A request that shows up every week is not a chore. It is evidence of a missing self-service feature, an unclear policy, or a weak platform.
Reading 06
If all the talent builds, operations rots
Pull every strong person into building and the service desk becomes a dead end — slower, weaker, and resented. Then the builders lose touch with how their work runs.
The structure rule
No single data group should own the platform, interpret the policy, set the priorities, and sign off on releases. All four together is a monopoly you cannot argue with — no matter who staffs it.
The people rule
Better structure does not excuse bad work, obstruction, or poor judgment. It just takes away the places bad work can hide: vague authority and an eternal queue.
The move: authority goes to where the context lives. Standards go to where the reuse lives. Controls go to where the risk lives.
02 / The split
Keep the split. Skip the caste system.
A service desk plus embedded builders is the right shape. The dangerous part is deciding who is "good" by reputation, locking both groups in place, and calling it an operating model.
| Your instinct | What it gets right | Where it backfires | Build this instead |
|---|---|---|---|
| Move routine work to a desk | Protects builders from constant interruption. Makes service work measurable. | A desk staffed as punishment turns into a slow, resentful dumping ground. | A professional operations function: request catalog, service targets, an automation budget, and a career path. |
| Let the strong people build | Puts scarce judgment next to products and customers. | "Strong" gets decided by manager folklore, and the same heroes stay heroes forever. | Written role standards, work samples, and outcomes as the evidence. Rotate everyone through operational exposure. |
| Take the silo out of delivery | Breaks the queue's grip on schedules and design choices. | Throwing out the expertise along with the veto gets you tool sprawl, quality drift, and unmanaged risk. | Remove the blanket approval. Keep the published controls, the platform, and a fast path for real exceptions. |
| Give the operators no say | Stops routine fulfillers from dictating architecture. | The people who see the recurring pain lose the power to fix it. | Operators run the playbooks and own the automation backlog. They advise loudly; they hold no general veto. |
The line not to cross: if someone cannot meet the bar after clear expectations, real support, and a fair window, that is a performance conversation. Reassignment to a punishment desk is not management — it is avoidance with an org chart.
03 / Target model
Four lanes. One front door. No ministry of data.
Split the work into four different jobs. Each lane gets its own purpose, authority, and scoreboard — connected by published interfaces, not personal permission.
Solid / work routed by class
Blue dashed / rules and evidence requirements
Dashed amber / recurring demand escalating to automation
A ticket that keeps coming back is a design flaw with a queue number. Past a set recurrence count, it must leave the queue and become platform work: automated, self-served, or eliminated.
Lane 01 / Embedded delivery
Put judgment next to the work
Capable data people inside priority domains, sharing accountability with product engineering — not a dotted-line advisory role.
Owns — domain pipelines, models, delivery order, reliability inside the guardrails.
Does not own — policy exceptions or the shared platform roadmap.
Lane 02 / Data platform
Make the safe way the easy way
Small and senior. Judged by adoption, reuse, and how much friction it removes — never by the number of standards it publishes.
Owns — approved patterns, metadata, observability, automated evidence, platform reliability.
Does not own — domain designs or product priorities.
Lane 03 / Data operations
Run service like a product
Documented request classes, clear authority, severity-based incidents, service targets, knowledge capture, and a budget to automate itself smaller.
Owns — predictable fulfillment, triage, known fixes, the feedback-to-automation backlog.
Does not own — novel builds, vague "fix the data" work, or architecture by ticket.
Lane 04 / Governance & assurance
Small, explicit, and off the critical path
Defines the non-negotiables, names accountable owners, checks the evidence, and decides real risk questions — not routine preferences.
Owns — classification, retention, acceptable use, audit evidence, high-risk escalation.
Does not own — the ordinary route to production.
04 / Decision rights
Remove the undefined veto. Keep named authority.
"No say" is too blunt an answer. Publish who decides what, who gets consulted, what evidence a stop requires, and how long an exception is allowed to sit.
Remove
What central data loses
Blanket approval of ordinary changes. Ownership of every backlog. Control of domain priorities. Preference dressed up as policy. "Advice" that works like a hidden veto.
Share
What becomes joint
Cross-domain architecture calls. What enterprise metrics mean. Data-quality accountability. Platform investment priorities. Incident learning and talent development.
Keep
What central capability keeps
The shared platform. Explicit security, privacy, and regulatory controls. Reusable enterprise capabilities. Emergency incident authority. A fast lane for real cross-domain exceptions.
| Decision | Who decides | Who's consulted | Central data's role | Clock |
|---|---|---|---|---|
| Normal pipeline or model change, inside standards | The domain team that owns it | Platform, if useful | No approval | Team cadence |
| What gets built first | Domain / product leadership | Consumers, finance | No veto | Portfolio cadence |
| Shared tooling and reusable patterns | Platform owner | Domains, security | Owns | Published roadmap |
| Classification, retention, acceptable use | Governance with security / legal | Domain owner, platform | Owns | Policy cadence |
| Standard access under policy | Automated workflow + the accountable data owner | Data operations | Executes | Same business day |
| Cross-domain or policy exception | A named architecture / risk forum | Domain, platform, governance | One voice | 48-hour decision |
| What an enterprise metric means | A named business owner | Finance, analytics, domains | Steward | Sized to impact |
| Production incident containment | Incident commander | Technical and risk owners | Emergency role | By severity |
Stop test 01
A citation
A specific policy, control, contract, or material risk — not "data needs to review it."
Stop test 02
Written evidence
The gap and its consequence go into the decision record, in writing.
Stop test 03
A named owner
One person accountable for resolving the risk or formally accepting it.
Stop test 04
An expiry date
A response clock so nothing waits forever. Silence is not a veto.
Rule: a stop only counts if it passes all four tests. Anything else is an opinion, and the work keeps moving.
05 / People
Design the roles on paper. Manage the people one at a time.
The service lane is a real specialization, not a sentence. Persistent underperformance is a management job, not an org-chart category.
The caste model
"Good people build. Bad people take tickets." Permanent labels, degraded service, quiet retaliation, hero dependency — and a queue nobody wants to improve.
The capability model
"Different work needs different evidence." Written roles, observable standards, real mobility, rotations, coaching — and honest performance management where it is due.
Step 01
Define the roles
Execution, reliability, judgment, collaboration, documentation — written down before anyone is placed.
Step 02
Gather evidence
Recent outcomes, work samples, peer input, incident behavior, learning speed. Not folklore.
Step 03
Place deliberately
Embedded, platform, operations, or governance — by fit, with the employee's input where possible.
Step 04
Support visibly
Pairing, training, runbooks, clear goals, and a time-boxed improvement window.
Step 05
Act honestly
Promote, rotate, reassign — or run the normal HR process if the bar stays unmet.
| Lane | Signs of fit | The mistake to avoid | Mobility design |
|---|---|---|---|
| Embedded delivery | Handles ambiguity, translates business outcomes, ships safely, works across disciplines. | Confusing fast coding with domain judgment or operability. | Community of practice, platform rotations, shared on-call. |
| Platform | Builds reusable systems, cares about developer experience, reasons about scale. | Turning preferences into mandates, or absorbing domain work. | Office hours, domain secondments, adoption-based progression. |
| Operations | Reliable execution, incident judgment, pattern recognition, clear communication. | Staffing it only with people leadership considers weak. | Automation ownership, builder rotations, an explicit promotion path. |
| Governance | Precise risk reasoning, policy clarity, proportion, fast decisions. | Using risk language to claim broad technical authority. | Embedded reviews, policy-as-code work, measured exception turnaround. |
Protect the service lane: strong operational leadership, real decision authority, a visible automation backlog, promotion criteria, and rotations — so builders stay accountable for how their work runs.
Protect fairness: calibrate assessments across managers, write the role expectations before placement, review outcomes by role and demographic, and make the way up real. A "temporary" lower-status track becomes permanent fast.
06 / Guardrails
Replace permission with proof.
Removing the manual gate is not removing the controls. Write the rules down, automate the proof, watch production, and save human judgment for the genuinely new or irreversible.
Solid / the default route
Dashed amber / the exception branch — the only place a human decides
The paved-road test: if teams keep going around the official path, the path is the problem. Governance is working when the safe way is also the easy way.
| Risk | Control that isn't a veto | Proof it leaves behind | When a human steps in |
|---|---|---|---|
| Wrong people get access | Role-based requests, least-privilege defaults, expiry dates. | Request and entitlement log. | New kind of role, sensitive data class, or emergency access. |
| Bad data ships | Data contracts, automated tests, freshness targets, quarantine. | Test history and incident record. | Material breach, repeat failures, or disputed fitness. |
| Nobody knows where data came from | Lineage emitted by the deploy pipeline; ownership required before production. | Catalog graph and deploy record. | A critical asset with no owner, source, or recovery path. |
| Privacy or residency violation | Classification tags, approved zones, scanning, transfer controls. | Classification and processing record. | New use, new jurisdiction, or external sharing. |
| Data kept too long | Lifecycle rules with automated deletion and legal holds. | Lifecycle config and execution log. | Conflicting obligations or a requested exception. |
| Tool sprawl | Supported interfaces, compatibility contracts, cost thresholds. | Architecture record and operational SLO. | A new shared dependency or a big irreversible commitment. |
07 / Transition
Stop the monopoly first. Move the people last.
Do not open with a mass personnel move. Open with decision rights, dependency evidence, and protection of critical knowledge — then move work and authority in controlled slices.
First 72 hours
Name one executive sponsor. Freeze any new manual gates. Point every request at one front door. Inventory who holds production credentials and which systems only one person understands. Say plainly that security and incident controls stay on while the approval power gets redesigned.
Days 0–30
Expose the real system
- Publish an interim decision-rights charter.
- Classify all work: service, incident, platform, product, exception.
- Baseline wait time, handoffs, rework, and queue age.
- Map every gate — access, deploy, knowledge, budget — and who holds it.
- Name owners and backups for critical datasets.
- Assess people against written role standards.
Proof at day 30Every request has a lane. Every gate has an owner, a reason, and a plan.
Days 31–60
Build the new paths
- Launch the service desk with a catalog and targets.
- Embed data people in two or three priority domains.
- Stand up the small platform team.
- Automate the highest-volume, lowest-risk requests.
- Replace the first approvals with pipeline evidence.
- Start coaching plans — or formal performance steps.
Proof at day 60Pilot work ships without a committee. Real exceptions resolve inside 48 hours.
Days 61–90
Transfer and prove
- Move selected pipeline ownership into the domains.
- Retire redundant reviews and shadow gates.
- Convert repeat tickets to self-service or platform work.
- Run recovery drills on critical data products.
- Publish lane scorecards against the baseline.
- Fix role design; act on individual gaps.
Proof at day 90The old silo is no longer the default road to production — and the quality evidence got more visible, not less.
Sequence discipline: pair up ownership before cutting access. Capture runbooks before moving people. Pilot in two or three domains before scaling. Remove a gate before you move the knowledge and you have converted frustration into outage.
08 / Measures
Measure flow, safety, and dignity together.
Ticket closures alone will lie to you. Pair every speed number with an outcome number, so fast cannot hide bad — and averages cannot hide the work that still waits forever.
Flow
≥70%
of ordinary compliant changes ship with no central human approval
Access
≥80%
of routine access filled through policy-based self-service
Exceptions
<2 days
p90 decision time for a properly formed exception
Resilience
100%
of critical data products have an owner, backup, contract, and recovery route
Exhaust
Top 10
recurring request types automated, eliminated, or funded on the roadmap
Suggested day-90 targets, not universal benchmarks. Confirm the baseline in the first 30 days, then calibrate — without weakening the direction of travel.
| Dimension | Watch | Pair it with | What it tells you |
|---|---|---|---|
| Flow | Median and p90 lead time, deploy frequency, handoffs, queue age. | Post-release defects. | Whether the bottleneck actually disappeared — for hard work, not just easy work. |
| Service | Target attainment by request class, time to restore, self-service rate. | Reopen rate; requester-confirmed fixes. | Whether operations is reliable, or just fast at closing tickets. |
| Quality | Freshness, completeness, contract pass rate, material incidents. | Business fitness and consumer trust. | Whether distributed ownership improved outcomes, not just test counts. |
| Governance | Owned / classified / traced critical data; exception and audit counts. | Control-caused delay and bypass rate. | Whether controls are strong and proportionate. |
| Resilience | Bus-factor reduction, exercised runbooks, recovery drills. | Drills that actually succeed. | Whether tribal knowledge and hero dependency are shrinking. |
| People | Role mobility, progression, team health, regretted attrition. | Outcomes by role and demographic. | Whether the service lane quietly became a punishment track. |
| Business | Trusted-product adoption, duplicate retirement, decision speed. | Independent user validation. | Whether the redesign created advantage, or just a cleaner org chart. |
Watch 01
The shadow veto survives
The old team still "reviews" everything informally, through access or tribal knowledge.
Watch 02
Operations becomes an underclass
Lower status, no growth path, and only people someone labeled weak.
Watch 03
Access volume keeps growing
Self-service is not maturing, so the new desk is just the old queue.
Watch 04
Exceptions become the main road
The standards are unusable — or being used as somebody's taste.
Watch 05
Teams build shadow systems
The paved road is slower than going around it. Fix the road.
Watch 06
The same heroes in every meeting
Strong people own no single outcome but absorb every escalation.
Watch 07
Quality drops after the handoff
Authority moved before the knowledge, contracts, and monitoring did.
Watch 08
Leadership declares victory at the reshuffle
Priority conflicts, underfunded platform work, and executive escalation habits never changed.
09 / Decision
If this were mine to run, I would make seven calls, in order.
- Announce the authority change: compliant work no longer needs blanket central approval.
- Name the four lanes, each with a leader, a backlog, and a scoreboard.
- Protect the control plane: security, privacy, quality, lineage, and recovery stay non-negotiable.
- Pilot embedded delivery in two or three domains that matter.
- Run the service desk like a product, and fund killing its top ten tickets.
- Assess people against written roles, support the moves, and manage real gaps directly.
- Come back at day 90 with flow, risk, resilience, and people numbers — not anecdotes.
A healthy central data team is the one you barely notice: excellent defaults, visible risk, and nobody asking permission to do routine work.
Neutralize the
monopoly —
not the people
monopoly —
not the people