Many software companies will go through a period of time when they institute a series of reorgs. There are generally two reasons for this. The first reason is that they are growing and they are shedding their old org structure because it needs to adapt to the increased size of the team. The other reason is that their org structure simply does not work.
There are many ways to think about doing a software reorg. Many people will talk about the need for product oriented organizations. Many other people will talk about the power of the matrix organization. Someone will invariably invoke Conway’s Law and before any final decisions are made another person will inject the notorious “Will this scale?” meme.
I have been in the middle of a number of software reorgs over my career. In the last few I noticed something very interesting.
It did not really matter what model was being applied to the eventual end product. Whether it was a matrixed organization, or one with teams dedicated to specific products or verticals, they all had one thing in common: The final organization matched the capacities of the team leads and managers.
Without much success, over the past few years I have attempted to explain this to people in the middle of their own reorgs.
Whether the reorg is happening top-down or bottom-up, there comes a time when someone has their favorite slideware open and they are attempting to put names into hierarchical boxes. There is a pool of unallocated leaders that gets assigned one-by-one like picking kids for your dodgeball team at recess.
About half to three quarters of the attempts to reorg a team will break down at this point because the chosen model results in too many unpicked managers/leaders, or they are too skewed towards one particular team or structure. I have stared at enough broken org charts at three o’clock in the morning to realize this is a recurring pattern.
Regardless of what model you choose to get those boxes filled in and all of your leadership allocated, you will always wind up going over each team and asking yourself a set of questions:
- Who is going to quit because of this structure?
- Who will need help supporting their team and/or products?
- Who will reap the most learning and career upside?
- Who will be unhappy about this?
There is some calculus that the management team will do in their head to determine churn, team satisfaction, and “what gaps will we need to manage through”.
At the end of that calculation there is an inherent “Yes, this will work” or “No, do it over” boolean response based on some unspoken feeling that one of those three variables is not within acceptable parameters.
If a reorg makes your team unhappy, or it causes your best people to leave, or leaves too many important things without an interim owner, then it does not matter what model you employed to get to that point. You will need to feed your homework to the dog and do it over.
I am going to call it out in the hopes that someone writes it down on Wikipedia someday for posterity. Heck, you can even call it “Szeder’s Law of Team Reorganization” and make me as famous as whoever the heck that Conway guy is.
“No team reorganization will succeed unless it takes into account the capabilities and satisfaction of the existing team”.
-John Szeder
I have run through this process enough times now that I sit down and start with the team allocations first. I try to pair up the most important people and the most important leaders with the most significant work. I make a list of people who will quit their jobs if given horrific assignments and attempt to assemble a working model that will make the fewest possible concessions to the team.
If the organization is big enough, then you might only be able to do this down to the director or team lead level. You might have a team big enough that you cannot go any further on your own. At that point it is worth it to engage your leads and conduct ranked team wish lists, a team draft, or something similar in order to construct viable models that make the most sense.
No reorg is perfect and you will generally have regrettable losses whenever you put up the final output of your efforts onto a screen in a company meeting. It is important to sit down and make sure you minimize those losses and successfully have an interim plan for any gaps that exist through a reorg.
If you do not do this then you will discover an unfortunate truth: If your reorg is not successful, you will have to do it again. Each successive reorg will have more churn and create more unhappiness, and suddenly you are trapped in a vicious cycle—reorgs all the way down.
One of two things will happen at that point. One option is that you will accidentally get it right, possibly through the team shrinking to the point that it is a much simpler problem. The other option is that you will have realized that your reorg approach is inherently flawed and will have applied a better filter to your reorg plans, managing to design one that takes into consideration the organization’s growth and retention based on the individuals in the organization themselves.
I hope you keep this in mind the next time you are staring at a list of employee names and an empty set of boxes in reorg-version-23.ppt at three o’clock in the morning.
If you do not, at the very least you are about to get really good at rolling out reorgs. Hashtag silver-lining.
Thank you for reading along! I hope you learned something valuable in today’s short post. If you did not, then why not buy this funny titled book (which I have viciously hidden under a short link, in an attempt to gaslight you for a click) that I randomly found on Amazon. Per Amazon’s Affiliate Policy: I must urgently warn you that I will enrich myself unfairly and gleefully indulge in shameless profit-taking should you click on this link and make a subsequent purchase. I hope to see you again next week for another random conversation on engineering and software product development!
