In order to interview, you might think you need to pretend to be a different person, walking an impossible line of conflicting traits. Calm but excited, confident but humble… talented but totally affordable.

You do not. You can be yourself and perform well in a behavioral interview! That’s because it isn’t about playing a character, but about telling a story you’ve told before.

What are you talking about?

When I say “behavioral interview” I’m talking about storytelling. Think “Tell me about a time you received critical feedback,” rather than “Invert this binary tree1” or “Tell me what an outer join is.” These are sometimes called “values interviews” or “culture interviews,” though each of those names carries a slightly different (and sometimes negative) connotation. Many interviews contain small behavioral bits, but the big behavioral interview is usually conducted by the Hiring Manager.

Isn’t this what the STAR method is for?

The STAR2 method is all well and good as a checklist of things you should be sure to cover, but it’s not a good way to construct that story. Steve “Meta” Huynh gives some good detail on this, including an example.

But in this article, I want to address a common mental blocker, not the tactical blockers that Steve addresses.

Playing a part

At first blush, these behavioral interviews feel artificial. You know you’re a strong engineer, and your past teammates know you’re a strong engineer3. But the first time someone gives you a prompt like “Describe a time you had to work on a team and something went wrong,” your response was probably not so great. After the rejection, it was natural to conclude: “I told them the truth, and they didn’t like the answer. Next time, I should lie.”

Let me push back against that conclusion with an example.

Practicing the story

Try to think about how you’d answer the question “What’ve you been up to this week?” from a friend or family member. Your answer is not going to be smooth. You’ll probably start with what happened most recently, realize some context is needed, explain some of that context, miss some pertinent facts, and thoroughly confuse the listener. Then, you realize they asked about your whole week, and try to remember what happened two days ago, think about checking your calendar, and give up.

Now to contrast, think about a story you’ve told a bunch of times. Maybe how you met your partner, or how you discovered your favorite hobby or author or artist? The first time you told that story, it sounded like that previous paragraph. These days, that story is smooth because people kept asking for it, and it got better each time.

With that in mind, try talking about your week again to your cat4. See the improvement in clarity and quality. Are you lying, or pretending to be someone you aren’t? No.

It’s about rehearsal, not lying

Every story is a tiny project, and the first draft of every project5 is a hot mess. Practice it, get feedback, and iterate before you deploy it in an interview for a job you care about.

Subscribe now

Is it a problem when you know more than your manager? Or, specifically for SWEs, how much technical expertise should your engineering manager (EM) have?

As usual, the answer is It Depends. Here’s the breakdown:

• There is an absolute minimum

• There is a higher, relative minimum

• It is useful for a manager to be above that minimum, with diminishing returns

• There is no maximum

Let’s take those one at a time.

There is a minimum

As the folks in my Slack community loudly asserted when I put this question to them, there's definitely a floor. If your EM knows nothing of what you do, it’s too hard for them to represent you to the org or understand your blockers, among other things. A few illustrative examples:

• One manager, in high-level meetings, would regularly make assurances to the rest of the C-suite that were flat-out untrue. This wasn't deceit, they just didn't know the specifics of what was technically possible! And worse, they were uninterested in learning those specifics, unwilling to admit “I’m not sure, let me check with my team,” and unable to get the more technical members of their team into that meeting.

• Another manager was unable to give even ballpark estimates on behalf of their team. They were asked by some external stakeholder to find someone to do a simple task, and they treated it like a quarterly project. (with awkward outcomes when their team found the ticket in Jira: "Oh, uh, I saw that spike deep in the backlog, so I clicked a button in AWS, which means the ticket is done now. I guess that's… zero story points?"). This is very frustrating for the stakeholder, and erodes their faith in the team.

• A major pain point for their reports was ignored for months by the EM. If the manager had been coding, they would have realized quickly that the issue was bad enough to be worth spending multiple sprints to fix.

What can we conclude from all this? You should be able to have a conversation about complex technical hurdles without your EM’s eyes glazing over. They don't need to be good enough to help you fix it, and it's fine if they have to ask a bunch of questions, but they should know what questions to ask in order to understand your blockers.

If they fake expertise, that's a big red flag. But be wary of over-interpreting this, since managers suffer from Imposter Syndrome just like you.

There is a higher, relative minimum

If there are no senior engineers around, your manager needs to be one or hire one.

Even if they hire one, the manager should not be way less technical than their entire team, else they'll be unable to answer any technical questions from leadership in real-time1. To be clear, it's fine if they are less technical than most of their reports, and it's even fine2 if they never code. In a healthy team, when someone gets blocked by something technical, one of their teammates will be able to step up to help.

They should know and account for their weaknesses. It’s fine for a manager to be bad at project management, as long as they can reliably find someone else they trust to manage the team’s projects. Similarly, it’s fine for them to be weak technically, as long as they can reliably find someone else they trust to help with technical design. Maybe that someone can be you!

To an extent, it’s good for them to be above that minimum

An EM is not just a SWE with a fancy title. Their duties vary wildly depending on what their team needs, but it’s a safe bet that they need to be great at giving feedback and communicating across teams3. Obviously, an engineering team has to have engineering talent, and the more such talent the manager has, the less they have to worry about hiring other people with those skills. But those skills can be delegated out more easily than feedback and communication can.

Let me put it another way: A good relationship between a manager and their report is one of partnership, not subservience. When they need a deep technical opinion, they can come to you. When you need to work towards a promotion, you can come to them.

Their job is different, so their skills are different. Technical skills are helpful, but gaining technical skills has sharply diminishing returns compared to gaining other relevant skills.

(Given how many engineers resent managers’ existence4, I should probably write an article about what they do at some point5.)

There is no maximum

What if your manager seems too technical? I’ve certainly felt this sentiment in my career, but it’s ultimately misplaced.

There is a risk that such a manager recognizes and relishes this skill, to the extent that they spend their time writing code that should spend supporting their team. Or worse, they tell their team exactly what to write instead of letting them learn for themselves6.

In the face of that, I’d say the problem here is not that they’re too technical, but rather about lacking something else: maybe delegation skills, maybe mentorship skills, maybe hiring skills. Avoiding a manager just because their technical skills are sky high is a misattribution. In a vacuum, all technical competency is an asset.

Do be wary, though, of how you use your 1:1s with such a manager; there’s a temptation to use all that time getting technical guidance, but it’s important that you leave some time for feedback, career progression, etc.

What do I do if they fail to meet this bar?

If you discover that your manager is below this bar, especially if your teammates agree, you have entered Managing Up territory. Again, this warrants another article, but I’ll give you two tools to start with:

In How to deal with jerks, we talked about giving critical feedback to people we don’t get along with. All the same advice applies to an insufficiently technical manager: build safety, talk about some of the data points that concern you, hear their analysis, and build a consensus. Maybe this is a huge miscommunication, and they have more competency than you think. Maybe they can learn technical skills by tackling some tickets7, or by taking courses. Maybe they can shift to another team. As with a jerk, escalation is always a valid option.

Depending on what skills already exist in your team, you might be able to find someone else to fill this niche. Lara Hogan calls this Building a Manager Voltron: with enough networking, you can find someone else to communicate technical stuff to leadership. If you have the technical and communication skills, that someone can be you!

To assess your manager, look at your team

I think a major source of this anxiety is a bias from early in our career: when we’re new to the job, our manager is surely our technical superior, and probably one of our best mentors. As we gain seniority, that inevitably changes, but our expectations don’t naturally adjust accordingly.

