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
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”?
This article focuses on using Chain of Command as a means of reducing cyclomatic complexity in our code. Along the way, we also create better adherence to SRP.
I recently worked with a team on a fairly significant refactoring. I paired with different team members each day over a three day period as we moved code around, pushing responsibility into other classes, reducing complexity, and make the code more expressive. On the fourth day, I put together some notes on the things we saw and general guidelines for the team to keep in mind. Nothing herein is new to the community, but it might be new to you.
Collaboration Contracts are a way of identifying who is involved in a decision and what level of decision-making authority each participant has. This isn't a delegation model where some individual is empowered and imparts unto others some fraction of their authority for a limited period of time. This is a collaboration model where all participants are equally empowered, but find consensus on all topics to be a suboptimal approach.
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
Whether you’re still figuring out your general product offering or you are enhancing and adding capabilities to a well established product, the ultimate test of whether or not you’ve hit the mark (or are at least trending in the right direction), is how your audience engages with what you’ve created. Yes, you can (and should) do market research before designing and coding up a potential solution to an identified problem, but the only way to know for certain, is to see what happens when your concepts come in contact with your audience.
So you’ve got some problem you’re trying to solve (Know the problem you are solving). You’ve agreed to work together on coming up with a solution. So you call a meeting and ask everyone to bring some ideas.
The objective of the meeting is to select the “best” option among the ideas presented.
In my observation, most folks tend toward an approach I call “Judge and Jettison”.
In this article, I want to go more in depth on Opportunity Solution Trees; what they are, how they are used, how to create one, and how I think about them slightly differently (but only slightly) than folks like Teresa Torres who really introduced them broadly to the Product community in her book “Continuous Discovery Habits”. This book, by the way, is a must have for anyone who works in software product development - not just folks in product-specific roles.
The Experiment Canvas is a simple means of planning, tracking, and responding to your experiments.