It’s the idea that somehow managers don’t contribute enough value “managing” so rather than “manage” they are more like “coaches” (mentoring, running the show) but they should also be “players” (doing individual work). It’s two delusions in one! The first: bad leaders that believe if the organization were correctly responding to their strategy that the friction of reaching alignment and operating the business would go to zero. Nonsense. The second: That a single person can both context switch all day long operating a team well by having the big picture in their head, and somehow also be in the weeds delivering “real value.” Nonsense, again.

That’s not how people work psychologically or physiologically. And if the counterpoint is “yes, but AI” then add a third thing to the list your leaders don’t understand.

It’s the same boring contempt for middle management that’s always been there from people who have managed to fail upward. 🥱 What’re the people asking for this actually doing? What’s their version of being a player?

1. I’d say most people struggle to get 30 minutes of true focus a day. The people who are good at focus usually have a 2 hour work block in the morning, a long break of true rest, and a 2 hour work block late afternoon.
2. Using the entire 4 hours, for 5 days in a row is exhausting- Saturday and Sunday will be staring at the wall.
3. If you “wear multiple hats” the time to come to speed for a task for role 1, do a thing, switch, come up to speed on role 2, all come from the same mental budget. You’re just doing two (or more jobs) poorly. Related: the human brain is not capable of deliberate multitasking no matter how much you might want to believe it is.
4. If you’re working below your optimal challenge level, yes, you can do more hours of “stuff.” Be honest though, you’re definitely not paying attention and engaged the entire time- that’s how cognitive economy works.
5. If you’re responding to Slack messages or email while focusing, you’re not actually focused.

Korn Ferry (the mega talent consultant company) identifies 38 general and unique competencies leaders and newbies alike all need to have in order to thrive. If you squint really hard you can reduce the list to maybe 35.

Technical interviews are designed to assess exactly 1 (one) of the 38. The other 37 dimensions are reduced to a combo of ✨vibes✨ and guessing based on side comments you make while programming something that has nothing to do with the role you’re being considered for. Take home problems? Also irrelevant for the other 37 dimensions.

It’s easier to change companies than get promoted because if you’re missing a key competency in an interview but they like you, you still get the job. If you’re already working there and missing a competency and nobody consciously knows that, knows how to coach it, or it’s not written down… you’ll just be held back for “reasons.”

I will also add that based on experience coaching & consulting this process I’ve heard “38 is way too many competencies” and yet if I choose any single one at random and say “if the employee had a material lack of this competency, regardless of what’s written down, would they still get promoted?” the answer is always “no.”

The idea that this isn’t completely insane persists because you get small companies with early employees that stick around. They accumulate social capital, backchannels, know the “real person” responsible for a thing on the far side of the company, etc and they manage to produce results where nobody else can. That’s because management/leadership has effectively failed and this person has accumulated enough systems and coping mechanisms to make up for it. Then you hire someone meant to do the same role and that person reasonably asks “What authority do I have to make sure these things happen?” -> “Well. None. You’re leading through ‘influence’.” Then very predictably they flounder for 18-24 months, ship nothing, and leave the company miserable.

I can tell you with certainty what happens when a person has the choice of doing what their manager says (The person who decides their performance and money) vs the person in their DMs asking very nicely.

It’s insidious because it effectively lets the people with the actual accountability (leadership) launder their responsibility away (executing the organization’s goals) on people who hold none of the systemic levers. If the ‘influencer’ fails, that’s an individual’s fault, not the system’s.

Firstly, all the ones like “be action oriented”, “do the right thing”, “the power of friendship” are all immediately tossed in the bin. A value must be able to be phrased as a trade-off in opposition to something that is reasonable. I’ve never once heard “actually, do nothing,” “let’s do the wrong thing”, or “fuck our coworkers.” At least in a remotely functional company. A good example is the Agile Manifesto. It gets this right by phrasing everything as “A over B.” As in “Individuals and interactions over processes and tools.” Process and tools are reasonable, but given the choice, we’d prefer to prioritize individuals and interactions.

Moving on.

