A few years back, during my early days at Affirm, a couple of us engineering leaders[1] were trying and struggling to orchestrate a reorg across our teams. There were a number of strong personalities to manage and key communications to sequence, complicated by tweaks based on feedback and pushback on the proposed structure.
So in one of our staff meetings, we were describing our challenges and explaining to the rest of product and engineering leadership why it was taking so long. The attending Head of Product—a Pinterest veteran—advised that to…not fret too much about it. In their previous role, they experienced so many reorgs that the team developed a set playbook on how to run the process, regularly, on a quarterly cadence. That we were stumbling in the dark meant that we didn't yet garner the reps for smooth operation.
Nobody knew whether this was a good or a bad thing.
Organizational shuffles are a powerful, but poorly understood tool, an astonishingly wide catch-all for business operations. At a fundamental level, reorgs are about realigning team structures, which includes changing managers for some people on the team. This is sometimes triggered by a senior person, high on the org chart, leaving or coming in; it can also be due to shifting business objectives, macroeconomic environment considerations, or as a promotion/retention mechanism[2]. Merging with or acquiring another company by definition needs a new org structure, though this trigger often comes with layoffs, with the euphemistic "eliminating redundant positions." And this is what employees remember: the general trepidation upon their announcements is from this association with losing jobs.
Most of the literature focuses on the final state of the org chart, incorporating organizational principles and theories on how people should work together; I've written much on the topic on this blog and have led conference discussions on how the right structure can make a difference. Frankly, it's the main part of the overall reorg process that's broadly applicable and transferrable, across companies and situations. It's also more fun to theorycraft structure to improve how things work, an undeniable appeal to efficiency and systems engineering, just with people instead of computers. There aren't that many aspects of people management where you get to pitch senior leaders on Star-Trek-inspired verbiage like the Inverse Conway Maneuver.
But for all the attention on shaping the team, there's less discussion on how to successfully execute the reorg: communication, details of how the new teams will operate, transitionary nuances, etc. It is this messiness en route to the end state that causes stress, uncertainty, opacity, and ultimately fatigue for its participants. Some of this pressure can be alleviated with some foresight and planning, but to be fair, it usually takes the new teams to start working with one another to hash out many of the operating details.
Unfortunately, reorgs typically aren't executed with this level of rigor. In one instance, I've had an executive lay out the vision, and sketch out the new team alignments in a lengthy email. It was a reasonable starting point, but after they were immediately busy with other priorities, and could not respond to follow-up questions and issues for weeks—which meant that managers, senior engineers, and HR were left to fend for ourselves. We were forced to infer meaning from reporting lines, divine intentionality from structural proximities, figure out who should be collaborating with whom across functions, and define operational outcomes independently. It was the managerial analog to a software architectural rewrite: as if the architect just sketched out a bunch of new services, ignored the resulting predictable development and migration challenge, and dropped the marker with a flourish walking away.
Yet, it's harder to give solid advice on this part of the reorg process because the details are so dependent on context and personnel. Say, there's a business goal to bring the web and mobile clients to parity, and the solution is to consolidate the teams. Even abstractly, there are a bunch of questions, most of which don't have good answers without concrete context: should the leader overseeing the combined team have a mobile background, a web background, or it doesn't really matter? How does design or QA plug into this new team? Should there also be architectural and framework changes, and does that implicate the backend teams supplying the clients with APIs and data structures? How does this team work with other front-end and mobile engineers elsewhere in the company in charge of their own apps?
Mercifully, teams will figure this out. Eventually. Empowered and motivated folks—usually managers, but I've had a good number of staff engineers step up as well—hash out the operational nuances with enough time and iterations from feedback. But this is one of the main reasons why it often takes months for a reorg to settle, and that assumes the best of circumstances. More often, teams are kept in the dark until the final announcement is made, or bottoms-up changes stall waiting for executive approvals.
And sometimes, by the time teams are able to digest all the changes and emerge on the norming side of team development, another reorg throws everything back into flux.
It's not just about the final org chart. The timing and execution matter, and you have a higher chance of success if you can define the incremental steps or the critical areas of focus for shifting processes. New structures come with new communication lines—some are explicit with the reporting structure, but a whole lot come from implicit relationships and working collaborations and enabling those comms helps the org move faster as well. Identify gaps in roles and positions and spin up recruiting as an immediate next step; the tricky part will be convincing candidates that the new position is unlikely to be fully baked so early in the new organization and will require a level of comfort with ambiguity.
If you get these bits right, though, the team can surprise you with amazing results.
We at the director/VP level reporting to the CTO were collectively the "L2s"; L1s were the C-level executives, and I guess L0 is the CEO. ↩︎
Management classes tell you that this is a bad practice, but I honestly see this pretty often, even in well-managed firms. ↩︎