takeaway

Recently, I read an article shared by a colleague introducing amazon’s STO organization model. After reading the article, I felt more comfortable with its working methodology and realized that my team actually has more or less the STO working model. Anyway, I think STO is a more flexible and focused mode of work, and I have already had the shadow of STO mode when I participated in some special activities in the department:

First identify an OnWER (either r&d or product), and then bring together various sources (r&d, design, or marketing) to form a task force focused on that particular project. The owner has the greatest responsibility for the whole project. The owner needs to provide the necessary input to the owner. The owner must master the global context and provide the direction for the next step.

So I tried to share this, because the original Google Translate felt too stiff, I tried to do the translation and correction of human flesh, if there is something wrong, please comment and give advice ~

Original: www.rubick.com/implementin…

Here is the translation:

I’d like to share with you the most interesting management practice I’ve ever been involved in. At a company I recently worked for, we implemented Amazon’s single-threaded principals (STO) model, where everyone on the team reports to a leader, including product managers, designers, and engineers. You can think of the STO model as a more extreme model of cross-functional team collaboration, where the team has all the support it needs to accomplish the task.

What is the single-thread responsible model?

This idea, which comes from Amazon, is based on the idea that a team can only focus on one thing at a time (as opposed to multitasking). At Amazon, each team should have a clear area of responsibility (such as a product area, based on customer needs) that needs to be kept on top of. The leader of this team is known as the “single-threaded lead” (STO).

The most common alternative to the STO model is what I call the “3-legged stool” model. In the “three-legged stool” model, engineering, product, and design have separate leadership levels. Designers sometimes report to the product. But you can then assemble a team of engineers, led by a director of research and development, with a product manager (usually a designer). Two or three of them became a local leadership team.

In the STO model, everyone is part of a team and reports to the STO.

Single-threaded principals drive alignment and ownership of tasks

We found a lack of alignment (goals, pacing) between the engineering team and the product manager, and we planned to reorganize the team to make the division of domain ownership clearer. We had a lot of former Amazon employees, including the CEO, who felt that reorganizing the team into the STO model would improve these issues.

At a previous company, I noticed problems in maintaining separate hierarchies of product, designer, and engineer, and reorganizations often took place in incompatible ways. It’s usually product along a line and engineers along a line. Or they’ll be working together in the same organization, but there’s a lack of communication between them, which will often require a series of cross-team reorganizations.

In local teams, I often see the engineering manager (EM) and product manager (PM) not working well together and often doing poorly. Often their managers will try to provide guidance to get them done, but in practice these teams won’t work effectively for six months or more.

So I was advocating the STO model even before I heard about it.

Transition to STO model

The transition to this model requires understanding how to define the roles of everyone on the team, how to organize the team, and what meetings and organizational structure we will have around the STO.

One of the things we need to decide is who is the single-thread lead, the product manager or the engineering manager? It’s a pretty tricky question, and here are the pros and cons, as I see it:

We have four teams: two product teams, an agency team and an infrastructure team. Each team was 3-4 people, and we were worried that the teams looked too small. I’ve learned that good hiring managers can leverage a team member’s skills to compensate for his lack of expertise. However, it is more difficult for someone who lacks experience in personnel management to make up for this skill. A product manager is unlikely to have the ability to manage people and organize, so I decided to let the PM report to the engineering department. Here’s a good idea: whoever is the better organizer or hr manager should be the STO. With the ideal skill set, an experienced HR manager can also serve as a product and process leader. Later, I learned from Ben Bernard that this is how Amazon works.

After restructuring, we ended up with three larger teams. We replaced the engineering manager with a single-threaded lead, and then changed their reporting relationship. So that designers and product managers on each team report to the new single-threaded lead. My role as manager of managers made me the single-threaded leader for all product lines and responsible for engineering, product and design. We have a senior product director who reports to me and focuses on senior product strategy.

Despite this violation of single-threaded principals, we have a team of three core engineers who report to the CTO outside of this hierarchy. They are placed in different teams and spend most of their time in teams.

Other changes we are making at the same time are the introduction of weekly metrics review sessions where STOs and PMS will present what they have learned based on the metrics they track and keep an ongoing eye on their field. We set up monthly business review meetings as a communication channel between senior management and the local team.

The monthly business review meeting is an opportunity for the team to align with stakeholders, with the goal of allowing each team to set direction within the larger strategy defined by the senior product manager.

How do I switch to STO model

Our results are mixed.

Our team grew rapidly under the STO model and became the best performing team in my career. Although the composition of the team changed slightly, most of the members came from the previous company, and the team had delivered a few less visible projects, the overall mood was still low when we restructured.

