Category: AI

The 30-Point Sprint: How Leaders Hoard Capability Instead of Building It

A staff engineer at a scaling tech company told me about their managing director — someone with organizational authority, access to the best AI tools, and apparently a lot of enthusiasm for using them. The director had assigned themselves 30 development story points in a single sprint. The rest of the team was carrying 6 to 16 each.

“They vibe code everything,” the engineer said, shaking their head. Their team was left babysitting that output.

I’m not here to cast shade, and I’ve seen enough versions of this pattern to know it’s rarely malice — it’s excitement without governance. Glee without the long view. AI makes execution feel effortless, and when that feeling hits someone with organizational authority, the natural instinct is to run with it and stay in motion.

But I keep thinking about what a different story that could have been.

Imagine the same director, the same tools, and the same gap in formal coding skill. Instead of assigning themselves 30 points, they walk into a team standup and say:

“Here’s the problem I was trying to solve, and this is how I approached it with AI. Show me how you would do it the traditional way — and then show me how you would do it with the AI tooling we’ve implemented. Let’s talk through the strengths, drawbacks, and leverage opportunities for all three approaches.”

How different would that be for the team? For that leader? For the org’s health as a whole?

That’s not a weak play. That’s one of the highest-leverage moves a leader can make — using their own ignorance as an opportunity to build a structured learning platform. The team gets to teach. The leader gets to learn. The org gets a three-way comparison that surfaces assumptions, tradeoffs, and best practices that would otherwise stay locked in individual heads — or leave entirely when those people move on.

It becomes a running growth exercise. It compounds, to the good, for a change.

Instead, the reality

30 story points for someone who should be focused on meta-level engineering concerns. A team stuck babysitting their leader’s output. And an opportunity for something genuinely great quietly wasted.

AI gives leaders without deep technical chops a real reason to lean in — not for the first time, but never has it been so readily accessible. The question is whether they use that access to hoard capability or to build it.

The answer is what separates a manager from a leader.

Originally shared on LinkedIn.

A New Job Is Lurking Inside Your Design/Product Org

AI capability inside a design org doesn’t distribute itself.

Enthusiasts will adopt it, of course. They build their own local workflows and see some gains. They may hoard the knowledge — not out of malice, but because nobody’s asked them to share it around. Everyone else keeps working in more traditional fashion, often quietly ashamed of their (self-diagnosed) ignorance.

This is AI Adoption Debt. And it’s not a training problem. Training can build knowledge, but it doesn’t build systems.

The role that builds those systems is forming right now inside mature design and product organizations. It doesn’t have a consensus title yet, and in most orgs, it doesn’t exist at all. Many don’t even know they need it.

What the role is not

It’s not a prompt engineer. It’s not an AI evangelist. It’s not a design technologist in the traditional sense, and it’s not a product manager for your AI tooling budget. Those roles exist and they matter — but they’re not this.

What the role actually is

The role’s primary responsibility is managing organizational AI adoption infrastructure — ensuring that knowledge compounds across teams rather than concentrating among early adopters. It sits at the intersection of DesignOps, systems-level organizational thinking, change management, and technical depth (without requiring engineering-level skills).

AI doesn’t speed up decision-making. Decision-making is still the bottleneck. This role builds the systems that distribute AI leverage equitably across the org so that the bottleneck doesn’t also become a single point of failure.

Building that infrastructure calls for a specific mix of skills

    • Deep familiarity with design practice
    • Systems-level organizational thinking
    • Change management expertise
    • Technical depth (not engineering-level, but fluent)
    • Accumulated judgment and pattern recognition

The 5th dimension: A foundation of judgment

The first four are table stakes. The fifth — judgment — is what separates someone who can describe this role from someone who can actually do it. It’s the ability to read an organization’s readiness, sequence interventions correctly, and know when to push and when to wait. It accrues slowly, can’t be hired in from scratch, and is what makes this role genuinely hard to fill.

Where the role is “beaming in” right now

It’s appearing most visibly inside organizations that have already built mature DesignOps functions. Those teams have the operational muscle memory. They know how to run programs, own shared infrastructure, and manage change at scale. The AI layer is new; the organizational pattern is not.

It’s also showing up in product orgs — particularly in companies where product operations has developed enough structural maturity to absorb a new domain.

Why it doesn’t yet exist

Because most organizations are still in the tool-buying phase. Leadership approves the budget. Individuals experiment. Ninety days later there are a dozen parallel workflows that don’t talk to each other, and one or two enthusiasts burning out trying to carry everyone else toward the goal post.

Nobody paused to ask: who owns the system?

What to do if you’re building a design or product org right now

    1. Audit honestly. Map who’s using AI tools, how, and what’s been shared beyond their immediate team. The gaps will be obvious.
    2. Assign ownership. Not enthusiast ownership — organizational ownership. Someone with design knowledge, organizational authority, and an operational orientation.
    3. Start with vocabulary. Shared vocabulary is what makes it possible for a new hire to be productive in weeks instead of months. It’s the cheapest, highest-leverage infrastructure investment you can make before building anything else.

The organizations that recognize this structural gap early will have a compounding advantage over those waiting for the formal job title to arrive before they act.

The role is forming. The question is whether it forms intentionally inside your org, or by accident.

Originally published on LinkedIn on June 2, 2026.