Don’t make the mistake of assuming that change is a problem. If your team has the technical skills it needs and your manager can follow the conversation, you should be fine.

Two of my favorite journalists, Casey Newton and Molly White, recently moved off of Substack. Since I am also on Substack, I’m trying to figure out what this means for this newsletter. Here are my thoughts at the moment; please tell me yours in the comments.

Leave a comment

Some context

Like all online platforms, Substack hosts a bunch of content that I disagree with. This spans the whole magnitude-of-disagreement spectrum, from "has a bit too much faith in the free market" to "explicitly advocates global genocide"!

All platforms draw a line somewhere on that spectrum about what sort of content they allow1. These lines are always blurry; that's why most companies have some sort of Trust & Safety team to adjudicate2. The nature of the platform partially determines where I think that line should fall; I’m fine with overt Nazis having internet access3, but I'm not OK with them having YouTube channels. Substack, thanks to its recommendation engine, feels more like the latter than the former.

To Substack's credit, when Casey asked them about six obviously awful accounts, Substack quickly banned five of them. But they also made it very clear that going forward, users would be responsible for reporting these. They plan to make zero effort to detect these sorts of accounts on their own. To me, this feels like a very low bar, and Substack has chosen not to invest the resources to clear it.

Does it make sense for me to leave?

My situation is rather different than Casey’s and Molly’s. Their publications are much bigger; Casey has 170,000 free subscribers to my 100. Importantly, they also have paid subscribers, and Substack collects 10% of that revenue. Since I have no paid subscribers, Substack is losing (a marginal amount of) money with this newsletter. On the other hand, I’m also driving (a marginal amount of) traffic to their other newsletters.

I would not describe Substack’s behavior on this matter as atrocious. They banned the obvious drivel when it was reported. Twitter is probably worse, and 4chan is definitely worse. But I’m not really on Twitter or 4chan, and both Facebook and Google (not exactly bastions of morality) do better.

If I leave, I’ll probably move to Ghost4. They promised Casey they will do a bit more than Substack:

[Ghost’s] terms of service ban content that “is violent or threatening or promotes violence or actions that are threatening to any other person.” Ghost founder and CEO John O’Nolan committed to us that Ghost’s hosted service will remove pro-Nazi content, full stop.

Migrating would be a hassle, but not as painful as it was for Casey/Molly since they had to deal with payments.

But I’d like to hear from readers about this, too. Are you comfortable reading a newsletter hosted on Substack? Would this deter you from paying for this newsletter, if that became an option? Is there something I’m missing in my reasoning? Let me know in the comments, in the Slack community, or via email.

Update [2024-01-24]

I wanted to close the loop on this. Ultimately, it doesn't look like it's currently worth the costs to make this migration.

This is frankly quite painful for me. We rarely encounter moral choices in our day-to-day, so it feels bad to take the easy way out on this one. But like all decisions, I have to consider the tradeoffs:

• Substack's product is, as far as I can tell, the best for what I want: a newsletter that looks good without my making any design choices, with support for footnotes, images, and subtitles. Ghost, Wordpress, beehiiv each fail one or more of these tests.

• Reader opinion was generally mixed and mild. Unsurprisingly, most of you fall roughly where I do: migrating feels right, but this isn't an important issue. There are a few outliers in both directions.

If one of these things changes, I'll reassess. As always, thanks for all your input5!

This is a time of year that people ponder changes.

I don’t like New Year’s resolutions. As I said in my last article, setting a distant, fixed goal (“I’ll read 100 books“, “I’ll cut my food spending in half”) is ironically not a great way to reach that goal. But in my life, I’ve deliberated plenty of changes over this turning of the year. And since many software engineers I talk to are wracked by indecision about whether to stay or leave1, let’s talk about that.

In support of resisting the change

You folks like personal stories, right? Here are some personal stories.

I stayed at Upstart for a long time. For a few years, whenever someone left, I assumed they knew something I didn’t. Why would they leave me, otherwise? But when I asked them why, their reasoning never clicked with me. One of them got a much better offer elsewhere, without interviewing. One of them was excited to join a friend’s company. None of their reasons ever seemed to quite apply to me, so each time, I decided to stay. I don't regret that.

Another example: I’ve had my fair share of difficult managers. Under one of these, I decided to stay and build up the relationship rather that changing managers (or companies). In the long run, this was enormously educational and beneficial for me (and them!).

Some folks I’ve talked to stay in place because they are, for lack of a better word, comfortable. They make enough to support their lifestyle and family, and they get sufficient stimulation from their current position, or from hobbies outside of work.

There’s plenty of material value in staying, even when the grass is greener elsewhere: with tenure comes clout and context.

On the other hand…

In support of making the change

I’ve met plenty of Upstarters who wish they had left the company earlier. I can’t say the same, but I do have to admit that I changed teams pretty frequently. One year, I changed teams twice! I had many different reasons for these moves, but if I had to pick one, it’d be boredom. If I get to pick two, I’ll add this one:

Steven Levitt (of Freakonomics fame) did this little pseudo-scientific study: asking people to flip a coin to decide whether to stay or go, and asking them 6 months later whether they regretted it. On average, the ones who changed were glad the coin had flipped that way. Of course, there’s always a risk of revisionist memory, and those people cannot know what would have happened if they’d stayed.

I mentioned comfort in the previous section as a reason to stay, but for some people, it’s a reason to leave. If your goal2 is to found a company before you hit 30, comfort is a liability, not a feature.

So there’s plenty of value in leaving. New work means new perspectives and new growth, and no learning curve is insurmountable.

You just made a case for both, how is that helpful?

Look, I’m not going to come down hard on one side or another. Simple answers are sus3, and I’d be a hypocrite to unilaterally endorse either path, since I’ve followed both! But maybe we can use the above stories to distill a few useful heuristics:

Are you bored by your current role?

Boredom is generally fixed by making a change. But before making a huge change, investigate smaller changes first. Maybe you can change projects or teams, which is way easier than changing companies! Absolutely talk to your manager about this; it’s a common problem, and they’re well-suited to find small changes so they don’t have to replace you.

What’s the cost of making the change?

Would you have to go back to school for a few years? Would the change burn any bridges?4 Would you need to spend time interviewing at a bunch of companies, or has a clear opportunity arisen?

Is there a specific opportunity in front of you that excites you?

Is some other team working in a domain that you have personal interest in? Is one of your favorite people hiring?

If your answers to these three questions are “yes, low, yes,” make the change. It’ll be fine.

My answers are “maybe, medium, maybe” so what do I do?

Fine, fine. If you insist on an answer, in a vacuum, I have to suggest just making the change. Even if there’s a 50% chance you regret leaving, that regret will come with growth, so the EV of the change is positive.

But if you’re on the fence like this, it’s especially important that you not burn any bridges. Don’t slam the door, don’t point fingers5, and give people as much advance notice as you can. Software engineering is a smaller world than you think.

Just don’t torture yourself about it

Let’s be honest, you’ll be fine either way. If you miss an opportunity to change, another one will come. If you change and regret it, you can change again (and maybe even change back).

So I think the biggest mistake people make is beating themselves up about whichever path they choose. Don’t do that. That’s Bob talking, and he’s just jealous that you can change and he can’t.

Looking at my blog’s short description, it says:

Writing about the stuff I like to talk about. Mostly the non-technical parts of software engineering. Sometimes other things, probably.

That “probably” has been poorly evidenced, since I’ve thus far only talked the non-technical parts of software engineering. Let’s change that!

