June 28, 2020.
This is a draft guide for staffeng.com
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’s come up is deciding where the senior-most engineers should report. Should they, as the org math dictates, report into managers in the organizational leaf nodes? Or should they, as key leaders in your organization, report into 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 particularly how configurations vary across the Staff-plus archetypes:
Understanding how these different archetypes typically report differently into the organization helps decode some of the seeming arbitrariness of reporting structures.
An aside on the “Office of the CTO” concept, as many folks haven’t encountered it in the companies they work at. 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 work around to an existing organizational problem that is a challenge to address, so 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.
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. 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.
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 report into 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.