Aligning our organizational structure with the customer journey
This is Part III in a series on how Automated Insights revamped its internal organizational structure. Start at the beginning with Part I.
In the last article, I described how we implemented a version of Spotify’s Tribes and Squads in our Engineering organization. As we fully committed to transitioning from a services company to a product company, it was time to rethink the organizational structure for the rest of the company too. Previously, we were functionally aligned (i.e. Engineering, Sales, Marketing, etc.) as is common in companies large and small.
Traditional Org Chart
A big challenge with that model is you can lose sight of the customer. One of our company values is Think Like a Customer. Employees, especially engineers down in the weeds of creating features and fixing bugs, can sometimes forget the real reason we do what we do. Our Think Like a Customer value is simply a reminder that Automated Insights is able to stay in business because of customers. It doesn’t mean “the customer is always right” or anything like that, but we can’t simply create features only because we think it is a good idea or fun to do. It must also be something that a customer ultimately wants.
With that context, the functional organization model doesn’t align well with the customer journey. If you want to improve or change some aspect of the customer experience, it is often challenging to assign end-to-end ownership for that change. Let’s say we have a goal of making the free trial process more successful. Does Product Management own that since they spec out the features? Or Engineering because they‘ll build the features? Or should it be Sales because they have the most direct interaction with customers doing trials?
It was in a meeting with our Chief Revenue Officer, Adam Smith, and VP of Product Management, Adam Long, that we discussed aligning our Squads with the customer journey. That way, responsibility for key features and processes (from the customer perspective) would have clear ownership. Much of the rest of this article came from brainstorming sessions the three of us had prior to implementing Squads company-wide.
Aligning Squads with the Customer Journey
First, we needed to define the customer journey for our Wordsmith product. This was a good exercise as we had never thought about the end-to-end process that a customer goes through when interacting with us as a company. A simplified version of that is as follows:
First, you hear about Wordsmith, then you learn about its capabilities, then you want to try it out, and you do that by writing an NLG template, then you’ll want to refine (edit) that template until you are ready to publish your content.
The initial Wordsmith customer journey map
Next, we mapped each of those functions to a Squad and thought about what was left over from our original organizational chart. The customer journey doesn’t map to every job you need to do inside a company (e.g. running payroll or keeping servers running). Some Squads aren’t aligned with a defined customer interaction, but that’s ok. We were coming from a model where there was virtually no alignment with the customer journey, so this was at least a step in the right direction.
What is a Squad?
A Squad is another name for a team. Nothing revolutionary there, but in the Spotify model, Squads are a particular type of team. They should be small, highly aligned, and loosely coupled. Each Squad should have the following attributes:
- Clear mission: how will they help customers at a particular stage or enable other Squads to do their work
- Clear autonomy: self-organizing team that can attack their stage’s problems
- Clear accountability: optimize the 1–3 metrics that measure performance for the Squad at its stage in the customer journey
- Focused: each person in the organization should be on only one squad (we had an issue where our best employees were spread too thin)
- Cross-functional: composed of people from different disciplines (dev, design, QA, support, etc.)
Ideally, each Squad is completely autonomous and has all of the resources it needs to accomplish its work, but in a 50 person company that’s just not practical. It would be hard to implement this model in companies that are less than 30-40 people. You just don’t have enough employees to fill out all of the Squads that map to the customer journey. And one thing we learned is single person Squads do not work well.
In the Ai model, each Squad has just two defined roles: Squad Leader and Squad Member. The Squad Leader is the one that is ultimately responsible for the performance of the Squad (and therefore its members). I’ll go into a lot more detail about the role of Squad Leaders in Part V.
A Tribe is a collection of similarly aligned Squads. Each Tribe has a Tribe Leader that works closely with the Squad Leaders in the Tribe. The Tribe Leader helps ensure Squads within the Tribe don’t conflict with one another. The Tribe Leader is also responsible for helping define the mission and metrics for each of their Squads in collaboration with the Squad Leaders.
Ai Tribes and Squads
We came up with sixteen Squads within five Tribes that covered all aspects of our business:
The Attract Tribe consists of our old Sales and Marketing functions. We inserted a Buy Squad after Learn and before Try even though customers generally don’t Buy before they Try. This was the first of a few compromises we had to make so the model would work for us. The Buy Squad in this context is our old Sales team. Since the Attract Tribe consisted of Marketing folks and the Build Tribe consisted mostly of Engineering and Product Management folks, it made more sense to have Buy be a part of the Attract Tribe (whose Tribe Leader was our CRO).
While not entirely consistent with the customer journey, we decided early on that we would not be held slave to a rigid structure. We used the customer journey as more of a guide than a strict rule. Another key feature of this model is that we wanted it to be fluid over time. We recognized we were trying something pretty different, so I wanted everyone to be comfortable with iterating on the model regularly. One of the major failings of the traditional organization is its inflexibility to change. I wanted to fix that.
For the Squads in the first three Tribes (that mapped with the customer journey), we named them after verbs that were associated with the action the customer was performing. This was one way to try and break away from the traditional org names (Sales becomes Buy, Marketing becomes Hear and Learn, etc.).
The Build Tribe was made up of engineers and product managers building the core Wordsmith product. The Scale Tribe consisted of our managed services team, which had a mix of data scientists and developers, as well as our account management team.
That still left several functions that were important but not represented in the customer journey. We created an Enable Tribe whose main purpose was to help the other Squads get work done. It was made up of our Research (Labs), DevOps, Security, and Analytics teams.
Finally, that left Finance, HR and Legal, which we created an Ops Tribe for. The main benefit of having Ops included in our Squad model has more to do with how we get work done than necessarily aligning with the customer journey, which I’ll describe in the next article.
Guilds
While our Squads covered most of the functions we could think of, there were still a few issues. For example, with developers spread out across at least nine of the sixteen Squads, how would we ever keep them on the same page? Likewise, when it comes to design, how do we make sure marketing folks in the Attract Tribe are using the same style guidelines as designers in the Build Tribe?
The answer is Guilds. A Guild is simply a self-organized interest group. Out of the gate we did not specify any Guilds. We wanted to see what would form organically and sure enough, they did. Guilds have the additional feature of providing leadership opportunities for people that may not be a Squad Leader yet. If you feel ready to show your leadership potential, form a Guild.
Guilds typically set standards for how to do a particular role across the company as well as share lessons learned.
Spotify also described the concept of a Chapter, which is similar to a Guild, but contained within a particular Tribe. That may be necessary when you are their size, but we haven’t found a need to carve out functions within a Tribe that aren’t relevant across all Tribes.
Cross-functional Guild
Summary
We covered a lot of ground in this article including why we adopted the Spotify Tribes and Squads model and how we mapped it to the Wordsmith customer journey.
Here are a few key points about Squads:
- Main benefits of this model include autonomy, agility and focus.
- One Squad per person — more than one Squad per person indicates a resource gap. Being on one Squad helps drive accountability and focus.
- Each Squad has 1–3 metrics they are held accountable for.
- The Squad Leader is accountable for all work produced by the Squad. The Tribe Leader is accountable for all work produced by their Squads.
- The Squad structure will be fluid over time.
Over the past year, we’ve seen many benefits from this model. While no organizational model is a panacea that will solve all your problems, we found that the Squad approach offered:
- Greater accountability
- Better execution
- Clear focus areas
- Cross-functional alignment
That does it for this article. Next up in Part IV, I’m going to talk about how we get work done with Squads. If you are familiar with Agile, it won’t be anything new — except we make every Squad use Agile including HR!
If you like this article, please let me know by clicking the ❤️ button below.