With Mint shutting down, I and thousands of other people are scrambling to find a service to replace it.1 So maybe it’s a good time to write about another topic I like to talk about: personal finance. More specifically, about a common anti-pattern I see in budgeting.2

Arbitrary limits don’t work, even when you set them

I’m going to tell you two totally unrelated stories.

You are a software engineer.

Your PM asks you to set the deadline of a complex project you’ll be implementing3. They emphasize how many customers are excited about this feature, and how visible the project will be to the org, so you set yourself an ambitious deadline. The PM announces the release calendar, and crows about you to everyone who will listen. You feel like a complete boss. You buckle down with your IDE in Focus Mode, and your Pomodoro timer at the ready.

Halfway through, you realize that you will not be done in time. Maybe you cut scope at the last minute, disappointing the PM by delivering a bare-bones outcome. Maybe you work overtime, taxing your family and your own mental health. Maybe you ask for an extension, disappointing customers. You feel like a failure, and your next performance review takes a dive.

You are an adult in a capitalist structure.

You don’t know how much money you’re spending. You don’t know what you’re spending your money on. Maybe you run out of money before your next paycheck, and you scramble to buy more time or take more debt until your account refills.

You’ve heard you’re supposed to have a budget. Maybe you try using Mint? You spend a weekend feeding a bunch of bank/card statements into it, you decide how much you’ll spend on each category, and maybe you install an app that tells you when you’re near your limit. It seems hard, but now that you’ve written down your commitments, things will finally turn around!

Things don’t turn around. Your food budget runs out partway through the month, but your family still needs to eat, so you overrule the app. You feel like a failure and you’re wracked with guilt, so you don’t bother to update the budget next month.

OK, I was lying, those stories were related. One month’s spending, and a one month software project, are both complex and unpredictable beasts. You cannot simply choose to spend less money next month, any more than you can simply choose to work faster (without sacrificing quality). And there are immediate consequences for under-promising, and delayed consequences for over-promising:

It feels like you’re damned whichever way you go! You feel like a failure, or you incur another overdraft, or the business suffers, or your career suffers.

Now even though I’ve just explained the parallel, I’m going to immediately abandon it. The problems are similar, but the typical solution for project planning (cutting scope, usually) is not the solution I recommend for budgeting: focus on tracking, and forget about setting limits for now.

Measure twice, cut later

This may seem a bit pointless, but bear with me.

Optimizing the performance of our code is generally pointless until we know how it performs in production. We learn how it performs in production by configuring metrics, and by watching those metrics over days and weeks to see what patterns emerge.

Similarly, you’re likely to spend your cost-cutting effort in the wrong places if you make cuts before setting up your metrics. You’ll miss your targets, get discouraged, and abandon the whole effort.

Then how do I setup metrics for my spending?

Software to the rescue! Instead of DataDog, SumoLogic, or CloudWatch, you’ll use YNAB, Quicken, Tiller, or Mint Monarch (these are referral links).

1. Add your financial accounts so the software can consume all your transactions from bank accounts and credit cards, and auto-categorize them.4

2. The software will pull in 1-3 months of transactions. Pore through all of those, correcting the numerous mistakes, and add an auto-categorization rule for each so that it doesn’t make the same mistake again. This is the most time-consuming part of the process (still easier than cost-cutting, though).

3. Ignore any budget or cash flow sections for now. Until you have a lot of well-categorized data, those dashboards will be confusing, wrong, and demoralizing.5

4. Watch the transactions stream in over the next three months, continuing to correct categories and create rules (weekly, or as needed).6 If you’re diligent about creating rules, the auto-categorization will become very reliable in this time.

At the end of this, you’ll have 4-6 months of clean, accurate data. Celebrate your glorious victory.

How is this a victory? I’ll still be spending too much money!

It is a victory on the way to that larger victory. You need to measure before you can cut.

I’ll start categorizing my transactions next month, because this month is a weird one.

You can’t possibly know that’s true unless you’re already categorizing your transactions. Human brains are not good at detecting patterns in big lists of numbers, unless you can sort and filter them. You need to feed them into one database, with plenty of metadata, before that’s possible. That’s exactly what the metrics are for.

The software shows my budget as red, and that demoralizes me.

I told you not to click on the budget tab!7

Wait, you folks are software engineers, right? Just change the CSS of the page so it’s something inoffensive, like cerulean. Oh, or make a new budgeting app!

No.

That’s fair, I don’t want to either. Just don’t click on the budget tab.

The most important step is the next one

Do not excoriate yourself for not having a handle on your finances. It’s an inherently complex domain, and we do a bad job of training our kids on financial literacy.

I’ll write another article next year about making cuts, so since this transaction-tracking process takes three months, start it today.

If you love your manager but are looking for a new job anyways, you should tell them that.

Ow, OK, I immediately hear millions of voices suddenly crying out in vigorous disagreement. Let me address them one at a time:

My manager is the reason I’m leaving!

If you’re fleeing your manager, this advice is not for you. Close the article, and maybe read about interviewing instead.

My manager isn’t the reason I’m leaving, but I don’t trust them.

Have they given you a reason to distrust them, or are you haunted by the ghost of a past manager’s betrayal? Regardless, I suppose it’s not worth investing time to build trust in a relationship you’re already trying to get out of. This advice is not for you. Close the article, or maybe share it with someone it might be better suited for!

Share

I generally trust my manager, but don’t they have an obligation to treat me differently if they know I’m looking for the exit?

Ah, now it gets interesting! My answer is a resounding “It depends”. Let me quote one of my favorite writers on this subject:

The key is to pay attention to how your employer has handled other employees who resign. Are people shown the door immediately? Pushed out earlier than they would have otherwise planned to leave? If so, assume the same may happen to you, and give two weeks and nothing more. But if your employer has a track record of accommodating long notice periods, has been grateful to employees who provide long notice, and has generally shown that employees can feel safe being candid about their plans to leave, take your cues from that. Some employers "earn" long notice periods and employees who keep kicking butt through their final day ... and some don't.

–Alison Green

I couldn’t say it better myself, so I won’t try to.

To be fair, if you read the rest of her article, you’ll see that Alison generally leans towards the “keep it secret” side of the decision. But that’s because1 she undervalues the benefits of divulging. Speaking of which—

I’ve looked around the company, and I gather that I’m unlikely to be punished for divulging. But why take the risk? What do I stand to gain from admitting that I’m looking for a new job?

Once you’ve determined that the probability of punishment is low, there are so many potential benefits to telling your manager:

• Depending on what you’re looking for, the manager might be able to find it for you internally.

  • For example, one manager I know was frustrated that their report left solely because another company was able to provide faster visa sponsorship: “If I’d known they cared enough to leave, I could have leveraged that with HR to speed up the process!”

  • Another manager was able to get their report a raise, and explained how the offer the report was considering2 was not as good as the report thought it was.

• Your manager knows your work better than anyone, and if they’ve done any performance reviews for you, they know how to talk about you to other people. So they’re a great resource when prepping for behavioral interviews.

• A soon-to-be-former manager is the ideal reference check. I’ve done a bunch of reference calls myself, and none were more impressive than hearing “I wish they weren’t leaving my team, but I can’t pay them what they deserve” from their current boss.

• If you give your manager plenty of time to fill your shoes, they will remember and appreciate that. Former coworkers and managers are the linchpins of your professional network, so this will pay dividends.

If that doesn’t convince you, think about how the C-suite does it: the most successful executives give their peers and board plenty of advance notice, for all these reasons. They know that they’ll be hard to replace, and they know the high value of keeping the esteem of their peers and leads.

