Software deploys and cognitive biases

There exist some wonderful teams out there who have valid, well thought through, legitimate reasons for enforcing “NO FRIDAY DEPLOYS” week in and week out, for not hooking CI/CD up to autodeploy, and for not shipping one person’s changes at a time.

And then there are the reasons most people have.

Bad decisions, and the biases they came from

 

We’re humans. 💜  We leap to conclusions with the wetware we have doing the best it can based on heuristics that feel objectively true, but are ultimately just emotional reactions based on past lived experience. And then we retroactively enshrine those goofy gut feelings with the language of noble motive and moral values.

“I tell people not to deploy to production … because I care so deeply about my team and their ability to have a quiet weekend.”

Barf. 🙄  That’s just like saying you tell your kid not to brush his teeth at night, because you care SO DEEPLY about him and his ability to go to bed calm and happy.

Once the retcon engine in your brain gets running, it comes up with all sorts of reasons. Plausible-sounding reasons! But every single argument of the items in the list above is materially false.

Deploy myths are never going away for good; they appeal to too many of our cognitive biases. But what if there was one simple thing you could do that would invert many of these cognitive biases and cause people to grapple with the question in a new way? What if you could kickstart a recalculation?

My next post will pick up right here. I’ll tell you all about the One Simple Trick you can do to fix your deploys and set you on the virtuous path of high-performing teams.

Til then, here’s what I’ve previously written on the topic.

 

Footnotes

 

Availability bias: The tendency to overestimate the likelihood of events with greater “availability” in memory, which can be influenced by how recent the memories are or how unusual or emotionally charged they may be.

Continued influence effect: The tendency to believe previously learned misinformation even after it has been corrected. Misinformation can still influence inferences one generates after a correction has occurred.

Conservatism bias: The tendency to revise one’s belief insufficiently when presented with new evidence.

Default effect: When given a choice between several options, the tendency to favor the default one.

Dread aversion: Just as losses yield double the emotional impact of gains, dread yields double the emotional impact of savouring

False-uniqueness bias: The tendency of people to see their projects and themselves as more singular than they actually are.

Functional fixedness: Limits a person to using an object only in the way it is traditionally used

Hyperbolic discounting: Discounting is the tendency for people to have a stronger preference for more immediate payoffs relative to later payoffs. Hyperbolic discounting leads to choices that are inconsistent over time – people make choices today that their future selves would prefer not to have made, despite using the same reasoning

IKEA effect: The tendency for people to place a disproportionately high value on objects that they partially assembled themselves, such as furniture from IKEA, regardless of the quality of the end product

Illusory truth effect: A tendency to believe that a statement is true if it is easier to process, or if it has been stated multiple times, regardless of its actual veracity.

Irrational escalation: The phenomenon where people justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting that the decision was probably wrong. Also known as the sunk cost fallacy

Law of the instrument: An over-reliance on a familiar tool or methods, ignoring or under-valuing alternative approaches. “If all you have is a hammer, everything looks like a nail”

Mere exposure effect: The tendency to express undue liking for things merely because of familiarity with them

Negativity bias: Psychological phenomenon by which humans have a greater recall of unpleasant memories compared with positive memories

Non-adaptive choice switching: After experiencing a bad outcome with a decision problem, the tendency to avoid the choice previously made when faced with the same decision problem again, even though the choice was optimal

Omission bias: The tendency to judge harmful actions (commissions) as worse, or less moral, than equally harmful inactions (omissions).

Ostrich effect: Ignoring an obvious (negative) situation

Plan continuation bias: Failure to recognize that the original plan of action is no longer appropriate for a changing situation or for a situation that is different than anticipated

Prevention bias: When investing money to protect against risks, decision makers perceive that a dollar spent on prevention buys more security than a dollar spent on timely detection and response, even when investing in either option is equally effective

Pseudocertainty effect: The tendency to make risk-averse choices if the expected outcome is positive, but make risk-seeking choices to avoid negative outcomes

Salience bias: The tendency to focus on items that are more prominent or emotionally striking and ignore those that are unremarkable, even though this difference is often irrelevant by objective standards

Selective perception bias: The tendency for expectations to affect perception

Status-quo bias: If no special action is taken, the default action that will happen is that the code will go live. You will need an especially compelling reason to override this bias and manually stop the code from going live, as it would by default.

Slow-motion bias: We feel certain that we are more careful and less risky when we slow down. This is precisely the opposite of the real world risk factors for shipping software. Slow is dangerous for software; speed is safety. The more frequently you ship code, the smaller the diffs you ship, the less dangerous each one actually becomes. This is the most powerful and difficult to overcome of all of our biases, because there is no readily available counter-metaphor for us to use. (Riding a bike is the best I’ve come up with. 😔)

Surrogation: Losing sight of the strategic construct that a measure is intended to represent, and subsequently acting as though the measure is the construct of interest

Time-saving bias: Underestimations of the time that could be saved (or lost) when increasing (or decreasing) from a relatively low speed and overestimations of the time that could be saved (or lost) when increasing (or decreasing) from a relatively high speed.

Zero-risk bias: Preference for reducing a small risk to zero over a greater reduction in a larger risk.

Software deploys and cognitive biases

Why every software engineering interview should include ops questions

I’ve fallen way behind on my blog posts — my goal was to write one per month, and I haven’t published anything since MAY. Egads. So here I am dipping into the drafts archives! This one was written in April of 2016, when I was noodling over my CraftConf 2016 talk on “DevOps for Developers (see slides).”

So I got to the part in my talk where I’m talking about how to interview and hire software engineers who aren’t going to burn the fucking house down, and realized I could spend a solid hour on that question alone. That’s why I decided to turn it into a blog post instead.

Stop telling ops people to code better, start telling SWEs to ops better

Our industry has gotten very good at pressing operations engineers to get better at writing code, writing tests, and software engineering in general these past few years. Which is great! But we have not been nearly so good at pushing software engineers to level up their systems skills. Which is unfortunate, because it is just as important.

Most systems suffer from the syndrome of running too much software. Tossing more software into the heap is as likely to cause more problems as often as it solves them.

We see this play out at companies stacked with good software engineers who have built horrifying spaghetti messes of their infrastructure, and then commence paging themselves to death.

The only way to unwind this is to reset expectations, and make it clear that

  1. you are still responsible for your code after it’s been deployed to production, and 
  2. operational excellence is everyone’s job.

Operations is the constellation of tools, practices, policies, habits, and docs around shipping value to users, and every single one of us needs to participate in order to do this swiftly and safely.

Every software engineering interviewing loop should have an ops component.

Nobody interviews candidates for SRE or ops nowadays without asking some coding questions. You don’t have to be the greatest programmer in the world, but you can’t be functionally illiterate. The reverse is less common: asking software engineers basic, stupid questions about the lifecycle of their code, instrumentation best practices, etc. 

It’s common practice at lots of companies now to have a software engineer in the loop for hiring SREs to evaluate their coding abilities. It should be just as common to have an ops engineer in the loop for a SWE hire, especially for any SWE who is being considered for a key senior position. Those are the people you most rely on to be mentors and role models for junior hires. All engineers should embrace the ethos of owning their code in production, and nobody should be promoted or hired into a senior role if they don’t.

And yes, that means all engineers!  Even your iOS/Android engineers and website developers should be interested in what happens to their code after they hit deploy.  They should care about things like instrumentation, and what kind of data they may need later to debug their problems, and how their features may impact other infrastructure components.

You need to balance out your software engineers with engineers who don’t react to every problem by writing more code. You need engineers who write code begrudgingly, as a last resort. You’ll find these priceless gems in ops and SRE.

ops questions for software engineers

The best questions are broad and start off easy, with plenty of reasonable answers and pathways to explore. Even beginners can give a reasonable answer, while experts can go on talking for hours.

For example: give them the specs for a new feature, and ask them to talk through the infrastructure choices and dependencies to support that feature. Do they ask about things like which languages, databases, and frameworks are already supported by the team? Do they understand what kind of monitoring and observability tools to use, do they ask about local instrumentation best practices?

Or design a full deployment pipeline together. Probe what they know about generating artifacts, versioning, rollbacks, branching vs master, canarying, rolling restarts, green/blue deploys, etc. How might they design a deploy tool? Talk through the tradeoffs.

Some other good starting points:

  • “Tell me about the last time you caused a production outage. What happened, how did you find out, how was it resolved, and what did you learn?”
  • “What are some of your favorite tools for visibility, instrumentation, and debugging?
  • “Latency seems to have doubled over the last 6 hours. Where do you start looking, how do you start debugging?”
  • And this chestnut: “What happens when you type ‘google.com’ into a web browser?” You would be fucking *astonished* how many senior software engineers don’t know a thing about DNS, HTTP, SSL/TLS, cookies, TCP/IP, routing, load balancers, web servers, proxies, and on and on.

Another question I really like is: “what’s your favorite API (or database, or language) and why?” followed up by “… and what are the worst things about it?” (True love doesn’t mean blind worship.)

Remember, you’re exploring someone’s experience and depth here, not giving them a pass-fail quiz. It’s okay if they don’t know it all. You’re also evaluating them on communication skills, which is severely underrated by most people but is actually as a key technical skill.

Signals to look for

You’re not looking for perfection. You are teasing out signals for things like, how will this person perform on a team where software engineers are expected to own their code? How much do they know about the world outside the code they write themselves? Are they curious, eager, and willing to learn, or fearful, incurious and begrudging?

Do they expect networks to be reliable? Do they expect databases to respond, retries to succeed? Are they offended by the idea of being on call? Are they overly clever or do they look to simplify? (God, I hate clever software engineers 🙃.)

It’s valuable to get a feel for an engineer’s operational chops, but let’s be clear, you’re doing this for one big reason: to set expectations. By making ops questions part of the interview, you’re establishing from the start that you run an org where operations is valued, where ownership is non-optional. This is not an ivory tower where software engineers can merrily git push and go home for the day and let other people handle the fallout

It can be toxic when you have an engineer who thinks all ops work is toil and operations engineering is lesser-than. It tends to result in operations work being done very poorly. This is your best chance to let those people self-select out.

You know what, I’m actually feeling uncharacteristically optimistic right now. I’m remembering how controversial some of this stuff was when I first wrote it, five years ago in 2016. Nowadays it just sounds obvious. Like table stakes.

Hell yeah. 🤘

Why every software engineering interview should include ops questions

How Much Should My Observability Stack Cost?

