Our topic this week is reader-submitted! A subscriber reached out for advice on how to manage through organizational change and today’s post is a write-up of my top tips. We had a wonderful conversation and I am deeply appreciative of the connection and idea spark! It makes my day to hear from subscribers about our posts - you can always reply to this mail or reach out on social media.
👋 Mind The Beet: Two working parents (both product leaders in tech) discuss our journey with career, parenting, and life. We publish every Sunday. Subscribing is free.
Reorgs get a bad rap. For most people, they fall into the class of things like “the current complex macroeconomic environment,” “supply chain disruptions” and bee stings. Outside of their control, never pleasant but rarely fatal, and best if not chronic and repetitive.
Ouch - the sting of organizational change!
Often reorganizations are sources of ambiguity and stress. Some people use cynicism or cutting humor to react to a loss of control. Managers make this worse if they are not clear on details and use mealy-mouthed language that hides behind HR processes.
Yet reorganizations can be an opportunity for a team leader. What better time than reorg moments to role model how to deal with ambiguity? They are an opportunity to increase the net sum of empathy and humanity in your team’s work life.
Reorgs are also how teams grow. I remember fondly earning the right to reorganize because we secured new funding or I found a structure that empowered an up-and-coming leader. Team members who thrive are those who figure out how to embrace the opportunities that come with change.
They are one of the most complex things a team leader will have to land - part gut feel, part science, part performance. If this is your first time as a team leader leading through organizational change, this article is for you.
The Set Up: Activate Your “Reorg Mode.”
Here’s the situation: You’ve now discovered the need to make a change to your team structure. Maybe there is a new initiative to bootstrap. Maybe someone is leaving. Maybe the team has grown to be too large for the current span of control between managers. The team is not broadly aware yet that you plan to make changes and you don’t know how you want to organize the team for the new path forward. What do you do?
It’s time for you to enter “Reorg Mode.” This is a special, time-bound type of management style that exists as long as there is remaining ambiguity and disclosure of plans to be done. The goal is to get back into the run state.
I’ve seen reorg mode take as little as one week or as long as 6 weeks. Seemingly small decisions you make can have an outsized impact on people’s work life, so entering a special sprint mode where this is your most important duty is worth it. You should have a bias for action and a drive for resolution - it should feel a bit like you are a character on the TV show 24.
Kiefer Sutherland would nail org planning. Ask yourself: WWKSD?
Generally, reorg mode can be broken down into two phases: planning your org - where you create clarity - and announcing your org - where you generate energy for the plan. I’ve got advice for each phase.
Planning Your Org
It’s hard to give generic advice on org planning - so much of it is contextual to the business and the people involved. That being said, if it’s your first time through it, here are a few tips:
🏰 Outcomes, not Empires
This is my top advice - remember this one before anything else. You need to focus on the transformative outcomes you want to achieve. It sounds easy, but it is so common to see people building or defending their team charters instead. I sympathize with the latter behavior - it’s a stressful time and managers have to represent the needs of their teams, which allows them to justify hoarding and rent-seeking behavior. However, if you can be a manager who focuses on growing a stronger organization tomorrow with clear objectives and be boundaryless in seeking out the global optima for everyone's careers and products, you will be #winning.
Don’t be that guy.
My tips for how to adopt this mindset:
Start with defining the impetuses for change. Write down why you are discussing a new org. Stack rank and prioritize if there are multiple inputs. Don’t skip this even if it seems obvious - writing it down clarifies the situation.
Be curious. If you bias toward curiosity, you are naturally less defensive. Questionstorming about options for team charters is a great strategy, which is like brainstorming but the group is only allowed to ask questions that need to be answered vs. proposing solutions.
Work backward. Write down the business and career/people success that you want to see out of the changes a year from today. This gets you to synthesize what’s really important vs. just transactional.
🎪 The Tent: Doors and Windows
A big mistake I see managers make is to remove their typical decision-making tools when planning an org. Often times orgs need to be planned “in secret” to avoid disruption so the conversations are “tented” and not too many people are brought “into the tent.”
Don’t compromise on the tools you use to make the best decisions because of this need for secrecy.
Here are my tips for navigating this balance:
Write down the names of the core working crew that you’ll involve on day 1. Take a leap and involve a couple more people than you generally would - you need broad perspectives and ideas. Reinforce this is about trust and buy-in among the core crew.
Create a working doc - call it an “org spec.” Org conversations are often unstructured, emotional, and prone to talking about things outside the decisions that need to be made. Creating written structure and asking for comments on written ideas force the right focus. Sometimes just pre-writing the org announcement mail is enough; sometimes it’s complex enough that you want an internal doc for the working crew to discuss tradeoffs.
Activate your inner Project Manager. You’ve probably been promoted into a job where you don’t get to do as much project management as you like. Well, congrats, reorg mode is a chance to dust it off. Use checklists, assign tasks, give milestones names.
Be intentional about a few ways you can get signal outside the core group. These are the windows in your tent that allow you to see what’s going on. You’ll want early signal on how a plan is going to land before locking on it. Sometimes this means a ring-like expansion of more people into the tent. Sometimes you need to assign work for a tented member to go get signal or feedback from a specific impact individual or partner.
🏗️ Conway’s Law: Org Impacts Product
Let’s talk about the product outcomes you hope to achieve with the reorganization.
Conways’s Law is famous in product making: It says that a product’s end result will mirror its designers’ org and communication structure. Do you want database product X and not Y to be used by the app teams? Organize X into the app teams.
This implies something about the choices you must make in designing your org; it will impact the product you create. However, here’s my corollary: a pyramid org hierarchy can only optimize for one thing, so it probably can only solve a small sliver of your total problem space. Do you want to encourage your front-end and back-end teams to collaborate more? Or do you want to bring all the endpoint teams together? Should you organize by architecture or scenario?
So the bad news is that, from a product outcome perspective, org structure won’t solve all that much. The good news is that it’s not that complex of a decision for you to make: choose something that will make sense to your team and partners and then move on. No matter what, people will need to learn to achieve results regardless of the one thing the org optimized for.
This also means that if solving an x-team issue is the only reason you are doing an org change, you might want to rethink your plan. The churn might not be worth replacing one set of problems for another.
In the past 5 years or so of my career, I’ve been involved in multiple new x-team initiatives. Each span over 10 teams and have over 100 people involved in the x-team coordination. There is no one org structure that would have made the x-team work easy, instead, we created systems to “Thrive in the Matrix.” This is a skill you can learn and a team can get better at.
👐It’s the People, Stupid
So if you are limited in your ability to accelerate organizational goals by the way you organize, what then do you optimize for?
People!
Nothing destroys the perfect org plan more than the humans that will need to enact it. It’s more than OK - it’s required - that you take into account the strengths of the leaders involved and accept risks to enable them to focus on growth areas.
My protip here is that it’s best to firstwrite down each leader’s strength and growth areas independent of any positions that are available. Create separation of your talent analysis from the org structure. It’ll help you see opportunities more clearly and ideate new ways of organizing.
🪧Team Names: A Surprisingly Tough Nut
It’s funny how you got a great plan, leaders all signed up, you are almost ready to disclose - and then you get stuck on the new name of the nascent team. The name of the team is one of the few “hard to reverse” decisions you’ll be making.
Team names need to pass the following checklist:
Clear: People will be seeing the name in JIRA/Azure DevOps ticket trees and a bunch of other places. It should be descriptive and accurate to the team’s charter.
Easy to remember. It must easily come to mind and be easy to spell.
Future-proofed. Often team names need an expansive charter to enable growth to new and adjacent charters. Are you going to regret too narrow a team name in a year?
No Exception Flags. Trust me, search for your name in Urban Dictionary before you launch. And search in your directory for distribution lists and groups that imply some other team already uses the name.
Clever: The above criteria are more important than this, but the name will be printed on t-shirts and part of people’s work identity. A work-safe pun or reference can give a new team a cool vibe.
One strategy is to launch the reorg with the new team names TBD and run a contest among the team members for the team name. This drives autonomy and ownership, at the expense of making it harder to communicate team charter at announcement time.
I’ve named dozens of teams over the past 18 years. My favorite naming-a-team story was my very first gig as a Group Product Manager. I owned a set of authentication and provisioning services in the early days of the Microsoft cloud. We settled on the name People & Org Platform (POP). Easy to remember, rolls off the tongue and is clear about the mission. Generic enough that the existing identity can take on more charter. It even enables clever allusions and logos we could reference in team meetings:
POP was a team name with years of runway for clever stock art that plays on the name!
Somewhat independently, the 2nd of the third backend teams worked on Storage, Network, and Performance (SNAP).
You might see where this is going. We ganged up on the third backend team - I don’t even remember what it stood for (something on Code Lifecycle) but yes, we got them to name themselves CRACL.
The Krispies building the Cloud was born!
As an added bonus, it make it clear that the three teams were the primary backend teams and needed to work together.
🌌A Final Concept: The Gravity Well
All reorgs have this thing that happens to them called the Gravity Well. I promise it’ll happen to you. You’ll have the sketch of an org change set and then someone will say “Hey, this has been bothering me - should we change this at the same time too?”
The reorg Gravity Well can be a good thing. Ongoing change can be exhausting so queueing it up for the team to digest all at once - and for you to be in “helping folks digest change” mode for a shorter period of time - is a good thing. On the other hand, it can also muddy the waters and send a mixed message to the team. It also has a habit of delaying a reorg announce - you thought it would take just one more day to figure out this adjacent org issues, but look at that - it’s a week later and still unsolved.
Sometimes it’s the right call to let things get sucked into your reorg gravity well; sometimes not. It takes judgment. My best advice is to recognize it will happen and get ahead of it - write down “what else could we possibly change” in your org planning doc and ask folks to suggest things early so you don’t get a last-minute surprise.
Like far away galaxies, sometimes org plans are drawn toward each other’s gravity wells.
Announcing Your Org
So you have the sketch of the plan, but now it’s time to get the information out there. Here are my top tips:
🕰️The Transparency Clock
Transparency Clock is a term that refers to how long you have before the rumors or news of the new organization is common knowledge. It’s important that you think carefully about the order in which people are informed. Anyone who is impacted directly should know well before any written communication is sent and hear the news directly from their boss. Others should get a heads up the day or two before. Often you’ll develop rings of disclosure, starting with those who need to make decisions (i.e. do you want to report to A or B?), then partners in other disciplines who will be impacted, then team members who don’t have a direct manage change, et cetera.
All of this disclosure starts a clock - the Transparency Clock. If you think you have more than 1-2 weeks after you start informing impacted employees, you are fooling yourself. It’s OK to have a couple active issues left when you flip into disclosure mode (maybe you want input from someone on the final org design), but disclosure is a race against the org’s rumor mill, so have a baked plan before you begin.
Once you start disclosure, you are on the clock.
✒️ The Written Comms
Keep your written comms precise, but remember your goal is both creating clarity and generating energy. Many managers forget the latter.
Here’s my advice for the structure of a post:
Every reorg written comms should start with a celebration of a recent accomplishment and a quick reaffirmation of the product strategy. Things are changing, and people need to be reassured that the future is bright and a steady hand is at the tiller. It doesn’t matter that everyone just wants to know what’s changing - this is critical context to reaffirm at the top.
Next, if someone is leaving, announce this with specifics and include a thank you and summary of accomplishments if you can do so in a heartfelt and honest way. Give the departing individual a chance to review the language.
Next, drive clarity with the specific changes: Who, What, When. Use bullets and alphabetize any list of people in your written comms. This ensures there is no bias or that people won’t make up stories of bias.
Next, list the teams and team members who are not impacted and reaffirm their charter and importance. Change adjacent to you is still scary. People want to be reassured their work still matters even if it wasn’t the subject of direct change.
Close with a short, optimistic note about the future and a personal story of customer interaction that was meaningful recently. This reminds people what drives the work we do: customers.
Keep it short but make room for generating energy and a personal, authentic human touch.
Don’t try to address the Why behind the change in the written comms. If you try to, it’ll be easy to get defensive and loquacious. Instead, incorporate it into your stump speech. 👇
📣 The Stump Speech: The Why
Every manager gets feedback on their written reorg mails. Surprisingly, many forget to get feedback on the stump speech that you’ll need to give in All Hands and 1:1’s over and over again.
The stump speech is where you can more fully address the Why behind the change. Have 3-4 bullet points where you can tell a “behind the scenes” rationale and tradeoff analysis. It doesn’t need to be all the gory details or even align to your chronological thought process - it just needs to help people understand what you value and prioritize and how they can help the new org best succeed.
🍩 Be Accessible on The Big Day. Let People Process.
I have a tradition on my team of bringing in donuts to the office on the day of an organizational change. It’s been harder to keep that up in a hybrid world, but the spirit is: “Hey, here’s an informal way you can drop by and say hello. I’m accessible to you today to ask any questions.” You should find your own version of the “donut tradition.”
Finally, don’t ship your new org on a Friday. You want to be around and present to help set the tone and help people see the future. Giving the weekend to stew on it creates risk. It’s better to ship early in the week and let the work days prove that progress continues.
Wrapping Up
Wow - at 3,000 words, this is one of our longest posts! I suspect few of you need this post the day we publish, but I hope it’s a good archived resource for the next time you do.
Clearly, there is a lot to unpack. Remember: Focus on outcomes, optimize for people’s strengths vs. the perfect org and strategy, geek out over the comms so it generates energy and clarity, and be human.
Reach out if you want a neutral voice to discuss tactics with.