Measure the risks and the rewards

Again, this advice doesn’t apply to everyone. If you have a bad-to-neutral relationship with your manager, or the company has a tendency to hurry people out the door, it’s not worth the risk. Otherwise, I strongly recommend it.

By metadata, I mean “Here’s an update about the newsletter, rather than an article itself.”

Hacker News

If Dan Moore sent you here by posting in HN, welcome! You might enjoy reading about imposter syndrome, or about telling the right story.

If you have questions or comments that you’re particularly proud of, I invite you to post them in the substack comments instead of (or in addition to) the HN comments. That way, my other readers can more easily see and respond to them. No pressure, I’m not the boss of you.

Community

If you like the stuff I write about, you might also like to join a Slack server I recently started. It’s mostly full of other software engineers who like to talk about the same stuff that I like to write about. No matter where you are in your career, we’re happy to have you; we have boot camp students, mid-level SWEs, and engineering managers (as long as they remember what it was like to be an IC). If you want to influence what I talk about, this is the best way to do that.

Click this invite link, or the “Slack” link at the top of the front page of the blog.

I talk to a lot of software engineers who are gearing up for a job hunt. Sometimes they left willingly, sometimes unwillingly, and sometimes they just anticipate leaving soon. In all these cases, they tend to be primarily worried about how to best represent themselves: in resumes, in take-home tests, and in interviews.

Much of that concern is well-founded. Interviewing is notoriously imprecise, because humans are too complex to assess in 5 hours. And yet, you have no other option1: the metrics are narrow and simplistic, so they are easy to game, so you have to game them because everyone else is.

I find this focus on interview prep to be appropriate, but disproportionate. You should spend some time on self-presentation, and there are a number of resources I recommend for this. But if you spend all your time there, you’ll be in deep trouble when you get an offer. You need to determine which job would the best fit for you, way before any offers appear.

Short on time, short on data

That’s because when you get an offer, it will come with some time pressure; usually on the order of weeks!2 Your first order of business will be to inform other companies in the running that you’ve received an offer, give them a chance to expedite their process, and then complete that process3.

After all that, by the time you have multiple offers in hand, you only have a few days to decide between them. That is not enough time to both decide what you want and understand which of those offers is best for you. So let’s talk about how we can accomplish both of these earlier in the process.

Decide what you want

It’s tempting to focus solely on the compensation and title, because money and status are, let’s admit it, quite nice. But they are far from the only things that matter. Reflect, if only for a moment, on each of these:

• Size or stage of company (How many rounds of funding? How many engineers? How many non-engineers?)

• Remote/hybrid/in-person (also location, if hybrid or in-person)

• Technology stack4

• Product domain (e.g. finance, medicine, media, manufacturing)

• Mission5 (For example, I’d have a hard time getting excited about high-frequency trading)

• Following people you’ve worked with previously

• Culture (e.g. collaboration vs. independence, wide vs. narrow focus, familiarity between coworkers)

(credit to Brian Mascarenhas for much of this list)

It’s very difficult for any of us to guess what makes us happy; we usually have to examine our anecdotal data to infer it. So when you scroll through this list of factors, don’t just ask yourself “Which of these sound nice?” Instead, try asking “In my career thus far, when have I felt most happy and fulfilled? During those periods, what was my job/company like?”6 For any factors that you don’t have any anecdotal data on, view your next role as an exciting experiment, and try to do something deliberately different than what you’ve done in the past.

Understand the job

Now that you understand what factors matter to you, let’s talk about how you assess each company, and the role you’d occupy within it. Remember that, since you’ll be short on time when the offer arrives, you need to understand the job before you get the offer. You might not be able to discover the compensation early in the process, but you can and must learn the rest.

Most of the factors listed above are easy to ask about but also easy to forget to ask about, so write them down somewhere7. Culture, on the other hand, is quite tricky to get a good signal on. The key here is to interview your interviewers with tough behavioral questions8. Deliberately construct these questions to make it easy for the other person to shed light on the factors that matter to you.

• “Roughly what does the promotion process look like? Have you ever seen someone who struggled to get promoted, even though you thought they deserved it?”

• “What’s the most painful or obnoxious part of your job?”

• “How frequently do you collaborate with your teammates on a project? Can you give me a representative example of what that looks like?”

• “What kind of critical feedback have you heard from your manager? How often does that happen?”

  • “What about positive feedback?”

  • “What about feedback you gave to your manager?”

• “What’s a typical conversation that you have with a product manager over some feature you’re implementing or debugging?”

• “Can you give an example of a time that a major part of the product failed? How did the company handle it?”

• “What sorts of topics are typically covered during manager 1:1s, and in what ratios?”

If you have other fun questions to ask interviewers, let other readers know by leaving a comment!

Leave a comment

Oh, and remember to ask the same question to multiple interviewers. If you get wildly different answers, that’s not exactly a red flag, but it’s definitely worth digging a bit deeper9.

You’re an interviewer, too

Having interviewed the interviewers, you’ll have a clear picture in your head of which job will best satisfy your needs. Compensation can be negotiated, but culture cannot10.

A ham-handed metaphor: it takes two to tango, and it takes a lot of time to learn to tango. Tango is just like signing a job offer (in this one very specific way). So take the time. Prepare yourself to be interviewed and to interview, and make sure to do both in every call.

In my earlier article Mind the tales you tell, I talked about the importance of deliberately crafting the stories you tell about who you are. I want to focus today on a specific type of story: why you left your last job, if it wasn’t your choice (that is, you were fired, laid off, or managed out)1.

This is a pretty important story to nail down since it’ll come up in interviews, and it’s a common place where folks disqualify themselves. Your first draft of this story is probably a negative one. Maybe you’re angry at the manager who fired you, or maybe you completely blame yourself? Neither of those stories are worth repeating; not to yourself, and not to recruiters.

Before you try to tell that story, take some time and do some research.

Take some time

Don’t interview immediately2. Losing your job is a (small ‘t’) trauma, and trauma requires time to heal. Give your vitriol some time to drain.

Moreover, having some space from the event will make it easier to tell the right story about it. With a bit of distance, you might realize that you were already mentally checked out of the job, or that you had let inertia keep you there, or that you were bored or tired.

Heck, if you can afford it financially, take a few months! No one will so much as blink at a 6-month gap for a software engineer, and even a longer gap can be explained.

Do your research

During this break, let’s do some shopping for other perspectives.

Make sure to get contact info out of any and all coworkers you respect and enjoy3. Use this sudden windfall of time to schedule calls with them, and try to get their perspectives on what happened.

• “What should I have done differently?”

• “Have you seen a situation like this elsewhere?”

• “Were there other factors behind the scenes that I wasn’t aware of?”

Your goal is to find a good story to tell recruiters, and better understand what kind of company/manager/role/team you want next. Your goal is not to enact vengeance, nor convince your contacts to follow you out the door.

In fact, if you left on good terms with your manager, they’re likely to be a great resource here! Use the same tools I discussed in my previous article to extract better feedback from them. Freed from the responsibility of managing you, they might be able to say things they couldn’t before4.

Before you hang up (and assuming you enjoyed the call), schedule a recurring call with them5. Even if you only talk once per year, you’ll forget they exist otherwise. This is how networks are formed!

Tell your story

Now that you’ve taken some time and shopped around for perspective, it’s time to work on your story. It might be helpful for you to try writing it out, but personally, I find these stories easier to speak than write6.

The ideal story describes a mix of contributing factors, such that no one factor would have been sufficient to condemn you.

Blame others

