While IDEs make refactoring straightforward, doing the same with your org chart is not as easy. Yes, you might use a tool to drag teams and people around, but the same principles that make for clean code don’t necessarily map to teams. Here’s a quick grab bag of pitfalls I’ve seen in my work. As they say, these were all learned the hard way.
Avoid Premature Organization
You might have learned in the past that premature optimization is the root of all evil. The organizational manifestation of the same problem is when we put in place extra structures, layers, managers, and different roles that are not yet needed. When you can very clearly see that these additional roles will be required as the company is going through hyper-growth, then it might make sense. Given that’s rarely the case nowadays, such decisions often end up introducing overhead and complexity with little gains to show for it.
No Nano Teams
A special case of the above is about forming very small teams. Often, when going through a restructuring, leaders feel like a particular set of responsibilities doesn’t fit “neatly” in any existing team and create a new team just for that. When those teams are minuscule and comprise 2-3 people, they often weigh down your organizational chart. (This problem is explained at length in Capitalizing Your Technology).
That’s because nano teams have a tendency to create micro managers. What’s a person managing 1-2 people supposed to do? It’s easy to manufacture busywork to fill the “duty,” not due to ego or politics but simply because new managers are trying to do things. Unless the nano team will be staffing new positions almost immediately, I’d recommend postponing the team’s creation.
Don’t Create Patches
If you’re considering a reorg, you necessarily already have an existing organization. That means you’ll have different limitations, needs, and politics to consider. At this stage, it is essential to resist the urge to “patch” things up by creating special roles, hierarchies, or functions to make things easy.
For example, the startup’s earliest engineers sometimes don’t want to become managers but frown upon the idea of being managed by newer managers. That’s how you end up with VPs that directly manage too many people and complicated project planning processes that have to span several teams and these snowflakes. Every time you contort the org chart, you are piling on organizational debt that would be very hard to eliminate later.
Hard Mode Isn’t Necessary
As tempting as it might seem, rolling all the different changes at once is not “ripping the bandaid.” It’s setting your team for a very hard time. As an example, putting in place 3-4 first-time managers at once is going to be very taxing on the director managing them. You don’t have to do startups in hard mode.
Communication Has to be Managed
The rule is: Anything you don’t plan how to communicate will be communicated in the worst possible manner. Therefore, put serious thought into forming a communication plan to ensure that the right message will come across. How will you handle people who are working remotely or on vacation? What about people who signed offers but haven’t started yet? Considering all of these will help minimize the negative impact the news will have. That’s because even positive changes that come from healthy growth usually make people nervous.
Don’t Just React: Proactively Handle Problems
Lastly, remember that even though it might be possible to make someone relax after a scare as part of the communication plan, it’s often best to avoid it in the first place. Have your leadership team come up with a list of people who might be expecting promotions, have difficulties with change, or just need extra time to digest.
One nitpick about this is that these shouldn’t be matters that wait for the last minute. Good management is about providing candid feedback all along, and therefore, most people shouldn’t be expecting a promotion to leadership if they’re clearly not there yet. However, sometimes, some cases haven’t been treated clearly enough, or where the decision came down to two people. Taking the lead as part of the reorg will only make things easier in those cases.