The New Clock Speed: What AI Changes About How Companies Operate

Most conversations about AI at work start with productivity.

How much faster can a developer write code? How many support tickets can an agent handle? How much content can a marketer produce?

Those are useful questions. But I think they miss the more important change.

AI is changing the clock speed of the company.

Work that once took weeks can take days. Work that took days can take hours. The distance between an idea, an implementation, feedback, and the next iteration is collapsing.

And when one part of an organization starts operating at a fundamentally different speed, everything around it has to change.

The Clock Has Changed

Software development makes this particularly easy to see.

A capable engineer working with today's AI tools can explore an unfamiliar codebase, prototype an approach, write tests, generate documentation, and produce working code dramatically faster than even a few years ago.

That doesn't mean AI replaces the engineer. Quite the opposite.

It increases the leverage of a good one.

I have personally seen this happen. A much-requested that normally would have gone into a planning cycle and traditional roadmapping process was delivered in a single week one developer leveraging Claude Code (specifically, skills for code generation, architecture, QA and documentation). This wasn't simply "get me a POC that I can demo." It was production-quality code that was tested, deployed, and documented.

The important thing isn't whether that particular task was 30% faster or 5x faster.

It's that the operating cadence changed.

And once that happens consistently, the organizational structures built around the old cadence start to actively slow things down.

Small Teams Are Faster Teams

For years, growing a technology organization usually meant adding people.

More engineers meant more teams. More teams meant more managers, meetings, dependencies, planning and coordination.

AI changes some of that arithmetic.

A small group of strong people (a Pod) with good tools can increasingly accomplish work that previously required a much larger group.

That doesn't mean every company should start cutting teams. It means we should reconsider an assumption we've carried for decades:

More output no longer necessarily requires proportionally more people.

I expect smaller, senior, multidisciplinary pods to become increasingly important — teams with enough context and authority to take a problem from idea through production without handing it through half a dozen organizational layers.

Over the years, I have seen the wastage that is the "handoff." Each functional team hands off to the next, with the "tax" of contextual awareness having to be paid over and over. Over the last 8-9 months, re-organized into Pods of 3-4 people max and empowered with as much decision making authority as feasible, I have see 30-40% improvements in throughput.

The organizational advantage isn't simply lower cost. It's fewer handoffs. And fewer handoffs mean a faster clock.

The Old Metrics Stop Making Sense

This creates an uncomfortable problem for engineering management.

If AI materially changes how quickly work gets produced, what does a story point mean? What does velocity mean?

These measures were already imperfect proxies. In an AI-assisted environment, they become even less useful.

These days I am much more interested in things like:

• How long does it take an idea to reach production? (Lead time)
• How often can we deploy safely? (Deployment Frequency)
• How quickly do we recover when something goes wrong? (MTTR)
• How much work gets sent back because it wasn't right? (Change Failure Rate)
• Most importantly, did what we shipped actually improve the customer or business outcome? (NPS/CSAT/Roadmap Delivery %)

Anchored firmly on top of DORA-style measures, pure output matters less than throughput and the ability to delivery value, with quality and a high rate.

**The unit of value isn't code. It's a solved problem. **AI makes that distinction harder to ignore.

Speed Creates a Quality Paradox

There is a catch.

When producing code becomes dramatically easier, producing more code becomes dramatically easier too.

That's not always a good thing.

AI can generate plausible software very quickly. It can also generate unnecessary abstractions, duplicate logic, excessive tests, bloated implementations, and code nobody fully understands. AI slop.

The danger is that an organization celebrates the increase in output while quietly accumulating a new kind of technical debt - quality issues and brittle designs.

So as code generation gets cheaper, other things become more valuable:

Judgment. Architecture. Review. Testing. Context. Restraint.

One of the skills I think will matter enormously for today's developers is knowing what not to build.

The best AI-assisted engineer isn't necessarily the person who generates the most code. It may be the person who deletes half of what the AI suggested. This requires architecture instincts.

Training Matters More, Not Less

There's another paradox here.

AI makes it easier for a new engineer to become productive quickly. It can explain unfamiliar code, answer questions, generate examples and accelerate onboarding.

But it also makes it easier to produce code without understanding the system underneath it. I see this frequently, in particular with younger developers who are over-leveraging AI without context.

That makes training more important.

We need engineers who understand architecture, operating principles, customer context and why the system works the way it does — not just engineers who are good at prompting a coding agent.

The companies that get this right will use AI not just to develop products, but to accelerate learning. The companies that get it wrong will use AI to disguise the absence of institutional knowledge. There is an interesting pattern to this - initially everything looks great when measured on pure throughput, until the complexity house of cards comes crashing down.

Eventually, Engineering Isn't the Bottleneck

This may be the bigger organizational issue every CEO and board will need to grapple with. 

Imagine an engineering team that can prototype something in a day. Now taking that a step further, imagine that:

• Product needs two weeks to approve the direction.
• Security review takes another week.
• Procurement takes a month.
• Budget approval happens quarterly.
• An executive decision waits for the next steering committee.

The technology organization may be operating at a new clock speed while the company around it is still operating at the old one.

That gap creates friction. 

And I think we're going to see more of it.

I've been fortunate to witness the transformation of a Product organization that kept pace with the Engineering clock speed. It helped avoid the most obvious Product-Eng disconnects. Larger organizational transformation takes time. It requires all functions to reassess their workflows.

The next phase of AI transformation therefore isn't just about giving employees better tools. It's about redesigning decision-making for an organization capable of moving faster.

The Tools Won't Sit Still

There's a temptation right now to standardize too quickly.

Copilot. Cursor. Claude Code. The next thing that hasn't launched yet.

The tools are changing too quickly for anyone to credibly declare a permanent winner (although Claude Code is doing a good job of vying for that position).

I've already seen preferences shift remarkably quickly as capabilities change.

The goal should is not finding the AI tool for the company. The goal is to build adaptability into the organizational DNA.

Create sensible guardrails. Protect customer and company data. Establish quality expectations. Train people. Measure outcomes.

Then give teams enough room to experiment.

I've seen the perceived right tools turn out to be the wrong tools. I've seen lack of proper onboarding lead to overly AI-heavy code with little context. The key is to empower people with a core AI tool for daily "reasoning" coupled with function-specific tools and the adaptability to switch tools when something isn't working.

Today's winning tool matters less than whether your organization can absorb tomorrow's.

Management Has to Catch Up

For me, this is where the conversation gets interesting. AI isn't simply another technology rollout. 

It changes assumptions embedded in how we organize companies:

• How large should a team be?
• How much work should require a meeting?
• How quickly should we make a decision?
• What should we measure?
• Where do we need approval?
• What does a manager do when individual contributors have dramatically more leverage?
• What should we build ourselves now that building is cheaper?

These aren't AI questions. They're operating-model questions.

And they increasingly belong in executive teams and boardrooms, not just technology organizations.

A Parting Question

Boards and executive teams increasingly ask:

“What's our AI strategy?”

I think there's a better question to be asking : 

Where has AI changed the clock speed of our company — and what parts of the organization haven't caught up?

The answer will be different for every company. It might be software development. Customer support. Marketing. Finance. Analytics. Product.

But once the clock changes somewhere, the surrounding organization eventually has to change with it.

That's the opportunity. Not simply doing the same work faster, but building a company designed to operate at a different speed.