tech culture

Things to know about engineering levels

mipsytipsy, , , , 11 Comments

This twitter thread seemed to strike a chord with people, rather astonishingly so. I am transcribing parts of it for the sake of longevity and findability.

I keep talking to engineers who are frustrated that they aren’t leveling up faster, aren’t reaching senior levels as quickly as other people they know, feel stuck and don’t know how to get to the next level, etc. And I’ve begun to notice a common blind spot around leveling —

✨ not every opportunity exists ✨
✨ at every company ✨
✨ at every time.✨

Sure, if you’re a junior engineer, you should be able to level up to intermediate pretty much anywhere. But it gets progressively trickier after that. Even the path from intermediate to senior can depend on a number of situational variables:

Is there oxygen?

  • How many other senior engineers do you work with? how many other intermediate engineers around your level? All of these people will be pulling from the same bin of work, looking for promo-worthy, solidly-senior projects.
  • Does your ladder explicitly call for mentorship or leading small teams of lower-leveled engineers? Are there enough of those folks to go around?
  • Have you sufficiently wrapped up your last project well enough to move on? Was it actually completed in a way that demonstrated clear mastery and readiness for bigger and harder work, ordid you leave a mess behind you? That may limit people’s appetite to take a risk on you with mission-critical projects.
  • What are the biggest needs of the business right now? Any process that generates projects ought to begin with this question before proceeding on to carve out a chunk that fits your promo desires, not the other way around. 🙃
  • Do you happen to work in a niche or specialty area of engineering, particularly one crammed with super-senior, world-famous highly leveled people? This can be fantastic when it comes to your ability to soak up knowledge from the world’s best, but it may simultaneously delay your ability to level up.

In short, is there oxygen at the next level? Does the company need more of the type of engineer you want to be, vs more of the type of engineer you are now? If they need more people pounding out code and fewer architects, they’re unlikely to want to promote you to a role that involves mostly architecture..

Literally no company can possibly make use of a top-heavy eng org stuffed with senior+ engineers, if all of them are expected to demonstrate company-wide impact or global impact every review period. There’s only so much high-level work to go around for every fifty engineers writing code and features and executing on those systems.

There is only so much oxygen at each level.

Inflation.

Of course, this is all assuming that your company takes leveling seriously. Most … really … don’t.

It’s tough. It’s tough to hold your ground when a valued engineer is complaining and dropping hints they may leave if they don’t get that promotion soon. It’s much easier to give in, make an exception, argue for rounding up.

This may sound good, but it is not ultimately in your best interests as that engineer. Seriously. </3

There is sooo much title inflation in this industry already. People are given the title “senior engineer” in just 3-5 years, need I say more??

If you let a little inflation into your system by making exceptions, it causes more trouble than it’s worth. Always. The only leverage you have when people try to get you to make exceptions is if you can honestly say, “no exceptions.” Give in just once, and your moral authority evaporates.

Leveling up.

I would urge you not to make most, if any, career decisions based on levels or titles that are offered you. But I do understand how frustrating and infuriating it can be to be in a situation that is clearly unfair (usually because a manager got pressured into making an exception… tsk tsk), or if you don’t understand how to move your career forward.