First posted on 2021-08-18 at https://www.honeycomb.io/blog/how-much-should-my-observability-stack-cost

What should one pay for observability? What should your observability stack cost? What should be in your observability stack?

How much observability is enough? How much is too much, or is there such a thing?

Is it better to pay for one product that claims (dubiously) to do everything, or twenty products that are each optimized to do a different part of the problem super well?

It’s almost enough to make a busy engineer say “Screw it, I’m spinning up Nagios”.

(Hey, I said almost.)

All of these service providers can give you sticker shock when you begin investigating them. The biggest reason is always that we aren’t used to considering the price of our own time.  We act like it’s “free” to just take an hour and spin something up … we don’t count the cost of maintenance, context switching, and opportunity costs of not using the time to build something of business value.  Which is both understandable and forgivable, as a starting point.

Considerably less forgivable is the vagueness–and sometimes outright misdirection and scare tactics–some vendors offer around pricing. It’s not ok for a business to optimize for revenue at the expense of user experience. As users, we have the right to demand transparency and accurate information.  As vendors, we have the responsibility to provide it.  Any pricing scheme that doesn’t align with best practices and users’ interests will be a drag on reputation and growth.

The core question, rarely addressed outright, is: how much should you pay? In this post I’ll talk about what your observability costs include, and in the next post, what you should consider including in your “observability stack”.

But I’ll give you the answer to your question right off the bat: you should probably spend 20-30% of infra costs on observability.

O11y spend should be 20-30% of infra spend

Rule of thumb: your observability spend should come to 20-30% of your infra spend. (I’ve seen 10% a few times from reasonable-seeming shops, but they have been edge cases and outliers. I have also seen 50% or more, but again, outliers.)

Full disclosure: this isn’t based on any particular science.  It’s just based on my experience of 15+ years working in operations engineering, talking to other engineers and managers, and a couple of informal Twitter polls to satisfy my own curiosity.

Nevertheless, it’s a pretty solid rule. There are exceptions, but in general, if you’re spending less than 20%, you’re “saving money” at the expense of engineering time, or being silently dragged underwater by a million little time leaks and quality of service issues — which you could eliminate completely with a bit of investment.

Consider the person who told me proudly that his o11y spend was just 1-3%. (He meant the PagerDuty bill and Pingdom checks, actually.) He wasn’t counting the dedicated hardware for their ELK cluster (80k/month), or the 2-3 extra engineers they had to recruit, train and hire (250-300k/year apiece) to run the many open source tools they got for “free”.

And ultimately, it didn’t meet their needs very well. Few people knew how to use it, so they leaned on the “observability team” to craft custom views, write scripts and ETL one-offs, and serve as the institutional hive mind and software usability tutors.  They could have used better tools, ones under active development by large product teams.  They could have used that headcount to create core business value instead.

Engineers cost money

Engineers are expensive. Recruiting them is hard. The good ones are increasingly unwilling to waste time on unnecessary labor. This manager was “saving” maybe a million dollars a year (he mentioned a vendor quote of less than 100k/month)–but spending a couple million more than that in less-visible ways.

Worse, he was driving his engineering org into the ground by wasting so much of their time and energy on non-mission-critical work, inferior tooling, one-offs, frustrating maintenance work, etc, all of which had nothing to do with their core business value.

If you want to know if an org hires and retains good engineers, you could do worse than to ask the question: “What tools do you use, and why?”

  • Good orgs use good tools. They know engineering cycles are their scarcest and most valuable resource, and they want to train maximum firepower on their core business problems.
  • Mediocre orgs use mediocre tools, have no discipline or consistency around adoption and deprecation, and leak lost engineering cycles everywhere.

So back to our rule of thumb: observability amounting to 20-30% of total spend is where most shops should fall. This refers to cloud-native infrastructure, using third-party services to instrument and monitor code, with the basics covered — resource utilization graphs, end to end checks, paging, etc.

So, what do I need in my “observability stack”?

What are the basics? Well, obviously “it depends”. It depends on your requirements, your components, your commitments, your budget, sunk costs and skill sets, your teams, and most expensive of all — customer expectations and the cost of violating them. You should think carefully about these things and try to draw a straight line from the business case to the money you spend (or don’t spend). And don’t forget to factor in those invisible human costs.

 

How Much Should My Observability Stack Cost?

Notes on the Perfidy of Dashboards

The other day I said this on twitter —

… which stirred up some Feelings for many people. 🙃  So I would like to explain my opinions in more detail.

Static vs dynamic dashboards

First, let’s define the term. When I say “dashboard”, I mean STATIC dashboards, i.e. collections of metrics-based graphs that you cannot click on to dive deeper or break down or pivot. If your dashboard supports this sort of responsive querying and exploration, where you can click on any graph to drill down and slice and dice the data arbitrarily, then breathe easy — that’s not what I’m talking about. Those are great. (I don’t really consider them dashboards, but I have heard a few people refer to them as “dynamic dashboards”.)

Actually, I’m not even “against” static dashboards. Every company has them, including Honeycomb. They’re great for getting a high level sense of system functioning, and tracking important stats over long intervals. They are a good starting point for investigations. Every company should have a small, tractable number of these which are easily accessible and shared by everyone.

Debugging with dashboards: it’s a trap

What dashboards are NOT good at is debugging, or understanding or describing novel system states.

I can hear some of you now: “But I’ve debugged countless super-hard unknown problems using only static dashboards!” Yes, I’m sure you have. If all you have is a hammer, you CAN use it to drive screws into the wall, but that doesn’t mean it’s the best tool. And It takes an extraordinary amount of knowledge and experience to be able to piece together a narrative that translates low-level system statistics into bugs in your software and back. Most software engineers don’t have that kind of systems experience or intuition…and they shouldn’t have to.

Why are dashboards bad for debugging? Think of it this way: every dashboard is an answer to a question someone asked at some point. Your monitoring system is probably littered with dashboards, thousands and thousands of them, most of whose questions have been long forgotten and many of whose source data streams have long since gone silent.

So you come along trying to investigate something, and what do you do? You start skimming through dashboards, eyes scanning furiously, looking for visual patterns — e.g. any spikes that happened around the same time as your incident. That’s not debugging, that’s pattern-matching. That’s … eyeball racing.

if we did math like we do dashboards

Imagine you’re in a math competition, and you get handed a problem to solve. But instead of pulling out your pencil and solving the equation, step by step, you start hollering out guesses.

“27!”
“19992.41!”
“1/4325!”

That’s what flipping through dashboards feels like to me. You’re riffling through a bunch of graphs that were relevant to some long-ago situation, without context or history, without showing their work. Sometimes you’ll spot the exact scenario, and — huzzah! — the number you shout is correct! But when it comes to unknown scenarios, the odds are not in your favor.

Debugging looks and feels very different from flipping through answers. You ask a question, examine the answer, and ask another question based on the result. (“Which endpoints were erroring? Are all of the requests erroring, or only some? What did they have in common?”, etc.)

You methodically put one foot in front of the other, following the trail of bread crumbs, until the data itself leads you to the answer.

The limitations of metrics and dashboards

Unfortunately, you cannot do that with metrics-based dashboards, because you stripped away the connective tissue of the event back when you wrote the metrics out to disk.

If you happened to notice while skimming through dashboards that your 404 errors spiked at 14:03, and your /payment and /import endpoints started erroring at 14.03, and your database started returning a bunch of mysql errors shortly after 14:00, you’ll probably assume that they’re all related and leap to find more evidence that confirms it.

But you cannot actually confirm that those events are the same ones, not with your metrics dashboards. You cannot drill down from errors to endpoints to error strings; for that, you’d need a wide structured data blob per request. Those might in fact be two or three separate outages or anomalies happening at the same time, or just the tip of the iceberg of a much larger event, and your hasty assumptions might extend the outage for much longer than was necessary.

With metrics, you tend to find what you’re looking for. You have no way to correlate attributes between requests or ask “what are all of the dimensions these requests have in common?”, or to flip back and forth and look at the request as a trace. Dashboards can be fairly effective at surfacing the causes of problems you’ve seen before (raise your hand if you’ve ever been in an incident review where one of the follow up tasks was, “create a dashboard that will help us find this next time”), but they’re all but useless for novel problems, your unknown-unknowns.

Other complaints about dashboards:

They tend to have percentiles like 95th, 99th, 99.9th, 99.99th, etc. Which can cover over a multitude of sins. You really want a tool that allows you to see MAX and MIN, and heatmap distributions.

A lot of dashboards end up getting created that are overly specific to the incident you just had — naming specific hosts, etc — which just creates clutter and toil. This is how your dashboards become that graveyard of past outages.

The most useful approach to dashboards is to maintain a small set of them; cull regularly, and think of them as a list of starter queries for your investigations.

Fred Hebert has this analogy, which I like:

“I like to compare the dashboards to the big display in a hospital room: heartbeat, pressure, oxygenation, etc. Those can tell you when a thing is wrong, but the context around the patient chart (and the patient themselves) is what allows interpretation to be effective. If all we have is the display but none of the rest, we’re not getting anywhere close to an accurate picture. The risk with the dashboard is having the metrics but not seeing or knowing about the rest changing.”

In conclusion

Dashboards aren’t universally awful. The overuse of them just encourages sloppy thinking, and static ones make it impossible for you to follow the plot of an outage, or validate your hypotheses. 🤒  There’s too many of them, and not enough shared consensus. (It would help if, like, new dashboards expired within a month if nobody looked at them again.)

If what you have is “nothing”, even shitty dashboards are far better than no dashboards. But shitty dashboards have been the only game in town for far too long. We need more vendors to think about building for queryability, explorability, and the ability to follow a trail of breadcrumbs. Modern systems are going to demand more and more of this approach.

Nothing < Dashboards < a Queryable, Exploratory Interface

If everyone out there who slaps “observability” on their web page also felt the responsibility to add an observability-enabling interface to their tool, one that would let users explore and identify unknown-unknowns, we would all be in a far better place. 🙂

 

 

 

 

 

Notes on the Perfidy of Dashboards

Engineering Manager Archetypes and Career Paths

Cross-posted from leaddev.com

Exploring seven common leadership scenarios.

If you’re looking for a very traditional breakdown of engineering manager archetypes – tech lead manager, team manager, director, and so forth – you can’t do better than Will Larson’s post, and I won’t try. I enthusiastically endorse everything he says, especially about Tech Lead Management roles being mostly a trap.

This post aims to capture a different set of archetypes: the common inflection points in a senior engineering manager’s career trajectory, what contributes to these, and some recommended next steps.

