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.
The problem with the term best practice is not always the practice itself—it’s the perspective the phrase invites. Best is steeped in finality. It implies that nothing better exists, or ever will. That the thinking is over. And while we may not mean it that way, language shapes thought. When we call something “best,” we stop asking “is it still working?”
These days, it seems like even talking about diversity and inclusion can spark a political debate. But here’s the thing—it doesn’t need to be political. This isn’t about left or right. It’s about people. It’s about teams. It’s about building environments where different perspectives aren’t just welcomed, but seen as essential.
Because they are.
In tech, in product, in leadership—diverse teams consistently outperform homogeneous ones. Not because it feels good, but because it works better. This is a business discussion. A design discussion. A collaboration discussion.
So let’s talk about it.
The way your teams are structured shapes the software you build—and vice versa. In this article, we explore the profound connection between team and software composition through the lens of Conway’s Law, uncovering how misalignment leads to chaos and inefficiency, while thoughtful alignment drives collaboration, modularity, and adaptability. Learn why your true architecture isn’t in diagrams but in the code itself, and discover actionable steps to align your teams and software for better outcomes.
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.
When teams hear about small, frequent deployments, they often picture chaos: code breaking, users complaining, and developers scrambling to fix issues. But in reality, small deployments do the opposite. They reduce complexity, amplify feedback, and create a smoother experience for both users and developers.
Full-stack teams are a brilliant concept. They’re designed to have everything a team needs to solve problems in a given domain—front-end, back-end, database, security, you name it. When done right, these teams are little microcosms of outcome achievement, creativity, and autonomy. They blur skill boundaries, enabling faster delivery and real-time learning across disciplines. Sounds great, right?
But there’s a catch. Somewhere along the way, we started confusing “full-stack teams” with “teams of full-stack engineers.” When I say we, I mean it. I did this too. I was on the full-stack teams of full-stack engineers bandwagon. But that shift—over time—has cost us. By prioritizing generalists at the expense of specialists, we’ve inadvertently traded depth for breadth and innovation for adequacy. Let me explain.
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.
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.
