Zume Retro Part 3: Don’t Manage. Lead!

Photo by Nicholas Swanson on Unsplash

I have left the most crucial lesson for last. Like Maria Montessori’s insight regarding education that provided the proper environment children will flourish driven by their curiosity, teams of knowledge workers thrive when given the right conditions, and can lead themselves. For my final post in this Zume retrospective, I describe how we went about restructuring and revamping a typical engineering/product org into an empowered and performant self-managed team. And while the example here is grounded in a technical team’s experience, the principles and takeaways can apply to almost any team regardless of discipline.

These principles helped 23 people from 10 different teams come together after a painful reorg in which the company we were now to rally behind had just let go of the majority of our friends and colleagues. These principles were the foundation of a quickly-formed, healthy community that was self-organizing, motivated, and fast.

Focus on Getting out of the Way

Historically at Zume, similar to many other high-tech companies, engineering teams were structured rather conservatively: engineering manager at the helm of roughly 5 to 10 engineers. The opportunity to create a cross-functional team and rethink the team structure and product building process from the ground up was vital in my decision to stay at Zume after the January layoffs. I was determined to create an environment that people would thrive in, where they would feel motivated and empowered, not micro-managed, stifled, or in-the-dark.

It’s not “fire all the managers,” but it’s fire all the managers in the traditional sense of managing another human being — that a boss is responsible for the human being and the employee is a ‘subject.’

As I began restructuring my new team, I read an interview with Chris Rufer, founder of Morning Star, that helped shape my thinking. Rufer described the rationale behind their renowned self-managed culture. “If you need a manager to manage a truck driver, the assumption is the truck driver can’t do the job. If the truck driver can’t do the job, do you want to be in the truck with a truck driver who can’t do the job? It’s not “fire all the managers,” but it’s fire all the managers in the traditional sense of managing another human being — that a boss is responsible for the human being and the employee is a ‘subject.’”

Why go through all the trouble and expense of hiring such incredible talent — engineers, designers, product thinkers — if you don’t trust them and need to ‘manage’ them? Focus instead on getting out of their way and figuring out what else is slowing them down.

While seeming extreme and unconventional, I realized that a self-organizing team structure would be the ultimate way to empower the team and truly hand them the ball.

Riffing off Spotify

I studied Spotify’s engineering culture and Henrik Kniberg’s excellent videos (part 1 | part 2) for inspiration. One point, in particular, really stuck with me: “Most organizational charts are an illusion. So our main focus is community rather than hierarchical structures. A strong enough community can get away with an informal volatile structure. If you always need to know who is making decisions, you are in the wrong place.”

So how did we go about creating a ‘strong,’ empowered, self-organizing community?

Instead of a hierarchical structure with managers managing people, we built Guilds to manage workstreams. Each sprint, we formed small cross-functional Squads to work on each project. And we created Growth Chapters to help support and mentor people.

While we riffed off of Spotify’s structure and nomenclature (many might be familiar with Spotify’s Tribes and Guilds), we made it our own. This process didn’t happen overnight. We took the time to experiment and figure out what we needed and what worked for us.

Although I don’t recommend you copy and paste any of this verbatim, below, I explain each of these mechanisms in more detail to provide a sense of how a self-organizing team can function. The principles behind these mechanics are what is essential.

1. Guilds

We formed three guilds, each named with a question: the “What do we build?” guild, the “How do we engineer?” guild, and the “How do we Phoenix?” (Phoenix was our team name) guild. For short, we referred to them as the Build, Eng, and PHX guilds. Each guild formed to focus on the three main workstreams we identified: the product we were building, how we were building it, and how we functioned as a cross-functional team. Each guild’s responsibility was to essentially answer the question in the name of their guild on an ongoing basis. Each guild came up with spikes and projects and maintained the priority of the guilds’ backlog.

As I mentioned in my first post, we adopted a hypothesis-driven development approach in developing our backlogs, projects, and spikes. For example, a hypothesis for the “How do we Engineer?” guild might have been: “Our current build and deployment process is slowing us down. Using a hosted tool like Codefresh would speed us up.” The hypothesis would contain an observation and an idea of how to solve the observed issue. If our confidence level in the proposed solution were high, we would go ahead and implement it. Otherwise, we would use spikes to run shorter experiments or conduct more research to increase our confidence level.