I’m of the opinion that career ‘planning’ is mostly overrated. There are just so many variables that go into what makes you feel happy, challenged, and content over the course of your life, and trying to predict how you’ll feel more than two or three years down the line is a fool’s game. You might get married, have kids, deal with immigration status or work visas, or family or health issues that suddenly throw a wrench in things. The company you work at might get acquired, go public, make some bad hires, get pummeled by changing market conditions or an economic downturn, or reorg you under somebody you absolutely loathe. The plum role you want might go to someone else. You might hitch your career to a technology that takes off like a rocket, or sputters out quietly, or suffers a series of community scandals.

Everything fails sooner or later, and most fail sooner rather than later.

And then there’s the fact that people who do plan their careers tend to plan in terms of hierarchy. They are eager to ‘make management’. Then they’re hungry to manage managers. They read ‘30 under 30’ lists and obsessively track which of their peers has climbed the ladder to director or vice president first, and their heart swells in tune with their headcount growth.

Few of us are completely immune to the siren song of such external signifiers of success. (Everybody’s mom congratulates them when they move into management – this shit runs deep in our culture.) But for most of us, nothing breaks the spell like spending time in those upper-hierarchical roles.

When you’re an engineer, it seems like managers hold all the power. Two or three years into a managerial role, you should be thoroughly cured of that illusion – aware of the constraints managers operate under and the multiple stakeholders they serve, but also newly appreciative of the powers and freedoms held by engineers, and attuned to how wielding influence and marshaling results may have little if anything to do with formal decision-making powers.

So, if you’re an ambitious person who wants a long, happy, rewarding career in technology, what’s the alternative?

Self-knowledge. Never stop working on self-awareness, being honest with yourself and others. Try to understand what truly matters to you – is it status and public acclaim? Is it spending half your life in the wilderness? Do you have a singular passion for compilers? Whatever it is, expect it to shift over the years.

  1. Do set goals for yourself – know what you want to achieve over the next few years, and have a hazy idea of where your nose is pointing five years from now.
  2. Whenever you don’t feel strongly compelled to make a particular move, act to preserve or expand optionality.

Don’t get comfortable. Once you’ve been doing any job for two or three years, it’s time for a change.

Let’s examine some archetypes and what to do if one of these applies to you. Keep in mind that these are just rules of thumb, and rules are meant to be broken. If your heart is pulling you in one direction, by all means, follow it.

The junior engineer who became an early manager

If you have worked as an engineer for less than seven-ish years before becoming a manager, you’re in risky territory. You’ll lose your fluency very quickly, and find it much harder to go back to engineering than if you had waited until you were more solidly senior. This can feel like a big compliment – and it is! – but this is your long-term career we’re talking about, not theirs, and too often those who progress early in their career aren’t warned about the downsides and the loss of optionality.

You’ll probably be fine as long as you stay at that same company, given that you know the systems well and management is all about relationships, but you may struggle when you try to find your next job, and you may also struggle finding someone willing to hire you as an engineer when you’re rusty. Technical skills buy credibility.

It’s worth noting that this seems to disproportionately happen to women, who are tapped for management because they are perceived as having better social skills, and then suffer a double penalty when they are rusty and judged ‘not technical’. If you’re a young woman, be extra cautious – make sure you ardently guard and grow your technical credibility.

The novice manager who wants to go back to engineering, six months in

When you’re deciding whether to be a manager or not, think of it as a tour of duty that will last for two to three years. Can you commit to that? If not, this probably isn’t the right time for you to try it out. If you aren’t sure, or you don’t feel like you have any idea what the job entails, don’t accept. Find ways to level up at managerial skills without taking on full responsibility for a team.

This might include taking ownership over a hiring loop – defining the role, writing a posting, designing the interview loop, training the interviewers, screening the candidates, adopting an intern or two (or even running the intern program), updating or open-sourcing your engineering job ladder, subbing for a manager while they’re out on paternity leave for a few months – any number of things. It’s okay to say no, and far better than saying yes, then backing out.

Why? First and foremost, it’s really disruptive to the team, and not fair to them. Secondly, you need to be prepared to shelve your own opinion of your work for the next two years and just keep doggedly plugging away, doing your best to learn and taking loads of feedback, without worrying too much about whether you personally think you’re doing a good job or not. You can’t base your self-esteem on how well you think you’re doing, because frankly, you’re not to be trusted. You have to gain a lot of experience and rewire a lot of neural pathways before you can once again trust your own inner voice on the topic of your job performance.

Management isn’t a promotion, it’s a change of career. And if you aren’t up for resetting the dial to ‘NOOB’ for a couple years, with all of the ups and downs, anxieties and discombobulations, then you aren’t up for management.

The manager who wants to go back to engineering, but only temporarily

One thing I hear surprisingly often from people is that they’re anxious that they’ll never get another shot at management if they step away from it – to take a new job at a new company, for instance, or to solidify their senior engineering skills. But they like management! – and are afraid of getting ‘stuck’ back in engineering.

It’s true: there are no guarantees in life. But in my experience, this fear is particularly overblown. There is a chronic shortage of good engineering managers, especially ones who genuinely enjoy the work. It’s pretty obvious when someone has the engineering manager’s skill set in their tool box; it permeates how you do your job, how you interact with your coworkers, and how you get things done. This means that it’s only a matter of time before you get tapped again. (And again.)

Engineers who have been managers tend to bat the question away over and over again – job after job, year after year. It takes more effort not to be a manager once you’re capable of it.

The manager who was forced into it and wants out…has wanted out for years

This is a tricky one, because it comes in two different guises. Sometimes it’s the person who got pushed into management unwillingly, or had a really rough time of it for a while, or maybe they have never worked in an environment where management was spoken of respectfully. For whatever reason, they still openly grump and groan about it despite the fact that they have actually come around and quite like the job now, and don’t actually want to go back to engineering after all.

Other times, the person got pushed into management unwillingly and genuinely dislikes it. Perhaps they were better as an engineer than they are as a manager, or maybe they simply never grew to love the management role enough to compensate for what they miss about engineering. If they’ve been complaining about it for years, and haven’t done anything about it, there are a few possible reasons: 1) they are genuinely getting pressured by their own boss and the organization to stay in their current role 2) they can’t bring themselves to give up the salary, the control, or the perceived status 3) there’s some other fear holding them back – for example, maybe they’re afraid it’s been too long and they’re too rusty.

In the first case, you should stay a manager, by all means, but own up to the fact that you enjoy it and find it rewarding. Even if you didn’t initially choose the gig, you’re choosing it now, so shut the hell up about being forced into it. Nobody wants to report to a manager who doesn’t want to be there, or is doing the job begrudgingly. Your complaining is toxic, and makes it impossible for you to coach others to have a healthy relationship with their roles.

In the latter case, if you genuinely don’t enjoy your job, then get the hell out. If it’s been years, then you have all the data you need. Your boss has no place forcing you into doing something you hate. You’re never going to do as well at a job you don’t enjoy as one that you do, so ultimately it’s a career-limiting move to stay where you are. Think long and hard about the distorting role that hierarchy has played in your life, and find a place where you are respected and valued for doing what you love.

Personally, I think the worst reason of all for not wanting to give up management is because it means giving up control. How do you think everyone else on your team feels? The good news is that you are ideally positioned to go back to engineering and model what a healthy power balance should look like between management and engineering – to demand transparency and model autonomy and ownership as a senior engineer.

The manager who has been managing for several years … now what?

If you’re a line manager who has been doing the job for around five years, and you feel pretty confident in your craft … what’s next?

That’s a great question. As you know, your technical credibility is grounded to some extent in your ability to do the same work as your team. So one question to ask yourself is, how wobbly are you on that front? Some managers manage to keep a hand in (but out of the critical path) the whole time; most managers do not. There is no right or wrong answer here, only an honest assessment of where you’re at. If you’re rusty, and you want to keep doing line management, it’s probably time to go back to the well for at least six months work as an engineer.

(This could be a GREAT opportunity to swap places with someone who’s questioning whether or not to be a manager full time.)

That’s definitely the choice that preserves the most optionality for you career-wise. It ensures you will still be hireable as an engineer or an engineering manager anywhere, regardless of how much technical knowledge the interview requires (and it does run the gamut, up to and including places that make you work as an engineer for six months before assuming your managerial role).

But most managers are at least slightly curious about what it would be like to move up the chain, or expand their managerial repertoire. This might be: managing teams where you are not the technical domain expert, taking on more of a hybrid product manager role, managing multiple teams, spinning off one or more subteams and managing those managers in addition to your primary team, or managing managers as a director.

Here your choices will likely be constrained by opportunities, which means that the company you work for matters A LOT. At a company with hundreds of engineers and high growth, there’s usually a nonstop trickle of reorgs, reteaming, and other opportunities opening up. If you work at a smaller company (or a place with less growth) and your bosses show no interest in leaving soon, you may need to switch companies to seek out those opportunities.

If this is important to you, you may want to consider switching earlier rather than later. You should pay extra attention to managing ‘out’ and ‘up’; building close relationships with your peers and those above you, in other words. Don’t be afraid to open your mouth and state your goals, and ask for your manager’s advice in getting there. People don’t get randomly tapped for these opportunities so much as they share their goals and are then grown into those positions over time.

The engineer who wants to be a manager, but hasn’t had the opportunity

The most demystifying thing about management is actually being a manager. To those who haven’t had the chance yet – or worse, who have seen colleague after colleague tapped for opportunities while being repeatedly overlooked– that can be cold comfort, or even infuriating to hear. If you want a shot at management, and haven’t had one yet: why not? What should you do or try differently?

Every circumstance is different, but I can offer some suggestions.

First of all, my personal belief is that in an ideal world, any senior engineer who wants to give management a try (and who demonstrates sufficient self-awareness, emotional intelligence, and respect for their colleagues), should get a shot at it. I also believe managers and engineers should both have parallel career ladders, should make equal salaries across their bands, and that technical leadership should be the purview of technical contributors. Leadership is not synonymous with management, and the more we can drain the relationships of hierarchy, the better people will be equipped to find the work that they love and find most fulfilling.

I live in the real world, so I know that most places don’t operate this way (although I believe the number is growing).

I also think that engineers tend to systematically underestimate and undervalue their own power, and they fail to inhabit and flex the power they should have. This leaves a vacuum, so managers step in to fill by default.