There’s a framework from McKinsey called 7S that I really like. It basically says that a well-functioning company is 7 interrelated pieces that all mutually reinforce each other. 3 hard “S”s -> Strategy, Structure, Systems. 3 soft “S”s -> Staff, Skills, Style. And those 6 all orbit “Shared Values” to make the “7S”s.

The “basic business” case for all of these is mostly self-evident. Where it gets muddy is when you say that something is “valued” and that’s definitively false. So let’s look at a common case.

Example: “Documentation is valued so I don’t know why ours always sucks.” Let’s break it down.

Strategy: Do you strategically plan for it? Is it included in the definition of “Done?” Does it facilitate your planning in any way? Is there an expectation it should be available across the business to learn?

Structure: Does the managerial reporting line in the company have a section carved out for documentation? Are managers asked about the state of documentation at all?

Systems: Is there a singular, maintained place for documentation to live? Is there a process to add updates to it? Index maintenance? How do you find things?

Staff: Do you have a specific role for maintaining documentation? Do you hire around it?

Skills: Do you ask for writing technical writing snippets in the interview? Is it possible to receive a promotion without writing documentation? Do you have feedback groups on how to write better documentation?

Style: Do you have a style guide? What’s the way that your company writes things?

The answer to almost all of these is usually one of “We don’t have that”, “we don’t do that,” or just “no.” In this case documentation is definitionally not a value and it’s no surprise it sucks.

Your brain is electrified hamburger in a chemical soup. Neurotransmitter depletion and re-uptake rates are very real. Nothing available to us is going to change that. Calling back to my other post, you have 4 hours of focus in a day ASSUMING you’re eating well, exercising, and getting 8 hours of sleep. Even dyed-in-the-wool introverts need socializing time. Your best work is what happens when you’ve balanced all the messy “being a human” parts. Optimization is recognizing that balance and integrating it.

Is there a time and place for a maximal approach? Sure. Sometimes extraordinary situations call for it. Recognize the situation for the atypicality it is though. Telling people to sprint when you know it’s going to be marathon is magical thinking.

Passionate people are like resistors. They can generate a lot of heat. There’s a problem, they throw themselves at it, work is accomplished and you get some heat. If you start packing them together without a plan or organization, it will quickly turn into waste heat. The desire to stay busy resulting in the wrong things getting done. Long and intense arguments about what’s the right thing to be working on or what’s the right approach. Bike shedding [1] for instance, is almost always a problem of misdirected passions. Sometimes people are super passionate about “work” itself and will find ways to fill 12 hours at a time regardless if that makes sense (sometimes manufacturing busy work and sometimes it’s perfectionism). And the biggest of all: burnout.

Passionate people are exceptionally good at burning out. There’s usually two major ways this happens. The first, they just do so much work and generate so much heat they melt. We let this happen because work is “virtuous” and they produce “value” at their personal expense and nobody told them to stop. It’s not sustainable. Startups thrive on this misunderstanding. The second, and more pernicious, is value misalignment or “moral distress.” That passion has to come from somewhere. For intrinsically motivated people it’s because the work appeals to their internal value system. You got them onboard, they love the mission, everything is rosy… and then the company does something to demonstrate that the company values don’t line up with their personal values. An easy example: the company said “we value technical craftsmanship” and then a feature was going to take an extra few week or two to be done well and management said “unacceptable, this has to be out Tuesday.” This kind of system shock results in an immediate “wait, why am I putting this kind of energy in? Turns out this is Just Another Company that doesn’t care.” Your highest performers can be disillusioned in the span of an afternoon. When people believe they’re working outside of their value system, or they’ve been lied to, even small tasks suddenly require almost all their capacity. Once this happens and you expect them to perform at their previous level, without fixing the underlying mismatch, it’s just a matter of time until they leave or collapse.

[1] Arguing about what color to paint the bike shed. You’ve already agreed on the useful thing to be done (build the shed), now you’re just arguing about what color to paint it.

What is it really for?

