As teams grow, the work of supporting the team grows as well. People begin asking if everyone is being productive. As coordination costs grow, many leaders worry that the team's time is being spent more on orchestrating the work rather than doing the work.

Charity Majors recently looked at this in her excellent article "Questionable Advice: “My Boss Says We Don’t Need Any Engineering Managers. Is He Right?”. It's a great read about how teams need more of a coordination function as they grow, and asks directly about what is most valuable for a leader to spend their time on. Just about everything in her article applies equally to product leadership.

It reminded me of my book review of Melissa Perri and Denise Tilles' Product Operations. I saw that book largely as an essay on what product leadership should and should not focus on when a team grows.

Do you see the same similarities? What should product leadership focus on?

Looking forward to hearing from you,
Jenny

The three rituals of a self-improving team

The simple practices that lead to more effective product development

My client‘s product leadership kept trying to make changes to how the product teams worked, yet nothing was sticking. They brought me in to figure out what was going on.

I found a string of communication challenges. I summarized one of my major findings:

The problem: the leadership team already knew this and it was what they were trying to fix. They had set up templates, tried to change communication patterns, and were begging for documentation. But nothing was happening.

My recommendation surprised them: Start by mandating one ritual – a standardized retrospective process for each team. Don't force any other changes. A good retro habit would get the team communicating about the issues. They would come to their own conclusion that documentation would help.

The magic of a retro is they would then design it themselves. Once that was set, I suggested layering in the two other rituals of a self-improving team.

Create a self-improving team

When a team is going through rapid growth or change, leadership can't manage everything themselves. They need to find ways to empower product development teams to lead their own change. Leadership should focus on encouraging self-improving teams.

To do that, I argue three rituals provide the foundation of a self-improving team:

• The retrospective: review processes
• The premortem: anticipate challenges
• The business review: evaluate impact

These three rituals help a team begin communicating not only about the immediate work at hand but about collaborating as a team. They force self-reflection on how the team is working together.

Instead of the leader forcing change on the organization, the leader asks to add these small ceremonies to the product development process. It puts the team in charge of driving change, which makes them more likely to adopt and encourage new ways of working.

The key elements of the rituals

Depending on the organization, it might make more sense to introduce all three rituals at once or to start with one and ladder up to the others. If starting with only one, I recommend retros. The retro is the one where it's most likely that the team will conclude that one or both of the other rituals are also needed.

The retro

There is no shortage of great articles on creating productive retros. I have a few items that I consider to be necessary for the MVP:

• Product, design, and engineering are in the room (at a minimum): Some companies do retros with engineering only, but the magic happens once everyone is in the room.
• They happen on a regular schedule: Retros are best when they're frequent and memories are fresh. Every 2 weeks is ideal, every month is the minimum. They shouldn't exclusively be after a project has shipped.
• Action items are reviewed at the beginning of the next retro: Teams need to be held accountable for the improvements they identified and highlight when they aren't making progress. Those who hate retros usually don't do this key step.

The premortem

Premortems are a marvelously powerful tool for teams trying to shift their product culture. They move teams towards shipping smaller and more frequently, increase cross-departmental communication, and encourage good user research hygiene.

A premortem is a technique you use before a product launch to help anticipate any major issues and plan around them. The team hypothesizes why a project, initiative, or launch might fail. They then prioritize the issues and create action plans to address the most critical ones. The most critical elements include:

• Getting a cross-functional group together: These are opportunities for marketing, sales, and operations to collaborate with the product team. It's important to have the right mix of people in the room.
• Have the time to do mitigation: A good premortem will end with a list of action items (much like a retro) – the ritual needs to be done with enough lead time to take care of action items.

For everything pre-mortem, I've got an in-depth guide.

The business review

Whether quarterly, monthly, or weekly, the business review is an opportunity for the team to look at what they shipped and evaluate it against what they were trying to achieve.

Key metrics are reviewed and the team is invited to discuss why the things they shipped did or did not have the desired impact. This is an opportunity for everyone to understand the team’s business goals.

The key parts of the business review ritual include:

• Getting a cross-functional group together: These are opportunities for marketing, sales, and operations to collaborate with the product team. It's important to have the right mix of people in the room. (just like with the premortem!)
• Reviewing the premortem predictions: This is a great opportunity to tie these rituals together. Was there anything missed in the premortem that needs to be considered for next time? How good was the team at predicting the future?
• Not just a presentation: The business review should be structured around discussion, not presentation. The data is there to inform the conversation, not to be the conversation.

For companies looking to become more iterative, the business review invites the opportunity for a team to request to revisit a feature or product and improve upon it.

Self-improving teams improve the organization

As self-improving teams get stronger, they will inevitably start bringing up larger changes that they'd like to see in the broader product development organization. Leaders need to celebrate those moments.

When the team suggests organizational changes, they make change management easier. It’s no longer the product leader nagging everyone to do more documentation, but teams asking their peers to improve communication.

Leaders need to then invest the time in training their teams in these ceremonies or bringing in specialists who can train the teams and help them do these rituals well. The sooner the teams start on these practices, the more value the organization will get from self-improving teams.

Thank you so much to Shivam Malhotra for your edits.