Doc Norton
This Has Happened Before. It's Happening Again.

I don't think we have five years before agentic coding becomes the mainstream context in which professional software development happens. I think we're talking about two or three. Possibly less.

If that sounds alarmist, I'd ask you to consider how it would have sounded in 1983 to tell a mainframe developer they had about eight years before their core expertise became a niche. Or in 1994 to tell a desktop developer they had about four years. Both of those statements would have seemed extreme at the time. Both were accurate.

This Has Happened Before. It's Happening Again.
Doc Norton
Speed Is a Side Effect

When leaders ask teams to "go faster," they're usually not asking for better outcomes. They're asking for more output. More stories delivered. More code shipped. More visible progress.

Implicit in that ask is a pretty big assumption: that we already know exactly what needs to be built, that the plan is correct, and that execution is the only thing standing between us and success.

So "go faster" becomes shorthand for "execute the plan harder."

That's where things start to go wrong.

Speed Is a Side Effect
Doc Norton
Don't fail fast; Observe often

The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.

What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.

Don't fail fast; Observe often
Doc Norton
Why I Joined Test Double

When I say I’m joining Test Double as their new VP of Delivery, I’m not just making a career move—I’m making an alignment move. This is a company that already values the things I value. They’ve built a strong culture, a strong team, and a strong set of practices. I’m not joining to overhaul anything. I’m joining to help make something great even better.

Why I Joined Test Double
Doc Norton
Collaboration Contracts beta release

Today, I’m excited to announce the beta launch of Collaboration Contracts, a lightweight app designed to help teams—especially distributed ones—quickly define and manage their roles in decisions. Whether you're using it to bring clarity to one-off decisions or baking it into how your team operates every day, the app is built to support alignment, accountability, and smoother collaboration.

Collaboration Contracts beta release

We're About to Unwind Fifty Years of "Progress"

We're About to Unwind Fifty Years of "Progress"

I want to make a prediction that is going to make a lot of people uncomfortable.

The programming languages, frameworks, and abstractions we've spent decades building are going to start collapsing. Not all at once. Not overnight. But the direction is clear, and the pace is faster than most people want to admit. Within a decade, possibly sooner, the tools we use to build software will look fundamentally different from what they look like today. And the driving force behind that transformation isn't a better language. It's the fact that the primary author of code is changing.

What Does "Good" Even Mean Now?

What Does "Good" Even Mean Now?

The bottleneck of developer speed is disappearing. Agentic systems can produce robust solutions quickly in ways that would have taken a team of humans weeks. The friction that made "build it small so you can change it easily" such critical advice is evaporating.

But the principle behind small steps was never really about code size. It's about maintaining optionality and creating feedback loops. That part isn't going anywhere. It's just shifting in emphasis.

This Has Happened Before. It's Happening Again.

This Has Happened Before. It's Happening Again.

I don't think we have five years before agentic coding becomes the mainstream context in which professional software development happens. I think we're talking about two or three. Possibly less.

If that sounds alarmist, I'd ask you to consider how it would have sounded in 1983 to tell a mainframe developer they had about eight years before their core expertise became a niche. Or in 1994 to tell a desktop developer they had about four years. Both of those statements would have seemed extreme at the time. Both were accurate.

Speed Is a Side Effect

Speed Is a Side Effect

When leaders ask teams to "go faster," they're usually not asking for better outcomes. They're asking for more output. More stories delivered. More code shipped. More visible progress.

Implicit in that ask is a pretty big assumption: that we already know exactly what needs to be built, that the plan is correct, and that execution is the only thing standing between us and success.

So "go faster" becomes shorthand for "execute the plan harder."

That's where things start to go wrong.

Solutions Disguised as Problems

Solutions Disguised as Problems

A product manager walks into your office and says, "We need a report that shows daily active users by region, broken down by feature usage, with trend lines for the past 90 days."

You nod. Sounds clear enough. You estimate it, add it to the backlog, and two weeks later you deliver exactly what was asked for.

The product manager looks at it, says "thanks," and then... nothing. It sits unused.

A month later, they're back asking for a different report with slightly different breakdowns.

What happened?

You built the thing. You didn’t solve the need.

How Small Steps Saved Millions

How Small Steps Saved Millions

A while back I worked with a large manufacturer that needed to modernize a system that managed a key part of their operations. Once completed, the company projected savings of more than $100 million a year.

The plan was to go big. A highly detailed three-year plan.

They assumed that if they were to get a large solution done, they needed to tackle it in big steps.

We suggested small steps.

Here’s what happened.

Don't fail fast; Observe often

Don't fail fast; Observe often

The problem with "fail fast" is that it too often becomes "move fast." Failure is hidden or spun as success, speed is rewarded, and the learning part gets lost entirely. At its worst, "fail fast" is an excuse to rush into the next thing without pausing to understand what just happened.

What I want to promote instead is Observe Often. The shift in language is intentional—when we say “observe,” we bring focus back to what matters: seeing, measuring, and learning from what we do. And “often” reinforces frequency over haste. It’s not about reckless speed; it’s about small, deliberate moves and frequent feedback loops.

Bug Bashes are a Smell

Bug Bashes are a Smell

The other day, I was in a Slack discussion with some of the good folks at Test Double. The topic of bug bashes came up, and the conversation was rich. People brought thoughtful perspectives and experiences, and the discussion left me reflecting on what bug bashes say about the systems we work in.

So, You Want To Release Ridiculously Often?

So, You Want To Release Ridiculously Often?

Many teams want to release faster. Some even feel pressured to. They set up CI/CD pipelines, automate deployments, and start talking about daily pushes. But then things go sideways. Bugs slip through. Customers complain. The team’s stress level skyrockets.