Narek Verdian

One is how we draw the company. The other is how it runs.
One is how we draw the company. The other is how it runs.

Start with the work, not the org chart

5 min read Copy link

On this page

I spent part of the summer speaking with founders, technology leaders, and teams building AI-native companies across California and Europe. One pattern showed up again and again: the companies achieving genuine leverage are not the ones with the longest list of use cases. They are the ones that began by rethinking the work itself.

Most enterprise AI initiatives start somewhere very different. A company creates a working group, runs workshops across departments, and asks each function to submit candidate problems: What could marketing do with generative AI? How could customer support use chatbots? Where can engineering speed up ticket triage?

The result is a neat catalogue of 50 or 100 use cases, mapped neatly to the boxes on the existing organisation chart.

It looks like progress. But it is fundamentally the old company accelerated.

Automating an inefficient process does not make you AI native. It makes you faster at doing things you probably shouldn’t be doing at all.

The more interesting question is not: How do we apply AI to each box on our org chart?

It is: If we were designing this company today, knowing what is now possible, would the work be organised this way at all?

Start with the work

Most organizational structures are historical compromises.

We created functional silos—marketing, legal, operations, finance, product, engineering—not because work naturally divides into neat vertical stacks, but because of coordination friction. In the past, people needed to sit near those with similar skills to share context, maintain standards, and manage communication bandwidth.

Handoffs, status updates, multi-stage approval chains, and governance boards were all rational mechanisms designed to bridge the gaps between those silos.

When work moves across a traditional company, it leaves digital exhaust everywhere: pull requests, tickets in Jira, threads in Slack, customer support conversations, design files, roadmaps, specs, and vendor contracts. No single person sees the whole picture. Each team sees only their own slice of the sequence.

Every trace the company left, held in one view — and the connections no single person can see.
Every trace the company left, held in one view — and the connections no single person can see.

One of the most powerful things modern models can do is reconstruct the actual workflow from those traces. Not the process as documented in an HR onboarding slide or a static governance diagram, but the messy, real path that work actually travels from customer intent to delivered outcome.

When you bring all those traces together, you quickly spot the seams where friction accumulates:

  • Three separate teams writing three versions of the same product specification for different audiences.
  • Work pausing for two weeks waiting for an approval that could now be evaluated continuously against policy.
  • Information being stripped of context as it moves from customer support into product backlogs.

Having a system map that reality is a powerful first draft. It gives leaders and operators a shared artifact to challenge, interrogate, and calibrate together.

Then rebuild it from first principles

Once the true workflow is visible, you can deconstruct it from first principles.

Every step in a process typically consists of three components: information gathering, judgement, and execution. Historically, all three had to be tightly coupled to human specialists because moving context between people was slow and lossy.

Today, those components can be separated:

  1. Information gathering and synthesis can increasingly be handled by agentic pipelines that aggregate context continuously across systems.
  2. Execution of routine tasks (drafting specs, formatting reports, code boilerplate, preliminary triage) becomes cheap and rapid.
  3. Human judgement is concentrated where it matters most: strategic tradeoffs, creative vision, novel exception handling, and ethical or brand accountability.

When you examine your workflows through this lens, you realise that many traditional steps existed solely to compensate for information scarcity. Remove the scarcity, and the need for the step evaporates.

This also sharpens your build-versus-buy decisions.

Commodity tasks with little differentiation should be delegated to external tools. But workflows that touch your proprietary knowledge, your domain context, and your customer feedback loops represent compound institutional learning. If you outsource the reasoning behind those workflows, you outsource the ability to understand your own business.

Building has become cheaper at the exact moment that owning your operational context has become more valuable.

Functions do not vanish

Rethinking work from first principles does not mean functional expertise disappears.

Engineering, design, finance, legal, and product management remain vital disciplines. Deep craft and rigorous domain capability are more important than ever when directing and evaluating agentic systems.

What changes is how those capabilities are organized around the work:

  • Functions become homes for craft and capability, responsible for standards, skill development, and foundational tooling.
  • Workflows are managed end-to-end as living systems, rather than fragmented chains handed off across functional boundaries.

When a workflow is managed as a unified system, you avoid the classic trap of local optimisation: the support team buys a tool to close tickets faster, while the engineering team buys a tool to triage bugs faster, yet the underlying customer issue still takes three weeks to resolve because the handoff between them remains broken.

Put the org chart away for an afternoon. Trace a single high-value workflow from the moment customer demand appears to the moment value is delivered. Ask what that flow looks like if information flows without friction and every step must justify its existence.

The org chart still matters

Structure still matters, but structure must follow the work—never the reverse.

If your AI strategy starts with your existing org chart, you will inevitably end up sprinkling automation over inherited organizational complexity. You will get incremental efficiency inside existing silos, but you will miss structural leverage.

The hardest part of becoming AI native is rarely the technology. The models, tools, and agent frameworks are advancing every week.

The hardest part is having the courage to challenge inherited ways of working, eliminate steps that no longer make sense, and redesign workflows around what is now possible.

Start with the work. The rest follows.