The biggest source of disagreement, to me, is what the point of something like a Hackweek even ought to be. Is it for innovation? Is it a stay-cation for developers? Is it team building? Is it a political maneuvering tool to free up developer time for project managers that want to experiment?

Honestly, in the absence of someone at the top saying “The reason we do this is for X,” the answer is it’s probably all of them—and it does all of them poorly.

Is it worth it?

So is it worth it if it does a bunch of things poorly? I think the only circumstance in which it’s worth it is it you have a shared value of “innovation for innovation’s sake,” and vanishingly few companies actually believe this. I’ll come back to this later.

If you’re doing it as a pseudo-staycation as in “recharge time to do something fun and exciting” you’d be better off having a mandatory minimum vacation policy. Hacking is fun, but it’s not rest. I can’t shout this point loudly enough: projects you work on or projects your employer gives you are both projects and are work. It’s good for people to take time off and not think about work. Only rest is rest.¹

If it’s supposed to be team building it’s only going to work for smaller companies and even then it’s not really worth it. The larger the corporate structure, the more the composition of hackweek teams will mimic the larger organization. People naturally gravitate to starting mini projects with people they know and trust- and that means the people they interact with on a daily basis. You can fight this with better organization and up-front planning but then it starts looking like any other company project and you start asking… “why though?” If the goal is to get folks to meet people outside of their bubble then cheaper more intentional options abound.

The fun one: what if it’s a political maneuvering tool? I have definitely seen this one and I have no special advice. In all likelihood you have a leadership vacuum and people are looking for ways to operate outside the system to get things done. Rebranding “Hackweek” as “Fix it week” is the technical version of this. Teams can’t get the headroom to budget time to address technical debt so what if we just, y’know, block off just one week so we can all focus on that stuff.

Innovation and the lens of “value”

So what if it’s about “innovation?”

If the key requirement behind the innovation is that it has “value” then Hackweek makes the least sense. You’re already part of a company- likely a legal entity with shareholders in furtherance of a mission statement to maximize value. Assuming that the leadership is executing their fiduciary responsibility, then your day job is already the greatest maximization of this goal.² So, really it’s about “what if there’s something related to our core mission we just aren’t seeing?” If that’s the case you would be better off with something like Google’s (often mythical)³ “20% time.” Building the overhead into the calendar all year long provides better flexibility, allows people time to think and plan, and lets groups form and reform as they want. As a system it’s also much more tolerant of surprise when things need to change. If someone needs to abandon it one week for “reasons” they know they’ll have it the following week or even double it up. It also provides breathing room for plans to change in response to new information.

So, at last, we come to the possibility you believe in “innovation for innovation’s sake.” Every once in a while you believe that people should just experiment. The differentiator here is that projects don’t need to have a connection to “value.” Just stretching what’s possible. Maybe the project is seeing which cereals in the micro kitchen combine well together and making a chart. Who knows. If this is true, then Hackweek might actually make sense. Just turn everyone loose and see what happens! The bigger point I want to underscore here is if you believe:

• experimentation time is “earned” and a “privilege”
• should always be value-focused
• is a “as long as everything is working well with no competing interests”
• at management’s discretion

Your company doesn’t actually believe this. You would almost certainly be better off doing something else.

Footnotes

I’ve been using Rust on-again-off-again for several years now. I’m not ashamed to say that a lot of my Rust journey has mirrored my early C++ journey… I just add sigils (or take them away) until the compiler stops complaining. I also read The Rust Book but, again, to be honest, I usually do a very surface reading until I think I’ve figured out how to solve an immediate problem. But I’ve got some time finally and I’m going back through and updating/cleaning my mental model for how things work. Hopefully someone else well find this useful too.

When I’m learning a new language I generally think of two specific patterns I want to know. “How do I make a concrete implementation of an action and then pass that to something else” (Strategy) and “How do I make a concrete implementation of a thing when I don’t know what I need up-front?” (Factory).

Strategy

use std::cell::RefCell;


pub trait Strategy {
    fn do_something(&self);
}

struct TypeA {}
struct TypeB {}
struct TypeC {
    internal: RefCell<i32>
}