So, here are a few strategic tips for leveling up.

  1. Generalists level up faster than specialists.
  2. When evaluating roles, choose ones where your specialty is part of their mission, or at least key to its execution. It has a far lower likelihood of getting outsourced, deprioritized, lacking investment in, or just forgotten about if what you do is core to what they do.
  3. Always ask to see the job ladder when interviewing. If they hedge or fumble, don’t take that job.
  4. Talk to your manager about the job ladder. Talk to your skip level about levels too! Managers love this shit. They can talk on and on and on about levels, long past your exhaustion point. It can be annoying, but it’s actually a sign of a good manager who cares and thinks about the edge cases in processes, and their impacts on people and teams.
  5. That said, don’t take the ladder as a checklist to memorize or thing to be pored over and obsessed over. It’s an incomplete attempt at both shaping and reflecting relative impact. Focus on impact.
  6. Is it easier to level up as a manager than as an engineer? Sorta-kinda, I guess so? There are at least two real phenomena at play here.
    1. There are simply more roles to go around in the management track. You need like, what, 1-2 E7/E8 (or principal, or architect?) level engineers per 100-500 engineers, but several managers/directors/etc
    2. Manager effectiveness is grounded in their relationships. It takes managers longer to have impact after they start a new role, but their potential impact grows and grows as their tenure gets longer. So yes, there’s a bit more of an escalator effect if you stay on the manager track at a company for several years. There is no similar escalator on the eng side; you have to be truly exceptional or truly lucky.
    3. But it really depends on the organization.
  7. It is much easier to level up quickly at fast-growing companies. When there is far more work than workers, and everyone is getting dropped in the deep end to sink or swim, you level up fast. Don’t underestimate what a stressful and awful experience this can be, though.
  8. Many engineers get stuck on the bubble getting to senior because they are impatient and want a map. They just want someone to *tell them what to do*. Which is the very opposite of what a senior engineer does. 🙃  Develop your judgment around what needs to be done, and do it.
  9. Your relationship with your manager matters. So does your ability to communicate about the work you are doing, its difficulty, its unexpected challenges and triumphs, etc. This is called “managing up”, and it is an actual skill which I am *terrible* at. So are most of you. 😉
  10. TLDR, if leveling matters to you (and it should matter to everyone, to some extent!), then look curiously and critically around for opportunities, and seek to maximize them. Want to become an E6/E7? Probably don’t join a startup that doesn’t have any very high-level work to do, or already has more than enough people functioning at those levels and many more nipping their heels looking for the same opportunity.This sort of thing is very obvious to us with the manager track (if you want to go from M->Dir, don’t join a startup that already HAS directors and managers who want to level up), but seems less obvious with engineering.

Most reasonable, non-desperate companies with options won’t hire you directly into the next level up which you haven’t done before, on either the manager or the engineer track. (Yellow flag if they do.)

But it is perfectly reasonable to express your career objectives in the interview, and make sure you’re on the same wavelength and seeing the same opportunities. Do you want to become a manager or a tech lead in a few months? Say so.

If it doesn’t exist now, do they think this opportunity may soon open up? Can they see a path forward for you there, if all goes well? Would they be interested in helping you get there? How many people may already be eyeing that same path? Is there enough opportunity for more than one? On what timeframe? Who will decide who gets the role, and how?

Engineers tend to find these conversations uncomfortable, and so they tend to avoid them because they don’t want to make the hiring manager uncomfortable by being pushy.

Relax. Managers don’t find this uncomfortable at all, it’s their bread and butter. (And even fi they do find it uncomfortable, tough beans.. it’s their job.) Ask away. ☺️

Misc notes on leveling.

P.S. Engineers seem to have a very sparse mental model of how leveling works, so here are a few more notes on how levels work at Honeycomb, which is adapted from conventions at Facebook/Google.

  • Each level after senior engineer (E5 for us) gets approx an order of magnitude harder to achieve, and an order of magnitude fewer engineers hold that title.
  • E5 is considered a “terminal level”, which sounds scary, but just means “you do not have to advance beyond this level.” If you never get promoted again, you won’t get fired either.
  • Whereas if you do not advance from E3-> E4 within 2 years, and E4->E5 within 3 years, you are automatically put on a performance improvement plan (at Facebook, I mean, not Honeycomb).
  • We (Honeycomb) hire into E5 as our highest level to start at, both because a) our interview process is not designed to let us parse differences between senior vs super-senior or super-duper senior, and b) we figure nobody is really able to come in the door with >E5 impact for the first 6 months anyway. So we can level them up quickly after they join and we get a feel for their work.

<3 charity.

Things to know about engineering levels

Questionable Advice: Can Engineering Productivity Be Measured?

mipsytipsy, , , , , , 15 Comments

I follow you on Twitter and read your blog.  I particularly enjoy this post: https://charity.wtf/2019/05/01/friday-deploy-freezes-are-exactly-like-murdering-puppies/ I’m reaching out looking for some guidance.

I work as an engineering manager for a company whose non-technology leadership insists there has to be a way to measure the individual productivity of a software engineer. I have the opposite belief. I don’t believe you can measure the productivity of “professional” careers, or thought workers (ex: how do measure productivity of a doctor, lawyer, or chemist?).

