Doc Norton
Hi.
I’m Doc and I am the founder of Doc Norton & Associates.
I have made it my life’s mission to make the world of software development a better place.
If you are leading an organization and you’re struggling to find or satisfy the market, I can help.
If you are leading an organization and software product clashes with your operational teams, I can help.
If you’ve got great talent, but you’re struggling to get product to the market, I can help.
If your technical debt is getting out of control, I can help.
Featured Articles
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.
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.
The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.
Simple Things
When I say simple, I don’t necessarily mean easy. And I certainly do not mean crude in form or incomplete. Simple indicates something that does not have superfluous parts or multiple responsibilities, is easy to understand, is as independent from the rest of the solution as possible, and meets a need as is.
Simple may not address all use cases, but it does address some use cases.
Over the past several years, as I’ve been helping teams and organizations improve their ability to deliver software products that are desirable, viable, and feasible, I have been experimenting with a Behavior Framework that has proven to be rather effective. And I’d like to share it with you in hopes that you find it useful and that you provide me feedback on your experiences with it.
My plan is to write a series of blog posts all related to the behaviors framework. Some of them will be about a specific behavior. Some of them will be about tools or techniques that help teams express one or more of the behaviors. Some of them will be my own experiences. And some will be damn near complete fiction.
In this excerpt from Escape Velocity, we take a more in-depth look at Velocity and try to answer (at least in part) the question, “What Is Velocity”?
Case Studies
A large enterprise struggled with inconsistent software engineering practices, leading to uneven code quality, suboptimal architecture, and collaboration challenges. Through targeted initiatives like the "Summer of Secure Code," a learning accelerator blending education with live projects, and a scaled technical coaching program, thousands of engineers were upskilled. These efforts improved code quality, test coverage, and architectural decisions, while also boosting team engagement, collaboration, and delivery effectiveness, creating a scalable model for sustainable growth.
A global manufacturer faced a challenge with vehicle delivery times exceeding 90 days, causing high costs and customer dissatisfaction. To address this, a cross-functional team was formed to develop a new software solution for a specific vehicle model, focusing on agile principles like delivering small, incremental improvements, ensuring visibility, and fostering collaboration. In just 120 days, the team reduced delivery times to under 30 days, demonstrating the power of agile practices to solve complex operational challenges and drive rapid, measurable results.
A growing organization faced record-high turnover in Product and Engineering, losing top talent due to a management culture that lacked feedback, growth opportunities, and employee recognition. To address this, a simple, team-specific survey was introduced to gather anonymous feedback, with results shared openly with both managers and teams. Managers were provided actionable resources to address key issues, leading to a cultural shift focused on clarity, autonomy, and career development. Within a year, employee satisfaction scores rose from 65 to 89, and retention rates improved significantly.
My Next Book
Will you join me in my journey to write another book?
The “Behaviors Book”
I am working on a new book about the essential behaviors that every software product team should exhibit. I’m writing blog posts on the topic to get the juices flowing and generating supporting materials as I go.
Behaviors Articles
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.
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.
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.

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.