It’s safe to partially blame the circumstances: systems, random happenstance, macroeconomic conditions, etc. It’s also fine to partially blame other people, though you want to be careful to avoid anything even close to an ad hominem attack (trigger words are “incompetent”, “corrupt”, “greedy”). Focus on their incentives and their background.

“I refused to play politics so I was backstabbed by my teammate” is a bad story, but “I should have sought out and listened more closely to detractors before publicizing my plan, so I was caught off-guard by their pushback” is very reasonable.

Blame yourself

In most cases, you should also partially blame yourself. But as when you’re blaming other people, be sure to stay far away from ad hominem attacks against yourself. You aren’t incompetent, corrupt, or greedy either. Own your mistakes, and pivot the story around them, but cast yourself as a student, not a fool or villain.

“I’m bad at time estimates” is a bad story, but “I missed one deadline, so I took an even more aggressive deadline the next time in a misguided attempt to prove myself” is totally sympathetic. Follow it up with a learning, like “I should have spent time talking through the edge cases with the PM before making a commitment.”

Practice

The first few times you tell the story, it will be awkward. You’ll repeat and contradict yourself, and the listener will ask questions that you won’t know how to answer. Don’t be tricked into assuming, just because your story sounds bad, that the underlying truth is bad. Practice, rewrite, and find a different way to say it.

Tell only truths

Storytelling is not lying. There are a million different ways to accurately describe what happened, and none of them are exhaustive, and all of them are true7. It is OK to completely omit certain facts, as long as that omission does not fundamentally alter the story. It is not a good idea to fabricate anything whole cloth; that’s the sort of thing that tends to catch up to you in an enormously destructive way.

Hero’s journey

Ultimately, what you want to put together is an accurate story that casts you and your former employer in a generally positive light. Like any good protagonist, you are flawed, but you’re learning8, and you’re eager to learn more in your next role.

In the spirit of stomping on overthought, I’m trying out a new article format. Instead of going through a painstaking 10-step, 3-week process to create the perfect article replete with footnotes, I’m going to write about something that I’ve had a couple recent conversations about: getting a job that you’ll like more than your last one.

In short, you’re overthinking it1. If you suspect that you want a new job (for whatever reason), just submit a few applications. If you’re not sure whether that job posting will actually make you happy, apply and find out (before you accept an offer, but after you apply). If you’re not sure whether you know how to do technical interviews (anymore, or at all), apply and find out.

If they ignore your application, you’ve learned you need to work on your resume. If the recruiter never calls you back, you need to work on your storytelling. If the rejection comes after the coding interview, you need to practice coding interviews.

Share

Deprioritize2 introspection. Deprioritize complaining at parties and meetups. Deprioritize reading a bunch of articles like this one3. Apply to a bunch of jobs that look vaguely like one that you think you might want, and go from there.

Some people are frustrating to work with; for the sake of this article, let’s call them jerks. But you’ll never find a role without jerks, so it’s probably worth figuring out how to work with them! Fortunately, figuring out how to work with them will also make them less jerky.

The Jerk Zoo

I doubt you need my help identifying jerks, but for the sake of example here are some of the stories I hear a lot:

• The teammate who criticizes every little thing you do

• The teammate who lashes out whenever you give a suggestion1

• The manager who gives unactionable feedback, or worse, zero feedback

• The PM who pushes you to add a new feature without giving you more time

• The cross-team collaborator who’s spending all their time on some other project

This list could go on for pages, but I don’t think anyone would read that article2. Sometimes these folks frustrate you with their words, and sometimes with their silence or inaction. What they have in common is that, if you found a new job and discovered that they would be your teammate, you would be less likely to take that job.3

A hidden path

Let me make a few wild guesses about your typical plan when confronted with a new jerk. You try to figure out how to get around them. You dream of getting them fired, but as a realist, you resign yourself to avoiding them. You pick projects that don’t involve them, or change teams, or change companies.

There’s a chance that these are your best options, and I’ll talk about them more under The fallback plan below. But I have good news: there’s another path, hidden in the underbrush, that works a majority of the time. It doesn’t require you to abandon your favorite project, or your teammates, or go through the hassle of another job search.

Instead, you can usually transmute your jerk, alchemy-like, into a non-jerk. Here’s how.

Step 1: Safety

Some bad news first: you will need to have an awkward, uncomfortable conversation with your jerk4 in order to transmute them.

It’s tempting to assume that this conversation will necessarily devolve into a shouting match. So let me assure you that this will only happen if you let it. There’s a kind way to say absolutely anything, even the sharpest critique.

They, too, will go into this conversation expecting the worst: that you’re trying to change their mind or get them fired5. So you need to unambiguously and repeatedly state your intentions to the contrary.

• Good: I’m trying to understand your point of view.

• Bad: I’m trying to make you less of a jerk, because Simon apparently thinks that’s possible6.

• Good: I want to figure out how we can work together more smoothly, and move this project forward in a way we both support.

• Bad: I want to beat you in a debate!

Try to anticipate some of the things they might suspect of you, and promise not to do those things.

• I’m not trying to trick you into a contradiction.

• I’m not trying to change your mind.

• I’m not trying to get you fired.

Finally, given all these disclaimers, ask their permission to ask a bunch of questions. They will probably say yes, begrudgingly and/or reluctantly.

Step 2: Curiosity

People always have a reason for doing the things they do. You probably have a few assumptions about this person’s reasoning, but those assumptions are mostly wrong. So the next step is to understand where they’re coming from, and why they do the things they do and think the things they think.

• What are their incentives? Who determines whether they get a raise or promotion, and how does that choice get made? Is there some obscure metric by which the entirety of their performance is assessed? Have they staked their credibility on one particular feature they promised to vendors?

• What are their limitations and bottlenecks? Budget? Headcount? Personal time?

• What is their history? Have they been burned by people like you in other companies? Do they associate your design philosophy with some failed project in their past?

• Is the feeling mutual? Do they think you are the real jerk, or are they totally oblivious to the tension between you? How would they characterize your relationship?

Try to make it feel like a casual conversation and not an interrogation. Repeat the disclaimers from Step 1 as needed. Hedge your questions:

• “I was wondering why…”

• “I’m curious whether…”

• “I’m beginning to wonder if…”

• “I have the vague impression that…”

Whenever they say anything that feels true or relatable to you, tell them that emphatically, since this will encourage them to say more. But at this early stage, resist the temptation to attack the things they say; most of your sentences should end with a question mark. Rhetorical questions (“Do you really think that’s true?”) don’t count as questions!

Next, invite your jerk to be curious about you, in turn. Look at those questions above, and answer them about yourself. Be forthright in your answers; don’t hold back just because you think it will give them the wrong impression of you. When you think you’re likely to be misinterpreted, just admit that and clarify. It’s fine, I promise, and it gives them space to do the same. Invite them to dig deeper and ask follow-up questions; it’s normal for this to take a significant amount of back and forth until you’re on the same page.

What you’re doing here is filling up a Pool of Shared Meaning7: the set of pre-existing “opinions, feelings, theories, and experiences about the topic at hand.” You don’t need to agree with their weird opinions and biases, but you do need to know what they are, and they need to know what yours are.

You know you’re ready for the next step when you can both authentically say “I see where you’re coming from, but the two things we each want are incompatible.” This second clause is the biggest incorrect assumption of all! If you can get on the same page as another person, you can almost surely find a solution that gives both of you (most of) what you want8. It’s time to find that hidden third option.

Step 3: Consensus