impl Strategy for TypeA {
    fn do_something(&self) {
        println!("A doing a thing");
    }
}

impl Strategy for TypeB {
    fn do_something(&self) {
        println!("B doing a thing");
    }
}

impl Strategy for TypeC {
    fn do_something(&self) {
        // "Internal mutability"
        // Allows a change behind a &self reference
        // without needing to change API to &mut self.
        let mut underlying_value = self.internal.borrow_mut();
        println!("C doing a thing {}", *underlying_value);
        (*underlying_value) += 1;
    }
}

// The Generic version uses monomorphism to do everything
// at compile time.
struct Executor<T:Strategy> {
    strategy: T
}

impl <T:Strategy> Executor<T> {
    fn new(input: T) -> Self {
        Executor { strategy: input }
    }

    fn execute(&self) {
        self.strategy.do_something();
    }
}

// The dyn version uses vtables and does everything
// at runtime.
struct ExecutorWithDyn<'a> {
    strategy: &'a dyn Strategy
}

impl <'a> ExecutorWithDyn<'a> {
    fn new(input: &'a impl Strategy) -> Self {
        ExecutorWithDyn { strategy: input }
    }

    fn execute(&self) {
        self.strategy.do_something();
        // This also works
        // let e = &self.strategy;
        // (*e).do_something();
    }
}

fn main() {
    let a = TypeA {};
    let b = TypeB {};
    let c = TypeC {internal: RefCell::new(0)};

    let e = Executor::new(a);
    e.execute();

    let e1 = ExecutorWithDyn::new(&b);
    e1.execute();

    let e2 = ExecutorWithDyn::new(&c);
    e2.execute();
    e2.execute();
    e2.execute();
    e2.execute();
}

Factory

struct Factory {}

pub trait SomeImpl {
    fn do_a_thing(&mut self);
}

struct TypeA {}
impl SomeImpl for TypeA {
    fn do_a_thing(&mut self) {
        println!("Type A did a thing");
    }
}

impl Default for TypeA {
    fn default() -> Self {
        Self {  }
    }
}

struct TypeB {}
impl SomeImpl for TypeB {
    fn do_a_thing(&mut self) {
        println!("Type B did a thing");
    }
}

impl Default for TypeB {
    fn default() -> Self {
        Self {  }
    }
}

impl Factory {
    pub fn build(&self, input: i32) -> Box<dyn SomeImpl> {
        if input % 2 == 0 {
            return Box::new(TypeA{});
        } else {
            return Box::new(TypeB{});
        }
    }

    pub fn build_generics<T:SomeImpl+Default>(&self) -> Box<T> {
        return Box::new(T::default())
    }
}
fn main() {
    println!("Factory");

    let f = Factory{};
    let mut r = f.build(3);
    r.do_a_thing();

    // It's cool this works, but again, you have to
    // know it at compile time.
    let mut r1 = f.build_generics::<TypeA>();
    r1.do_a_thing();
}

Regardless of perception, (almost) nobody has an effective Staff+ program (yet).

What you should read before

What do Staff engineers actually do?

The Archetypes

Who am I?

For my day job I’m definitively in the right-hand category. Think of me as an “Office of the CTO”-type and working alongside the People team at a Fortune 500 in an engineering department in the neighborhood of 900 people. I’m not a manager in that people don’t directly report to me, but my job is entirely about engineering culture, leadership competencies, internal community, and the like. My primary focus is on our internal Staff+ community and making sure they’re set up for success. I’m also a career engineer with the right technical chops but it turns out organizational trouble is where I find the most leverage.

What do I mean by “program”?

I use “program” to refer to the holistic view of all the components of the employee lifecycle. It’s onboarding when folks join the organization, it’s the ongoing conversations to make sure people are engaged, it’s the deliberate spaces folks can go to when things aren’t working out well.

Who I talk to

I’ve been working with internal colleagues alongside my friends and contacts in industry to better understand the current state of the world. All in all, I’ve interviewed about 60¹ folks at this point with the following 30-minute interview:

