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.

You Can’t Skip Steps. You Can Only See the Next One.

I was sixteen, maybe seventeen, working the shipping operation for a small publishing house. My job was simple: box the books, run the postage, get the orders out. The books were about process improvement and quality control — dense, technical stuff aimed at engineers and operations managers I’d never met and couldn’t have imagined.

In the downtime between orders, I taught myself to juggle, and I started reading the books almost immediately. Out of curiosity, and a restlessness I didn’t yet have a name for.

But somewhere between the shipping manifests and the packing tape, I absorbed a way of thinking about systems, variation, and process that I had no professional vocabulary for yet — and wouldn’t for years.

I wasn’t actively learning about process control. I was just in the room with books about stuff, right? That distinction turns out to matter more than I understood at the time.


There’s a concept in complexity theory called the adjacent possible. Stuart Kauffman introduced it to describe the boundary of what can come next in biological evolution — not all futures are accessible from a given state, only the ones one step away. Steven Johnson later applied it to innovation: you can’t leap to arbitrary ideas; you can only reach ideas that neighbor your current knowledge and experience.

I didn’t encounter this framework until long after I’d already lived it several times over. When I did, it named something I’d been carrying without language.

That’s the thing about the adjacent possible. From my experience and in the patterns I’ve observed across organizations, you rarely recognize you’re moving into it in real time. You’re just following the problem, the curiosity, the need. The new territory only becomes visible in retrospect.

Most Organizations Try To Leap

Most organizations approach AI adoption the way people approach career planning before they’ve lived enough to know better: they try to leap.

The pattern is familiar enough to be a cliché, but familiarity hasn’t made it less common. Leadership identifies the destination — “we’re getting AI” — and announces it org-wide, often with namedropped companies and models, and almost always paired with vague assurances that this won’t result in layoffs. Then comes the silence. Eventually, links appear, and maybe some basic instructions. Rarely anything that draws a clear line between existing strategy, the gaps AI is meant to address, and how the workforce is actually supposed to use the tools toward that end.

What happens next is predictable. The futurists and early adopters — the people who are curious and adaptive by nature — will engage. They’ll explore, experiment, build local workflows. But their work won’t be aligned or focused, because no one told them what problem they’re solving for the organization. Everyone else pokes at the tool with a stick, gets nothing useful back, and walks away. Adoption flatlines. Leadership concludes the tools weren’t as useful as advertised.

The tools were fine. It’s that steps were skipped.


Don’t Skip Steps

You can’t adopt an AI-native workflow if your team doesn’t share a vocabulary for how AI systems work. You can’t build that vocabulary if people don’t feel safe admitting what they don’t know. You can’t build that safety if leadership is signaling — through rushed timelines, vague reassurances, and the absence of any real curriculum — that uncertainty is a problem to be hidden rather than a condition to be managed.

Each step is only accessible from the one before it. Skipping them doesn’t accelerate the journey. It just means you’ll retrace them later, at higher cost, after something has already broken.

The organizations that move differently do something structurally simple but operationally demanding: they communicate a phased plan that connects strategy to tooling, provides a curriculum that serves every level of expertise and every function, and gives people immediate next steps they can take today. The longer arc includes touchpoints — moments to come together, review what’s been learned, and focus further with more clarity on goals. The plan evolves as the org learns.

The result isn’t that everyone becomes an AI power user overnight. It’s that everyone understands where this is going, how it connects to their work, and what their next step is. Everyone comes along for the ride — or at minimum, knows enough to make an informed decision about how they engage with it.

That’s not a technology problem. That’s an instructional design problem. And it’s solvable.


Closing The Gap Deliberately

Knowing the adjacent possible exists is half the work. The other half is building the bridge to it.

This is where instructional design enters — not as a corporate training concept, but as a discipline for closing the gap between where people are and where they need to be. The best practitioners of it start not with curriculum but with analysis: what does current capability actually look like, what does the next state require, and what specifically stands between the two?

That gap is the unit of work. Not “we need to learn AI” but “our teams can’t evaluate model output because they have no shared criteria for what good looks like.” Instead of the old trope “designers need to code,” the better lens is “designers need enough systems literacy to have a productive conversation with an engineer about tradeoffs.”

