Routines to align squads

The great and worst thing about squads is that they are independent teams to execute. Why worst? Because, as they are independent, they may not build upon each other. How can we make sure that doesn’t happen?

At Ontruck, we are always experimenting to improve the way we work. We know it’s vital to have excellent communication between roles and squads. The success of one needs to trigger more successes from others. Our objective is to have independent squads who can execute and meet their OKRs, while at the same time enabling others to go further.

To provide some context: we are almost 50 people between Product, Engineering, and BI. We have five independent products squads and a platform team.

On this article, I’m focusing on Product routines we use to align between squads. Engineering has others.

Written dailies in Design

Even though Product Designers work in squads with developers and Product Managers, they have a design channel in Slack where they share daily what they are working on, their blockers and doubts, including links to work in progress.

This triggers several things:

• knowledge about what other designers are doing
• share related information I may have about the project you are doing, especially useful during research
• challenge and new ideas on the current work, without the need to wait until Friday for the Design critique
• alignment between Product Designers on specific techniques or Design System

It’s essential that they feel comfortable sharing unfinished work.

Design critiques

Each Friday, Product Designers (6 people) meet during two hours to share projects they want feedback from the rest of the Design team. Ideally, they share one or two elements (research approach, solution decision, scope decision, UX challenge, visual) they want to be challenged from the rest of colleagues.

This session helps the team on several aspects:

• Get ideas on how to approach a project or a design phase (a designer may share a new type of session s/he has tried)
• Improve the research and the solution, reduce usability issues before user testing and reduce problems that can arise on production
• Improve how you communicate your ideas, and how you give and receive feedback
• Know what other teams are doing, which can impact your squad

This session isn’t easy to do because some designers tend not to share enough, people don’t usually know how to give feedback (look at our Design Critique Bingo); and of course, receive hard input about your work isn’t easy.

Weekly PM meeting

Each Wednesday, Product Managers (4 people) meet to discuss topics and align between squads. We don’t have a fixed agenda; it depends on the week. We keep testing new ways of organizing this meeting. We usually cover these topics.

• Company updates. I, as CPO, share any relevant update from management they should know. Usually, the main message is about priorities. As a company, we want to focus on X in the next months.
• Product critique. We have started doing it this year. Each PM writes in advance some paragraphs about a project they want to be challenged. At the beginning of this session, we read and comment on them individually on our computers (following Amazon’s approach). After, we go over them following up on the comments.
• Projects which involve several squads. If they are relevant enough we talk about them, so all PMs are updated; in case we may be forgetting about something.
• Discoveries that a PM shares. Usually, when the PM or PD does research, they find relevant info they want to share with another squad. This happens organically, but this is another moment to share in case that information is of interest to more teams.
• Relationships with other departments. We evaluate how well we are collaborating with Sales, Ops, Technology, BI, etc.
• Align OKRs. On this, we usually involve Engineering Leads. The objective is to align OKRs between squads before we agree on them. We’re currently seeing that this is needed because — no matter how you divide the business — squads will always have friction points between them. Who should be responsible for a particular problem? What if that team doesn’t have the resources?

Product Updates Slack channel

We have a Slack channel where we post all product updates. They all follow the same structure to help the teams write them, and the rest of the company to read them. A good tip is to share a GIF/video of the feature.

Sprint Demo

Every two weeks, we have a session in which we share what we have deployed to production in the previous sprint. Anyone in the company can come; and in fact, we encourage at least someone from every department to come.

Each squad shares their updates, explaining how they related to one of their OKRs. They usually share slides with GIFs, to avoid demo problems. Anyone can ask questions.

This is complementary to the Product Updates Slack channel, but it serves some other purposes like:

• Know when it’s deployed, in case we have forgotten about a potential impact (sales, marketing, another squad)
• Explain better why we have phased the solution on a certain way, so stakeholders keep calm that more is coming (as you may know, we try to scope and phase a lot)
• Sometimes a feature is a technical one (machine learning algorithms, connection to GIS systems…). This forum triggers many conversations on how other squads can take advantage of that new piece of technology.

As I mentioned at the beginning of the article, we keep experimenting to improve how we work to achieve better outcomes. The routines changes as you grow.

We would love to know your routines to get more ideas!