Issue #3 March 23, 2026

Agents, Jobs, and the Productivity Puzzle

Editor's Take

This week crystallized a tension that will define the rest of 2026: the AI industry is shipping autonomous agents at breakneck speed, while the evidence on whether any of it actually makes us more productive remains stubbornly mixed. At GTC 2026, Jensen Huang declared OpenClaw — the open-source agent framework that went from zero to 250,000 GitHub stars in two months — "the operating system of intelligent computers," drawing explicit parallels to Windows and Linux. Anthropic's Claude Code now authors 4% of all public GitHub commits. Perplexity shipped a $200/month Mac mini that runs as your 24/7 digital proxy. Meta-backed Manus launched a desktop app that lets agents control your local files and applications. The message from Silicon Valley is unanimous: the age of the AI agent has arrived, and the operating system is being rewritten in real time.

Then Andrej Karpathy, OpenAI co-founder and the man who coined "vibe coding," published an interactive treemap scoring 342 U.S. occupations for AI exposure. It went viral instantly — 42% of jobs scored 7 or higher, covering 59.9 million workers and $3.7 trillion in wages. Elon Musk amplified it, declaring "all jobs will be optional." Within hours, Karpathy deleted the GitHub repository and clarified it was "a Saturday morning two-hour vibe-coded project." But the damage — or rather, the discourse — was done. The fundamental problem wasn't the visualization; it was the methodology. An LLM scored how replaceable jobs are by LLMs. That's not labor economics — it's a mirror looking at itself. The analysis omitted regulatory barriers, organizational inertia, demand elasticity, union resistance, and the simple human preference for dealing with other humans. Tasks are not jobs. Automating 60% of a role's tasks doesn't eliminate 60% of the role — it changes what the role looks like.

Which brings us to the hardest question: does GenAI actually boost productivity? The answer depends entirely on where you look. In the lab, BCG consultants using GPT-4 completed 12.2% more tasks, 25.1% faster, with 40% higher quality — but were 19% less likely to get correct answers when the task fell outside AI's capability frontier. In the real world, the picture dims. A Danish study of 25,000 workers across 7,000 workplaces found "no significant impact on earnings or recorded hours in any occupation." The Federal Reserve Bank of St. Louis estimates GenAI has saved just 1.6% of all U.S. work hours — meaningful in aggregate, modest per worker. And in Kenya, a randomized trial giving 640 entrepreneurs a GPT-4 business mentor found no average treatment effect at all: high performers gained roughly 15%, but low performers did 8% worse. The pattern is consistent: GenAI is a skill amplifier, not a skill equalizer. It widens the gap between those who already know what to ask for and those who don't. That's worth remembering the next time someone shows you a treemap that scores your job for obsolescence.

This Week's Essay

Functional Design vs. Business Unit Design — Part I

The AI productivity debate above makes one thing clear: technology doesn't create impact on its own — organizations do. A tool that makes high performers 15% better while making low performers 8% worse isn't a technology problem. It's an organizational design problem. This week, we begin a series on the structural choices that determine whether new capabilities — AI or otherwise — actually translate into results.

Your People Are Too Loyal to You

Those who know me know I've long been passionate about one thing: teaching future leaders and entrepreneurs how to scale a business — from the first hire to five hundred people and beyond. For years I've been studying, living, and preaching what it actually takes to scale effectively. And one of the most critical — and most underestimated — levers is this: how you design your organization has to evolve as your company grows.

This is the first in a series of articles exploring exactly that. We start with one of the most consequential design choices a scaling company faces: functional structure versus business unit structure — and the very real trade-offs that come with each.

The Comfort of Clean Reporting Lines

In organizations where data analysts report to the Head of Data, software engineers report to the Head of IT, and content people report to the Head of Marketing — functional leaders build something that feels like excellence. Deep expertise. Strong standards. A team that knows how to do the work properly.

What they sometimes build instead is a silo with good intentions.

The Org Chart Looks Clean. The Work Doesn't.

There's a satisfying logic to functional reporting. Like reports to like. Expertise compounds. Standards hold.

But the moment a product owner needs to bring a new offer to market — or a strategic initiative leader is tasked with entering a new segment, transforming a customer experience, or driving an enterprise-wide change program — they hit the same uncomfortable truth: the work requires ten functions and they control none of them.

Every capability they need lives behind a functional boundary. Every request becomes a conversation, a queue, a negotiation, a prioritization meeting they weren't invited to.

The product owner is asking permission to use your data analyst. The initiative leader is lobbying three functional heads simultaneously just to stand up a working team. Both are spending energy on access that should be spent on execution.

The product doesn't care about reporting lines. The customer doesn't. The strategic deadline definitely doesn't.

What Actually Happens When Functional Walls Are High

Product owners and initiative leaders are resourceful. When functions are hard to access, they adapt — but not always in ways that serve the organization.

They build informal networks — finding the data analyst who's "helpful" and routing everything through them until that person is quietly drowning.

They hire around the gap — a coordinator here, a junior analyst there — creating shadow capability that duplicates what the function already has.

They lower their ambitions — launching with approximate data, good-enough content, and financial models built on assumptions because the right experts were unavailable when the decision couldn't wait.

They lose weeks — not to the complexity of the work, but to the complexity of getting the right people in the room.

None of this shows up on anyone's KPIs. It just quietly degrades the quality and speed of what the organization produces.

Opening the Aperture

The functional leaders who create the most organizational value aren't the ones who protect their teams. They're the ones who deploy them.

Imagine a product launch where the data analyst is embedded with the product team — direction set by the product owner, quality standards held by the Head of Data. Where the content person executes the launch narrative inside the business unit, with Marketing ensuring brand consistency rather than approving every output. Where engineering, finance, and sales show up as genuine contributors, not vendors processing requests from a distance.

Now imagine a strategic initiative — a new market entry, a digital transformation, a major customer experience overhaul — where the initiative leader can assemble the right cross-functional team without a month of stakeholder negotiations. Where functional leaders actively second their best people into the work, confident that their standards travel with them.

The functional leader's job in both models isn't diminished. It's clarified.

You're no longer managing what your people work on. You're ensuring they're excellent wherever they work — developing their capability, holding their standards, building their careers.

That's a harder job. It's also a more valuable one.

The Real Test of Functional Leadership

Any functional leader can build a great team that reports to them.

The harder test is whether you can build people who are trusted and effective across the organization — inside launches they didn't plan, inside initiatives whose outcomes they don't own, solving problems they didn't define.

If a product owner or initiative leader asked tomorrow to direct your data analyst's priorities for the next six weeks, what would your answer be?

If there's hesitation — it's worth asking honestly whether that hesitation is about quality, or something closer to territory.

A function that can't be deployed isn't a capability. It's a department.

For functional leaders: When a product launch or strategic initiative lands in your organization, how freely can a product owner or initiative leader actually access your people? And what would genuinely have to change — in governance, in mindset, in how your own role is measured — for that answer to improve?

Next in this series: when business units move fast and own everything, the organization gains speed — but starts losing consistency, standards, and the deep expertise that made it great in the first place. That's when functional leadership stops being a constraint and becomes the answer.

Get the newsletter in your inbox

A weekly, curated digest on AI and organizational design.