Yesterday I gave a talk at the NYC CTO Summit on Reorgs (slides). Here's a rough summary of the content, prior to the video release.
The general theme of this summit was "Driving Change." When I came across that theme, I immediately decided to talk about the process of reorganizations. In particular, the process of being a leader of a team involved in a large top-down reorganization. I have been in the leadership team through three of those over the past four years or so, and I have had many conversations with friends at other companies over the years who were in the middle of them, either leading them or as a person swept up in them.
My first point about reorgs is that fundamentally, in companies big and small, they happen. They are disruptive and stressful, but I personally think they are often a necessary evil, the "full GC" of organizational structure change. You can get a lot of value having smaller parts of the organization morph and change as needed, but sometimes a higher-level view of the business drives the need for larger and more top-down change.
I happened to see a tweet that led me indirectly to this blog post, and in particular, the following structure:
This is a great structure for talking about a reorganization, and in particular, your role as a leader in a reorganization.
Vision: The Vision is the "why" of what is happening. You may not be the initiator of the "why", it might be your CEO or someone else in the leadership team, but you must understand it and focus it. Usually the reasons leading to a reorg are one or more of:
These are all well and good as a root cause, but you need to provide a lot more nuance to make this something that people buy into and want to follow. Especially when a reorg is in response to strategic change of focus. You're the leader of tech, so first make sure you understand and are on-board with the why, and then think about the way to communicate it to the rest of the engineering team in a way that makes sense. Without a clear vision, people will be confused as to why this is happening, even if what they are supposed to do when and how makes sense.
Skills: Do you have the skills to actually make the change happen? You may think that a reorg shouldn't require a lot of skills you don't already possess as a manager, but I disagree. There are many details to be ironed out in a reorg, many steps to follow, especially in a large team.
The first reorg I helped with moved our tech team from functional teams (frontend/storefront, backend) to what we called "pods", cross-functional teams with tech and product and high-level business goals. It was driven by both inefficient communication and a growing team. This was probably the easiest reorg that I led because the team was pretty small, and the lesson here is important: things that are practically free for a 20-25 person team are much more complicated when you're dealing with 60 people, let alone hundreds. The reasons were clear, we didn't need a ton of planning or incentives for people to do it, we just needed to clearly communicate what was happening why and move it through.
The most important skill for you as the leader of a large team through a reorg is communication. (In general, this is the most important skill that leaders need for pretty much everything). When reorgs go bad, one of the ways they go bad is that the reason for the change is not communicated well to the whole team, and the timing of communication is not coordinated, so some people know what's happening, others don't, and thus starts the rumor mill and the anxiety skyrockets. You are the leader. Write down exactly what the purpose is, the nuance behind it. If you need to write versions for your managers and versions for the whole team, do so. Think about your communication, and plan it as best you can.
Incentives: Why should people play along? What are they going to get out of it? You need to advocate for your team, and make sure they are going to be eager to embrace this. This is not selfish but rather sensible. If your team doesn't buy in, the reorg won't go as well, and the company will suffer for it.
Resources: Do you have available now what you need to make this happen? In the case of a reorg, that usually means time and focus. If your whole team is pushing out a major release of your mobile app, or focused on some other new launch, are you really going to distract them right now with the turmoil of a structure change? I hope not. Yes, a reorg may very well mean things need to slow down for a period of time while you figure it out and get the new teams formed, and gelled.
Of course, the other element of resources is in the new organizational structure you create. This brings us to the story of my second reorg. We had good success with the "pod" structure, but we saw that the focus for the pods was too high-level and we wanted to really get a focus on certain business strategies. We also wanted to expand the teams beyond tech/product to include other areas of the business who would be involved in the business strategies such as marketing, customer service, finance, operations. So we created what we called "strategic pillars". These were somewhat like business units, with a general manager who was responsible for the strategy of the cross-functional team (although not the people management), and members from technology, product, and the business.
Both incentives and resources were a big part of this reorg. On the initial list of candidates for general manager we did not have anyone from engineering, and I pushed to make sure that we did end up with a general manager chosen from the tech team. This was to ensure that engineering continued to be seen as an important strategic partner in the overall company, instead of an execution arm for product and business leaders. We also created a specific tech lead role for each pillar, who served as part of the pillar leadership.
As for the issue of resources, one of the mistakes I believe of the initial pillar list was creating one more pillar than we had adequate staff to support. Instead of spreading the team too thin, we simply did not staff that pillar with tech, saying that it would start out with more business analysis and research and as we came up with concrete plans we would hire into it. We ended up never getting the staffing the pillar needed to be successful, and eliminating it, which in turn was a big disappointment for the people who had been on that pillar. If you put people into leadership opportunities and then take them away, even if it is a good business decision and not an indictment of the person, they will still see it as a loss and you are very likely to lose them over it.
It's a cliché that every "Yes" you say implies a "no" to something else, but saying "no" to stretching your team too thin in a reorg is an essential part of making it successful.
Finally, the action plan. Without a clear action plan, you end up trying to start, realizing you're not ready, stopping, and starting again, sometimes many times over. You may not be the right person to make the entire action plan yourself, I know that is not my personal skill set. But you will still be involved in the planning process. If your reorg is intended to help focus people on new business strategies and goals, take your analytical mind and scrutinize those goals. Do they make sense? Are teams going to be able to work on their goals without negatively impacting other teams? If you have multiple teams with conflicting goals, you will quite possibly end up with turf wars.
This was one of the major elements of the final reorg I worked through. We had a nuanced set of goals that we wanted the teams to accomplish, and it took us several rounds of revisions to get to teams with goals that were productively aligned, independent enough to allow separate measurement without being in conflict. This process was necessary, but we suffered the downside of lacking a clear action plan, false starts, while we ironed it out. The team knew changes were coming, and they tried to tie up loose ends and finish up their work to be ready to move with the new organization. But we took longer to get the new organization together than anyone expected. With better planning earlier, we may have been able to avoid this period of uncertainty.
All of the reorgs I went through helped to move the company towards a more healthy, productive and focused structure, and I believe they were generally good for us. My final two pieces of advice for anyone managing a large team in a reorg are to remember that you don't have to do it alone, and that in the end you have to let go. Work closely with your peers to plan this, and expect that you will do some negotiating and have some outcomes that you like and some that you hate. Then, when it's out, let go. The teams will take a while to fully gel, the goals will probably shake out even more as they go through the actual process of planning on the teams. Some people will be happy with their new place, others will be unhappy and may even quit.
So, vision + skills + incentives + resources + action plan = success, right? Hopefully! However:
Reorgs are unlikely to solve all of your problems overnight. They are not a magic bullet exercise that fixes cultural issues or a lack of business strategy. If you aren't careful, your reorg will feel like rearranging deck chairs on the Titanic, a pointless waste of time for everyone involved. So don't be afraid to do them as necessary, but be realistic. This is a major disruption that impacts everyone, don't just do it for fun.
The general theme of this summit was "Driving Change." When I came across that theme, I immediately decided to talk about the process of reorganizations. In particular, the process of being a leader of a team involved in a large top-down reorganization. I have been in the leadership team through three of those over the past four years or so, and I have had many conversations with friends at other companies over the years who were in the middle of them, either leading them or as a person swept up in them.
My first point about reorgs is that fundamentally, in companies big and small, they happen. They are disruptive and stressful, but I personally think they are often a necessary evil, the "full GC" of organizational structure change. You can get a lot of value having smaller parts of the organization morph and change as needed, but sometimes a higher-level view of the business drives the need for larger and more top-down change.
I happened to see a tweet that led me indirectly to this blog post, and in particular, the following structure:
Vision: The Vision is the "why" of what is happening. You may not be the initiator of the "why", it might be your CEO or someone else in the leadership team, but you must understand it and focus it. Usually the reasons leading to a reorg are one or more of:
- Inefficient communication and collaboration between teams
- Adding or removing major products or focus areas
- Change in the size or makeup of the team
These are all well and good as a root cause, but you need to provide a lot more nuance to make this something that people buy into and want to follow. Especially when a reorg is in response to strategic change of focus. You're the leader of tech, so first make sure you understand and are on-board with the why, and then think about the way to communicate it to the rest of the engineering team in a way that makes sense. Without a clear vision, people will be confused as to why this is happening, even if what they are supposed to do when and how makes sense.
Skills: Do you have the skills to actually make the change happen? You may think that a reorg shouldn't require a lot of skills you don't already possess as a manager, but I disagree. There are many details to be ironed out in a reorg, many steps to follow, especially in a large team.
The first reorg I helped with moved our tech team from functional teams (frontend/storefront, backend) to what we called "pods", cross-functional teams with tech and product and high-level business goals. It was driven by both inefficient communication and a growing team. This was probably the easiest reorg that I led because the team was pretty small, and the lesson here is important: things that are practically free for a 20-25 person team are much more complicated when you're dealing with 60 people, let alone hundreds. The reasons were clear, we didn't need a ton of planning or incentives for people to do it, we just needed to clearly communicate what was happening why and move it through.
The most important skill for you as the leader of a large team through a reorg is communication. (In general, this is the most important skill that leaders need for pretty much everything). When reorgs go bad, one of the ways they go bad is that the reason for the change is not communicated well to the whole team, and the timing of communication is not coordinated, so some people know what's happening, others don't, and thus starts the rumor mill and the anxiety skyrockets. You are the leader. Write down exactly what the purpose is, the nuance behind it. If you need to write versions for your managers and versions for the whole team, do so. Think about your communication, and plan it as best you can.
Incentives: Why should people play along? What are they going to get out of it? You need to advocate for your team, and make sure they are going to be eager to embrace this. This is not selfish but rather sensible. If your team doesn't buy in, the reorg won't go as well, and the company will suffer for it.
Resources: Do you have available now what you need to make this happen? In the case of a reorg, that usually means time and focus. If your whole team is pushing out a major release of your mobile app, or focused on some other new launch, are you really going to distract them right now with the turmoil of a structure change? I hope not. Yes, a reorg may very well mean things need to slow down for a period of time while you figure it out and get the new teams formed, and gelled.
Of course, the other element of resources is in the new organizational structure you create. This brings us to the story of my second reorg. We had good success with the "pod" structure, but we saw that the focus for the pods was too high-level and we wanted to really get a focus on certain business strategies. We also wanted to expand the teams beyond tech/product to include other areas of the business who would be involved in the business strategies such as marketing, customer service, finance, operations. So we created what we called "strategic pillars". These were somewhat like business units, with a general manager who was responsible for the strategy of the cross-functional team (although not the people management), and members from technology, product, and the business.
Both incentives and resources were a big part of this reorg. On the initial list of candidates for general manager we did not have anyone from engineering, and I pushed to make sure that we did end up with a general manager chosen from the tech team. This was to ensure that engineering continued to be seen as an important strategic partner in the overall company, instead of an execution arm for product and business leaders. We also created a specific tech lead role for each pillar, who served as part of the pillar leadership.
As for the issue of resources, one of the mistakes I believe of the initial pillar list was creating one more pillar than we had adequate staff to support. Instead of spreading the team too thin, we simply did not staff that pillar with tech, saying that it would start out with more business analysis and research and as we came up with concrete plans we would hire into it. We ended up never getting the staffing the pillar needed to be successful, and eliminating it, which in turn was a big disappointment for the people who had been on that pillar. If you put people into leadership opportunities and then take them away, even if it is a good business decision and not an indictment of the person, they will still see it as a loss and you are very likely to lose them over it.
It's a cliché that every "Yes" you say implies a "no" to something else, but saying "no" to stretching your team too thin in a reorg is an essential part of making it successful.
Finally, the action plan. Without a clear action plan, you end up trying to start, realizing you're not ready, stopping, and starting again, sometimes many times over. You may not be the right person to make the entire action plan yourself, I know that is not my personal skill set. But you will still be involved in the planning process. If your reorg is intended to help focus people on new business strategies and goals, take your analytical mind and scrutinize those goals. Do they make sense? Are teams going to be able to work on their goals without negatively impacting other teams? If you have multiple teams with conflicting goals, you will quite possibly end up with turf wars.
This was one of the major elements of the final reorg I worked through. We had a nuanced set of goals that we wanted the teams to accomplish, and it took us several rounds of revisions to get to teams with goals that were productively aligned, independent enough to allow separate measurement without being in conflict. This process was necessary, but we suffered the downside of lacking a clear action plan, false starts, while we ironed it out. The team knew changes were coming, and they tried to tie up loose ends and finish up their work to be ready to move with the new organization. But we took longer to get the new organization together than anyone expected. With better planning earlier, we may have been able to avoid this period of uncertainty.
All of the reorgs I went through helped to move the company towards a more healthy, productive and focused structure, and I believe they were generally good for us. My final two pieces of advice for anyone managing a large team in a reorg are to remember that you don't have to do it alone, and that in the end you have to let go. Work closely with your peers to plan this, and expect that you will do some negotiating and have some outcomes that you like and some that you hate. Then, when it's out, let go. The teams will take a while to fully gel, the goals will probably shake out even more as they go through the actual process of planning on the teams. Some people will be happy with their new place, others will be unhappy and may even quit.
So, vision + skills + incentives + resources + action plan = success, right? Hopefully! However:
Reorgs are unlikely to solve all of your problems overnight. They are not a magic bullet exercise that fixes cultural issues or a lack of business strategy. If you aren't careful, your reorg will feel like rearranging deck chairs on the Titanic, a pointless waste of time for everyone involved. So don't be afraid to do them as necessary, but be realistic. This is a major disruption that impacts everyone, don't just do it for fun.