Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Where do Staff-plus engineers fit into the org?
- Does the Staff title even matter?

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.

Does the Staff title even matter?

This is a draft guide for staffeng.com

If you’re safely nestled within the comfortable clutches of the Senior Engineer career level, you might wonder if you ought to pursue the Staff title. It’s a considerable investment of time and energy, along with requiring a good amount of luck, is that investment worth your time?

The answer is, of course, that it might be! The four consistent advantages that generally come with a Staff-plus title are:

1. allowing you to bypass informal gauges of seniority,
2. facilitating access to “the room,”
3. increase in current compensation,
4. Compounding increase in total career compensation.

The title also grants more agency onto the projects you work on, but some find that increase in agency is swallowed by a commensurate increase in accountability to the business.

Informal gauges of seniority

When I spoke with Nelson Elhage about whether reaching the Staff level allowed him to take on new work, he answered:

The question of “allowed” is interesting, and might not be quite the right question because there were very few official policies on who got what kind of role. Most things relied on more informal gauges of seniority.

Many technology companies describe themselves as pursuing meritocracy, creating the conditions for their most talented employees to rise to the top. We lack any widely accepted measure of merit, which leads most companies pursuing an equity of ideas to favor what Nelson aptly termed “informal gauges of seniority.” While these informal gauges are intended to create an equal playing field of ideas, the sheer informality of such gauges creates a vector for bias and often conflates confidence with competence.

The freedom from the cycle of re-establishing one’s competence came up frequently as a key advantage of the Staff title. Duretti Hirpa said,

“What’s something that’s changed for you since becoming a Staff-plus engineer? Honestly? Being listened to and being treated like I have expertise. The title carries weight, and I’m taken more seriously from the jump.”

Similarly, Keavy McMinn shared,

“When you have a title, you don’t have to spend so much energy putting your credentials on the table. It helps set the context for others. You’re more respected from the outset, and that’s been really noticeable.”

A Staff-plus title allows you to reinvest the energy you’ve previously spent on proving yourself into the core work you’re evaluated on. If you find that you’re not investing much energy into this, perhaps you’ve been at your current company long enough to prove yourself many times over, then you may not even notice the difference. If you do find your time diverted towards proving and reproving yourself, the title will return a considerable measure of time to you for reinvestment.

Being in the room

Another frequent advantage of a Staff-plus title is “being in the room.” Dan Na described this as,

“I have a seat at the table at higher level engineering discussions that occur at a level above individual projects and teams. We have recurring staff engineering meetings where we discuss problems that span teams which are both technical and non-technical in nature. As a hypothetical example, I'd feel comfortable surfacing what I perceive as shortcomings in the engineering onboarding process in this type of meeting.“

Silvia Botros called out performance calibration meetings as a particularly impactful moment to be in the room:

“Getting included in certain private email groups, being invited to performance calibration meetings, and so on. Calibration meetings are particularly important, because you can bring feedback that might not otherwise surface in a room of managers.”

For any important decision, there’s the time leading up to the core decision being made and then there’s everything afterwards. In more senior roles, you’re often in the right place to provide input while it’s relatively cheap to incorporate, where otherwise your feedback might not incorporated–despite being very valuable–because the related rollout or implementation has already begun.

Compensation

Small companies tend to have fairly ad-hoc compensation, and generally increases come from direct negotiation with your manager. A promotion to a Staff-plus role in such a company might not even come with a corresponding increase in your compensation. However, most companies introduce compensation bands for each role by the time they reach one to two hundred folks, and those compensation bands will generally ensure your compensation increases along with the role.

The highest paid roles at any company tend to be the executive and senior management roles, and as companies grow they typically create a compensation mapping between management and engineering roles, such that reaching Staff-plus roles–and sometimes this is Sr Staff or Distinguished roles rather than the initial Staff role–will significantly bump your compensation.

Even if your current company doesn’t compensate for Staff-plus engineer roles much differently than for Senior engineer roles, some companies do. Over the course of your career, you can choose to steer towards such companies, and doing with a Staff-plus title will meaningfully increase your lifetime earnings.

Access to interesting work

Many folks take on Staff-plus roles believing it will give them access to the most impactful or exciting work. That’s true to some extent, but it depends on the Staff archetypes which are most prevalent at your company. For example, Solvers often do get access to the most interesting work. Conversely, a Team Lead would probably be undermining their own team if they operated that way.

Among the folks I’ve spoken with, the most consistently effective way to get access to interesting work is being hired to do it, such as Ritu Vincent hired to launch Dropbox's product incubator and Keavy McMinn hired to design Fastly's API strategy.

Different rather than better

Even though the title does matter, it’s not necessarily the case that you ought to pursue the role. Even if you love the privileges and perks of a Staff-plus title, it’s important to recognize that they come on the back of a very different job. Michelle Bu captured this in her advice for folks pursuing the Staff title,

If you’re more focused on hitting Staff than on setting yourself up to do work that energizes you, it’s easy to end up stuck in a role you don’t want. Being a Staff-plus Engineer, especially a broad-scoped Staff-plus Engineer, is a very different job than being a Senior Engineer. It’s important to take a step back and think about whether it’s a job you really want.

The advantages of senior titles are real and for some folks those advantages shift their career from one characterized by survival to one with the necessary prerequisites for their success, but many other folks find that the expectations of their Staff role eliminate the work that excited them to begin with. In your career, there are few choices without consequences and this isn’t one of them.

Material but not magic

You'll occasionally meet an engineer who believes that attaining a certain title is the only thing standing between them and an important accomplishment or opportunity. Such folks might express frustrations such as, “If I just had the Staff title, I could decide the technology stack for our team.”

Increased organizational authority does allow you to solve problems in ways you previously couldn’t, but successfully retaining organizational authority in a well-managed organization requires a great deal of nuance and restraint. If you have a problem and believe that your title is the only thing holding you back, I want to reassure you that focusing on developing your approach and skills will be far more impactful than the title. The title will get you over the ledge once you’re close, but they’ll never do as much work as you’d expect.

The one consistent exception to this rule is that women and minorities often do find they spend significantly less time and energy proving themselves once they attain a Staff-plus title. The title doesn't unlock new abilities for them, but it does remove some of the weight they'd been carrying with them throughout their career.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!