All that said. First, look at your company. How many opportunities are there for new managers, really? Is it too small, or not growing fast enough, or do you work in a specialty niche? Most companies aren’t bristling with new opportunities; if this is important to you, you should go work for a company that is growing fast, and you should state your ambition from the outset – yes, to the recruiter or hiring manager in the interview process.

Second, make friends with your manager and the other managers, and eagerly absorb as many managerial tasks or responsibilities as you can. Be more concerned with learning the skills and gaining the experience than with the title itself.

Third, work on your communication skills, written and spoken. Consider doing some public speaking. Run a workshop for your coworkers in something you know well. Take good meeting notes, write great technical project docs.

Fourth, ask your manager (and any other trusted senior people you work with) what you’re missing. Make it clear that you want to hear honest feedback, even if it hurts. If there’s something holding you back that you don’t know about, and someone is willing to tell you, that’s an incredible gift.

Fifth, educate yourself about diversity and inclusion issues. Stand up for others on your team who are getting talked over or having their ideas stolen. Be a leader among your peers, be someone who is willing to do what is right despite the temporary social costs.

The senior manager, director or vice president who daydreams about being an engineer again

Very often, people who were in the right place at the right time and climbed the ladder rapidly, get to the top and realize they feel restless and empty inside – they miss the intrinsic stimulation of writing code, solving problems, delighting users. Very few of them have the courage to go back.

It’s a true fact: the higher you climb the ladder, the further removed you are from the work that brings most people intrinsic joy, that feels real. Some manage to find dopamine hits in their work as a director or a vice president, but the dose is usually fainter and always on a delay.

It’s also a true fact that you’d have to go from being atop the monkey pyramid to being just another individual contributor, slinging code in the mines with the rest of them. That’s a lot for an ego to take. And it’s rough to pick up the skills again if you’ve been ten years or more away from writing code on a daily basis. Lots of people who are in their 30s, 40s or 50s feel like they have lost the mental agility to do so and therefore it might not even be an option anymore.

I don’t have an enormous sample size, but what I do have suggests the above is bullshit.

Consider my friend Molly Stamos, who was a software engineer from 1997-2001, then rapidly climbed the corporate ladder working in product, as a director, then as a vice president. She actually joined Honeycomb as our vice president of customer success, but she was burnt, and admitted to herself shortly after that she deeply missed software engineering and that was where her heart still lay. She worked in support for a while and picked up tasks from the backlog, and formally joined the engineering team in 2020, almost 20 years after she stopped coding full time. She’s freaking great at it and says she’s never been happier.

Be like Molly. Life’s too short to be miserable at work.

And P.S. most of the prestige is in your head. If you go from being an exec to being a senior engineer, I guarantee you that lots of people, especially other engineers, will actually respect you tons more.

Engineering Manager Archetypes and Career Paths

Career Development For Engineering Managers

(Cross-posted from leaddev.com)

What comes to mind when you hear the words, ‘career development for managers’?

If you’re like me, it’s one of two things: either obsessively climbing the ladder or those awful mandatory ‘trainings’ that get hastily assembled. (Otherwise known as, ‘How can we have hired so many brilliant engineers, yet none of them seem to have any idea what appropriate professional behavior looks like – and how long till we get sued?!’)

No one would claim that we have things like engineering roles, levels, and career progression locked down, but it all looks quite mature and well-understood compared to the Wild Wild West that is engineering management. Engineering at least has some basic skills (data structures, algorithms etc.) that one can study and structure an interview around, whereas for managers those basic skills (communication, relationships) come from ‘being human’.

To be fair, you can (and should!) work very hard on being a better human. All of us should – our entire life! Skills like communication, empathy, discipline and self-mastery, emotional self-regulation, self-awareness, and self-acceptance are a huge part of being an effective leader.

But let’s say you know all that. You’re a manager, you were dropped into this gig with precious little guidance (most of it contradictory), and all you want (for heaven’s sake!)  is some straightforward advice on how to grow and become a better one.

Perfect. Let’s get started.

With great power comes the responsibility to understand power dynamics

‘I totally support women/LGBTQIA+/POC in tech, but come on, it’s not as bad as some of them keep going on about. It can’t be, or I would have seen it myself by now. I’ve been in tech for ten years, and we’ve always treated every woman just the same as the guys. Besides, you know, there are two sides to every story.’

Does that sound like you? If so, please don’t become anyone’s manager until you have done a lot of listening and learning.

It’s one thing to be unaware of power dynamics and structural inequities as an individual contributor, and another when you wield formal hiring and firing powers on behalf of the org. You can really mess people up that way, and it doesn’t matter if the harm came from your ignorance instead of malice.

Build a trusted peer group of other managers and talk regularly

Get yourself some peers. You need a personal circle of other managers for mutual support, swapping stories, and talking through tricky interpersonal scenarios with strict confidentiality. You need to know these people well enough, and they need to know you and the personalities in your life well enough, that when something is bothering you it won’t take an hour of preamble just to set the stage for the story you need to tell.

I enjoyed my peer circle as an engineer. I couldn’t survive without them as a manager.

It can take some time to amass the right trusted circle, and it will shift with time, as some connections drift away and new ones emerge. Building, nurturing, and curating your circle is a continuous background process.

And it’s the number one thing you can do for your managerial career.

Give as much as you have been given

If you went to university, don’t let it fool you: our profession is fundamentally a web of apprenticeships.

This is why you should be extra generous with your time; everything you learned came from someone else.

Teach, explain, and tell stories about your own successes and failures as a manager. Helping somebody else with their problem has a way of giving you fresh eyes for your own problems, and your skills become more firmly ingrained after you teach them to others.

Invest in your public speaking skills and broadcasting skills

If public speaking terrifies you, lean into that fear and crush it like a bug. Verbal fluency in front of a group is a learnable skill, just like any other. And as a manager, you will draw on this skill 20 times a day, whether it’s running efficient meetings, holding people’s attention, representing your team well, etc.

I used to be catastrophically terrified of speaking in front of people. Back in 2015, I had to give my first internal infrastructure talk in front of maybe eight people, and for weeks in advance I woke up almost every night, sick and clammy from having nightmares about it.

Personally, I have found that a combination of practice, experience, and sometimes using anti-anxiety medication has made this an easier journey for me.

Get a therapist

Get a therapist. Get a work coach too, if work will pay for it. Yes, it’s good to work on your self-awareness, your relationship patterns, etc., but it’s also super useful to learn new metaphors and descriptive phrases from people who do this for a living. The richer your descriptive arsenal, the wider your range when connecting with people.

If you’re reluctant to do this, ask yourself honestly: couldn’t you use some better coping mechanisms and tools for emotional regulation? (Couldn’t everyone?)

Such a huge part of being a manager is making sure you don’t turn your problems into other people’s problems, or make your feelings other people’s problems. And that’s hard. It’s hard, and the ground is constantly shifting beneath your feet. Just when you think you’ve got it down, things change again.

Do a tour of duty as a manager at a big company

I list this one somewhat begrudgingly, but it’s a big one. If you really want to accelerate your career as a manager and learn lots of core skills fast: consider going to work at a Google/Facebook/Amazon, or any large and relatively faster-paced (or extremely fast-growing) tech company.

I learned so, so, so much about management (and organizational politics, and bureaucracies, and formal and informal power structures) at Facebook.

None of it was what I wanted to learn, mind you, but in retrospect it turned out to be pretty darn invaluable.

These big tech companies have their flaws, but they aren’t stupid, and they have invested a lot more into sophisticated business operations than any startup. Startups get away with so, so, so much sloppy behavior from a management and human resources perspective.

Managing a team at a big company for a year is a killer crash course in the best practices and established defaults of engineering management. If you can’t or won’t go work for a big company, try Will Larson’s book An Elegant Puzzle, which outlines a lot of the same best practices and the reasons behind them.

Overcome your fear of confrontation

If you hate confrontation, I’m sorry honey, but you have to push through that barrier ASAP. It is the one thing that will hold you back, poison your relationships, result in loss of trust, and ultimately hurt your direct reports faster than anything else. Read Radical Candor, practice with your therapist, practice with your group of peers, do whatever it takes. You have got to learn to lean into that itchy feeling and open your mouth instead of shrinking away.

Experiment with your 1:1s

Learn to have better, more interesting, more fulfilling, more varied 1:1s with your reports. This is a tough one for introverts, but it’s super worth investing some time into. I will leave ‘how’ as an exercise for the reader – there are lots of interesting blog posts out there, or you could start picking the brains of other managers who you respect.

Most of us have never had a very good manager, let alone a great manager. If you dreaded your 1:1s or were bored by them, etc., it doesn’t have to be this way. 1:1s are the great bidirectional lens into each other’s roles and lives, and with a little curiosity and experimentation, they can be much more than 30 minutes of awkward conversation or the same 3 questions every week.

Run better meetings

Running great meetings – efficient, productive, interesting, with exactly the right people present – is an understated, underestimated art. We usually only notice when a meeting is being run poorly. Train yourself to notice meetings where everyone is leaning in, eyes sparkling, devices forgotten, or even just the meetings that you never dread going to: who runs those? Pay attention to those jedi masters, and copy the hell out of them.

Volunteer to do things that are new and challenging. (Nobody else knows how to do them, either)

Put your hand up and volunteer for things. Is there a new job ladder that needs to be written or revised? Does the on call schedule need refactoring? Has anyone checked to make sure salaries are fair and not biased by race or gender?

Who better than you? 😁

And finally, having saved the hardest and most open-ended for last:

Look for ways to improve and optimize your organization as a sociotechnical system

Anyone who calls themselves a technical leader, whether engineer or manager, shares responsibility for identifying, maintaining, and optimizing the inner feedback loops that help you build and ship software. They are at the heart of how your organization delivers value and becomes a place people want to work.

Figure out how high-performing your team is (start with the DORA metrics), then begin to evaluate how much time is being wasted and consumed by wheel-spinning due to inefficiencies in your core sociotechnical feedback loops.

Try to step back from fighting all the symptoms and pathologies; instead, try to address them at the source.

This may involve:

  • Staying up to date on technical news
  • Getting your hands dirty and tinkering from time to time
  • Talking to others in the org to identify shared pain
  • Learning what really motivates each person on your team
  • Crafting a pitch that excites them and pushes their boundaries
  • Breaking down massive technical debt into bite-sized initiatives
  • Knowing when to speak and when to shut up
  • Doling out strategic praise

In conclusion