In a healthcare UX org, that analysis might produce a capability map showing that clinical researchers can evaluate AI-generated synthesis but lack the vocabulary to specify what they need from a model — which points to the first curriculum artifact being not an AI tools tutorial, but a shared glossary.

The adjacent possible tells you where you’re going. Instructional design tells you how to get there without skipping the steps that make arrival possible.

Organizations that combine both — that map the next achievable state and build deliberate learning infrastructure to reach it — don’t just identify the gap. They close it on purpose, with a plan the whole org can see and follow.


How I Know This Is True

I was trained as a designer — classically, at art school — and somewhere in my first decade of professional work I drifted into engineering. Not because I planned to. Because the problems I was solving kept pulling me one step further into territory I didn’t have a name for yet.

Design gave me the vocabulary for how things should feel and function from a human perspective. Engineering gave me the vocabulary for why things behave the way they do at a system level. Neither one was a leap. Each one was adjacent to where I already stood.

In college, for gas and grocery money, I took a job caring for three disabled adults in their home. Long shifts — sometimes a full weekend, 24 to 48 hours at a stretch. It was unglamorous work in the way that most essential work is unglamorous.

Caring for someone who is wholly dependent on you — for meals, mobility, dignity — compresses your awareness in a specific way. You stop taking your own capability for granted. You develop a constant low-level inventory of what you have, what they need, and what the gap is. Not as a burden, but as a discipline. A practice of noticing.

The adjacent possible of that work wasn’t a job skill. It was an orientation — a habit of accounting for the advantages you’re operating with instead of moving through the world blind to them. Gratitude, yes, but the kind that makes you more capable: functional, not decorative.

Neither transition was planned. Both were adjacent to where I already stood.


What This Has To Do With You

If you’re navigating a career transition, a role change, or an org-wide transformation right now — and in 2026, most people in design and technology are doing at least one of those things — the adjacent possible is a more useful frame than almost anything else I know.

The question isn’t: where do I want to end up? The question is: what is genuinely one step away from where I am right now? What capability, relationship, or context sits just at the edge of my current reach?

That’s the step worth taking. Not because ambition is wrong, but because the steps you skip have a way of showing up later as gaps you can’t explain.

I spent time as a teenager running the shipping operation for a small publishing house — boxing and sending out books about process improvement and quality control before I had any professional context for what those books contained. I spent weekends in college learning what it means to be responsible for someone else’s wellbeing, happiness, and safety. I moved from design into engineering without a plan to do so.

None of it was linear. All of it was adjacent.


Originally published on LinkedIn on May 11, 2026.

Design Operations & Shiny New Tools

Your AI tools are ready. Your design org isn’t.

Design organizations have adopted a remarkable number of tools in a short window — Figma, FigJam, DevMode, and now AI layers on top of all of it. The tools work. That’s not the problem.

The problem is that nobody owns what happens next.

AI adoption isn’t a tools problem. It’s an ops problem.

There’s a pattern I keep seeing: leadership approves the budget, individuals start experimenting, and within 90 days the org has fragmented into a dozen parallel workflows that don’t talk to each other. One or two enthusiasts are burning out trying to carry everyone else toward the goal post. Everyone else is either quietly falling behind or quietly waiting to be shown the way.

This isn’t an AI-specific failure. It’s the same challenge DesignOps has always addressed — just with a new surface area and a much shorter adoption curve compressing the timeline.

What “ready” actually requires

Sustainable AI adoption happens across three layers:

    • Layer 1: The Tool — where nearly all budget concentrates. The licenses, the subscriptions, the pilots.
    • Layer 2: The Workflow — how the tools actually integrate with how people work day to day.
    • Layer 3: The System — the infrastructure for capturing what works, sharing it, governing it, and iterating on it over time.

Most organizations invest heavily in Layer 1, lightly in Layer 2, and do nothing about Layer 3. Then they wonder why adoption stalls six months after launch.

The shared vocabulary problem

One of the earliest symptoms of missing infrastructure is vocabulary fragmentation. Teams develop local language for the same concepts. New hires have no map. Knowledge stays locked in individual heads — and leaves the org entirely when those people move on.