For software engineering in particular, I feel that metrics can be gamed, don’t tell the whole story, or in some cases, are completely arbitrary. Do you measure individual developer productivity? If so, what do you measure, and why do you feel it’s valuable? If you don’t and share similar feelings as mine, how would you recommend I justify that position to non-technology leadership?

Thanks for your time.

Anonymous Engineering Manager

Dear Anon,

Once upon a time I had a job as a sysadmin, 100% remote, where all work was tracked using RT tasks. I soon realized that the owner didn’t have a lot of independent technical judgment, and his main barometer for the caliber of our contributions was the number of tasks we closed each day.

I became a ticket-closing machine. I’d snap up the quick and easy tasks within seconds. I’d pattern match and close in bulk when I found a solution for a group of tasks. I dove deep into the list of stale tickets looking for ones I could close as “did not respond” or “waiting for response”, especially once I realized there was no penalty for closing the same ticket over and over.

My boss worshiped me. I was bored as fuck. Sigh.

I guess what I’m trying to say is, I am fully in your camp. I don’t think you can measure the “productivity” of a creative professional by assigning metrics to their behaviors or process markers, and I think that attempting to derive or inflict such metrics can inflict a lot of damage.

In fact, I would say that to the extent you can reduce a job to a set of metrics, that job can be automated away. Metrics are for easy problems — discrete, self-contained, well-understood problems. The more challenging and novel a problem, the less reliable these metrics will be.

Your execs should fucking well know this: how would THEY like to be evaluated based on, like, how many emails they send in a day? Do they believe that would be good for the business? Or would they object that they are tasked with the holistic success of the org, and that their roles are too complex to reduce to a set of metrics without context?

This actually makes my blood boil. It is condescending as fuck for leadership to treat engineers like task-crunching interchangeable cogs. It reveals a deep misunderstanding of how sociotechnical systems are developed and sustained (plus authoritarian tendencies, and usually a big dollop of personal insecurity).

But what is the alternative?

In my experience, the “right” answer, i.e. the best way to run consistently high-performing teams, involves some combination of the following:

  • Outcome-based management that practices focusing on impact, plus
  • Team level health metrics, combined with
  • Engineering ladder and regular lightweight reviews, and
  • Managers who are well calibrated across the org, and encouraged to interrogate their own biases openly & with curiosity.

The right way to look at performance is at the team level. Individual engineers don’t own or maintain code; teams do. The team is the irreducible unit of ownership. So you need to incentivize people to think about work and spending their time cooperatively, optimizing for what is best for the team.

Some of the hardest and most impactful engineering work will be all but invisible on any set of individual metrics. You want people to trust that their manager will have their backs and value their contributions appropriately at review time, if they simply act in the team’s best interest. You do not want them to waste time gaming the metrics or courting personal political favor.

This is one of the reasons that managers need to be technical — so they can cultivate their own independent judgment, instead of basing reviews on hearsay. Because some resources (i.e. your budget for individual bonuses) are unfortunately zero-sum, and you are always going to rely on the good judgment of your engineering leaders when it comes to evaluating the relative impact of individual contributions.

“I would say that Joe’s contribution this quarter had greater impact than Jane’s. But is that really true? Jane did a LOT of mentoring and other “glue” work, which tends to be under-acknowledged as leadership work, so I just want to make sure I am evaluating this fairly … Does anyone else have a perspective on this? What might I be missing?” — a manager keeping themselves honest in calibrations

I do think every team should be tracking the 4 DORA metrics — time elapsed between merge and deploy, frequency of deploy, time to recover from outages, duration of outages — as well as how often someone is paged outside of business hours. These track pretty closely to engineering productivity and efficiency.

But leadership should do its best to be outcome oriented. The harder the problem, the more senior the contributor, the less business anyone has dictating the details of how or why. Make your agreements, then focus on impact.

This is harder on managers, for sure — it’s easier to count the hours someone spends at their desk or how many lines of code they commit than to develop a nuanced understanding of the quality and timbre of an engineer’s contributions to the product, team and the company over time. It is easier to micromanage the details than to negotiate a mutual understanding of what actually matters, commit to doing your part … and then step away, trusting them to fill in the gaps.

