When I share the third behavior, “Work Together”, most teams proclaim that they already do. They’ll make a point of sharing - “We have daily stand-ups, planning meetings, review meetings, and retrospectives.”
Well, well… Look at all of that working together - they get together to discuss the work, get together to sequence the work, get together to review the work, and get together to review the work process.
Did you notice the profound lack of getting together to do the work?
Me too.
When I say, “work together”, I mean just that. Do the actual work together.
Every aspect of the product lifecycle is an opportunity for collaboration - Identifying problems to solve, user and market research, design and architecture, formulating experiments, development and testing, deployment, monitoring, maintenance, and gathering user feedback.
I, of course, am not suggesting that all of these activities be performed by all members of the team together, rather that most (if not all) of these activities involve two or more members of the team. Anything you suppose you are losing in the efficiency of a task will be offset by the efficiency of the team.
In future articles I will talk about tools, techniques, and roles that further explore “work together”.
If you want to keep up on the progress of the Behaviors Book, pay attention to the Behaviors Book page. And if you would like to learn more about how we use The Behaviors to guide teams, reach out.
Related Articles
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.
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.
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.
If you are not familiar with Liberating Structures, I suggest you take a look at them. I use a few of them now and then as circumstances warrant. In future articles, I will discuss some of the others, but today’s installation is dedicated to the Liberating Structure I most often use — 1–2–4-All.
When I say, “work together”, I mean just that. Do the actual work together.
Every aspect of the product lifecycle is an opportunity for collaboration - Identifying problems to solve, user and market research, design and architecture, formulating experiments, development and testing, deployment, monitoring, maintenance, and gathering user feedback.
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.
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.