How ONA helps you pick the right lens — with measurement, evidence and course correction
In the first article, I argued that the problem is often not your org chart, but the lens you use to look at it. Especially in an AI context: execution gets cheaper, but direction, integration, quality and accountability become more important.
The question is: how do you know which lens to put on? And how do you stop "flattening" or "more governance" from becoming an article of faith instead of an evidence-based choice?
This is where ONA (Organizational Network Analysis) comes in: a way to measure how work, decisions and coordination actually flow through your organization — independent of reporting lines.
This article does two things:
- Explains what ONA is (in plain language).
- Shows how you can use ONA per "lens" to back up decisions and course-correct them
1) What is ONA (Organizational Network Analysis)?
ONA is, in essence: a measurable map of collaboration.
Where an org chart says "who reports to whom", ONA says:
- Who actually works with whom?
- Who asks whom for advice?
- Where do decisions actually flow?
- Where do bottlenecks, overload or silos form?
- Where do escalations actually go?
- Which teams are (wrongly) cut off from critical knowledge?
Think of ONA as the X-ray of collaboration: not to judge individuals, but to understand the system.
What data do you actually use?
ONA can be fed by different sources, typically in two categories:
- Collaboration metadata (digital trail) For example: meeting networks (who sits together often), communication volume between teams, handoffs between tickets/requests, response times on escalations. Important: this often works with metadata rather than content.
- Targeted surveys (collaboration questions) For example: "Who do you turn to for X?", "Who unintentionally blocks your work?", "Who is critical to getting things done?"
In practice, a combination usually works best: digital metadata gives you scale, surveys give you nuance.
What makes ONA useful for org design?
ONA translates "gut feel" and anecdotes into patterns such as:
- Bridge figures (people/teams that connect silos)
- Bottlenecks (where everything has to pass through)
- Overload (where too many dependencies land)
- Isolation (teams that sit too far outside the flow)
- Fragmentation (too many parallel mini-networks)
- Escalation paths (where exceptions/risk actually go)
That's exactly the information you need to decide: do we cut layers, or add orchestration? Do we unbundle jobs, or redraw workflows?
2) EU/GDPR: how do you do ONA realistically?
ONA is possible in the EU, but only if you frame it correctly: organizational diagnostics, not personal monitoring.
Concrete, realistic principles:
- Purpose limitation: define a clear question up front, e.g. "Where do incident escalations get stuck?" or "Where's the coordination overhead in order-to-cash?"
- Data minimization: use what you need, not everything you could, e.g. meeting attendance per team, handoffs per ticket flow, interaction volume aggregated.
- No content mining: no analysis of email or chat content. In many contexts, metadata is already enough.
- Aggregate first: insights at team/workflow level. No "ranking of most influential people" as an output.
- Transparency: explain what you're doing, why, and what you're not doing with it. Involve works councils/employee representation and your DPO where relevant.
- Short retention: work with rolling windows (e.g. 30–90 days). Measure trends without building permanent "shadow profiles".
If you apply these guardrails, ONA stays a tool for improvement, not control.
3) ONA as a "decision aid" for the five lenses
Here's where it gets practical: how do you use ONA per lens to (1) back up a decision, (2) measure whether your choice is working, and (3) course-correct?
Lens 1 — The "Great Flattening" lens: AI cuts away coordination work
What you want to know Is a large part of our management and coordination layer mostly occupied with status, routing and follow-up?
Applying ONA
- Measure coordination intensity per workflow: how many handoffs, how many sync meetings, how much "routing" between teams?
- Identify bottleneck hubs: where does everything have to pass through (for better or worse)?
- Look at span of control in practice: how many interactions "land" on certain roles/teams?
Decisions you can make with more confidence
- If coordination is mostly "status & routing": flattening can work, but pair it with compensations (coaching/quality).
- If coordination is mostly "exception & risk": flattening is probably a trap.
Course-correcting
- After a flattening move: measure whether bottlenecks shift onto fewer people (overload risk) or actually decrease.
(Context: Fortune discusses flattening and how AI is changing org charts, with caveats about the role of middle management.) Source: Fortune – AI is already changing the corporate org chart and Fortune – Surviving the Great Flattening
Lens 2 — The orchestration lens: less executing, more steering (and monitoring)
What you want to know Where does your organization need to orchestrate "human + agent" collaboration, and where is governance genuinely needed (versus bureaucracy)?
Applying ONA
- Map escalation paths: where do exceptions actually go?
- Measure cross-silo dependencies in critical workflows: where is integration fragile?
- Detect risk clusters: places where review/approval keeps recurring (a symptom of either uncertainty or genuine compliance need)
Decisions
- Where escalations are frequent: you need orchestration (rhythms, roles, guardrails).
- Where escalations are rare: governance can be lighter, agent-first can move faster.
Course-correcting
- When you add orchestration: measure whether escalations resolve faster and whether handoffs drop, without risk increasing.
Lens 3 — Task unbundling: jobs don't disappear, they get rebuilt
What you want to know Which roles consist of tasks AI can take over, and which consist of judgement, context and exception-handling?
Applying ONA
- Look at feedback patterns: a lot of "rework loops" points to review/judgement work.
- Look at search/expertise traffic: who gets contacted for context? That's often not automatable, but it is supportable.
- Measure shadow work: unexpectedly high micro-coordination and ad-hoc alignment around a role points to hidden task bundles.
Decisions
- You rebuild roles: less "doing", more "review, exception handling, system thinking".
- You decide where agents get built into the workflow rather than into the org chart.
Course-correcting
- After task unbundling: measure whether expertise traffic drops thanks to better self-serve (AI), or instead explodes (chaos/role confusion).
Lens 4 — The "work chart" lens: value creation over reporting lines
What you want to know How does value actually flow? And where are the frictions (handoffs, wait times, misunderstandings)?
Applying ONA
- Build a network per value stream (e.g. lead-to-cash, incident-to-resolution).
- Measure handoff density: how many transfers per case?
- Measure time-to-respond at nodes (aggregated): where does wait time build up?
Decisions
- You can draw your "work chart" with evidence: where an agent can automate a step, where human checkpoints must stay.
- You can show the gap between the "official process" and the "actual work".
(Inkeep explicitly describes why org charts fall short for agents and why work charts are more useful.) Source: Inkeep – AI Agents in the org chart… work charts
Course-correcting
- After redrawing: measure whether handoffs drop and whether cycle time improves without loss of quality.
Lens 5 — The accountability lens: agents don't belong "in" the hierarchy
What you want to know Where does responsibility actually sit, and where is it diffuse or unintentionally concentrated?
Applying ONA
- Map "incident ownership" and "decision ownership" via escalation data: who ends up holding it when things go wrong?
- Look at approvals: where are the real decision gates?
- Detect "accountability gaps": places with a lot of interaction but no apparent owner.
Decisions
- Define ownership per workflow (and per agent use case): who's accountable for outputs, guardrails, audits, updates.
- Design auditability where it's needed, not everywhere.
(EMA argues for workflow-centered ownership and governance around agents.) Source: EMA – AI Agents Revolutionizing Corporate Org Charts
Course-correcting
- After ownership changes: measure whether escalations "wander" less and land with the right owner faster.
4) How your leadership team actually uses this: measure → choose → course-correct
Once you add ONA to your C-level conversation, the question shifts from:
- "Should we get flatter?" to
- "Where is coordination mostly status/routing, and where is it risk/exception?"
A simple decision logic (practical, not perfect):
- Lots of status/routing traffic + few exceptions → flattening can work
- Lots of exceptions/escalations + cross-silo integration → orchestration needed
- Lots of rework loops & expertise traffic → task unbundling + a better "review" architecture
- Lots of handoffs & wait time → redraw the work chart
- Diffuse ownership → accountability lens first
ONA makes that conversation measurable, repeatable, and correctable.
5) Closing: ONA isn't a "new truth" — it's a calibration instrument
ONA isn't about "the perfect structure". It's about learning faster which lens is right for which part of your organization.
Because in an AI era, a single structural answer is rarely correct. But one mistake remains universal: continuing to steer with an outdated lens.