But we should expect this; it’s worth it. It is in those gaps where we feel trusted to act that we find joy and autonomy in our labor, where we do our best work as skilled artisans.

Questionable Advice: Can Engineering Productivity Be Measured?

Trolley Problems as a Service

mipsytipsy, , , , 6 Comments

Consider:

  • Is it ethical to discriminate in whom you will sell to as a business?  What would you do if you found out that the work you do every day was being used to target and kill migrants at the border? 
  • Is it ethical or defensible to pay two people doing the same job different salaries if they live in different locations and have a different cost of living?  What if paying everyone the same rate means you are outcompeted by those who peg salaries to local rates, because they can vastly out-hire you?
  • You’re at the crowded hotel bar after a company-sponsored event, and one of your most valued customers begins loudly venting opinions about minorities in tech that you find alarming and abhorrent.  What responsibility do you have, if any?  How should you react?
  • If we were close to running out of money in the hypothetical future, should we do layoffs or offer pay cuts?

It’s not getting any simpler to live in this world, is it?  💔

Ethical problems are hard.  Even the ones that seem straightforward on the face of them get stickier the closer you look at them.  There are more stakeholders, more caveats, more cautionary tales, more unintended consequences than you can generally see at face value. It’s like fractal hardness, and anyone who thinks it’s easy is fooling themselves.

We’ve been running an experiment at Honeycomb for the past 6 months, where we talk through hypothetical ethical questions like these once a month. Sometimes they are ripped from the headlines, sometimes they are whatever I can invent the night before. I try to send them around in advance. The entire company is invited.**

Honeycomb is not a democracy, nor do I think that would be an effective way to run a company, any more than I think we should design our SDKs by committee or give everyone an equal vote on design mocks.

But I do think that we have a responsibility to act in the best interests of our stakeholders, to the best of our abilities, and to represent our employees. And that means we need to know where the team stands.

That’s one reason. Another is that people make the worst possible decisions when they’re taken off guard, when they are in an unfamiliar situation (and often panicking). Talking through a bunch of nightmare scenarios is a way for us to exercise these decision-making muscles while the stakes are low. We all get to experience what it’s like to hear a problem, have a kneejerk reaction .. then peeling back the onion to reveal layer after layer of dismaying complexities that muddy our snap certainties.

Honeycomb is a pretty transparent company; we believe that companies are created every day by the people who show up to labor together, so those people have a right to know most things. But it’s not always possible or ethically desirable to share all the gritty details that factor into a decision. My hope is that these practice runs help amplify employees’ voices, help them understand the way we approach big decisions, and help everyone make better decisions — and trust each other’s decisions — when things move fast and times get hard.

(Plus, these ethical puzzles are astonishingly fun to work through together. I highly recommend you borrow this idea and try it out at your own company.)

cheers, and please let me know if you do try it ☺️

charity

** We used to limit attendance to the first 6 people to show up, to try and keep the discussion more authentic and less performative. We recently relaxed this rule since it doesn’t seem to matter, peacocking hasn’t really been an issue.

Trolley Problems as a Service

17 Reasons NOT To Be A Manager

mipsytipsy, , , , 40 Comments

Yesterday we had a super fun meetup here at Intercom in Dublin.  We split up into small discussion groups and talked about things related to managing teams and being a senior individual contributor (IC), and going back and forth throughout your career.

One interesting question that came up repeatedly was: “what are some reasons that someone might not want to be a manager?”

Fascinatingly, I heard it asked over the full range of tones from extremely positive (“what kind of nutter wouldn’t want to manage a team?!”) to extremely negative (“who would ever want to manage a team?!”).  So I said I would write a piece and list some reasons.

Point of order: I am going to focus on intrinsic reasons, not external ones.  There are lots of toxic orgs where you wouldn’t want to be a manager for many reasons — but that list is too long and overwhelming, and I would argue you probably don’t want to work there in ANY capacity.  Please assume the surroundings of a functional, healthy org (I know, I know — whopping assumption).

1. You love what you do.

