When I work on the organization design of an engineering organization, I think a lot about "organizational mathematics," the guideline that each team should have one manager and six to eight engineers, and each manager of managers should support four to six managers. From those numbers, you can rapidly determine an appropriate structure for your organization that'll work fairly well. It might not be perfect, but it'll work.

As I've applied that approach to designing multiple organizations, one of the recurring edge cases that have come up is deciding where the senior-most engineers should report. Should they, as the org math dictates, report to managers in the organizational leaf nodes? Or should they, as key leaders in your organization, report to more senior leaders to have better access to the information and authorization they need to excel in their role?

Before answering, it's worth describing the most common configurations you'll find in companies today, in particular how configurations vary across the Staff-plus archetypes:

• Tech Leads typically report to a manager responsible for one team. Less frequently, they'll report to a manager responsible for two to four teams. In both cases, they'll operate at the same scope as that manager. Examples: Dan Na reported to the manager for the Internationalization Platform.
• Architects typically report to a more senior manager, often a manager of managers. Often they'll be responsible for a horizontal-slice across that manager's area of responsibility, for example, data modeling. Examples: Keavy McMinn reported to the CTO.
• Solvers typically operate in companies that feature a "weak team concept," and often reporting hierarchies are less defined or deliberate in such companies. It is most common to see them reporting to a team manager, but you'll find a bit of everything. Another common pattern is collecting these folks into an "Office of the CTO" or "Office of the CEO" where they report to an executive who directs their work. Examples: Ritu Vincent is part of an incubator reporting to the CEO.
• Right Hands report into a senior leader, often managers responsible for a hundred or more folks, operating with that leader's authority. Examples: Rick Boone reported to the VP of Infrastructure; Michelle Bu reported to the Chief Product Officer.

Understanding how these different archetypes typically report differently into the organization helps decode some of the seeming arbitrariness of reporting structures.

Office of the CTO

An aside on the "Office of the CTO" concept, as many folks haven't encountered it in their work. Typically, the CTO, although sometimes a CEO will do something similar, will have two to eight Staff-plus engineers who report to them directly. These folks are treated as senior leaders in the sense of getting a problem or opportunity to pursue, very little management support, and the proximity to lean on the executive for support when necessary.

Within these offices, you'll find a mix of Architects, Solvers and Right Hands.

Typically the Office of the CTO comes relatively late in a company's evolution and is often introduced as a workaround to an existing organizational problem that is a challenge to address, for example, lack of trust between Staff-plus engineers and management teams, or an inability to delegate by the CTO. If you find yourself reaching for it early in a company's evolution, ask yourself if you're avoiding a problem you should be fixing instead of introducing this concept into your structure.

But in practice…

Based on the archetypes, there is usually a theoretically correct place for every engineer to fit into the organization, but you'll find that in practice, few organizations fully align their actual reporting structure with that theoretical structure.

Sometimes this is due to a lack of attention to organizational structure by your management team. In other cases, it's due to a lack of managerial bandwidth to support folks at the correct positions. For example, the "correct" manager is already managing a team of twelve and can't support another engineer effectively. Another common scenario is that the structure is shifting frequently enough that managers are reluctant to change the engineer's manager again, especially as manager-changes often lead to abstract, middle-of-the-road performance reviews.

If you find yourself reporting to someone who you believe is the wrong manager, it's a reasonable conversation to have with your manager, but it's worth acknowledging that many managers will react defensively to the implication that they're not the right manager for you. If your manager is mature and you have a strong relationship with them, go ahead and have the conversation. If not, it may be less risky to instead have a more abstract discussion with their skip-level about where Staff-plus engineers report in their organization.

Before you rush to advocate for change, ask yourself what you think would be different if your reporting structure changed. The reporting structure is a form of authority, and generally, folks over-estimate how authority will help them. The classic trap is, of course, that the folks who benefit the most from additional authority--minorities and women--are the folks whose managers are most likely to react defensively to the suggestion of the change.

How should it work?

If you're looking to design a proposal for your management team on how they ought to perform these sorts of organizational adjustments over time, a few things to consider. When possible, reporting changes should happen immediately. Delaying forces folks to navigate two transitions, including a particularly challenging intermediate environment between the previous and new roles. It's always lower risk to navigate a single role transition, even if it means agreeing to reduced manager support if your new manager is underwater with their workload.

If you can't make them immediately, always set a timeline for reporting to the correct manager after a role change. If you don't have a timeframe to clearly reopen the structure, it's relatively less likely to happen.

Most companies struggle to set up this sort of organizational infrastructure to fully support Staff-plus engineers as genuine leaders, so you should look at this as a problem you want to make progress on over years, rather than one that'll get fixed overnight. If you go into it expecting an immediate, permanent solution, you're likely in for some turbulence.