As recommended by this HBR article on cross-functional teams, we created a Portfolio Governance Team (PGT) to coordinate the three guilds, streamline the different backlogs and determine what would go into each sprint. Our PMs and the Build guild maintained a tight connection to the rest of the business org to ensure what we were building was relevant to where the business was going.

Takeaway principle: given the right inputs, resources, and trust, a talented team can figure out on its own what to build, how to build it, and how to best work together.

2. Squads

At the beginning of each two-week Scrum sprint, the entire team reviewed the work planned for that sprint. We would go down the list starting from the highest priority and asked for volunteers for each project and spike. Team members gravitated to projects based on their expertise and interest.

We had rough guidelines of how many engineers, designers, and product managers we would need for each initiative. The team working on a project was called a Squad. At first, we divvied up all the work in the sprint at the beginning of the sprint. But after a few sprints, we moved to a one project/spike per team member model to mitigate context-shifting. If you finished your work before the end of the sprint, you either picked up the next project/spike from the sprint backlog or volunteered to help an existing squad.

There were clear advantages and disadvantages to this method. A few of the pluses:

• Members could work on what they were interested in and got to learn parts of the codebase they weren’t necessarily familiar with
• People got to work with new team-members almost every sprint.
• Quickly cut down knowledge silos.

Some disadvantages and what we did to mitigate them:

• Some engineers required time to ramp up when they worked on projects that touched unfamiliar parts of the codebase. We addressed this by ensuring there was always an SME (subject matter expert) on a given Squad. Pair programming also helped to transfer knowledge quickly.
• At times people finished work and weren’t sure what they should work on next. We fixed this by inviting folks who had completed their work to be more vocal in our daily stand-up and via the team’s Slack channel.

Takeaway principle: giving a team agency to self-organize around their work means giving them a sense of genuinely owning their time and sprint, trusting them to know where they can best contribute and where they need to grow the most.

3. Growth Chapters

Since we had forums to manage workstreams and Squads to work on projects, we didn’t need ‘managers’ in the traditional sense.

Nevertheless, we wanted to provide mentors and advocates to all team members to make sure we heard them and cared for their needs. So we created Growth Chapters with Growth Chapter leads. These leads were the ‘managers’ on paper and in Workday. But again, they did not manage their members’ work. They conducted weekly one-on-ones. They helped figure out what areas their chapter members wanted to grow in and helped them figure out ways to accomplish that growth.

Each chapter consisted of a chapter lead and up to 3 members. We could have increased the number of members by a few. But since all our chapter leads were also directly contributing code, design, or product guidance, we did not want to overburden them with growth chapter responsibilities. It was fascinating to see how decoupling the role of ‘mentor’ from the traditional position of ‘manager’ enabled chapter leads to focus on being present for their members and think of ways to help them grow and thrive.

Some questions that we began dealing with in regards to the Growth Chapters included:

• If chapter leads weren’t managing their members’ work, how do we handle performance reviews?
• What meaning is there to the chapter if the primary relationship is between the chapter lead and the members? Some leads began holding chapter sessions, and I envisioned this becoming a space where members supported and mentored each other, further decentralizing and democratizing that dynamic from the chapter lead.

Takeaway principle: removing the onus of managing ‘work’ from a manager allows them to focus on their team members’ growth and needs. By creating the right dynamics, team-members can, and should, also support each others’ growth.

Conclusion

My goal here has not been to provide a template model for how a product team should be structured. But instead, make a case for:

1. Seeing each of our team members as leaders, not ‘subjects,’ whom we trust with ‘driving the truck.’ In turn, they trust us to create the environment in which they can do their best work together and continue to grow.
2. Creating a culture of empowerment in which teams have a real say regarding what they build and how they build it.
3. Realizing that how we organize our teams and our time directly shapes that culture.

While this self-organizing model of Guilds, Squads, and Growth Chapters seemed a bit odd for some at first, since we embraced a spirit of experimentation, the team trusted our ability to iterate and figure it out. Within just a few weeks of tweaking, the team felt empowered and excited, worked extremely collaboratively, and the fastest we had in months. The model might seem complicated and burdensome, but it ended up taking less time than people had spent in meetings prior and guaranteed that we were always devoting the right resources to the right work without ‘managing’ anyone. And since no one was ‘managed,’ people began to think bigger, take more initiative, and lead.

Don’t think your team can handle this level of independence and responsibility? Give it a try. They might just surprise you.

And with this, I close out my Zume retrospective and this insane year.

Happy holidays and happy new year, everyone!