The "Kitchen Model"
At HelloFresh, I moved teams a few times. From the day I started, I focused on a Tribe called Weekly Active Customers (or WAC for short). There, I began as an Individual contributor, working for a team responsible for churn management, and later moved into a managerial role, taking care of the entire Tribe (3 squads / 4 designers).
As the company expanded, there was a need for a new Design Manager for a different area of the business, focused on the core meal selections experience and a recently created marketplace for add-on products. I pointed out my interest in moving to that team since I felt it was time to move to a different part of the product and continue my growth and learning (+ challenging the biases I've constructed throughout two years of work at WAC).
I made a move, and the Tribe eventually turned into the "Food Alliance" (group of Tribes). This was the setup:
4 Product Designers
1 UX Writer
1 UX Researcher
1 Staff Designer (freelancer)
With the rapid growth of the squads into multiple Tribes and then into an Alliance, Designers got pulled and pushed too many sides and ended up operating in a centralized fashion for almost a year.
Discussing with each designer on our 1:1 sessions, and also opening a forum to collect pain points, this is what I found out:
Some positive things also popped up, such as:
The constant rotation of projects worked well for designers who didn't like so much immersing themselves too deep and too long into a particular domain area.
Although there was a lack of connection with results and following up on initiatives, they still felt the Alliance provided them with a place filled with opportunities.
Introducing the Kitchen Model
High-end kitchens operate like a Swiss clock. The best restaurants can scale their output without compromising excellence in execution. Also, a particular role structure enables this machine to run.
From that model, we took the Chef de Cuisine and the Sous chef roles as inspiration to build a pairing model.
This is how the model would work:
All Designers would be allocated as chefs to their primary team and Sous chefs to a secondary team. Time spent in each is correspondent to the priority (Chef 70% and Sous chef 20% respectively)
The Chef Designer dedicates most of their time to operate under the same team, participating in team ceremonies, and collaborating closely with their PM and Dev teams.
The Design Sous Chef serves as a fixed pairing buddy. Their goal was to: - Be a go-to person for quick ideation and problem-solving sessions. - Understand the domain area and meet the team. - Ideally, have a complementary skill set to the Chef Designer
We ran this experiment for about six months, and here are some of the results.
More delivery capacity
We released a long-waited improvement in the product navigation system after both designers from the Menu team managed to split delivery work and buy themselves extra time to investigate the navigation topic. It would've been unlikely to happen in the old format.
Levelled up skills
Designers shared feedback that they felt some of their soft skills were improving since we purposefully paired Designers with foundational solid and soft skills.
Designer vs. teams matching
In 2 teams, we ended up exchanging the Chef Designer with the Sous chef since we noticed the interest and motivation shifted naturally.
Created time for discovery
There was an unintended side effect: PMs felt more comfortable prioritizing more Discovery work since they now had their teams covered by 2 Designers.
Career growth opportunities
Lastly, a pleasant surprise was seeing two mid-level Designers showing up to be great mentors, which helped later in the year to build promotion cases and support the less experienced ones.
Some of the downsides:
It was hard, if not impossible, to track if designers respected the time split. The ones with better time management did that well, but the others got easily overwhelmed by the context switch.
I faced a dilemma around enforcing vs. having the process more informally applied, which would make it slower and hard to track. I decided to instate the model as mandatory, including having a field in Jira where all Stories and Epics created by Designers (a process that we already had) needed both Chef and Sous Chef tagged. Also, I regularly did check-ins to understand if they could cope with the work.
"Abusing" the system
Ultimately, some PMs were abusing their "extra headcount" to push for even more delivery work, another factor to be managed by the team and me.
Developers and PMs sometimes felt lost, not knowing who to talk to when the participation of both Designers was equally balanced for specific projects.
We identified 3 main learnings from this experiment:
We were operating understaffed
This fact was hidden behind the existence that designers were overstretching on execution mode and delivering enough for the teams not to feel the need for a dedicated designer (even all of them focusing on consumer-facing features).
You can't process your way through collaboration
Getting designers to collaborate with one another is a long term game. Managers need to create a safe environment where people with all communication styles and experience levels can contribute to a common goal.
Education is needed
Implementing a system that wasn't natural to the teams demanded significantly more education from my side. I didn't correctly set up the rules of the game and the possible traps that PMs and Designers could fall alike. It was partially intentional to see if the system would adjust itself, which it didn't.
Ultimately we rolled back the experiment and returned to the model of a single Designer per squad. The issues simply surpassed the benefits.
With the learnings, though, we managed to:
Hire an additional Designer to cover for a team that started investing significantly more in discovery
Place a Senior Designer that performed as a great mentor to a Design manager in the training program
Better matching Designers and teams as we learned more about their skills and motivators.