The higher up the organizational ladder that you go, the farther removed you get from the code being your focus: the team is your precious project now. Refactorings give way for re-organizations. New frameworks and tools are out, new processes are in. Architecture diagrams step aside, you now deal with the org chart.
There are similarities between those two responsibilities, and a part of that is the fact that you can notice organizational smells, much like you learn to spot code smells quickly. To surface the most critical issues, I do an “org chart debugging” session when onboarding clients. I ask them to describe the org chart, without any additional questions, and see how many tangents, explanations, and excuses I get.
If the organization seems to have redundancy, it is often a smell that indicates the attempt to work around problems and issues. I’ve seen several times that new hires turned out not to be fit for their roles. When this mismatch was not handled, a bottleneck was created—the organization ultimately created a bypass. Think of companies with a few “chief architects,” or what seems like overlapping Product organizations, for example.
This stems from what I call cowardly management: shying away from treating the root issues, instead trying to find remedial measures for the symptoms.
It is perfectly acceptable that the company and its leaders will make certain efforts to keep key people satisfied and in the company. However, if not weighed against long-term effects, these efforts might result in suboptimal results.
A very typical scenario is that, a few years after the company has started, one of the founding members is given a special responsibility to prevent them from moving on. The entire organization is then forced to support a product that does not match the company’s strategy, or useless processes that do not justify their complexity.
There comes the point where sidelining results for the team’s happiness does not hold up: especially if that happiness is localized to a few key people and not your entire group.
This smell is trivial to spot: you go over your org-chart, and you have to explain that a certain team is called X but actually does Y. These end up happening in every company—especially during the early years. As you are going through customer development and haven’t reached product/market fit (or keep innovating), you will have things change faster than the organization might be willing to change.
If these pile up too much, you run the risk of words losing their meanings, borders of responsibility become vague, and things get lost along the way. Not to mention the (sometimes nontrivial) annoyance of trying to fill positions in an “application group” that doesn’t handle any applications and similar peculiarities.
This is also the case where business changes have altered the org-chart but not enough: think of an “unbalanced tree” where one director might be in charge of seven teams and another for a single team. A balancing act should often follow.
When I see an engineering group that has a lot of tiny teams, I know that someone might be trigger-happy with promotions. Somewhat similar to an engineer that first read Design Patterns and now wants to use them everywhere—so are some new executives rushing to create structure where no structure is needed yet.
Premature organization increases the chances that you will suffer from outdated structures down the line, and vastly increases your communication and management overhead.
Lastly, the opposite of premature organization is when it is clear that a certain part of the company is being under-managed: a single manager has a huge number of direct reports. Unless you’re going for a flat organization, this might indicate that you are suffering from a developmental disorder.
Either leadership doesn’t know how to delegate, cannot hire fast enough, or is afraid of changing structures. No matter which one it is for your managers, you should help them overcome these issues swiftly. Otherwise, matters will start crumbling, often at exactly the wrong time.
How many of these can you remember going through during the last time you onboarded a new employee and went over the org-chart? Get to fixing.
Get a sample chapter
Get the best newsletter for tech executives online, along with a free sample chapter of The Tech Executive Operating System 📖. Tailored for your daily work. Weekly, short, and packed with exclusive insights.