Career development as a manager isn’t about racing up the org chart at a breakneck speed. What makes someone a great, fulfilled, happy engineering manager doesn’t necessarily translate into making them a great director or VP (or a happy one). Opportunities to advance to upper management are scarce and somewhat random. There’s a lot to learn about the craft of management and technical leadership, which is a much healthier thing to focus on.

Check in with yourself regularly about whether you still enjoy your work. Swinging the pendulum back to engineering every few years is a great way to ensure you remain employable and your skills remain fresh over the long run.

Building a long and rewarding career in tech is not about chasing titles or levels, it’s about learning to follow your curiosity (and learning to love the uncertain feeling of being out of your depth.)

One final warning: managers have a tendency to slip into a pattern of only doing things or growing in ways that are useful to the org, but useless to them personally (once they change jobs or leave the company). Don’t do this! Be more selfish. Insist on building skills that are transferable and inherently valuable, not just knowing where all the bodies are buried at your current employer.

Anyone who manages to be happy in management will have to seek out fresh dopamine hits to replace those they gave up in engineering. Happy hunting.

Career Development For Engineering Managers

How To Hire An Engineering Manager

Cross-posted from leaddev.com

Why it matters to look internally first.

So, you need an engineering manager. Maybe what you need is to replace a departing manager – someone who is leaving the company, being promoted, or going back to hands-on individual contributor (IC) work. Maybe your team has gotten too large and unwieldy and is ready to split in two, amoeba-like, or you’re on the verge of hiring a few more people and spinning off another team. Maybe you are a baby startup and this engineering manager will be your first formal structure, or maybe something else entirely.

Whatever the genesis, the point is the same: you need to find a manager. And your very first fork in the road will be, “Should I hire one from the outside, or tap one of my engineers for the role?”

Here is a brief overview of the considerations involved in asking this question and making that decision.

First of all, I should confess to my biases. I am a big believer in the philosophy that management is not a promotion, but a change of career. There is a great deal of evidence that hierarchy produces worse outcomes in creative industries, of which software is decidedly one. I think that management is not and should not be synonymous with leadership; in fact, there are areas of technical leadership and implementation details where managers have no business exerting ownership. There should be technical leadership levels that track management levels as their equals in compensation, authority, and respect, but with different domains – ‘non-overlapping magisteria’, as the great Stephen Jay Gould might have said.

Engineering managers are ultimately responsible for the health of the team, the career progression of the engineers under their care, and for making sure that engineering teams are focused on the right priorities. They are the essential link between business and engineering; they must be able to translate between the two worlds many times a day. But once the decision is made that something is a priority, how it is done is the proper domain of engineers and technical leads.

Now, back to our choice. What should we do – hire from within, or hire from without?

Give preference to internal candidates

I am a firm believer that you always, always owe your existing team first crack at any and every opportunity that arises from within. It may not always be possible; you may need someone with more experience or a different skillset than you have on your team, but you owe it to your team to seriously explore the possibility, every time, before you give in and begin to explore outside possibilities.

That is an ethical stance which I happen to hold. But there are also pragmatic reasons for preferring internal candidates over external candidates where possible. Effective line management requires a manager to have a reasonably good understanding of the tech stack and the slate of current problems and tradeoffs; who better than one of the engineers working on it? And good management, in general, is all about relationships, relationships, relationships; someone coming in the door will always take longer to build those relationships and be effective than someone who already knows the lay of the land and the people who dwell in it. Internal candidates taking a lateral transfer to a management role are the most likely to succeed, in my experience.

So, what are some questions you might ask yourself when looking around for management candidates?

Who is the best engineer?

This is traditionally the first (and sometimes only) question leadership asks before ‘promoting’ (sic) said engineer to management. Unfortunately, this is the wrong question to ask yourself. There is no correlation that I’ve observed between someone’s engineering skills and management skills – no positive correlation, at any rate.

I do believe engineering managers need to have a strong technical background in order to be effective, but they don’t need to be the best engineer in the room. Many fervently mediocre senior engineers have developed into strong, admirable engineering managers – some of whom then swing the pendulum back to IC and leverage those hybrid skillsets to become supremely valuable senior technologists.

This is one big reason why it’s important to decouple leadership from management. Your best engineers are likely hungry for advancement, autonomy, and impact (just like everyone else), and you do not want them to conclude that management is the only vehicle for their ambitions – the only way they’ll ever get a seat in the room where it happens. You want them to solve your hardest technical problems if that is where their heart is. A better question to start with might be:

Who is senior enough to be a manager?

Don’t consider anyone for management until they have achieved a solid senior level and status – at least 5–7 years of hands-on engineering. Their technical judgment should be well-respected by their peers; they should know enough to know how much they don’t know, and where to trust their own opinion or not.

You won’t be doing them any favors by asking them to switch careers earlier in their tenure, and you might well be inflicting permanent damage on their career. At least half of those who try management end up not liking it, or go back to engineering at some point. If they make the leap to management too early, it will be extremely difficult for them to return to engineering a couple of years later. You might be sentencing them to a one-way trip whether they like it or not.

It will also be difficult for them to effectively manage junior engineers, who need mentorship and career development, or senior engineers, whose experience and judgment will far outstrip their own. Too many managers end up frustrating their teams by lurching between command-and-control leadership, and blind trust and abdication of leadership – not because they want to, but because they lack the technical subtlety to know when to speak or shut up.

Are any of your engineers interested?

Is anyone on your team interested in trying out the manager gig? Don’t guess; ask. Not just once, but regularly. And don’t wait until a position opens up to ask, either. Managers should have a chat about career plans with everyone on their team at least once or twice a year, and that includes asking whether they would like to try being a manager at some point.

Management is just a bundle of skills and practices, after all. You don’t have to have a formal manager title in order to be tasked with or practice things like running an interview loop, mentoring an intern, running team meetings, and writing up plans. If someone wants to become a manager at some point in their career, you should help them find opportunities to practice some of these skills and habits.

This is the quickest and easiest way for someone to find out if the work actually doesn’t interest them. And it’s a great low-risk way for you to watch them in action and observe their skills, without having to entrust the fate of an entire team to them yet.

When an opening does arise, you should already have a mental map of who on the team is likely to be interested, and how skilled they are.

Do I need to interview them, or what?

If you’re seriously considering an internal candidate for management, start by having a conversation with them – a different sort of conversation than you may have had up to this point. Start with some simple, open-ended questions, like:

“Why do you think there are so many more men than women in software roles?”

And let them talk for a while. You aren’t trying to trap them, or looking for ideological purity, but if you are going to put someone into a position of formal organizational power over others, it’s your responsibility to make sure they won’t inflict harm.

You have to have a higher bar for managers when it comes to awareness of structural racism and interpersonal power dynamics. Being a ‘really good person’ is not enough to do the job; ‘good people’ inflict immense harm every day without meaning to. You need managers who are humble, self-aware, and eager to learn – not ones who will have a meltdown and become the problem any time they mess up.

What if there are two or more who want it?

This is another great argument for treating management as a change of career, not a promotion, and for legitimizing and normalizing the idea that it’s okay to go back and forth between management and engineering, every few years.

If it’s not a promotion, then you don’t have any status to give up. If it’s an ordinary thing, there will be other opportunities. Not every opportunity exists at every company at every time, but the more you can do to lower the perceived scarcity and intensity, the more you will find people becoming managers or engineers for the right reasons rather than the wrong ones.

The team’s opinion matters more than yours

You should never inflict a manager on a team who doesn’t want to receive them in that role, no matter how qualified they seem on paper. If someone wants to be manager, your next move should be to quietly chat with each of the team members to see how they receive the idea, giving special weight to the opinions (and body language) of any underrepresented minorities on the team. Do they want to report to this person? If not, don’t push it – even a little.

Slight caveat: if the proposed candidate is a gender or racial minority, and if you suspect the team’s discomfort is related to their status, it’s worth digging in a little more to understand the situation and even possibly overrule some hesitation. As ever, trust your intuition but interrogate it, and use your best judgment.

Reasons to go ahead and open an external req

I said that internal candidates are my preference by default, but there remains a long, long list of reasons why you might decide to hire externally after all. A few of them include:

  • Your team is mostly junior-to-intermediate, and your senior folks are lukewarm on the idea of management (never push someone into it!)
  • All your existing managers are first-timers, and you really need some more experienced managers in the mix to help you formalize policies and processes as you grow
  • The team is split, and there is no consensus behind any internal candidate.

Listen to your own intuition, too: if you don’t have a great feeling about any of your options, take that seriously.

If you decide to hire a manager from the outside, the first thing you need to do is sit down and take a long hard look in the mirror. Hiring isn’t about finding the ‘best person’, it’s about crafting the strongest team. Where is your team weak? Who do you worry about? What are your strategic goals for the upcoming year or two, and what kind of leadership experience will help you get there? Do you need someone who can be very hands-on with the technology, or someone skilled at systems building, or driving transformation? Will recruiting be make-or-break for you? How diverse is your team, and what are your diversity goals?

All of these archetypes call for different types of leaders. But that’s a topic for another time.

How To Hire An Engineering Manager

Questionable Advice: “What Should I Say In My Exit Interview?”

I recently received this gem of a note::

Hi Charity, I really enjoy your writing and a lot of it has directly contributed to me finally deciding to leave a company with a toxic management culture. I’ll also be leaving many great IC friends that will have lost a strong voice.

My exit interview will be next week. Any advice on how honest I should be?

I’ve googled quite a bit but there are only generic “don’t burn bridges” comments. Would love to see something a little more authoritative 🙂

–Anonymous Reader

Ew, fuck that. That’s exactly the kind of quivering, self-serving, ass covering advice you’d get from HR. It’s exactly the kind of advice that good people use to perpetuate harm.

I wouldn’t worry about “too much honesty” or personal repercussions or whatnot. I would worry about just one thing: being effective. This is your last chance to do the people you care about a solid, and you don’t want to waste it.

So … ranting about every awful person, boring project and offensive party theme of your tenure: not effective. Ranting about people who were personally irritating but had very limited power: not effective. Talking only in vague, high level abstractions (“toxic culture”), or about things only engineers understand and are bugged by: not effective.