People are complex, and their actions emerge from a wide, deeply-nested tree of root causes. So it’s statistically unlikely that there’s some fundamental or foundational difference between the two of you, because the space of all such trees is so vast. Once you understand one another, and trust that you are acting in good faith, you can frequently find an outcome that both of you will be OK with.

What that solution looks like depends on the nature of conflict between the two of you. If you disagree about how to implement some shared project, maybe you can figure out the part of the project that each of you care the most about, and favor the preferences of that person in that corner of the project. If it’s just a matter of rubbing each other the wrong way in meetings, find some tiny behavior modifications that are easy to make, but have a huge impact on how much the other person is bothered.

The fallback plan

The above strategies will usually work. In fact, you’re not allowed to read the rest of this section until you’ve tried them! I’m serious, scroll up, I’ll know if you don’t.

But sometimes, folks will prove intransigent despite your best efforts. Maybe they refuse to even engage with you. Maybe your backgrounds are too different to find common ground. Maybe they refuse to believe any third option exists. In this case, your only remaining options are escalate or avoid.

Escalate

There’s a chance a lot of people are struggling to work with this person, but if none of them have reported it to company leadership, there’s not much to be done. Talk to your manager, and/or their manager, so that they can spot a pattern if one exists.

If the person you’d escalate to is part of the problem, you should go up a level. Most managers-of-managers are quite interested in hearing feedback about their reports. But if you go through a couple levels of this, that implies that a significant part of the company is incompatible with your working style. At some point, it is reasonable to give up and fall back to avoidance of the whole gosh-darn company! Speaking of which…

Avoid

This was probably your default choice anyways, so I almost hesitate to mention it. But it is a valid choice, in many situations. Be mindful of the cost, which tends to scale depending on how close you are to the person:

• If you can get expenses approved by your friend in Finance, it’ll probably be pretty easy to avoid some other person in Finance.

• If they’re a cross-team collaborator, you can try to avoid projects that touch that team’s domain. This is likely to slow your career progress, but career progress is worth less than happiness.

• If they’re on your team, you’d probably need to transfer to another team, which requires time and high performance (or a fervent ally elsewhere in the org).

• If they’re your manager, avoiding them probably means leaving the company, since they would likely need to approve any transfer.

It was a trap

You’d know this if you’d read the footnotes: I was lying when I said you could transmute someone. However, you can transmute yourself into a person who can be productive and happy alongside most jerks, and also maybe stop thinking of them as jerks, just like we did halfway through this article. And, to be sure, your bitter and frustrated feelings towards them are absolutely valid! But you can only control your own actions; thankfully, that is enough.

More than coding, more than writing, more than testing; this one weird trick will drastically unlock the number of engineering roles that you can be happy with. Since you’ll have to learn it sooner or later, you might as well learn it today.9

The things you say about yourself matter. This is true even when those things are said in jest, and also when you only say them to yourself.1

It is good and proper to have an opinion about what we are good at, and what we are bad at! But when we describe ourselves, we are also shaping ourselves, so we want to do this with great care.

Storytime

I’ve been wary of doing this in any of my articles so far, but to clarify what I’m trying to say, I think it’s time for a personal example. I invite you to skip ahead to the next divider if you just want the recipe without learning my whole life story.

Since time immemorial (or maybe middle school), I had poor memory. I’d forget assignments, peoples’ names, and things I’d said. My mother suggested I write things down to mitigate this, so I wrote down the important stuff like homework assignments. It felt a bit too weird to write down “The guy who sits next to you in Spanish is named Steven” or “Today you told that great turtle joke.”2 So I forgot those things, and joked that I could never remember them because “I don’t keep a journal,” and of course never started a journal so that I could keep using the joke.

This line worked as intended for lots of years. Seriously, like 15 of them! I don’t think I have any old friends who haven’t heard it. Whenever I forgot something, the narrative was strengthened; when I did remember something, it went unremarked. Since everyone knew I couldn’t be relied upon to remember names, they generously lowered their expectations accordingly.

A few years into my engineering career, my manager declined to lower their expectations. They asked “Have you ever thought about actually keeping a journal?” I gave a great list of reasons that wouldn’t be helpful or practical.

“Have you ever tried improving your memory?” I obligingly checked out a couple books they suggested on the topic (I liked books, and that manager), and decided that the techniques within were just not my cup of tea.

They didn’t push.

But my next manager pushed; that was their, ah, distinct style. They said “You often use that excuse to justify your mistakes or gaps in knowledge. Maybe you have a bad memory, or maybe you have a good one; I’ve seen plenty of evidence in support of both. But regardless of its truth, it is an excuse, and it colors your reputation. You would be more successful if you stopped using it.” I was offended, but also weirdly flattered that they thought it was possible for me to do this.

In the end, I didn’t even need a book. I just stopped saying I had a poor memory, and so it stopped being true to the people around me. I still forget plenty of things, just like everyone else.

The crux of the issue is that, through the power of confirmation bias, repeated negative stories like mine usually become self-fulfilling prophecies.

I hear a wide variety of these when I talk to other engineers about their careers. Some of these tales come from a depressive mindset, like “I’m just not good at this.” Sometimes it’s a joke, like “I don’t keep a journal.” Sometimes it’s more accusatory, like “No one listens to my ideas.” Sometimes it’s situational, like “Being on-call always sucks.” Sometimes it’s sarcastic, like “Did you hear my covert narcissism I disguised as altruism?”3 And none of these stories are helpful!

In order to keep your stories out of this trap, they must be singular, scoped, or strategic.

Singular

There is incredible power in repetition. Even when unsupported by evidence, the phrases you casually toss around your home or office will inscribe themselves upon your friends’ and coworkers’ consciousness. Even when you repeat the stories to yourself, and even when you initially know they aren’t necessarily true, you will gain confidence in them merely by thinking them repeatedly.

So, if you spot a negative narrative that you want to rob of power, it must be viciously quashed wherever it appears.

Quashing externally is relatively straightforward: just don’t say it out loud. It’s hard to break a habit, so enlist your friends and family to call you out on it.

Quashing4 internally is much harder, but equally vital. Intercept the narrative when the thought appears in your brain. Identify the storyteller as Bob, not you. Find some evidence that runs contrary to the story (evidence, not proof; proof doesn’t exist) and print it out to hang on your wall. Speak the evidence out loud, and present an opposing narrative in opposition: “I remember why I made this design choice two years ago; I have a fantastic memory, not a poor one.”5

Alternatively, if this is a narrative that you want to empower through repetition, make sure that it doesn’t overreach by narrowing its scope.

Scoped

There are a few common missteps that I want to address here.

When you phrase the story as if it has ended or is permanent, you’re implying that the state of affairs cannot possibly improve. This is false; the story is unwritten, and the pen’s in your hand6. Leave open the possibility of change by saying “I’m still working on this” rather than “I’m bad at this,” and “That last on-call shift sucked” rather than “Being on-call sucks.” If there’s a pattern, identify it as a pattern, but never imply that the pattern is permanent: try “Being on-call is currently a full-time job.”

Similarly, “No one listens to my ideas” is an incredibly strong and surely incorrect statement. No people listen to any of your ideas? This might be scoped down to “I didn’t get much traction in my last two RFCs,” or “My manager tore apart my last PR review.”

Pare it down to pure fact. It’s good to recognize patterns, but be very explicit about what is fact versus feeling. “I feel like I’m struggling with this,” not “I’m not good at this.” Your intuition is valuable and worth sharing, but also fallible and worth disclaiming.

