When your company is in hypergrowth, you will be doubling the team every 6–12 months on average. At that pace you could go from 20 to ~300 people in two years and to 500 or 1,000 people in four years. You will be adding new functions rapidly (finance, HR, legal), potentially expanding internationally, while product road maps will expand and new areas will be launched or acquired into the company.
You will effectively be working at or running a different company every 6–12 months, with most of the people at the company having joined in the last 12 months. When I was at Google, it more or less 10X-ed from 1,500 or 2,000 people when I joined to >15,000 people when I left 3.5 years later. My startup was acquired when Twitter was ~90 people, and I left a full-time role with Twitter at over 1,000 employees. 90% of the people at Twitter had not been with the company just 2.5 years earlier.
As the company scales and increases in complexity you will also need to change the organizational structure of the company to reflect new executives, new functions, more employees, and changing alignment against your market and product. In other words, re-orgs will occur at the company frequently.
Early on many of the re-orgs will be at the executive level and then cascade down. As you add more functional areas, there will be finer division of executive roles. If you add a CMO or other CX-level person then some of the executive roles may consolidate under that individual.
Early on, you may re-org the entire company frequently. But once you hit 500 to 1,000 people, you should expect fewer company-level re-orgs and many more interfunctional re-orgs. For example, a change within the structure of the sales team, versus changes across all teams simultaneously. Some teams such as sales are more likely to re-org frequently at that point as they scale, while others like product and engineering tend to be more stable. Part of this has to do with where head count grows and needs change most rapidly in a company as it switches from being solely product-centric, to focusing more on go-to-market. The biggest cross-company re-orgs later as the company scales will occur when changing product/engineering/go-to-market simultaneously, adding new product areas or acquisitions, if a company flips from a matrix to business unit-like organization, or flips between centralized and decentralized internationalization.
Early on, you as CEO will need to be adept at re-orgs. Later, as re-orgs shift more frequently to functional organization, you will need to make sure your leadership team knows how to approach them. Most companies and new managers screw up their first re-org or two, causing unnecessary pain in the organization. Below is a simple guide to re-orgs.
1. Decide why you need the new org structure. Determine what the right structure is and the logic for why this is better than before. Do you need renewed focus on a specific area? Are there collaboration issues? Has the team grown dramatically and now needs additional management? Has something changed in your market that means you need to re-align functional priorities or the set of people working together? Spell out to yourself the logic of why you need to re-org first, and then think through the leadership and org structure that works best.
2. Determine what org structure is most pragmatic. Who on your leadership team is overloaded and who has bandwidth? Who is building out a great management layer? What areas would fit well together? Sometimes, there is no single right answer, and you need to balance managerial bandwidth with the logic of the situation.
As you determine who needs to work on what and the proper reporting structure, remember that nothing you come up with will be 100% perfect and that is OK.
Should you have cross-functional product and engineering organizations or verticalized product units? Should international be distributed or centralized? These sorts of questions come up all the time as companies grow, and some companies flop between structures over time (Oracle supposedly flips its international org every few years).
Relatedly, reporting is an exercise in tie breaking—i.e., you want people who are likely to disagree to eventually report in to a single tiebreaker (this may be the CEO, or it may be someone lower down in the org).
3. Get buy-in from the right people before implementation. If possible, you should consult with a handful of executives whose functions would be most impacted by the change. They may have good feedback about how changing the org in your function impacts their own functional area (e.g., changing the org structure for product may impact how engineering and design are structured).
Re-orgs should never be open conversations with the whole company (or a functional area) about what form the new organization structure should take. This only opens you up to lobbying, internal politicking, and land grabbing. It also prolongs the angst—re-orgs should happen swiftly and with as little churn as possible.
4. Announce and implement the re-org soup-to-nuts in 24 hours. Once you have decided what form the new organization will take, discuss it with your reports in their 1:1s. Your executives should have a clear plan for how and when to communicate the changes to their team members. If there are key people deeply affected or likely to be unhappy with the change, you or one of your reports can meet with them either right before or right after the announcement to hear them out and re-affirm the logic for the changes.
You should never drag out a re-org or pre-announce it. Try not to announce “this week we will re-organize product, and next month we will change engineering.” If possible, all elements of the re-org need to be communicated and implemented simultaneously. If you pre-announce a portion of the re-org, that team will not get any work done until the re-org happens. Instead, there will be hushed conversations in conference rooms full of gossip and speculation, crazy rumor-mongering, and executive lobbying.
5. Every person on the leadership team should be briefed on the re-org and be ready to answer questions from their team about it. If the re-org reaches or impacts enough of the company, the executives of the company should be briefed ahead of time. Write up an internal FAQ if needed and circulate it.
6. Remove ambiguity. Know where ~100% of people are going. Don’t do a partial re-org. When the re-org is announced, you should know where ~100% of people are going if possible. The worst possible situation for people is to not know what their future entails.
Make a list of the people most likely to be unhappy with the change and reach out to them quickly after the announcement, or speak to them before the change if necessary. Make sure to later be accessible to these people later so you can explain the reasoning first-hand.
7. Communicate directly and clearly, and compassionately. Don’t beat around the bush when doing the re-org. Explain in clear language what is happening and why. Listen to people’s feedback but be firm about the change.
There will always be people who are unhappy with the shift in org structure. They may feel passed over for promotion or demoted, even if this is not the case. Listen carefully and see if you can meet their needs in the future. However, keep backtracking to a minimum. You are making this change for a reason, and if you start making exceptions for the squeakiest wheels you may reverse the whole reason you are making the change, as well as show people you are open to being politicked.
Just like letting people go, a re-organization can be unpleasant. There will undoubtedly be people disappointed with their new role or diminished responsibilities. If done right however, your company will function more effectively and be aligned to win. Re-orgs have to occur for the long term success of the company.