1. What’s your experience been so far here? Has the shape of your current job matched your expectations?
2. Have you seen, at your current company or anywhere, a particularly effective Staff+/senior IC program?
3. What would you like to see from such a program?
4. What problems have you run into that are particularly important to you?

And some context notes:

• Mean years of experience of the interviewees: 18 years.
• Combined years of experience: 1,080 years.

The results of the second question (have you seen an effective program?) have given me pause. There were essentially only two answers²: “No” and “Yes, Amazon… but I hated the culture and left anyway.” Given the range of places folks have worked, from BigCo to SmallCo to startup, nobody, other than Amazon apparently, really understands what to do with an engineer with 15+ years of experience that also doesn’t want to manage.

What the symptoms of dysfunction look like

So if we ask people directly if their IC program is effective and they say no, what does that look like and how does it manifest? Here’s a collection of signals I’ve put together from feedback and first-hand observation to let you know that your company probably has some organizational development to work on.

Managers hiring senior folks to be “self-directed” when they actually mean “unsupported”

• Usually seen at: All companies.
• Missing: internal support.

A very common discussion I hear goes something like this: “We’re drowning. Headcount finally opened and we can hire for the team. Junior folks take too long to come up to speed. Let’s just hire someone senior that can be very self-directed.”

If a hire is made you can’t name the people who are accountable for that person thriving you can safely swap “self-directed” with “unsupported.” Healthy self-direction is about autonomy with support.

At larger companies, say 150+ engineers, it’s also a false dichotomy that junior folks need more time than senior ones. The key difference is where they spend their time ramping up. Sure, you’ll need to give junior folks time to wrap their minds around technical things, which might take a few months… but staff folks with leadership expectations typically need much longer to ramp up. Especially if they lead via influence (See “Lead with influence” below).

A related phenomenon is hiring/promoting managers saying “Don’t ask me what to work on. You should be telling me what’s most important.” Firstly, an external hire has no idea how your organization works. You absolutely need to give hints and help a new person come up to speed and find all the ways to figure out what is important. And secondly, someone trying to move up the ranks almost certainly doesn’t have all the necessary context to judge what is “most important” according to the business needs, especially if their primary network is entirely within engineering.

Exploration Prompts

• What does your onboarding process look like?
• Do you have structured feedback? How often does it happen?
• What’s the 30/60/90-day plan for a person stepping into the role?
• Will a new hire have the right support to thrive in a reasonable time frame?

“Lead with influence”

• Usually seen at: All companies.
• Missing: internal support.

This one is pernicious because leadership is largely about influence but it’s also usually said by managers who hold structural authority in the company. The reporting lines of the company naturally align with manager positions. Managers have a monopoly on power. If managers were disempowered to write performance reviews, decide compensation, or even their team makeup they would probably feel pretty trapped. And yet this is often the circumstance non-managerial leaders are expected to work from. If some random person has to choose between doing what some Staff+ person knows would be better for the technical health of the company vs the person who writes their performance review (and thus decides their pay) I can tell you who’s going to win. “You should be able to influence people to make choices that go against their self-interest” is an absurd position- but I’ve heard it.

Coming at it from a second angle, if someone needs to “cultivate influence” then onboarding and “becoming effective” is going to take 18-24 months while they prove themselves to colleagues. It’s a combination of unsustainable, expensive, and wildly disrespectful to folks’ time and experience.

Exploration Prompts

• How do you support folks coming in?
• What systems support non-managers from getting their work done?
• Are you comfortable hiring external leaders?

Micromanaging the leadership

• Usually seen at: All companies.
• Missing: leadership competencies, role clarity.

Ostensibly you’ve hired some very senior ICs to be leaders in the organization. While nobody wants to be micromanaged, it’s especially true for people you hired expecting them to be leaders. Sometimes it’s because very hands-on founders have to step away and the loss of control leads to micromanaging engineering’s schedule and sometimes it’s just because people are control freaks. Whatever the particular cause it always creates dysfunction.