Never underestimate this one, and never take it for granted.  If you look forward to work and even miss it on vacation; if you occasionally leave work whistling with delight and/or triumph; if your brain has figured out how to wring out regular doses of dopamine and serotonin while delivering ever-increasing value; if you look back with pride at what you have learned and built and achieved, if you regularly tap into your creative happy place … hell, your life is already better than 99.99% of all the humans who have ever labored and lived.  Don’t underestimate the magnitude of your achievement, and don’t assume it will always be there waiting for you to just pick it right back up again.

2. It is easy to get a new engineering job.  Really, really easy.

Getting your first gig as an engineer can be a challenge, but after that?  It is possibly easier for an experienced engineer to find a new job than anyone else on the planet. There is so much demand this skill set that we actually complain about how annoying it is being constantly recruited!  Amazing.

It is typically harder to find a new job as a manager.  If you think interview processes for engineers are terrible (and they are, honey), they are even weirder and less predictable (and more prone to implicit bias) for managers.  So much of manager hiring is about intangibles like “culture fit” and “do I like you” — things you can’t practice or study or know if you’ve answered correctly.  And soooo much of your skill set is inevitably bound up in navigating the personalities and bureaucracies of particular teams and a particular company.  A manager’s effectiveness is grounded in trust and relationships, which makes it much less transferrable than engineering skills.

3. There are fewer management jobs.

I am not claiming it is equally trivial for everyone to get a new job; it can be hard if you live in an out-of-the-way place, or have an unusual skill, etc.  But in almost every case, it becomes harder if you’re a manager.  Besides — given that the ratio of engineers to line managers is roughly 7 to one — there will be almost an order of magnitude fewer eng manager jobs than engineering jobs.

4. Manager jobs are the first to get cut.

Engineers (in theory) add value directly to the bottom line.  Management is, to be brutally frank, overhead.  Middle management is often the first to be cut during layoffs

Remember how I said that creation is the engineering superpower?  That’s a nicer way of saying that managers don’t directly create any value.  They may indirectly contribute to increased value over time — the good ones do — but only by working through other people as a force multiplier, mentor etc.  When times get tough, you don’t cut the people who build the product, you cut the ones whose value-added is contingent or harder to measure.

Another way this plays out is when companies are getting acquired.  As a baseline for acquihires, the acquiring company will estimate a value of $1 million per engineer, then deduct $500k for every other role being acquired.  Ouch.

5. Managers can’t really job hop.

Where it’s completely normal for an engineer to hop jobs every 1-3 years, a manager who does this will not get points for learning a wide range of skills, they’ll be seen as “probably difficult to work with”.  I have no data to support this, but I suspect the job tenure of a successful manager is at least 2-3x as long as that of a successful IC.  It takes a year or two just to gain the trust of everyone on your team and the adjacent teams, and to learn the personalities involved in navigating the organization.  At a large company, it may take a few times that long.  I was a manager at Facebook for 2.5 years and I still learned some critical new detail about managing teams there on a weekly basis.  Your value to the org really kicks in after a few years have gone by, once a significant part of the way things get done resides in your cranium.

6. Engineers can be little shits.

You know the type.  Sneering about how managers don’t do any “real work”, looking down on them for being “less technical”.  Basically everyone who utters the question “.. but how technical are they?” in that particular tone of voice is a shitbird.  Hilariously, we had a great conversation about whether a great manager needs to be technical or not — many people sheepishly admitted that the best managers they had ever had knew absolutely nothing about technology, and yet they gave managers coding interviews and expected them to be technical.  Why?  Mostly because the engineers wouldn’t respect them otherwise.

https://twitter.com/jetpack/status/1169685458340573184

7.  As a manager, you will need to have some hard conversations.  Really, really hard ones.

Do you shy away from confrontation?  Does it seriously stress you out to give people feedback they don’t want to hear?  Manager life may not be for you.  There hopefully won’t be too many of these moments, but when they do happen, they are likely to be of outsized importance.  Having a manager who avoids giving critical feedback can be  really damaging, because it deprives you of the information you need to make course corrections before the problem becomes really big and hard.

8.  A manager’s toolset is smaller than you think.

