AI Sped Up the Wrong Part

Are we using AI to optimize the wrong steps?

I've added Deep Questions with Cal Newport to my routine listening pool. I particularly appreciate his more reserved and grounded take on what AI productivity is and isn't. Cal recently sat down with David Epstein (episode: "Why Do Better Tools Make Me Worse at My Job?"), and they discuss Eliyahu Goldratt's Theory of Constraints, a framework from the 1980s originally applied to industrial production that became a cult classic in tech. Something clicked for me when they applied this view to AI productivity tools.

Is the ability to generate 10x more code and open 10x more PRs actually making me more productive?

The Pattern AI Is Repeating

Cal's argument is that AI is following the same pattern as other digital productivity tools that have come before and "revolutionized" work.

Email made communicating easier and faster, but the consequence was a flood of information and messages that need to be triaged before they can be funneled downstream into actual productive workstreams — The New Yorker covered this well. Generative AI is doing the same thing. We can generate a slide deck in minutes. We can spin up a prototype over a weekend. We can produce a summary of any document in seconds. These are all real speed improvements at steps that were never the bottleneck.

Two Receipts From My Own Work

The prototype that lost to the prospect's prototype.

I spent a weekend building an AI-native GTM pipeline before a prospect call. Mock data, enrichment, composite scoring, CRM routing. I was pretty proud walking in. The prospect had already built their own, and theirs was better. Why? Because it was built against their real data using their domain expertise (which I obviously did not have after a weekend). Turns out, generating the prototype wasn't the hard part or, more importantly, the way for me to add value as a consultant.

The hard part was helping them make architectural decisions that get a version of this prototype in front of prospects.

The stack consolidation that wasn't actually about the stack.

I'm currently leading an M&A CRM and tooling consolidation project for a client. Mapping fields, deduping records, reconciling overlapping tool stacks, handling custom objects is well-trodden technical territory that their team + AI tools could handle. So why hire me? Because the real bottleneck is that nobody internal has the bandwidth to own the project end-to-end, chase stakeholders, and be accountable for the outcome.

The Bottleneck Is Rarely a Skill Gap

Both stories are about something AI couldn't speed up.

In the first it was judgment. More specifically, knowing which architectural bets were at least directionally correct to move the needle. In the second, it's something that took me some time to recognize. The company could do the work — their team has the skills. What they don't have is one person with the bandwidth to own it end-to-end, and be accountable for the outcome.

Faster code generation doesn't give your senior engineer six uninterrupted weeks. Better prototyping tools don't make anyone on your team the single accountable owner when the migration goes sideways at 2am on cutover weekend. Speeding up the steps your team was already good at doesn't help when the constraint is human attention and ownership, not technical capability.

I think this is why when Goldratt was asked to summarize his Theory of Constraints concisely, he condensed the entirety of it into one word: focus.

A Quick Diagnostic

Before adopting any AI tool (or before building one), Goldratt's framework suggests one question worth running first:

Where in this process is work actually piling up?

The obvious bottlenecks usually take care of themselves. If a step is visibly slow and visibly important, someone is already working on it. The insidious ones are the bottlenecks that aren't obvious, or that are uncomfortable enough to surface that "let's grab the low-hanging fruit first" becomes the path of least resistance.

A few pointed questions that have helped me on real engagements:

1. Where does work sit waiting for a human? That's almost always the bottleneck. Generation is rarely the wait. Review, approval, and verification almost always are.
2. What are you avoiding because it's hard, ambiguous, or politically expensive? That step is usually the bottleneck. The "low-hanging fruit" framing exists to give us permission to keep avoiding it.
3. If you doubled the throughput of the step you're about to speed up, would anything downstream actually move faster? If not, you're speeding up the wrong part.

If the tool you're evaluating attacks the answer to those questions, it's potentially transformative. If it speeds up something else, it's a quality-of-life improvement at best and a pile-up generator at worst.

Work will flow faster to the bottleneck and sit there longer (and probably stress you out — nothing hurts me more than stale PRs).

What I Actually Do

This framing also helps clarify for me the value that Flynn Data Services provides with fractional data engineering.

Your team is already busy and juggling a million other important things. Rather than add another item to another full plate, someone like me could be the answer. A temporary person whose full attention is on it for the next three months: scoping, building, catching the edge cases, standing behind the result.

If you're staring at a project where the bottleneck is "nobody has the bandwidth to own this" — or if you are ready to finally answer "where is work actually getting stuck?" — give me a call.