What is effective? Hm, let’s think on this..

  • Start off with your high level assertion (toxic culture) and methodically assemble a list of stories, incidents, and consequences that support your thesis. Structure-wise, this is a lot like writing a good essay
  • Tie your critiques to the higher ups who enabled or encouraged the bad behavior, not just the flunkies who carried it out.
  • Wherever possible, draw a straight line to material consequences — people quitting, customers leaving, your company’s reputation suffering
  • Keep it crisp. No more than three pages total. Pick your top 1-3 points and drive them home. No detours.
  • This one sucks, but … if someone was perceived as an underperformer or a problem employee, avoid using them as evidence in support of your argument. It won’t help you or them, it will be used as an excuse to discredit you.
  • Keep it mostly professional. I am not saying don’t show any anger or strong emotion; it can be a powerful tool; just be careful with it. Get a proofread from someone with upper management experience, ideally with no connection to your work. (Me, if necessary.)
  • ✨Put it in WRITING!✨ Deliver your feedback in person, but hand over a written copy as well. Written words are harder to ignore or distort.
  • For extra oomph, give a copy to any execs, managers, or high level ICs you trust. Don’t just email it to them, though. Have a face to face conversation where you state your case, and hand them a written copy at the end.

The sad fact is that most exit feedback is dutifully entered in by a low ranking employee who makes a third your salary and has no reason whatsoever to rock the boat, after which it gets tossed in a folder or the trash and is never seen again.

If you want to use your voice on your way out the door, the challenge you face isn’t one of retribution, it’s inertia and apathy. HR doesn’t care about your feedback … but they care if they think their boss saw it and cares about it

And I think you should use your voice! You clearly have some clout, and what’s the point of having power if you won’t extend yourself now and then on behalf of those who don’t?

Good luck!!

charity

Questionable Advice: “What Should I Say In My Exit Interview?”

Know your “One Job”, continued

Holy macaroni batman, I was not expecting that post to ignite a shitstorm. It felt like a pretty straightforward observation: you were hired to do a job, you should do your best to do that job.

Interestingly, the response was almost universally positive for the first 8 hours or so. But then the tide began to turn as the 🔥hot takes🔥 began rolling in (oh god 🙈) and then began pingponging off each other, competing for and amplifying each other’s outrage. 😕You Had One Job | Know Your Meme

When something touches a nerve like this, it swiftly becomes less about your actual words and more of a public event, or maybe a Teachable Moment. (🤮) Everybody has to weigh in with their commentary, and while it’s not super fun to be on the receiving end, I have mostly learned to distinguish the general pile-on from the few engaging in bad faith. I just keep telling myself that public discourse is how we create shared consensus and shift the Overton window and industry norms. So that’s all fair game, it’s done in good faith and it’s the price of change. I can take a few days of shitty twitter mentions for the team, lol.

The one comment that did worm under my skin was a woman who said she believed my post would give an abusive former boss ammo to use against people like her in the future. And that, more than all the hatertomatoade, is why I wrote this epic followup.

Two responses i’d like to foreground

First, I’d like to link to something Terra said about the importance of ERGs for marginalized workers, especially during times of duress.

Thanks Terra, I stand corrected — I can totally see how that work counts as part of one’s core job, and managers should understand this and define it as such.

I still don’t think it means you promote someone purely on the basis of that work; I don’t see how you can promote someone up an engineering ladder until they can fulfill the technical FAIL Nation - ocd - Vintage FAILs of the Epic Variety - Cheezburgerrequirements of the next level. It could certainly mean expanding the core requirements of your role to include your ERG labor, though perhaps not replacing the technical work entirely (over the long term).

This goes both ways, fwiw. Nobody should be promoted without doing their fair share of the emotional labor and glue work it takes to keep the company going. A successful career in sociotechnical systems means leveling up your social repertoire as well as your technical skills. Your job descriptions and levels must reflect this, spelling out both the social and the technical requirements at each level.

🔥🔥🔥Tip of the Day🔥🔥🔥

If you want to know what your company REALLY cares about, take a management gig for a while and listen closely to the debates over whether or not to promote someone to the post-senior levels, and why or why not. You are LITERALLY witnessing as your organization decides, over and over, what it values the most, what it wants to reward, whose footsteps they want you to follow in, and where to spend its scarcest, most inelastic resource: staff and principal engineering titles. Fascinating shit.

Secondly, please go and read Shelby’s excellent thread, written from the perspective of someone who has been “Susan” for a number of reasons.

https://twitter.com/shelbyspees/status/1368705471532568581

 

These situations are complicated, and managers should always, always try to listen and understand the subtleties of each unique situation before coming to some mutual understanding with their team member about what the core responsibilities of the job are. Jobs are living documents, and it doesn’t hurt to revisit them and clarify from time to time. <3

Objection: “Nobody has Just One Job”

Completely true. I was trying to be funny by referring to the “You had one job!” meme. I apologize. Yes, everybody has a basket of responsibilities. I DO think that a well-written job description and clarification on the priorities of the job is a good thing, and will go a long way towards helping you figure out how to spend your time and how to not get burned out.

Also: am I prone to hyperbole? Yes ma’am, sweeping statements are LITERALLY ALL I DO. (Sorry ☺️)

FTR, I don’t think your core responsibilities should be overwhelming, and there should be plenty of time in your normal 40 hour work week to devote to so-called electives and extracurriculars. I’ve said many times that I don’t believe anyone has more than four hours a day of real, focused, challenging engineering labor in them. So maybe 15-20 hours/week of moving the business forward in your areas of ownership?

Everyone should have cycles free for participating in the “squishy” parts of work. It’s an important part of taking a group of random individuals and connecting them with meaning and a sense of mission. That isn’t HR’s job, or the managers or execs’ jobs, that is everyone’s job, the more the better. Everyone should have flexibility, autonomy, and variety in their schedule, and should feel supported in using work hours to support their peers. Nothing I am saying contradicts any of that. But sometimes something’s gotta give, and usually your core responsbilities are not what you want to sacrifice.

Objection: “Interviewing isn’t optional”

Sure. But you weren’t hired to interview. It’s just part of the basket of secondary responsibilities that come along with being a member of the team. If you’re an engineer, you likely weren’t hired to write blog posts or mentor folks — unless you were! were you?? — which makes them similarly in the bucket marked “valuable, but secondary”. Honestly it could be on purpose though, it could just be words in another language. - Imgflip

We aren’t talking about “steady state”, we’re talking about what to do when you aren’t able to fulfill the core functions of your job. This should be a temporary state of emergency, not the status quo. When you’re overwhelmed, it’s totally normal to ask to be excused from the interviewing rotation for a quarter or so, or any of your other secondary responsibilities.

Objection: “How dare you not promote someone who is getting good peer reviews”

I said she was getting some compliments and rave reviews. If you’re getting compliments from HR, marketing, and other people sprinkled across the company, but you aren’t delivering for your own team; if you’re holding back core initiatives for your closest peers, then you aren’t doing your work in the right order.

I’ve seen this happen when an engineer’s public persona becomes more important to them than their actual work. When they get hooked on the public adulation of giving talks and writing posts and going to conferences, meanwhile their output at work drops off a cliff. This isn’t fair to your coworkers. Maybe you don’t want to do this job anymore, maybe you want a job where your core responsibilities are writing and speaking. I don’t know. All I know is that if I’m the manager of that team, my responsibility and loyalty is to the well-functioning of that team, so we need to have a conversation and clarify what’s happening.

Again, all I am saying is that your commitments to your immediate team come first. Not following through affects way more than just you.

Objection: “You are hating on / devaluing glue work”

I really wish I had thought to link to Tanya Reilly’s invaluable material on glue work in my original post, but I didn’t connect those dots, sadly. Yes, it can be hard for engineering managers to recognize or reward glue work, and yes, glue work is an invaluable form of technical leadership. I don’t have a lot to say about this other than I completely agree, and it is not what I am talking about.

Objection: “All these extra-curriculars should count towards promotions”

Well, yes! Duh! I am all for promoting people not based on raw individual coding output, but on overall impact. People who perform a lot of glue work are invaluable to any high functioning team, and people who run internal ERGs, do lots of DEI work, etc — that SHOULD factor into promotions. In my original post I said that sadly, when someone isn’t performing the key parts of their job, you don’t get credit for these wonderful positives — they are not enough on their own (unless of course you have an understanding with your manager that your core responsibilities have changed), and can even be evidence of time mismanagement or an inability to prioritize.

you had one job Keep trying - Paranoia meme | Make a MemeI cannot honestly understand why this is controversial. If you were hired as a database engineer, and you spent the year doing mostly DEI work, how does it make sense to promote you to the next level as a database engineer? That’s not setting you up for success at the next level at ALL. If this was agreed upon by you and your manager, I can see giving you glowing reviews for the period of time spent on DEI work, as long as your dbeng responsibilities were gracefully handed off to someone else (and not just dropped), but not promoting you for it.

However, if you ARE competently performing your core responsibilities as a database engineer, and are performing them at the next level, then all your additional work for the company — on DEI, ERGs, mentoring, interviewing, etc — adds up to a MASSIVELY compelling body of work, and a powerful argument for promotion. It certainly ought to be enough to push you over the edge if you are on the bubble for the next level..

Objection: “You hate DEI work and demean those who do it”

It does not make me anti-DEI work to point out that you were hired to do a certain job, first and foremost. If you want your first-and-foremost job to be DEI work, that’s great! Go get that job! If you want your first-and-foremost job to be engineering, but then not do that job, I … guess I just fail to see how this is a logically defensible position.

As someone else put it: “Your One Job is the cake, the rest is the icing”.//TODO citation You can often negotiate a job that has a LOT of icing — but you should negotiate, no surprises. DEI work is absolutely valuable to companies, because having a diverse workforce is a competitive advantage and increasingly a hiring advantage. But that work isn’t typically budgeted under engineering, it comes from G&A

I can also understand why you might want to keep the (unfortunately higher) engineering salary and the (unfortunately higher) social status you have with an engineering role, even if engineering no longer feeds your soul the way doing diversity work does. I know people in this situation, and it’s tricky. 😕 There is no single right or wrong answer, just a question of whether you can find an employer who is willing to pay for that configuration. But I should think clarity and straightforwardness is more important than ever when your heart’s desire is unconventional.

Objection: “You’re letting managers off the hook. This is entirely a management failure.”

You might be right. This is often a consequence of negligent, unclear, or biased management. But not always. I’ve also seen it happen — close up — with engaged, empathetic, highly skilled You Only Had One Job on Twitter: "Whoever wrote this, probably never saw a sign like this when he/she was a kid #youonlyhadonejob #youonlyhad1job https://t.co/BGLHCWwtGo"managers who were good at setting structure and boundaries, deeply encouraging, gave tons of chances and great constant feedback, tried every which way to make it work … and the employee just wasn’t interested. They volunteered for every social committee and followed every butterfly that fluttered by. They just weren’t into the work.