The folks in charge seldom think things are moving fast enough… but the size of your organization is going to impose kinetic limits. Certain things are just going to be slow and nothing you can do will change that because organizations are made of people. One of the most effective leaders I’ve ever worked with (literally managing thousands of people) told me once “the hardest part about my job is that it’s going to take at least six months to know if we’re even on the right track.”

Install feedback loops to see the progress, but put them at a granularity that makes sense. Check-in on goals on a recurring cadence and resist the urge to ask for out-of-band updates.

Exploration Prompts

• What do you expect your leaders to be able to do?
• What do you think of as leadership competencies in non-managers?
• What are you doing to ensure space for leaders and experts to be both leaders and experts?
• Do your goals have reasonable time frames?

“Everyone should be coding”

• Usually seen at: All companies.
• Missing: leadership competencies, role clarity.

Every once in a while I read a hot take about how “all managers should also be working” suggesting that management is, somehow, not real work. All my seasoned manager friends then have a hearty chuckle about how nonsensical that is and get on with their day. The junior managers though often take pause because they’re still internalizing that message. It’s a difficult jump for most new managers to accept that “management is real work.”

So here’s the tough pill for a lot of new staff+ non-managers to swallow: all the non-coding you do is now the real work. Editing other folks’ designs, mentoring, planning meetings, coordination- All of it adds up to a full-time job very quickly. Further, if the job is expected to have “scope & impact” there’s almost certainly no way to deliver on that via code, and even if there was, you would be having a greater impact by teaching other people how to do it.

This problem is particularly thorny because it calls into question personal identity. Am I still an engineer if I’m not coding every day? It’s very easy to justify the position that everyone should be coding and “as hands-on as possible” because it’s what you personally want to be doing. I do get it… but it’s also just not your point of greatest leverage anymore. The first counterargument is often “but won’t our high-level ICs lose touch and start designing things they don’t feel the pain or accountability for?” To which I say: if they are the ones writing the design you’ve already lost- they should be editing and curating the design of the folks with that accountability to grow them. It’s about teaching the next generation what to consider and how to think about the problem- not telling them what to do or how to do it.

Exploration Prompts

• Do you understand what your non-manager leadership competencies are?
• What do you expect staff+ folks to spend their days doing?
• When do you know that coding is no longer the right tool for the job?

You hired brilliant people to change the way you do things… and everything is exactly the same.

• Usually seen at: All companies.
• Missing: change management, role expectations, support, leadership buy-in.

Here’s a pretty typical story:

At last, you’ve managed to hire the great soul that scaled company X to the cloud. Her expertise in a particular area you have great needs around is unparalleled… And then she quits after two years of a mostly-fruitless journey. She has made some appreciable impacts but not the key strategic ones she was meant to.

Any time you hire a great leader and they don’t deliver the magical result you expected and leave burned out, it’s basically always the organization’s fault. Sometimes it’s a lack of maturity in organizational change management and sometimes it’s a combination of the other failure states (especially “Leading with influence”).

Exploration Prompts

• What are you doing to empower your experts to make a change?
• Is your organization actually willing/open to change?
• Do you have a change management strategy for making things sticky?
• Why do you believe you need an external person to achieve the desired change?

All men

• Usually seen at: All companies.
• Missing: shared values.

Still shockingly common. In my experience, this is almost always a mismatch with the company’s values. The things you care about have to be actively reflected in what you do every single day. No exceptions. You can honestly and sincerely say you care about diversity & inclusion (and mean it!) but if you aren’t cultivating it as a leadership competency, connecting it to performance, and making it the air you breathe it just isn’t going to change.

Exploration Prompts

• Do you actually believe in Diversity & Inclusion as core tenents?
• Are your “core values” your actual values?
• What are you doing to make people feel like they belong?
• How do you institute real change?
• Do you know how to holistically include Diversity & Inclusion into your organizational practices?
• When was the last time a [category of person] was promoted in Engineering?³

The only engineer you have is a de facto principal/CTO

• Usually seen at: Small companies.
• Missing: role clarity.

This is essentially only possible in very small companies. The summary is easy: the most senior person you have is not a de facto leader/principal.

