Working as an effective team
How product, engineering, and design can do their best work
It’s common to find overlap between roles when building software - product managers do user research, designers have opinions on prioritization, and engineers (sometimes) talk to customers.
Some people think this is bad. That roles should be clearly defined, and each member of the team should stay in their lane. That we should create an assembly line of product development, where each person hands off a well-defined output to the next as the primary method of collaboration. Usually people like this idea because the structure makes them believe everyone is working together effectively. It looks like everything is going well.
I think this way of working is ineffective for high-performing teams.
In this post, I’ll break down how small, integrated teams can best work together, and how you can start moving towards a more effective way of working.
Small, Integrated Teams
The idea that small teams are more effective is not new. From Jeff Bezos’ Two Pizza Rule to the Ringelmann effect , leaders understand the effectiveness of keeping teams lean.
There are obvious reasons for this, like minimizing overhead and reducing communication channels, but there are also more subtle distinctions.
Let’s take a look at two different dynamics for small teams and how they impact the ways we work.
Agile Assembly Line
The Agile Assembly Line has a few key characteristics. Usually, the team works in sprints but struggles to adapt to change. There is a repeatable cadence to work and things are getting done, but it’s hard to tell if the work is high impact.
In this type of team, you may hear engineers complain if a feature that’s shipped to production needs revisions. “They’re changing the requirements again!” they’ll say.
You may hear designers who are frustrated that their company ignores user experience and is prioritizing a .csv export over new tooltips. “We never prioritize user experience!” they’ll say.
You may hear product managers who avoid responsibility for how a feature works. “Product defines problems, engineering creates solutions!” they’ll say.
Chaotic Good
A Chaotic Good team looks a little different. In this team, each member of the team intentionally has overlap with one another.
The product manager understands software well enough to decide if an engineer’s solution meets requirements before it gets shipped.
The engineers understand the customer's needs well enough to make independent decisions that improve the user’s experience during implementation.
The designer pushes back on the prioritization of a UI overhaul because they believe another feature can offer more value to customers and the business.
What’s the difference?
There are three core difference between these styles of working:
Types and frequency of feedback
Empathy
“Well enough”
Types and Frequency of Feedback
In the Agile Assembly Line, feedback between silos is limited or non-existent.
The primary type of feedback comes from peers of the same function.
A PM will get feedback from PMs on other teams or from their manager.
A designer will get feedback from designers on other teams or from their manager.
Engineers provide each other with feedback and get feedback from their EM (or skip manager).
PMs and designers may collaborate more on specific functions, like user research.
In a Chaotic Good team, the same is true, but the team also provides feedback across silos.
In this structure, the EM has a good enough understanding of their team’s business objectives that they can provide feedback on the PMs prioritization.
The PM has a good enough understanding of the software that they can spot issues in implementation while working collaboratively with individual engineers.
The designer has a good enough understanding of the team’s tech debt that they can make suggestions on interaction design that are easy to implement and add immediate value.
And, perhaps most importantly, everyone has first-hand experience with what their customers want.
This type of feedback is critical, because no one else in your organization is solving the same problem as your team. Getting feedback from other PMs can be useful, but they likely won’t have a deep understanding of your problem space. Getting feedback from your team allows you to have faster iterations and reduce risk.
Empathy
We often hear that we should have empathy for our customers. This means understanding their problems and perspective so we can craft effective solutions.
But what about empathy for each other?
In an Agile Assembly Line, it can be difficult to understand the problems and perspectives of our team members. We don’t really know what they’re doing or why they’re doing it. We may even have a negative viewpoint on someone else’s role, like the common refrain that product managers don’t add value.
In a Chaotic Good team, empathy with customers and one another is a bi-product of the team structure. It’s nearly impossible to categorically blame engineering for missing a deadline if you understand what goes into building the feature.
Why? Because you would either prioritize the problem that pushes out deadlines (tech debt), or move the deadline itself to something the engineering team can reasonably hit.
“Well Enough”
You’ll notice that I always say that we should understand each other’s work “well enough”. You are not expected to be an expert in another silo’s domain.
Knowing something “well enough” lets your team communicate more effectively and move faster by minimizing time spent on fundamentals. It lets you build trust that everyone in the team is working towards the same goal, rather than a goal specific to their silo. It lets the team make decisions together rather than always making tradeoffs between timelines & business value, user experience, and tech debt.
How to start working more effectively
These ideas rely on a few cultural norms. Without these norms, a Chaotic Good team becomes simply chaotic. Let’s dive in.
#1 - Hold a high bar
Holding a high bar comes in two forms: hiring and managing.
When hiring, it’s critical that you hire people who are coachable and highly competent. This entire idea relies upon each individual bringing value to the team. If your PM can’t make good decisions in challenging circumstances, engage and build support from internal stakeholders, and deliver solutions that create value for customers and the business, they can’t lead a Chaotic Good team.
Effectively managing this type of team also requires additional effort. You need to be tuned-in enough to have clear insight to what’s going well and where things should improve. You should measure a Chaotic Good team based on their outcomes rather than each silo’s output, and work collaboratively with other leaders to improve the performance of the team.
#2 - Offer unique value
Each team member in a Chaotic Good team offers unique value. They are an expert in their domain and an amateur in the domains of their teammates.
Removing processes in favor of outcomes will quickly reveal if a team member brings unique value. If a team member is not providing unique value, you have an opportunity to shift their work towards higher impact tasks and increase the overall value created by the team.
#3 - Create clear decision rights
Overlap in understanding should not degrade decision rights. Teams should be clear who is responsible for each domain and when they are invoking their right to make a final call.
#4 - Have no ego
If you get offended by feedback or want to be the smartest person in the room, this style of working probably isn’t for you. Minimizing ego is essential to being able to receive feedback from a team member in another silo. After all, you’re supposed to be the expert, right?
Remember that your job is to get to the best outcome possible. If that happens through successful implementation of ideas offered by others, you’re doing your job.
#5 - Hold individuals accountable
Managers need to hold each individual accountable for the outcomes of the team and their individual work. Cross-silo collaboration is not an excuse for any individual function or person to take it easy.
Wrapping Up
The Agile Assembly Line looks good from the outside, is easier to manage, but produces less value.
A Chaotic Good team is harder to understand, values impact over process, and provides feedback across silos.
My preference? Chaotic Good.
What type of team do you work in?
Are there times when an Agile Assembly Line is the right approach?
Let me know what you think!
The Agile Assembly Line Quiz
Are you working in an agile assembly line? Find out with this quick quiz!
Can your product manager explain how any part of the software works?
Have your engineers ever interacted with a customer?
Do your designers understand the business outcomes the team is working towards?