As an engineer, if you really feel strongly about something, you just go off and do it yourself.  As a manager, you have to lead through influence and persuasion and inspiring other people to do things.  It can be quite frustrating.  “But can’t I just tell people what to do?” you might be thinking.  And the answer is no.  Any time you have to tell someone what to do using your formal authority, you have failed in some way and your actual influence and power will decrease.  Formal authority is a blunt, fragile instrument.

9. You will get none of the credit, and all of the blame.

When something goes well, it’s your job to push all the credit off onto the people who did the work.  But if you failed to ship, or and, or hire, or whatever?  The responsibility is all on you, honey.

10.  Use your position as an IC to bring balance to the Force.

I LOVE working in orgs where ICs have power and use their voices.  I love having senior ICs around who model that, who walk around confidently assuming that their voice is wanted and needed in the decision-making process.  If your org is not like that, do you know who is best positioned to shift the balance of power back?  Senior ICs, with some behind-the-scenes support from managers.  For this reason, I am always a little sad when a vocal, powerful IC who models this behavior transitions to management.  If ALL of the ICs who act this way become managers, it sends a very dismaying message to the ranks — that you only speak up if you’re in the process of converting to management.

11.  Management is just a collection of skills, and you should be able to do all the fun ones as an IC.

Do you love mentoring?  Interviewing, constructing hiring loops, defining the career ladder?  Do you love technical leadership and teaching other people, or running meetings and running projects?  Any reasonably healthy org should encourage all senior ICs to participate and have leadership roles in these areas.  Management can be unbundled into a lot of different skills and roles, and the only ones that are necessarily confined to management are the shitty ones, like performance reviews and firing people.  I LOVE it when an engineer expresses the desire to start learning more management skills, and will happily brainstorm with them on next steps — get an intern? run team meetings?  there are so many things to choose from!  When I say that all engineers should try management at some point in their career, what I really mean is these are skills that every senior engineer should develop.  Or as Jill says:

12. Joy is much harder to come by.

That dopamine drip in your brain from fixing problems and learning things goes away, and it’s … real tough.  This is why I say you need to commit to a two year stint if you’re going to try management: that, plus it takes that long to start to get your feet under you and is hard on your team if they’re switching managers all the time.  It usually takes a year or two to rewire your brain to look for the longer timeline, less intense rewards you get from coaching other people to do great things.  For some of us, it never does kick in.  It’s genuinely hard to know whether you’ve done anything worth doing.

13. It will take up emotional space at the expense of your personal life.

When I was an IC, I would work late and then go out and see friends or meet up at the pub almost every night.  It was great for my dating life and social life in general.  As a manager, I feel like curling up in a fetal position and rolling home around 4 pm.  I’m an introvert, and while my capacity has increased a LOT over the past several years, I am still sapped every single day by the emotional needs of my team.

14. Your time doesn’t belong to you.

It’s hard to describe just how much your life becomes not your own.

15. Meetings.

16. If technical leadership is what your heart loves most, you should NOT be a manager.

If you are a strong tech lead and you convert to management, it is your job to begin slowly taking yourself out of the loop as tech lead and promoting others in your place.  Your technical skills will stop growing at the point that you switch careers, and will slowly decay after that.  Moreover, if you stay on as tech lead/manager you will slowly suck all the oxygen from the room.  It is your job to train up and hand over to your replacements and gradually step out of the way, period.

17. It will always be there for you later.

In conclusion

Given all this, why should ANYONE ever be a manager?  Shrug.  I don’t think there’s any one good or bad answer.  I used to think a bad answer would be “to gain power and influence” or “to route around shitty communication systems”, but in retrospect those were my reasons and I think things turned out fine.  It’s a complex calculation.  If you want to try it and the opportunity arises, try it!  Just commit to the full two year experiment, and pour yourself into learning it like you’re learning a new career — since, you know, you are.

But please do be honest with yourself.  One thing I hate is when someone wants to be a manager, and I ask why, and they rattle off a list of reasons they’ve heard that people SHOULD want to become managers (“to have a greater impact than I can with just myself, because I love helping other people learn and grow, etc”) but I am damn sure they are lying to themselves and/or me.

Introspection and self-knowledge are absolutely key to being a decent manager, and lord knows we need more of those.  So don’t kick off your grand experiment by lying to yourself, ok?

 

17 Reasons NOT To Be A Manager