Be intentional about how and where you share each story. In a small group of people you’ve worked with, you have more space for authenticity and vulnerability. So it’s healthy to share your feelings with your manager in a 1-on-1… but in an all-hands post-mortem, stick more closely to the facts.

As an engineer, I suspect you’ve already identified a few edge-cases in my advice? Before you leave an angry comment explaining what I missed, let me discuss a broad category of what I’ll call strategic exceptions.

Strategic

This last one is a bit of an advanced technique: sometimes, it’s useful to carefully construct a story to achieve a specific goal, and that goal requires you to abandon scoping.

The first time you’ll want to do this is when you’re looking for a job. It’s OK to repeatedly call yourself an incredible, ambitious engineer in applications and interviews, even if (when?) you don’t really feel like one.

Later in your career, you’ll find that this sort of story is necessary to enact broad organizational change by motivating people towards some nebulous goal. Since different people respond to different narratives, you’ll want to craft and target your stories accordingly.

This is a big topic that I can’t totally cover in this article. Ok, now you can yell at me in the comments if you want me to write that article sooner rather than later, or if I missed your favorite example. Here’s a button!

Leave a comment

A note on complaining

One common anti-pattern of these stories is the complaint. “I need to keep complaining about this issue to my team, or else we’ll never fix it.” This is valid, but when you raise such an issue, you want to be deliberate and intentional about it: how you phrase it, and who you’re talking to.

When you tell the story to people who are unable to get it fixed, all you’ve done is demoralize them, and diminish their faith in your team. Instead, if you have the ability and latitude to fix it, do that. If you need someone else’s support to get it fixed, petition them for that support. But repeated, unvarying complaints are not a petition, they are self-destructive noise.

How does it serve you?

To be clear, this is not a call to suppress7 your inner monologue from leaking out of your mouth. Heck, my last article endorsed authenticity! But there’s an important difference between admitting “I feel like I’m no good at this” to your manager when they check in on you, as opposed to declaring “I’m not good at this” when they ask what your blockers are. The former is a factual confession of your internal state, and the latter is an easy shield that obscures the real problems.

Stories have power, even when made in solitude or in jest. This isn’t magic, it’s just psychology8. Focus on how you want each of your stories and jokes to serve you. Identify which ones are constructive, and which ones are destructive. Repeat them accordingly, sculpt them carefully, and target them wisely.

If you’ve been burned by company leadership (or anyone else, but let’s stick to your work life for now), it’s tempting to adopt a defensive stance when working with new people. This is a mistake. Trust is too valuable to wait to give it. There are risks, but they are easily worth it.

Why trust is hard: little betrayals

Trust is hard because you’ve been burned before.

• You were judged for asking a question.

• You were thrown under the bus when a deadline was missed.

• Your PM told you to build the wrong thing.

• You admitted a challenge (maybe a disability, a personal crisis, or an insecurity) that was held against you in a performance review.

Let me be clear: none of this was OK. Whichever coworker is responsible was in the wrong. But is it fair to your new coworkers to punish them for the sins of your prior ones? Is it fair to yourself?

There’s a voice in your head that tells you Everyone Will Betray You1, so you need to protect yourself. That voice is Bob, and as always, his advice is bad.

Why trust matters

If you don’t trust a coworker, they can tell. You are worse at disguising your feelings than you think you are. This discourages them from trusting you, in turn. Without that mutual trust, you can’t form strong relationships.

And strong relationships are… everything, frankly. Humans are a social species. If someone trusts you, they’ll respond positively to your suggestions and requests, they’ll give you feedback, they’ll think of you when new opportunities arise, they’ll ask you what you want instead of guessing, and they’ll give you the benefit of the doubt. Over time, these relationships will form your network, and you need a network for your career to thrive.

One truism that is actually false is “Trust should be earned, not given.” It’s impractical to expect someone to prove themselves to you if you don’t risk anything. People can only handle so much suspicion or cynicism before they give up on trying to reach you! You need to give a little, and risk a little, so they can do the same.

The hidden cost of hypervigilance

Let’s take a look at each of the examples I raised earlier, and talk about what you’re missing by closing yourself off.

If you suppress a question because you don’t want to look stupid, that’s a great way to look much stupider in the future. You learn by asking questions, and you’re denying your teammates a precious opportunity to teach what they know by staying silent.

If you blindly build whatever you’re assigned to cover your ass, you’ll get promoted more slowly, since experienced engineers are generally expected to have an opinion about the product. And of course, if your company is building the wrong stuff because employees are too scared to push back, business will suffer, which will cascade to you in subtle (or sometimes very loud!) ways.

If something in your personal life is making work more difficult, your team will eventually notice. If you let them know before someone calls it out, it will not sound like an excuse. This vulnerability-sharing is also a great way to form unexpected bonds with coworkers who may have been through something similar in the past! Even saying something curt like “I have some stuff going on” will evoke less sympathy and understanding than actually telling your story2.

In all these cases and others, in a good company, the people around you will prioritize solving the problem over finding a scapegoat, and reward you for delivering value even if it wasn’t what they requested3.

And if you’re under a bad manager (or in a bad company), and they fire you for a mistake or for trying to solve the underlying problem, they’ve done you a favor.4

I can’t just choose to trust someone!

That’s true, you can’t. But you can choose to act with authenticity, speaking out loud that thing you feel. Ask the question. Push back on the plan that makes no sense. Give the feedback. Tell your manager (and/or HR) what you need to do your best work.

If it helps you to push through your fear, hedge by signaling uncertainty and curiosity:

• “Maybe I’m missing something obvious, but…”

• “I wonder whether we should instead…”

• “Would it make any sense to…”

• “I’m not sure I’m following. Do you mean…”

• “I’ll understand if this isn’t feasible, but it would help if…”

• “I don’t know if this is a pattern, but here’s one data point: …”

• “In my past work, this went poorly because …. Can you help me understand why this situation is different?”

And you needn’t trust your teammates or leadership blindly! Trust, but verify5. They make mistakes and have blind spots, just like you do. They’re doing what makes sense to them, and they probably care about your well-being. You’ll be pleasantly surprised by how often people will do the right thing when you give them a chance.

In my last article, I wrote about a defensive response to being rejected for a promotion. A few observant readers pointed out that this is not the only common response; another is the self-critical one: “I guess I don’t deserve to be promoted.” I wanted to dig a bit into this, especially since that sentiment hits me where I live.

The Thought and its Catalyst

Actually, let’s talk about that whole family of self-critical little stories. Here are a few of its siblings:

• “I’m not good enough at this.”

• “I’m not a ‘real’ engineer.”

• “I should be fired for this screwup.”

When one of these Thoughts barges its way into your consciousness, it was usually summoned by some unfortunate event, which I’ll call the Catalyst because I’m insufferable. Just to name a few examples, off the top of my head, that I’ve heard (or um lived):

• My code broke production

• My PR was rejected in its entirety

• My promotion was denied

• My favorite mentor left the company

The narrative that emerges is that the Catalyst provides evidence that the Thought is a fact: “I’m bad at this, so my PR was rejected”. But in truth, the causality runs in the other direction: “My PR was rejected so I think I’m bad at this.”

Sometimes the real Catalyst is outside the workplace, connected to the Thought by a long causal chain. For example, if your apartment floods or your kids get sick, you’re not going to blame your work ethic. But you are likely to run short on energy, which degrades the quality of your work, which breaks production...

You probably know all this. In fact, when you say it out loud, I bet you can immediately recognize what’s going on: Imposter Syndrome has reared its ugly face.

Power in naming