YES, managers should be keeping close tabs on their reports and giving constant feedback. YES, it’s on the manager to make sure the role is clearly defined.

YES, managers should be clear with employees on what the promotion path is, and YES, no review should ever be a surprise.

YES, if people all over the org are heaping requests or responsibilities on the Susans of the world, it can be difficult to prioritize and it is not fair to expect them to juggle those requests, the manager should help to shelter them from it. Yes yes yes. We are all on the same page.You had one job! – inkbiotic

But I am writing this post, not to managers, but to engineers, people like me, who are confused about why they aren’t getting promoted and others are. I am writing this post because good managers are in scarce supply, and I don’t want your career to be on hold until you happen to get a good one. I am trying to provide a peek behind the curtain into something that frustrates managers and holds a lot of people back, so that you can take matters into your own hand and try to fix it. If your manager hasn’t been clear with you on what your core job is, they suck and I’m sorry.

Is any of this your fault? Maybe, maybe not. But it is something you have some control over. You can at least open the conversation and ask for some clarity.

You shouldn’t HAVE to do their job for them. But why let a shitty manager hurt your career any more than you must?.

Objection: “This is a gendered thing. ‘Steven’ would have been promoted for this, while ‘Susan’ gets scolded.”

110 You had one job.. ideas | you had one job, one job, jobA surprising number of people thought I was writing this as advice specifically to and for women, and got mad about that. Nope, sorry. It was not a gendered thing at all. I’ve seen this happen pretty much equally with men and women. I had planned on writing three or four anecdotes, using multiple fake names and genders, but the first one turned out long so I stopped.

Confession: I put zero thought into constructing a realistic or plausible list of activities “Susan” has at work. This came back to bite me. A LOT of people were doing a super close read of the situation (e.g. “She’s on three ERGs, so she must be a queer woman of color, which means she’s probably the most senior person at the company along all three dimensions of marginalization…”) — which, AUGH — this isn’t real, y’all —

✨This is Not A Real Situation✨.

— it was MADE UP! Totally! I just listed off the first several things that came to mind that people do at work that aren’t things they specifically got hired to do. That’s it.

I rather regret this. I should have put more time and thought into constructing a scenario Image tagged in you had one job,road stripes,timmy - Imgflipthat was less easy to nitpick. But I didn’t want anyone to see themselves in it, so I didn’t want it to be too recognizable or realistic. I just wanted a placeholder for “Person who does lots of great stuff at work”, and that’s how you got Susan.

TLDR — yep, Susan probably has a tougher go of this than Steven. I would argue that Steven generally wouldn’t be promoted either if he wasn’t adequately performing his core responsibilities, but who knows. This isn’t a real person or scenario. Women and nonbinary folks have it tougher than men. Your point? ÂŻ\_(ツ)_/ÂŻ

Objection: “Why do you hate collaboration” and “This doesn’t apply to me because my job isn’t just writing code”

I never meant to imply that your “One Job” was only work you could do heads down on your own. Lots of people’s jobs involve a ton of force multiplying, mentorship, reviewing, writing The best you had one job memes :) Memedroidproposals… typical glue work. If you have a manager that thinks you are only doing your One Job when you are heads down writing code with your headphones on, that’s a Really Bad Manager.

The more senior your role is, the more your One Job involves less “write feature X” and more “use your judgment to help fine tune our sociotechnical systems”. This is natural and good.

It is also MORE of an argument for making sure you are in alignment with others in your org about what is the most important thing for your time and energy to be spent on, not less of one. Communication and persuasion are what upper levels are all about, right?

Objection: // Placeholder

I reserve the right to add to this list of objections after I go catch up on twitter, lol.

In conclusion

Finally, I want to call out a perceptive comment by @codefolio, where he said this:

Ouch. Truth.

This speaks to something I should probably be more explicit about, which is that my writing and my advice generally assumes you are operating in a high-trust environment. That’s the kind of environment I have been tremendously fortunate to operate in for most of my career — an environment where people are flawed but compassionate, skilled, and doing their best for each other, with comparatively low levels of assholery, sociopaths, and other bad actors. If your situation is very unlike mine, I can understand why my advice could seem blinkered, naive, and even harmful. Please use your own judgment.

I only write because I want the best for you — even those of you who very openly and vocally despise me (and yes, there are quite a few of you. Start a club or something). 🥰

All said and done, about 95% of the people who replied said that my post was helpful and clarifying for them, about 3% had very interesting critical takes that I got something valuable from, and only 2% were hurling rotten tomatoes and reading and interpreting my words in ways that felt wildly detached from reality. I try to remember that, when I get discouraged and feel like the whole world hates me and wants me to shut up. 🍅🍅🍅

I am not everyone’s cup of tea, and that’s alright. 💜 My advice is not relevant or helpful to anyone, and that’s okay too. Hopefully I have cleared up enough of the misunderstandings that anyone who is reading my words in good faith now has a clear picture of what I was trying to say. And hopefully it’s helpful to some of you.

PSA: I will be your rubber ducky advice buddy🐥❤️🐣

I have posted this on twitter a few times, but if you are struggling with a career conundrum, sociotechnical growing pains, or management issue, I am generally happy to hop on a phone call over the weekend and talk through it with you. I have benefited SO much from the time and energy of others in the tech industry, it’s nice to give back. (I like giving advice and I think VERY highly of my own opinions, so this also counts as fun for me 😂)

I 💜 talking to women and enbies and queers.🌈 (I love talking to guys too, but if my calendar starts filling up I will rate-limit y’all first to leave space at the front of the line.) If you are a white dude who hasn’t been following me on twitter for at least a year, this offer is not for you, sorry. If you’re a marginalized person in tech, otoh, I don’t care if you use that hellsite^W^Wtwitter or not. And if you hate my blog, you are not gonna like me any better live & unfiltered. 😬

🍃🌸🌼Sign up here🌼🌺🍃
(please read the instructions!)

Things I am generally well-equipped to discuss include startups, observability, databases, leveling and promotion issues, management, the pendulum, senior and staff levels, new manager issues, team dynamics, startup executive teams, and some complex workplace You Had One Job and You So Failed ~ 27 pics | Team Jimmy Joe | Building fails, Construction fails, Architecture failssituations.

Things I am not equipped to help with include how to improve diversity at your company, how to get women to want to work for you, or why only men are applying for your jobs online. I cannot be your personal DEI coach or guide to women in the workplace (there are great consultants out there doing the lord’s work, and you should give them all your money). I can’t find you a new job, help newbies find their first job (sorry 😕), give advice on raising venture money or tell you how to found a company (answer: never found a company, it’s the literal worst). In general I am not very well equipped to discuss early career issues, but if you’re an URM and you’re desperate i’ll give it a shot. I am not a therapist. And if you’re going to ask should you quit your job, I will save you a phone call: yes.

charity.

Know your “One Job”, continued

Know your “One Job” and do it first

Story time.

Susan was hired as a database engineer. Her primary projects, which are supposed to be upgrading/rolling out a major point release and running load tests against various config options and developing a schema management tool, keep slipping. But she is one of HR’s favorite people because she is always available to interview, even at short notice, and gives brilliant, in-depth feedback on candidates.

Susan also runs three employee resource groups, mentors other women in tech both internally and external to the company, and spends a lot of time recruiting candidates to come work here. She never turns down a request to speak at a meetup or conference, and frequently writes blog posts, too. She is extremely responsive on chat, and answers all the questions her coworkers have when they pop into the team slack. Susan has a high profile in the community and her peer reviews are always sprinkled lavishly with compliments and rave reviews from cross-functional coworkers across the company.

Lately, Susan has been getting increasingly exasperated about her level. She is a senior engineer, but the impact of her work is felt all across the company, and many of the things she does are described in higher level brackets. Why doesn’t her manager seem to recognize and acknowledge this?

Actually, Susan’s manager is absolutely right not to promote her. Susan isn’t adequately performing the functions of her job as a database engineer, which is the “One Job” she was hired to do, and which her teammates are all relying on her to do in a timely and high-quality manner.

When someone isn’t meeting the basic expectations for their core responsibilities, it doesn’t matter how many other wonderful things they are doing. In fact, those things can become strikes against them. Why is Susan available for every interview at the drop of a hat? Why is she agreeing to speak at so many meetups and conferences, if she can’t find the time to perform her core responsibilities? Why doesn’t she silence Slack so she can focus for a while? These things that should be wonderful positives are transformed instead into damning evidence of personal time mismanagement or an inability to prioritize.

When you are meeting expectations for your One Job — and you don’t necessarily have to be dazzling, just competent and predictable  — then picking up other work is a sign of initiative and investment. But when you aren’t, you get no credit.

This may sound obvious, but I have seen everyone from super junior to super senior fall into this trap — including myself, at times. When you get overwhelmed, all of your commitments can start to feel like they are of equal weight. But they are not. “You had One Job”, as the kids say, and it comes first.

Extracurriculars can feel like obligations, yet these are qualitatively different from the obligation you have to your core job. If you did only your core responsibilities and none of the extras, your job should not be in any danger. But if you don’t do the core parts, no matter how many extras you do, eventually your job probably will be in danger. Explain to your coworkers that you need to hit the pause button on electives; they’ll understand. They should respect your maturity and foresight.

If you’re feeling underwater, scrutinize what’s on your plate. Which are the parts you were hired to do? the parts that are no one else’s job but yours? Focus on those first. If you need more time, cut down or hit pause on the electives until you’re comfortably on top of things again.

Do you have too many core responsibilities? Those should never add up to 40+ hours of work every week. Everyone needs some flex and variety in their schedule.

If you are having a terrible time summoning the motivation to do the work you were hired to do, or if this is a recurring theme in your life, then maybe you are in the wrong role. Maybe you really want to find a role as a developer advocate instead of a software engineer. Maybe you just aren’t into the work anymore (if you’ve been there a while), or maybe you don’t know how to get started (if you’re new). Maybe it’s even as simple as mentioning it to your manager and reshuffling your responsibilities a bit. But don’t assume the problem will solve itself.

Take these feelings seriously. All of us need to buck up and plow through some work we don’t find engaging from time to time. But it shouldn’t be the norm. In the long run, you’ll be happier and more successful if you are truly engaged by the work you were hired to do, not just by the extracurriculars.

charity.

Know your “One Job” and do it first

How much is your fear of continuous deployment costing you?