I believe the truly successful changes are twofold: One is that the new leadership of the team is a powerful combination, but it seems that the STO model has made the combination even stronger:

  • The STO, the product manager, the lead engineer, and the designer were all very consistent, and I heard the same thing from each of them, basically showing the same point of view. They are more strategic than any team I’ve ever worked with.

  • They take greater responsibility for their area of responsibility and begin to challenge some of the product directions they “give”. They succeed in focusing their direction on what is more important, and leaders can be involved in meeting those challenges.

  • The team became very productive and kept growing, and they started delivering things to customers every few weeks. They go from starting with a single release without a plan to making incremental releases of large projects in ways that are useful to customers, so often that people don’t care about specific timelines. But they always finish on time, so much so that they usually accomplish their goals within a few days, sometimes even ahead of schedule.

  • Their work takes on a different nature. Instead of delivering a large project every few months, they prioritize iterations on smaller projects. They get new input from the customer and develop a small project for 1-2 weeks. I believe this leads to better service: they pay more attention to customer feedback than before.

Here’s Alexa Stefanko describing her personal experience:

I love it, and if I could be STO forever, I would. It made me better, it made our team better. I felt inspired, excited, challenged and engaged in a way I had never been before. I like the fact that my decisions have a tangible impact. My biggest takeaway was that it made my previous weaknesses unacceptable. I mean, my weaknesses (relationship with PM, technical mastery, lack of market awareness) were no longer tolerated in that position. I have to overcome all these weaknesses and quickly turn them into something harmless or an advantage. For example, it taught me how to have a good and productive relationship with my PM, something I’ve been struggling with.

It also forces my leadership team to stay consistent. Because everything went through me, we were able to challenge each other on assumptions we didn’t agree on. Our forced alignment meant that our team got clear and consistent direction.

While I think our data is often inadequate (and I wish we were more willing to admit it), I like to share our successes and failures with our products. I’m confident in our decision, and I’ll be even more confident when we can make it right.

The second team didn’t perform well, and the engineering manager felt that this new role was extremely responsible, but not supported by the product manager. Because one of the challenges their team faced was around product direction, which ended up being a big problem for STO.

The best thing you can say about the team’s STO model is that it clearly doesn’t work. PM eventually leaves and things start to look up. The biggest benefit is that problems can be exposed better than before, and EM can then take immediate action to improve the problem. However, the EM report says the whole experience was extremely stressful.

What are the pros and cons of the STO model?

One of the biggest challenges is the STO model, which requires everyone not to focus on who they are (whether you’re an engineer or a product manager). There is constant friction between product managers and designers, who feel that STO gives them less power. As primates, we’ve been part of power hierarchies since before we were humans, and people think that reporting hierarchies represent status and importance. The STO model is the opposite, and I think it will always be the same in the STO model. For example, say you think your company’s problem is the need for a better product direction. If you want to hire an experienced product to solve this problem, it may be more challenging to get someone to take on this role under the STO model. Many experienced leaders want to have a group of people reporting to them, or they feel their position of power is not “real” enough.

Throughout the experiment I saw some minor resistance to the STO model mostly from product managers and designers. It seems tempting for a product manager to blame any problem on the STO model not working. The top product manager will evaluate the single-threaded leader against his own criteria and discover that the STO lacks product-related capabilities because it is not as product-focused as he is. The job of an STO is very different from that of an engineering manager (or product manager), and a much harder one. I think of it in many ways as a director-level position because you’re leading a more complex organization (you’re leading engineers, product managers and designers). The biggest difference compared to the traditional engineering manager is that in terms of direction setting, you can’t just be a manager, you have to lead.

There was initial confusion between the roles of product manager and meeting panelist. One of the questions was: How often do you invite STO to meetings to participate in decisions? Ideally that’s not the case, but it’s a question we hear all the time. What I’m trying to say is that product managers are like technical leaders: experts who listen and learn about a particular area. For product managers, they are professionals who are good at prioritizing issues, guiding customers, and making sure we understand the context in which we are currently located. Just like technical leaders, they should be making judgments in areas of expertise they know best. The STO and the product manager should be on the same page, and the STO is ultimately responsible for leading. But product managers should be the ones who spend most of their time doing that, because they are the ones who perform that function on the team.

Ben Bernard, Lead Engineer: “Having worked on three different teams at Amazon and tried it again with you, it’s clear to me that you need very strong product leadership at the team level. This can come from STO (often done at Amazon) or from PM. Either way, the person must have the best understanding of the customer and its application scenarios, and the product vision. They must also be able to prioritize things (though this can be helped by a “data-driven” culture or other leaders on the team).”

One of the challenges we faced was that the company was small enough that dividing responsibilities between teams still resulted in each team taking on too much. The idea that you can focus on a single thing (the “single-threaded” idea) is not entirely true, because each team has so much control over so many areas.

The people who support STO are very important to the success of the model. If you do not have confidence in the product manager, technical lead, or designer, you may fail after adopting the STO model, and you should adjust your expectations accordingly. According to Ben Bernard: “It definitely happened at Amazon — Amazon just fired some people… Instead of trying to solve the problem, people often change roles or leave the company. This had some bad ripple effects on the old-timers, a feeling that Amazon couldn’t keep anyone, and a feeling that it wasn’t connected to the company. However, I think they are doing a good job of removing people from the team if necessary (with the exception of higher-level people). If you have a team that does its job, but has poor performance at several points in the chain, then working in that organization is going to be terrible. Single-threaded ownership can help solve this problem because each level is amazon’s STO and there are plenty of lenient ways to handle things. This makes every organization very different. AWS and Kindle, for example, are known for having different engineering cultures. This has led me to offer this advice to other engineers: “Never change teams unless you have friends on the new team and know it’s not screwed up.”