Levels are tools to talk about career stages and expectation setting for particular roles. If the most senior person you have is 3 years into their journey they probably aren’t a post-career-level expert. One day, if your small company is successful, you’re going to need to introduce levels and you’re going to have a very awkward conversation- especially if you start hiring other folks that do have the experience.

If you do want to hire particularly senior folks at a very early stage, go for it, but have a growth plan. Plenty of small companies have tried to hire a very senior staff only to have it turn into a bitter battleground because nobody knew who was going to get to be the VP of Engineering or the CTO.

Exploration Prompts

• Do you understand how your current staff capability compares to industry norms?
• What do you expect from principal engineers?
• If you double in size do you know how that’s going to affect your people?

Recruiters writing “we’re looking for a senior, staff, or principal” for a single role along with a list of technologies.

• Usually seen at: startups, small companies.
• Missing: role clarity.

This is essentially “we just need people.” As a former startup founder, I can empathize. It’s just too wide of a net and there’s likely no internal definition of what these titles mean. Luring people in with whatever title resonates with them is certainly a strategy but it’s not setting people up for success.

Exploration Prompts

• What is the job description for the person you’re looking to hire?
• Does it make sense to advertise this role to a range as broad as 3ish-to-20ish years of experience?
• Do you have a plan for when you’re larger and you’ve only hired seniors/principals?

“We know we don’t want architects, but…”

• Usually seen at: Small-to-Medium companies.
• Missing: role clarity, career ladder, shared values.

This is a rapidly-growing company trap. At some point organizations that are used to being very flat come up against the point where social forces alone stop holding everything together. I don’t have hard evidence on this, but anecdotally I believe it’s around ~150 people. At some point thinking about architecture and communicating it is going to be a full-time job for at least one person. You don’t need a blessed council of approvers, but you do need accountability for making sure it gets done and all the organizational levers for them to succeed.

Exploration Prompts

• How do you decide who is going to be accountable for the technical health of the organization?
• How much time do folks spend “thrashing” on trying to reach consensus or decide things?

Custom leveling system

• Usually seen at: Small-to-Medium companies.
• Missing: role clarity.

A growing company wants to introduce a sense of a career ladder so folks can see what the next steps look like. Instead of hiring one of the key HR firms or someone with expertise in ladder design to explain the how’s and why’s, your engineers come up with their own leveling scheme with custom rungs from “first principles.”

Every single instance of this I’ve seen has been nothing short of an unmitigated disaster.

In one case, a rapidly growing startup of about 150 predominantly senior people decided to introduce levels via a quota system. The idea was only 1 in 10 engineers could be “senior” and only 1 in 10 of the “seniors” could be “staff.” It was essentially determining title by stack ranking people behind closed doors. Attrition was through the roof and A Lot(tm) of very good folks left (for good reason).

There are very good and valid reasons that nearly every company listed on levels.fyi looks almost identical. If you’re going to customize the levels and “meaning” behind them proceed with extreme caution.

Exploration Prompts

• How do you believe you’re going to do better than the experts here? (Sorry, you really just need to have experts do this.)

Folks aren’t thriving / under-utilized & under-stretched.

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, support.

You’ve hired a ton of great people… and they’re bored. If you hire someone accustomed to a very broad scope & impact in their previous role, and you hire them specifically based on that experience, and then don’t provide that immediately you’ve essentially bait & switched your new hire. If an individual is expected to “lead through influence,” and you don’t offer shortcuts to acquire that influence, don’t be surprised when senior folks show low engagement. Similarly, if someone is used to leading very complex efforts and they’re suddenly in charge of a single, small service they’re probably dissatisfied.

Exploration Prompts

• Do you check in with folks after they’re hired to see if the job matched their expectations?
• Are folks challenged? Are they engaged?
• Can you articulate what “optimal challenge” looks like for your folks?

“Staff+ is a qualitatively different role”… but that’s clearly not true.

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, support.