Most people aren’t doing true CI/CD. Most teams wait far too long to get their code into prod after writing it. Most painful of all are the teams who have done all the hard parts — wired up continuous integration, achieved test coverage, etc — but still deploy by hand, thus depriving themselves of the payoff for their hard work.

Any time an engineer merges a diff back to main, this ought to trigger a full run of your CI/CD pipeline, culminating with an automatic deploy to production. This should happen once per mergeset, never batching multiple engineers’ diffs in a run, and it should be over and done with in 15 minutes or less with no human intervention.

It’s 2021, and everyone should know this by now.

✨✨15 minutes or bust✨✨

Okay, but what if you don’t? How costly can it be, really?

Let’s do some back of the envelope math. First you’ll need to answer a couple questions about your org and deploy pipeline.

  • How many engineers do you have? ____________
  • How long typically elapses between when someone writes code and that code is live in production? _____________

Let (n) be the number of engineers it takes to efficiently build and run your product, assuming each set of changes will autodeploy individually in <15 min.

  • If changes typically ship on the order of hours, you need 2(n).
  • If changes ship on the order of days, you need 2(2(n)).
  • If changes ship on the order of weeks, you need 2(2(2(n)))
  • If changes ship on the order of months, you need 2(2(2(2(n))))

Your 6 person team with a consistent autodeploy loop would take 24 people to do the same amount of work, if it took days to deploy their changes. Your 10 person team that ships in weeks would need 80 people.

At cost to the company of approx 200k per engineer, that’s $3.6 million in the first example and $14 million in the second example. That’s how much your neglect of internal tools and kneejerk fear of autodeploy might be costing you.

It’s not just about engineers. The more delay you add into the process of building and shipping code, the more pathologies multiply, and you find yourselves needing to spend more and more time addressing those pathologies instead of making forward progress for the business. Longer diffs. Manual deploy processes. Bunching up multiple engineers’ diffs in a single deploy, then spending the rest of the day trying to figure out which one was at fault for the error.

Soon you need an SRE team to handle your reliability issues, build engineering specialists to build internal tools for all these engineers, managers to manage the teams, product folks to own the roadmap and project managers to coordinate all this blocking and waiting on each other…

You could have just fixed your build process. You could have just committed to continuous delivery. You would be moving more swiftly and confidently as a small, killer team than you ever could at your lumbering size.

✨✨15 minutes or bust✨✨

In 2021, how will *you* achieve the dream of CI/CD, and liberate your engineers from the shackles of pointless toil?

P.S. if you want to know my methodology for coming up with this equation, it’s called “pulled out of my ass because it sounded about right, then checked with about a dozen other technical folks to see if it aligned with their experience.”

 

 

How much is your fear of continuous deployment costing you?

Questionable Advice: “How can I sniff out bad managers while interviewing for a job?”

A few weeks ago I got a question from Stephane Bjorne on twitter, about how to screen for bad managers and/or management culture.

This is a great question. I’ve talked a lot about my philosophy for interviews, which boils down to equalizing the power dynamics as much as possible to reflect the reality that the candidate should be interviewing the company just as much as the reverse. You are all highly compensated subject matter experts who can find jobs relatively easily; there’s no reason all the judgment and critique should flow in a single direction.

But HOW? What questions can you ask, to get a feel for whether you will join this team and belatedly discover that you’re expected to be a jira ticket monkey, or that the manager is passive aggressive and won’t advocate for you or take a stand on anything?

Glad you asked.

First of all, backchannel like mad if you can. If you can’t, do ask the same question of multiple people and compare their answers. Pay particular attention to the different answers given by junior vs senior members of the team, and give extra weight to the experiences of any underrepresented minorities

Questions to consider asking the manager:

  • “How did you become a manager? Do you enjoy it?” Trust me, you never want to work for someone who was pushed into management against their will and still seems openly bitter about it.
  • “What do you like about your job?” Red flags include, “I was tired of being out of the loop and left out of decision-making processes.” That could be you next.
  • Is management a promotion here, or a lateral move? Do people ever go back from managing to engineering? Is that considered a viable career path?”
  • “What kind of training do you offer new managers, and what are they evaluated on? What are YOU evaluated on?”
  • “Do you have a job ladder for individual contributors (ICs)? Can I see it? Do the IC levels track management levels all the way to the top, or top out at some point?”
  • “What does your review and promotion process look like?”
  • “Are your levels public or private? What is the distribution of engineers across levels, roughly?” Here you are looking for how high the IC track goes, and how many engineers exist at the upper bound. Distribution should be scant at the upper levels, roughly an order of magnitude less for each level after “senior engineer”. Do the written level descriptions seem reasonable and appealing to you? Do you see yourself in them, and feel like there is a path for growth?
  • Do you have any junior or intermediate engineers, and how many? If not, why the fuck not?” Ask.
  • “How often do you have 1x1s with each of your direct reports? How often are the skip levels?”

And then there is the ur-question, which every one of you should ask in every single interview you ever have:

What is the process by which someone ends up working on a particular project?” In other words, how does work get decided and allocated? Bad signs: they get flustered, don’t have a clear answer, you have no say, there is no product/design process, it’s all done via jira assignments.

Pay just as much attention to their body language and signals here as the answer they give you. Are they telling the truth, or describing their ideal world? Ask what happens when there are problems with the  normal process, or how often it gets circumvented, or how you know if your work aligns with company strategy.

Questions to ask an engineer:

  • “What do you talk about in your 1x1s with your manager?”
  • “How often does your manager have career conversations with you, asking how you want to develop over the next few years?” Ideally at least a couple times a year, but really any answer is fine other than a blank stare.
  • “Does your manager care about you? Has working here moved your career forward? How so?”
  • “Have you ever been surprised by feedback you received in a review from your manager?” You should never be surprised.

Most of all, can you get the manager to tell you “no” on a thing you clearly want during the interview? (Maybe a level, or WFH schedule, or travel, etc.) Or are they squirmy, evasive, or hedging, or make you promises that they’ll look into it later, etc? Anyone who will look you straight in the eye and say “no, and here’s why”, is someone you can probably trust to be straight with you down the line, in good times and bad.

Depending on your level and career goals, it’s a good idea to ask questions to ascertain if the right gap exists for you to fill to reach your goals. Don’t join a team where five other people have the same exact skill sets as you do and are already eyeing the same role you want. (I wrote more on levels here.)

We also got some great contributions from @GergelyOrosz and @JillWohlner:

  • “Ask about specific situations, any half decent manager can BS on hypothetical stuff.”
  • “Who was the last person you promoted? Why/how?”
  • “How do you handle when X complains to you about Y? Can you give an example?”
  • “What was the best team you managed and why?”
  • “What is the biggest challenge the team currently has and why? What are you doing about it? Biggest strength?”
  • “How many people have left the team since you’ve been here?”
  • “Who was the last person to leave your team? Why did they leave?” (These leaving questions are tough to ask but will give you a lot of signal. Especially seeing how the manager frames it — are they playing victim, or owning up to it?)

Anyone who won’t be honest about their real personal weaknesses and struggles, probably isn’t someone you want to report to.

Jill says that she wants to hear from ICs:

  • when their manager has gone to bat for them
  • when their manager gave them hard to hear feedback (if it’s never, it’s a flag — all positive feedback = little growth)
  • when their manager coached them through a tricky situation

and from Managers:

  • when they went to bat for someone on their team
  • a team member’s growth they feel really proud of
  • when they got negative feedback about someone on their team and how it was handled

Obviously, you won’t be able to ask all of these questions in an hourlong slot. So ask a few, and lean in whenever they seem avoidant or uncomfortable — that’s where the juicy stuff comes from. And personally, I wouldn’t consider working somewhere that sees management as a promotion rather than a peer/support role, but that may be a high bar to clear in some parts of the world.

Good luck. Joining a team with a good manager can be one of the best ways to accelerate your career and open the door to opportunities, in part because it ensures healthy team dynamics. Workplace friction, bullying, harassment, passive aggressiveness, etc can be truly terrible, and even in the milder cases it’s still a huge distraction from  your work and a big quality of life issue.

A manager’s One Job is to make sure that shit doesn’t happen. It’s really is worth trying to find a good one you can trust.

Questionable Advice: “How can I sniff out bad managers while interviewing for a job?”

Questionable Advice: Premature Senior Followup Q’s

Some interesting followup questions arose from my recent post on the trap of the premature senior:

I found your blog (from Hacker News, I think) and your “Questionable Advice: The Trap of the Premature Senior” spoke to me, but I was wondering, do you have any followup advice on handling compensation in this situation? Should one be open to making less with this type of move, or is that not actually an issue?

You should ABSOLUTELY be open to making less. Consider it an investment in your long term career. Think of the extra money your company is paying you now as a hostage premium on top of your real market value. Staying isn’t what’s good for you, and that makes it hazard pay.

Your career is the single most valuable asset you have — it’s a multimillion dollar appreciating asset, and you should curate and guide it with an eye toward longevity. The first decade of your career is way, way too early to start optimizing for salary over experience.

This question was very relevant to me right now, as I recently spoke to a recruiter about a position that’s more in line with my career goals but pays less, and her immediate reaction was “don’t go backward on compensation.” But I can see the trade-off value in losing some comp to gain “better” experience.

Yeah, I think that’s terrible advice. 🙂 In general, if the compensation is fair and respectful, I think that is the absolute *worst* reason to make a job decision.

Salary is not a one-way escalator that you hop on after school, and gracefully exit at the peak upon retiring. It’s possible your recruiter’s advice was based on the assumption that your employers are likely to ask for your current salary and base their offers off of it. That used to be common practice, but is less and less so because of the fairness issues involved. Comp should be based on the value of your labor to the company, not your past comp, and in many states it is illegal to ask about your salary.

You may choose to take lower salaries at various times in your career — to work at a nonprofit or gov job, to learn new skills, in exchange for more flexibility or vacation time or titles or stock options, or as a result of moving to a different city or country.

I am not a financial advisor, but I am a big believer in retaining optionality. If the opportunity of your dreams came along with a starting salary of 150k, but every penny of your 170k salary is already committed, that’s a big loss of opportunity for you. This is a strong argument for trying to live well within your means, save religiously, and always have fuck you money in the bank. If you’re young and you get a salary bump, consider automatically diverting the raise into savings. Avoiding lifestyle inflation is the most painless way to save.

We have the unfathomable luxury of being incredibly well compensated for what we do. What is that luxury worth if we don’t use it to liberate ourselves, to facilitate happiness and fulfillment?

Questionable Advice: Premature Senior Followup Q’s