At the same time we were moving to more metrics-driven work, and while we were seeing good results from metrics and learning a lot from “metrics-driven,” it sometimes felt contrived because the amount of data we had wasn’t actually scientific enough. The main benefit of holding a “metrics review” meeting is to force THE STO to think about their area and report on it. The metrics themselves seem less important than observing the behavior of their domain. However, as time goes on, I think we will become more mature and more metrics-driven.

One of the challenges for STO is the coordination between the leadership and STO. Ideally, this way of working is where leadership provides goals and STO selects projects to achieve those goals. In practice, this can be difficult in small companies when founders and executives want to be highly involved in the work of the team. In our case, the local team was not fully empowered, so they could not fully make decisions without being empowered by senior management. This violates the expectations of the STO model and creates friction back and forth.

Do I recommend the STO model?

I believe the STO model is more effective than the standard “three-stool” model with a separate leadership hierarchy. But it has drawbacks that require more discipline to implement and maintain, so I’m going to use it as a tool I can use but won’t use in most cases.

Here are my factors in deciding when to use the STO model:

  • Ideally, you start with the STO model. Once you’ve established a separate hierarchy, it’s almost impossible to switch over unless you have very strong-minded and strong leadership. Few product or design owners want to give up all their direct reports. They see it as a career limit.
  • I probably wouldn’t introduce this in a larger organization, there are a lot of obstacles that would prevent this model from being successful, and I wouldn’t spend all my political capital in this environment.
  • An important determinant for me is the company’s work culture. Companies with employees who are more flexible in their roles or more customer-focused can achieve greater success with the STO model. Cultural flexibility is another factor. If I believed I could completely shape the organization over a long period of time, I would be more inclined to adopt the STO model.
  • Accepting a structured work culture will also be more successful. The STO model requires good standards and good processes to succeed.

If STO is adopted, I will focus on the following aspects:

  • I would hire an STO in a different way than an engineering manager or a product manager. You need people who are really good at creating direction from scratch, great people and process management, and great product awareness and even product management experience. A person with both product management and engineering skills is your best bet, but they are rare. Look for organization-centric product managers and product-centric engineering managers.
  • I spend a lot of time talking about people’s roles. They see themselves as “product manager” and “engineering manager,” so straddling those two roles can be confusing.
  • I expect many managers will have to challenge role reversal. In particular, I will assess the strength of their roles (technology, product and design) and better prepare for their gaps. This is a very big role reversal, and many people may not succeed, especially if they don’t have the right people to support them. Some people may not make the transition and may need to switch to another role or be managed.
  • Switching to the STO model requires you to set good standards for all positions. You need a clear definition of roles and career ladder so that their managers can be promoted fairly even if they don’t have the expertise. These are not prerequisites, but if you implement the STO model you will be working on it immediately.

I find it disappointing to conclude that the STO model is better, and you may not want to implement it. I think it showed me some of the benefits of truly decentralized teams: having strong ownership and being consistent. It showed me what was possible, and I found myself thinking about hybrid models and wondering if they could reap some of the same benefits. One thing I’d like to know is whether some of the same benefits can be gained by modifying traditional management methods.

Try to think, you might be able to achieve some of the same results by combining these measures:

  • Develop organizational concepts that apply to design, product, and engineering: including team size, ratio between specialties, and principles for team design (e.g., based on product domain or customer base), and write a short list of rules for this. For example, one of the rules might be that all reorganizations must be coordinated (or that an organization can be reorganized) and done as a team. This is quite a lot of work, and it’s easy to overlook, so I don’t think most organizations do it in advance, and you can do it through the STO pattern.

  • Enable product managers and designers to serve organizations, products to provide direction, context, and customer information, and designs to provide usability and utility. If any of them don’t satisfy the engineering manager, they can basically “terminate the contract” with the organization. As a practical example, let’s say Lisa is the engineering manager of a team who feels that her team has not set a good enough product direction to effectively fulfill the team’s mission. She can tell the product lead that she is not satisfied with the service she is currently performing and “send it back” to the product manager she works with. Then, the product organization needs to provide another person as soon as possible, and they can transfer the product manager to another role or let them go. I’ve found that product managers or engineers who have the ability to terminate contracts are just as effective at setting direction.

  • There may be ways to set up responsibilities so that the EM or PM has a larger perspective on their role, similar to the “you own it all” philosophy in the STO model. I used to have my manager tell me, “Everything that happens with this product is your fault. If customer support is poor, it’s your fault. If you have a bad product direction, it’s your fault. You have a responsibility to make this work.” Some of these issues are actually a stretch — I’m not technically responsible for the product direction, but taking a larger perspective on the characters helps ensure things work, even if it’s not on their track. Communicating your team’s success is key, even if it’s beyond your scope, and that’s something we probably need to emphasize more.