Where do Staff-plus engineers fit into the org?

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:

• Team Leads typically report into a manager responsible for one team. Less frequently they’ll report into a manager responsive for two to four teams. In both cases, they’ll operate at the same scope as that manager. Examples: Duretti Hirpa reported to the manager responsible for their transactional email product, Dan Na reported to the manager for the Internationalization Platform.
• Architects typically report into 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: Silvia Botros reported to the Chief Architect, 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 into 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 into 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 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.

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. 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 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.