You recognize it easily because you can see it so clearly in other people. When your favorite actor or writer delivers that heartfelt diatribe about their own inadequacies, it seems obvious that their inner monologue deceives them. The notion that Taylor Swift could think that she’s never achieved anything of significance is silly!1

But when it comes to your own self-judgement, the voice of Imposter Syndrome feels painfully true, like Everyone Has Imposter Syndrome, Except You. Even when your loved ones call it out within you, you smile and agree, but you don’t really believe it. You are grimly sure that you have tricked them. In a feat of mental acrobatics, you juggle two2 incompatible thoughts at once: “This is probably just Imposter Syndrome” and also “I’m actually not that great.”

Since the Thought is coming from inside the house your head, it’s tempting to assume that it carries as much validity as all your other thoughts. So to disempower it, we’ll instead attribute it to a monster that lives in your brain.

Molly Graham, one of my favorite writers on the subject, named her monster Bob. I’m going to shamelessly steal both the name and the art.

Bob is not you, but he is trying to protect you. By constantly critiquing you and evoking every worst-case outcome imaginable, he hopes to make those outcomes better! Tragically, he is so very bad at his job. So let’s figure out how to pat him on the head and send him on his way, instead of letting him dictate our actions.

How to build self-empathy

Your loved ones are great at spotting when Bob is in control. That applies in both directions: you can hear their monster’s voice coming out of their mouth, too. But we don’t call it out in ourselves, because we have more empathy for our close friends and family than we do for ourselves. That’s good news, because it means we already have the skills we need to intercept Bob:

1. Talk or write out your fears, doubts, and whatever Catalyst “proves” your apparent incompetence.

2. Choose whichever Loved One (maybe a partner, sibling, or child) you most instinctively protect3.

3. Imagine if they said all of (1) to you, about their own life. What would you think? How would you support or comfort them? What evidence can you find to contradict their thesis?

4. In your mind’s eye, transform your Loved One into you. Say the same thing.

The key here is that you already have the ability to convincingly contradict Bob, because you leverage that ability in your relationships with others. Trick yourself into using it on yourself. Be your own Loved One; you deserve it.

You don’t need Bob to motivate action

A warning: when you use this strategy to fight Bob, he’ll fight back.4 “If you ignore me and stop criticizing yourself, you’ll never get any better and you’ll keep making the same mistakes!” Ah, a classic “tough-love” defense. And I suppose he’s partially correct: you do need to take action, but he’s wrong that you need his help to do that.

• If you broke production, add tests.

• If your PR was sent back to the drawing board, talk to your reviewers and figure out what really needs to change.

• If your promotion was rejected, take the solid advice in this great article.

• If your favorite mentor left the company, find a new one (either within the company, or in the community at large)

• If your kids are sick or you need to move, explain what’s happening to your manager and ask for whatever space you need.5

Note that none of these actions require shame or anger. You can change and improve without an iota of help from Bob! The hard part is learning to do this every time Bob chimes in, because he chimes in a lot6.

Getting rejected for a promotion feels awful, but is not a disaster. It’s not even a setback. It’s probably the greatest opportunity to grow that you’ll have in the next few years. Instead of being a bummer on all of your Zoom socials, here’s how you can realize that opportunity.

Rejection and Response

When your manager comes to you with the rejection, they’ll give you a reason. I have a prediction: it’ll probably sound like complete BS1. Here are a few of the classics:

• “You haven’t had a broad enough impact on the organization.”

• “You haven’t demonstrated enough independence in your projects.”

• “The work you’ve taken on has had smaller scope than what is expected of the next level.”

• “You haven’t built up enough consensus around your ideas.”

None of these sound very satisfying, because none of them are immediately actionable. And the handful that are actionable, you’ve already done! Maybe this sounds familiar: “I’m doing the projects that you gave me! You said I’ve done good work, so why aren’t I being rewarded for it?”

I have an alternate suggestion that will put you on a better path: thank them.

What can you control?

Look, all of your objections and feelings around this are completely valid. Maybe you feel robbed, maybe you’re angry, and you have every right to be so.

Your manager could have given you all this feedback months ago, before promotion decisions were finalized. They could have given you more impressive-looking projects. They could have written a better proposal for your promotion, or argued more convincingly on your behalf in the calibration meeting.

All of this is outside your immediate control. Your response will be the same, regardless of the mistakes your manager made or the hoops they want you to jump through. They hold the keys. But you are anything but helpless, and there is so much you can do even with the worst of managers.

Extract better feedback

Better feedback is buried somewhere in your manager’s brain, and you can tease it out with probing questions.

Set the stage for your questions.

Earnestly thank them for what they’ve given you. Management is hard, and giving critical feedback is harder. You want to make it clear that you’re not trying to trap them, or prove them wrong. You’re all on the same side, here. You just want to understand what happened, so you can improve going forward.

Ask questions until you understand their viewpoint.

Here’s a handful to get you started.

• “What are some examples of the behavior that you saw, or didn’t see?”

• “Have you ever received this sort of feedback in your career? What did you do with it?”

• “How far along the company’s promotion process did I get?”

• “If I need more independence, how can I show this? Ask fewer questions? Where/when/how should I get help?”

• “If I need broader impact, who hasn’t heard of me or my work? What kind of projects do those people tend to care about?”

• “If my projects are too small, what bigger projects can I do? Why haven’t I seen those yet?”

Importantly, you don’t need to agree with their viewpoint; it’s useful to know why they hold it.

Confirm your understanding

Complex communication (e.g. most feedback) gets lost in translation. Take a minute to breathe, review your notes, and reflect your understanding of your manager’s expectations back to them.

If you go back and forth with them a bit on this, that’s perfectly healthy. Once you grok their perspective, ask for some time to think about this and get the perspective of other people you’ve worked with. Reassure them that you’re not trying to go over their head (like most humans, managers are insecure sometimes).

Shop it around your network

Your manager’s opinion matters more than most, but they are only one person with limited perspective. There are lots of other people who are likely to have an interesting contrasting take on all of this.

Your current teammates, your current skip-manager, former teammates or former managers… each of them has interacted with you in a different context, and will see the feedback you extracted from your manager in a different light. So show it to them, and ask your network what they think.

• “Does this match your perception of me?”

• “Have you received or given feedback like this? Where did you go from there?”

• “What would you do with this, in my situation?”

None of them will be weirded out by this. If anything, they’ll be flattered that you came to them for advice! Try to ask a variety of people: some who are close to you, some who are more detached, some who are famously empathetic and others who are, ahem, notoriously critical.

Beware that plenty of people in your network will, by default, assume that you’re there for emotional support. You surely need some of that, and you should take as much as you need. But you also want perspective and advice, so thank them for their support, and make your goal explicit.

Validate your findings

Of course, this wide net of feedback you cast is another link in a chain of complex communications. So as before, you’ll need to validate your findings by documenting them and presenting them to your manager.

There’s a chance they’ll disagree with your summary. This is exciting, because it means you’re getting new feedback from the person whose opinions matters the most! You’ll have to repeat the steps above, but it’ll be worth it.

Alternatively, they might agree completely… which is also exciting, because now you have a path forward that your manager supports! I guess that means both outcomes are exciting.

Check back continuously

  Be assured it’s not a
  one-and-done.
  Reference it in every
  one-on-one!

Please forgive the rhyme; I swear it occurred naturally and Liz said I should “lean into the cringe.”

You should feel comfortable referencing that summary in every one-on-one you have with your manager. Point out your wins and your roadblocks. Give them a chance to disagree, clear your path, and celebrate.