This one is more of a trap for internal promotions. Sometimes companies, big and small alike, create a step in their ladder/thinking that says “at a certain point, the career ladder rungs are qualitatively different” usually with a bias toward leadership. There’s even a cute quip that goes “senior engineers work in Docs, staff engineers work in Sheets, and principals work in Slides” to suggest how it changes as you rise. Your people have to justify not only that they have the scope, impact, technical chops, and whatever else, but also have to prove that they fundamentally “get” that the next level is “different.” Then they get promoted… and nothing changes. They’re still doing the exact same thing. They look around and it turns out everyone else who was also promoted is also still doing whatever it was they were before. If you use Radford style numbers where a senior engineer is 4 and a staff engineer is 5, the staff role ends up looking more like 4+1.

Exploration Prompts

• What changes when someone is promoted? If they were already “performing at level” does that mean their peers are doing something different?
• How do you communicate the change in expectations?
• Do new mechanisms of organizational support become available?

No language to discuss specialization

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity, career ladder.

It turns out there are many different ways to practice non-managerial leadership and all of them are important to the long-term health of an organization. If you have more than a handful of services or engineering teams you really need a consistent approach to architecture if you plan to enjoy any economy of scale. It’s also likely the person or people doing architecture are also likely different from, say, PhDs specialized in machine learning.

Exploration Prompts

• Do you have a way to capture the difference between the breadth of the architect and the depth of the specialist? What about the engineers that focus on the organization itself?
• What does your career ladder look like?

A high percent (20%+) of engineering is Staff+

• Usually seen at: Medium-to-Large companies.
• Missing: role clarity.

This is also connected to level inflation. Healthy organizations tend to be shaped like a triangle or a diamond.

• Triangle: few people at the top building a wider-and-wider base of more junior folks to level them up.
• Diamond: A few at the top, and a few at the bottom, with a very healthy middle band.

If 1/5 of your entire organization is “post-career leadership” you’re setting up a very unsustainable situation. It’s usually a vicious cycle of “we can’t hire junior folks because we don’t have the bandwidth, so hire senior folks” except all that specialist knowledge they don’t know how to pass on… continues being specialist knowledge and is now also compounding over time. Top heaviness is a self-reinforcing problem.

Exploration Prompts

• Do we need this many leaders?
• Are we adequately challenging our people?
• Are you hiring enough junior folks for your leaders to actually lead?

What you can do about it / Organizational Development

If reading through the failure states was uncomfortable I have at least some good news. Your company is 100% not special in this regard. There are off-the-shelf solutions: hire a good People/HR team and make sure they have partners within engineering.

If we classified the failure states into buckets you’d be left with something like this:

• Lack of shared values. This is always the biggest issue. Does the organization articulate what it actually believes is valuable?
• Lack of role clarity. What is it you expect people to do? How do you know they’re doing it? Why do you want them to do it?
• Lack of support. What do folks need to do their jobs? Are they getting it?
• Lack of leadership buy-in. Does leadership believe that the role and “the clarity of what that role should be doing” are useful?
• Lack of leadership development. Does leadership know how to think about the problem space? (Startup founders, take particular note here). Does leadership know how to think of their own development?
• Lack of change management. Do you know how to introduce change in a way that makes it stick?
• Lack of learning & development. Are you investing in your folks’ career development? Do your managers know how to further and develop their reports?

This is all Organizational Development work. It’s important and necessary because as nice as “hire smart people and get out of their way” sounds, it’s just not how it works.

Returning to “Yes, Amazon.” I’ve never worked there and it’s large enough I’m sure these don’t universally apply, but plenty of folks I’ve talked to did and what they said could be summarized:

• Expectations on the role were well-documented and supported.
• You had same-level⁴ managerial leadership support to execute on the job.
• You had well-established institutional rails to succeed.
• The criteria you were judged against largely made sense.

If I were to generalize this into advice it would be: take organizational development seriously.

Thanks!

I would also like to give a special thanks to the folks that helped me with edits and feedback.

• Samantha Branham @glompix
• Marc Hedlund @marcprecipice
• Tim Kordas @timothyzillion
• Ryan Burkhardt @ryanburk
• Steve Conover @sconover

Footnotes