Shared vocabulary is what makes it possible for a new hire to be productive in 15–30 days instead of six months. It’s not glamorous work. It doesn’t make the demo reel. But it’s the foundation everything else is built on, and it’s the cheapest, highest-leverage investment you can make before building any other system.

The governance gap nobody wants to talk about

AI tools introduce new questions that most design orgs haven’t formally answered yet: What’s confidential? What’s a quality standard for AI-assisted work? Who gets attribution? What are we not using these tools for, and why?

Without explicit answers — in writing, owned by someone — teams will answer these questions differently. And inconsistency at that level compounds fast.

DesignOps is the function that builds the guardrails

I’ve started calling the accumulated risk of inadequate adoption practice AI Adoption Debt. Like technical debt, it’s not visible until it’s expensive. Unlike technical debt, most orgs don’t even have a name for it yet — which means they’re not tracking it, not measuring it, and not paying it down.

DesignOps is the function positioned to own this work. Not because it’s glamorous — it isn’t — but because DesignOps already owns the operational infrastructure of the design org. AI adoption is just the newest domain in that scope.

Who owns this?

Right now, in most organizations: nobody. The enthusiasts do their best. The stragglers fall further behind. Leadership looks at tool adoption metrics and sees green.

What’s needed is an explicit owner — someone with design knowledge, organizational authority, and an operational orientation. Not the most excited person. The most equipped person.

Three concrete starting points for org and design leaders

    1. Audit your current AI adoption honestly. Where is it happening? By whom? What’s been shared beyond the team that built it? The gaps will be obvious once you look.
    2. Assign ownership thoughtfully and explicitly. Enthusiast ownership is not organizational ownership. This work needs someone with the authority to set standards and the skill to build systems.
    3. Start with vocabulary before building systems. A shared glossary is not a small thing. It’s the connective tissue that makes everything else transferable.

The tools are ready

They’ve been ready. The question was never whether the tools would work. The question is whether your organization is built to absorb what they make possible — and whether you’re willing to do the unglamorous ops work that separates sustainable adoption from AI Adoption Debt.


Originally published on LinkedIn on May 5, 2026.

This Isn’t Even a Unicorn Role. It’s Just Gibberish.

As a usability professional, the struggle with recruitment communications is real. I want to share some requirements from a recent UX job “description” — in quotes because it’s more of a laundry list of hopes and dreams than a coherent role definition.

Preface

Before I get into it – many items here are better suited for dedicated roles, or too broad for any single UX hire regardless of seniority. Some items are just… odd.

Here’s what this posting actually asked for

    • Establish the company’s technical vision — lead all aspects of the company’s technological development
    • Direct the company’s strategic direction, development and future growth
    • Do workshops internally and with customers
    • Conduct technological analyses and research
    • Open up new whitespaces for us
    • Help in pivoting our image from being an “executor” of designs to a “design & strategic” partner
    • Management of sales process and product delivery
    • Experience in overall transformation of Front/Back end systems for digitization
    • Experience in Mobile First Methodology to ensure internal systems are supported on all devices
    • Expert skills on Project management
    • QA/Test experience
    • PR/marketing experience

Breaking it down

CTO/VP Engineering territory: establish tech vision, lead technological development, direct strategic direction and future growth.

Niche or dedicated role territory: PR/marketing, sales process management, product delivery, project management, QA/Test.

Genuinely odd: “Open up new whitespaces for us.” I’ve been in this field a long time. I still don’t know what action I’m supposed to take on day one to accomplish that.

My Analysis

This isn’t a unicorn role. A unicorn role is a real job that asks for a rare combination of skills. This is a job description written by a committee that never stopped to ask: what does this person actually do on Tuesday morning?

Every touchpoint in your recruitment process is a signal about your organization. A job description this incoherent tells strong candidates — the ones with options — exactly what working there might feel like. They read it and move on.

If you’re writing a job description right now: start with what the person will own. Then what they’ll influence. Then what experience makes someone good at those specific things. That’s a job description. Everything else is a wishlist.

Originally shared on LinkedIn.