Tips For Better Meetings

Managers work through meetings. In this short post, I posit three dimensions along which we can improve meetings and present tips that have had the most impact on my meetings along these dimensions.

Growing up as an engineer, I equated meetings with wasting time. Naturally, when I become a manager, I tried to reduce or eliminate meetings, which did not work (duh!). I failed to understand that meetings are a manager’s work. I might as well have been trying to become a champion swimmer by eliminating water.

Andy Grove’s High Output Management was the bright light that cut through the darkness of my anti-meeting feelings. Grove devotes an entire chapter to meetings, calling them “the medium of a manager’s work” (good summary). He decomposes meetings into different classes, identifies why they are necessary, and builds a framework around how much time and energy should be devoted to these. For the first time, things made sense.

Since that step-changing moment, like any competent engineer, I have been focused on optimizing meetings. To make something better, we have to agree on what “better” means. I think of improving meetings on three dimensions:

  1. Correctness: did the meeting achieve a good outcome? If it was a decision-making meeting, did we make the right decision?

  2. Efficiency: how quickly did we get to our goal? Did we communicate clearly?

  3. Culture: did people feel included and heard? Did people move forward as a team, even if they disagreed with the outcome?

In the sections below, I present tips that have made material differences along each dimension. This note is not a comprehensive survey; it’s meant to be a quick 1–2–3. For the impatient: skip directly to the tips in bold.

A disclaimer: This material is not original. The business world has studied meetings forever. This 1976 article (HBR) is one of the best on running good meetings. Here’s New York Times and Rands In Repose. My contribution is to distill tips that you can copy without having to read through tons of meeting-theory.

Another disclaimer: Meetings can range from huge (company all hands) to tiny (1–1s). Somewhere in between are the 5–15 people meetings where a company’s crucial work gets done. This article is about those meetings.

Correctness ✅

I am a big fan of Kahneman’s Thinking Fast and Slow (video summary). Our savannah evolved brains are hardwired to do what he calls “Type-1 Thinking”. When our ancestors saw a lion, they didn’t spend much time thinking deeply about their choices; they climbed a tree. The ones that thought hard aren’t our ancestors. When we sit in meetings where we see material for the first time and have to pass judgment under the gun, we are engaging in Type-1 thinking.

The alternative is to engage the slow brain. This deliberate, rational process is called “Type-2 thinking” in Kahneman’s lore. Engaging the slow brain is challenging: it is genuinely hard work and time-consuming. But it leads to better decisions on complex topics.

Correctness Tip: Send out materials 24 hours ahead to be read as homework. 📖

Engage your slow brain. Read in the peace of your home or wherever you can think deeply. Think about it in the shower, or on your run, or wherever you do your best thinking.

Sending everything out as homework is taxing. Gathering materials and putting things together a day early shifts the schedule. It also forces more work on everyone attending the meeting: they need to spend time reading, digesting, and preparing for the meeting the day before.

My advice is to ease into this: try doing this with your most important meetings first, then work backward until pre-reads become team culture.

Efficiency ⏰

People have put much energy into making meetings more efficient. Good meeting hygiene goes something like this:

  1. Send the agenda out ahead of time.

  2. Define and focus on the goal.

  3. Keep track of time.

  4. Make a decision.

  5. Write whatever was decided and send it out to everyone.

There is some variation, depending on the type of meeting, but mostly variations on the same theme.

I believe #2 is the most important. It is amazing how many meetings people go to and ask, “why are we here?”. Or we are halfway through the allotted time, and we haven’t even talked about the most important thing we are here for. What’s the problem? We are missing a goal.

Efficiency Tip: Have a clear and stated goal. Focus the conversation on said goal. 🎯

Meetings with unclear goals tended to meander off course, people ratholed on things that were secondary to the task at hand, and these meetings mostly resulted in follow-up meetings, with no actual progress made.

Start your meetings with an articulation of why you’re all in one place and what success is.

“Let’s talk about making things fast.” is not a goal statement. We can talk about the topic for a long time, but to what end? Is it because we think the site is slow? Is someone complaining? Or do we believe in speed as an engineering value and want to enforce it?

“We are here to decide whether or not we should invest in performance right now.” This statement clarifies our purpose, what success would look like (a decision, positive or negative), guides the conversation (is your point germane to deciding whether we should invest now or later?)

To build this discipline, start each meeting by asking two questions:

  1. Why are we here?

  2. What would success look like at the end of the meeting?

You may feel this is rote work, but soon, the team will adapt, and these questions will be answered in the material before anyone has to ask.

Culture ✨

Humans are social animals. Meetings aren’t just about getting work done. There are a lot of other things going on in meetings — signaling social status, validation of ideas, people, and their work, building a sense of Team. We can pretend to be robots, but we aren’t (yet).

The cultural aspects can go very right — people come out of meetings with clarity, purpose, camaraderie, eagerness to make progress — or it can go very wrong — people not feeling heard, hurt feelings, anger, and frustration at adverse outcomes.

Leaders tend to focus a lot of correctness and efficiency, but forget about the cultural element. To build a strong, cohesive team and organization, pay attention to this part.

When I was working on Facebook Stories, we observed a phenomenon in any prominent meeting. As things were getting started, people would walk into the review room — and make a beeline for the chairs on the side while the table was unoccupied. Even worse, the people sitting off-table were often women or minorities or people who were shy or reserved by nature. They might be the primary authors and experts — their work was about to be presented, but they didn’t sit at the table.

Culture Tip #1: Everyone sits at the table. 🪑

(The credit for this tip goes to Adam Mosseri, Head of Instagram, boss extraordinaire. He would publicly call out people and get them to sit at the table, even if he had to stand on the side.)

We may think this sort of physical signaling doesn’t matter. And most meetings nowadays have some people dialing in remotely. Our non-scientific evidence would suggest otherwise.

Designers should present designs. Researchers: research. Data scientists: analyses. This idea seems obvious but is rarely the case in practice. Typically, the Product Manager, or the person synthesizing the materials to create one cohesive narrative, presents the work. Additionally, she also takes the first stab at answering questions, all while the primary author, the expert, is sitting in the room. Net result: people feel voiceless.

Culture Tip #2: Authors present their work. 👩🏽‍🔬

Let primary authors talk about their work, even at the cost of interrupting flow. Changing speakers mid-flight seemed awkward at first. Presenters want to control the room because they feel it will get them to better outcomes. However, we’re not in the middle of a sales pitch; we’re in the middle of trying to come together as a team and work things out.

One way to ease into speaker rotation is to enforce crediting. “Liz and the research team found this through their survey work. I am going to talk through this, but they’re the experts.” Clear attribution gets you halfway there.

In its most optimal state, speaker rotation makes everyone on the team feel valued. They feel like the leader knows who they are, and cares about them, and binds them closer as a result.

Every meeting has someone that talks too much (I know; I used to be that guy) and people that don’t speak up, even when they have the best knowledge or the most astute and relevant opinion. It is the leader’s job to make sure they have heard from everyone in the room by creating space for the quietest people to speak.

Culture Tip #3: Everyone speaks at some point, and nobody interrupts. 💬

The way to accomplish this is to quiet the loud person — indirectly: by giving them high cognition tasks like being the scribe, or directly: by telling that you understand their perspective and would like to hear from others instead.

Getting the quiet people to speak can be harder. The most effective technique, in my experience, is to directly ask them. “Jo, what do you think?” Keep a mental track of who has spoken and remember the people dialed in on Zoom.

Also — getting people to speak up is not useful if they get interrupted or passively ignored. Both these behaviors make people feel like nobody cares or values their thoughts. Fixing interruptive or ignoring behavior takes work and courage. One has to call out the interrupter publicly, and often, the person interrupting is the leader. The best people do this, gain the respect of everyone in the room, and build stronger teams as a result.

Parting Thoughts

I hope you incorporate one or more of these tips into your meeting repertoire. If you had to pick only one, I’d recommend the pre-read / homework tip. I guarantee it will make your decisions and outcomes better.

Do you have tips that have made your meetings infinitely better? I’d love to hear them (so would the world!). Drop me a line.


I’m your host, Rushabh Doshi. After spending nearly a decade managing some of the brightest engineering teams at Facebook and YouTube, I’m taking a break and doing some writing, spending time with my family and figuring out my next thing.

You can find me on Twitter @radoshi and my writings at or

If you’re not signed up for the news letter, you can do so here:

Durable Decisions

One of my favorite internal posts at Facebook outlined a framework on making sticky decisions. This post is a rewrite of that original "Durable Decisions" post by Ficus Kirkpatrick, in turn based on  ideas and input from Nikhil Chandhok. The credit for the idea and framework go to them; this post is written by me since I have more cycles to write.

Your team needs to decide whether to focus on making your product faster or building a feature that is going to be the next Big Thing. The team follows best practices, does its homework, runs it by you. Decision made. We are focusing on building the feature.

Fast forward two weeks, and you hear rumblings. The star engineer on the team is working on speed. The feature isn't making as much progress as everyone would like. Three weeks in, the team has started to work on speed and drop the feature altogether. It just happened. Four weeks in, the feature is not built, and the product isn't significantly faster either. Oops.

So, what happened? We made a decision four weeks ago. Then something changed. And the decision unmade itself over the course of a month. Can this be avoided? How?

Enter durable decisions.

A durable decision is one that doesn't change if its inputs haven't changed.


1. Goals

What are the goals of the project? What are non-goals? Is a project results-bound (done when metric X is at threshold Y?), delivery-bound (done when feature 𝝰 is shipped), or time-bound (done in a month)?

The goal discussion is almost always the right place to start. Disagreements at this phase result in significant downstream thrash. Have precise goals (and non-goals) and write them down.

2. Assumptions

We are baking in many assumptions when we come up with various options. Time, money, technical capability (CPU, GPU, RAM, disk, network), people (how many people, how much bandwidth), this list goes on. 

Assumptions are the second biggest reason (after unclear goals) for decisions to fall apart. People either assumed different things, or those assumptions changed. Exhaustively documenting every assumption is not a good use of time; documenting the major assumptions, those that are likely to break or cause disagreements is a good use of time.

3. Options

Come up with a good list of options, including tradeoffs between them, or the rationale to choose one over another. Take care to not get too attached to one option over another; we are human, and this is natural. A mentor gave me a pretty good trick to get over this attachment. He said: 

You don't understand your opponent's argument until you can argue their points, just as strongly, on their behalf, without them being in the room.

Understand your options thoroughly and *drumroll please* write them down.

4. Decider(s)

Be explicit about who is making the decision: some person, some committee. When things change in the future, you'll want to know whom people should go to talk.

Gathering Inputs

To make a sticky decision, get everyone's buy-in. The best way to get them bought in is to get them involved in making the decision early on. You need to consult people to gather input, to build your set of options, to understand all the assumptions that are being baked in. 

Consult the stakeholders. Talk to everyone that is likely going to get affected by a significant decision. More buy-in at this stage reduces the chances of follow-on debates.

And finally, *surprise!*, Write It Down. Somewhere where everyone can see, read, comment, access. Be transparent, disseminate all your materials widely. Remember: there are going to be people who're not even on the team yet, that will want to know "why did we do X" in the future. This document will explain things clearly, including the conditions, set of choices, and the decision making rationale.

Make The Decision

This post isn't about how to make the decision itself. There are scores of books written on this subject; my favorite is Chip and Dan Heath's Decisive. This book lays out a useful 4 step framework to make sure you're defending against your own biases, considering all the information, and giving your slow brain a chance to think. This post is a good summary, along with their WRAP cheat sheet.

Regardless of the framework or process you use, this is the time to make the decision. You have all the inputs, the assumptions, the options. Make a call.

Communicate, Communicate, Communicate

Communicate the decision: quickly, clearly, and as widely as possible. Repete thyself: people are unlikely to understand everything on the first try. For strategies on effective communication, see "Communication is The Job," by Boz, an excellent communicator and head of AR/VR at Facebook, where he lists out eight strategies he uses.

Did I mention that you should write it down?

From Durable Decisions to Disagree and Commit

The start of this article defined durable decisions. The side effect of making durable decisions is that if the inputs don't change, the decision shouldn't change either.

Often, there will be a set of people that disagree with the decision. It is tempting to grumble about this, let it lie for a bit, and then re-open the debate and revisit the decision at a later point in time, with the hope of overturning it.

If the decider lets a decision by revisited, without substantial new input, the whole system falls apart. 

Even worse, people stop believing that decisions are sticky and put less effort into the decision making process because they know those decisions aren’t final. 

Having durable decisions means that they cannot get overturned if nothing has changed. This principle forms the basis of "Disagree and Commit": you may disagree with a decision but have to be fully committed to making the product/team/company successful by going along with the implications of the decision.

The hardest decisions are typically the closest calls. Knowing that you'll revisit the decision if the circumstances change will give you the confidence to get behind it. We make the most progress when we're running together at full speed, not pulling against each other in doubt.


Hey! I’m your host, Rushabh Doshi. After spending nearly a decade managing some of the brightest engineering teams at Facebook and YouTube, I’m taking a break and doing some writing, spending time with my family and figuring out my next thing.

If you enjoy these articles, please drop me a line and let me know. You can find me on Twitter @radoshi. If you’d rather get these posts in your mail, you can subscribe to my newsletter.

A Most Useful Management Framework

Management books are full of different leadership and management frameworks and advice. A lot of these use contrived examples and war stories that are hard to replicate. Over the course of a decade of managing engineering teams, I have found Situational Leadership to be the one framework that applies to a broad range of scenarios, is practical enough to be easily understood and applicable, and tremendously valuable once you know it.

Life at

Amy and Bob are two engineers on the FizzBuzz team, building the next great feature your product needs. Amy thinks deeply about the underlying data structures and problems; Bob is a front-end ninja.

However, managing them is rather challenging. Amy often feels like things are a bit too easy; her output is variable; you think she might be unmotivated. There is no shortage of work, but she hesitates to pick up new work before asking you.

Bob, on the other hand, is **really** into FizzBuzz. He was so into the product that he applied to join your company out of school and couldn't wait to get started. Bob works hard but often gets stuck on things. Even worse, the quality of his code can be variable - he makes bad architectural calls, copy-pastes when he shouldn't, and doesn't test enough.

What should you do?

Employee Behaviors

Amy and Bob are two different engineers; they need different approaches to being managed. What are some specific things you can do to make them both individually successful?

The underlying core thesis behind Situational Leadership is the solution to this problem.

We can segment the engineers along two axes - ability/competence and willingness/confidence/security. Depending on where they are in their journey, you can use different techniques to help them. This theory is not new. Ken Blanchard and Spencer Johnson wrote about this in One Minute Manager, first published in 1982.

Note: My 2x2 is slightly different from what you'll find by Google searching situational leadership. I'll explain the traditional model below and why I prefer to start with the people view rather than the manager view.

In our case, Bob seems highly motivated and excited about his work. But he may not be able to do the work - he just joined FizzBuzz out of school, and this is his first job.

Amy, on the other hand, is highly skilled. She can knock stuff out at will, and produce high-quality products. She may lack the confidence or the motivation to get her work done and be the independent rockstar you know she can be.

In other words, the picture that emerges is something like this:

Our goal is to get both Amy and Bob to be high performing engineers - who are highly competent, motivated, and self-directed.

How do we get there?

Manager Behaviors

How should our behavior change when working with Amy or Bob taking into account their different stages? We can think of leadership on two axes (surprise!): Supportive and Directive.

Highly directive leadership is mostly "Do this, in this way, by this time." There is no autonomy and little opportunity to be creative. The opposite is complete autonomy: the freedom to pick problems, priorities, solutions, and timelines.

Highly supportive leadership is akin to being a great coach. You give feedback. You ask hard questions. They can come to you when they are stuck or need to problem solve. The opposite is being left entirely alone: engineers solve their problems, and the results are the feedback (did the product succeed?).

Bringing It All Together

Now we a rubric for helping Amy and Bob.

In Amy's case, we need to Sell (S3 in situational leadership parlance) - give her the confidence to take on more and more challenging tasks, encourage her to seek out problems, to go after things she thinks are essential without having to check back with us. We still need to give her feedback to both help her grow and increase her confidence and security. But in no case should we micromanage her or give her task-specific direction.

For Bob, we need to be more directive (S2 in situational leadership parlance). Some might interpret this as micro-management, and that's okay. But Bob needs a tight feedback loop and smaller, lower complexity tasks. As Bob grows in his ability, he will graduate to more challenging projects while maintaining a high level of quality and delivery.

Where does it all go?

The end goal is to get to Delegation holy land.

Doesn't that put the manager out of a job? Yes! That's the whole point - build enough leverage and capacity on your team that you don't actually have to do anything - and then grow the team or seek other challenges.

In delegation mode, the manager is both low directive and low supportive. They are not giving the employees direction or feedback. Does that sound bad? Every CEO, every leader of a sizeable organizational unit, every person who is out on their own lives in this mode. If the employee is so good that they need no management, they are ready to take over your job!


One Minute Manager might have been plagiarized from Arthur Carlisle's work in MacGregor.

The 1-1 Zoo

This is a post about the different types of 1-1 I have encountered in my life. It is almost as if 1-1s were animals in a zoo. Seasoned managers will quickly identify a member of each species and know how to deal with them. Newer managers might mistake a tiger for a house cat, and lose a limb in the process. As a manager with plenty of scars (yours truly made nearly every wtf mistake in the post below), I hope to help newer managers not get mauled when they misidentify a 1-1 animal.

A quick aside: this post is not about the reason for 1-1s, or why you should have them regularly, or why you should have a 2-way agenda, or what you should discuss in them, how to give and receive feedback, etc. There are a plethora of articles on that, including a whole app to help you run them better. Instead, this post is about real-world situations managers encounter, for which an app can't tell you what to do. If you're interested in learning more about the mechanics of 1-1s, drop me a line, and I'll write it out.

If you've been managing people for a while, these 1-1 types will appear familiar to you. I'd love to hear about ones that I missed to add to the zoo. Comments and feedback appreciated - @radoshi on Twitter.

🐶 No Agenda Chill

Engineer: "Hey, boss, what's up? I thought we could just hang, I got nothing on the agenda."

I'm a type-A organizer. This message is my kryptonite. A meeting without an agenda? Say what? Why are we even meeting? Should we cancel?

The obvious answer is no. But it often takes me a few deep breaths to get there.

Me: "Sure, let's hang."

25 minutes of conversation into the "no-agenda" 1-1:

Me: "And how is X going?"

Engineer: "Oh, it's a total disaster, and the team is really clowny, and I've been super stressed about it and not sleeping, but didn't know how to bring it up, because I'm so stressed, what should I do?!?"

Well, that escalated quickly. Let's get into emotional support and problem-solving in the last 3 minutes.

As a manager, the no-agenda-chill 1-1s are the second-worst (Quitting is the worst). You never know what to expect - it might be a waste of time, you might have to prompt the engineer to write an agenda next time, or you come out with some scars because you were in the dark and didn't ask enough probing questions. 🤷🏽‍♀️

Approaching the No Agenda Chill:

  1. Go really broad on topics, ranging from how they are doing, personally and professionally, and probe for areas of concern.

  2. When you find a problem, follow it up with the immediate help solving the problem.

  3. Think of ways to avoid surprise next time.

🧯Everything Is On Fire

Engineer via email or slack, sometime before 1-1: Hey, I'm really concerned about Thing. Can we spend 5 mins in our 1-1 talking about Thing?

5 minutes. Yeah, right. This Thing is going to take up the rest of your 1-1. If you got anything else, get it done before you talk about the Thing.

These 1-1s are amongst my favorites. As a manager, I don't have to dig around for where the fire is. Staring at a blazing inferno, being asked to point the firehose. My help! Yay, I feel useful.

The natural response, of course, is to jump into problem-solving mode immediately. I am an engineer (well, I was an engineer, but self-delusion is a powerful thing). This is what I do best. I solve problems. Let's go.

The fly in the ointment is that, as a manager, you don't really know what the problem is. One thing it most definitely isn't: the thing your report tells you it is. Not because they aren't smart; au contraire, they are better than you at their job. If they knew what the problem was, they would have likely solved it by now. By immediately jumping into solution mode, you're probably just pointing out the obvious.

Approaching the Everything Is On Fire:

  1. Do a lot of active listening. (If you are not familiar with active listening, I strongly recommend watching a few YouTube videos on the topic. It will change your 1-1s forever.)

  2. Ask clarifying questions. Try and understand the problem in multiple different ways.

  3. Do not offer solutions in the 1-1. Think about it offline and write some suggestions within 24 hours.

  4. Often, the people talking through the problem, with the aid of your questions, will solve the problem for themselves. This is an excellent outcome. Use the credits to unlock the next level in the Manager RPG.

🦨 That Team (or Person) is Terrible

This 1-1 is a variant of Everything Is On Fire, but we are dunking on a person or team instead.

Engineer: "This person is an idiot. They did everything wrong, and now I have this whole mess to clean up. Why can't we just fire them? I don't want to work with them again because they're just so hard to deal with."

Or: "That team has no clue what they are doing, but they won't let me get my work done. They are blocking my commits, won't answer my questions. Moreover, their code or API or whatever is just a complete mess. Why are they even around?"


This is a dangerous 1-1 and must be approached with care. On the one hand, you must walk the engineer off their rage-fueled, emotionally flooded edge. On the other hand, you must help them put things in context and approach problems constructively. Additionally, there might be an element of truth to the engineer's rage, and you must investigate things further.

There are two large danger signs associated with this 1-1.

  1. Engineer says something overtly racist, sexist, against company values, or deeply offensive, in the heat of the moment. Depending on the severity of the infraction, this can result in a stern talking to and a reminder that certain types of speech are not acceptable, or in the extreme, a discussion with HR that can lead to censure or dismissal.

  2. It can also be really tempting to join in on the gossip and slam the other team or person. As a manager, you've just made your position infinitely worse by doing this - you've sent a message that this sort of behavior is okay, you've given the engineer the impression that you agree with it (and they're definitely telling their friends), and put yourself in a vulnerable position.

Approaching That Team Is Terrible:

  1. De-escalate as quickly as possible. Help Engineer to calm down. Focus on facts.

  2. Re-focus the conversation on people having good intentions, but not being capable (everyone is learning/growing), or circumstances conspiring a certain way etc. Dig into the exact complaint.

  3. Investigate the engineer's claims. Follow up with others as appropriate. Follow up with Engineer to close the loop.

  4. If appropriate, get HR involved, or escalate to higher leadership.

🐰 It's Urgent

Engineer: "Hey, can I chat with you urgently?"

Uh oh. This one is important but seldom good.

If we are lucky, this urgency is about a time-sensitive decision that needs to be made. However, most decision problems get sent over slack or email, and there is usually no need to be coy about the agenda.

This is the 1-1 where the dire stuff comes out. Someone got sexually harassed, someone found something deeply wrong that violates company guidelines or is straight out illegal, anything else that is just Serious.

Approaching It's Urgent:

  1. Make time for this asap. If you need to get out of a meeting, do so.

  2. If the report is serious, escalate to HR or senior leadership as appropriate. If in doubt, check with HR, they are here for precisely this reason.

  3. Follow up with engineer (there are some circumstances where HR or legal would require you not to, but those aside, you should follow up to make sure the issue was addressed.)

🦘Feedback Hour

There are two flavors of these - the conversation after the formal performance review, and the ad-hoc feedback conversation. The former is more mechanical: prep beforehand, send the recipient a writeup that they can read and digest beforehand, then spend time going over it in person.

The ad-hoc feedback conversation is more interesting.

"Do you have any feedback for me?"


Approaching Feedback Hour:

Rookie version: "Sure. Here are 3 things you could be doing better."

Battle scar version: "How do you think you're doing with area X, Y, Z? What things are going well, and what aren't?" You have a list of things they need to be working on (right? RIGHT?), and this is your opportunity to check their self-perception on their growth. "I agree with X and Y, think you could be doing more on Z, here are two specific ways I would have approached it if I were in your shoes.". ✅

Remember: you don't have to diagnose, create, and deliver feedback all on the spot. It is perfectly fine to follow up over email or slack or another 1-1 in 24h, as long as you do actually follow up.

🦡 Promote Me

Engineer: "What do I need to do to get promoted?" or even better: "Reviews are coming up. Are you going to promote me?"

Side note: I love working with people that are bullish on themselves and straight up ask for a promotion. That being said, remember that there are a lot more people who are shy, who have cultural issues against asking for a promotion, who suffer from imposter syndrome, or a bad case of Dunning-Kruger. Care about these people, possibly more than than the ones that ask you to get promoted.

Back to regularly scheduled programming.

The decision tree here is straightforward.

  1. You believe your report is ready for a promotion. You are genuinely going to fight for your report in whatever promotion process your company has (unless you're Google, in which case managers have little say 🤷🏽‍♂️.)

  2. You don't think they are ready for a promotion and are not willing to put them up or fight for them.

In either case:

Inviolable Rule: Be Honest.

There is no better way to break long term trust than to make things up.

Approaching Promote Me:

If they are ready for promotion, go into expectations management in case the promotion does not happen: "I think you're close and are crushing it on many fronts. Here are two areas that are still questionable. I'm going to get feedback from other senior people at the company (or whatever the promotion process is) and make a good call.".

If they aren't ready, let them know: "I'm not sure you're ready yet. We believe in trailing promotions, and you need to be performing at the next level for at least N months. You need to demonstrate more of X and Y for this to be a slam dunk promo. However, I'm going to bring up your case and get feedback to make sure I am calibrated."

☠️ I Quit

My worst 1-1. And they almost always start innocuously.

Engineer: "How's it going, how's the family, isn't the weather great?".

It's like some human desire to push away talking about difficult things until the last possible moment, even in the very meeting that you're supposed to talk about it. Once the engineer feels the manager is warm enough, they drop the bomb:

"So, I was thinking about doing something else in the future."

Me, blinking furiously, half my brain telling the other half to keep calm because they're not quitting: "Okay, what were you thinking of?"

Engineer: "Well, my friend started this company, and I have an offer to go be their CTO. I'm thinking of taking it."

Me: "Ffffffffff"

Approaching the I Quit:

After a moment of panic, take 5 deep breaths, and let's unpack this.

  1. 🤦🏽‍♂️Manager person WTF! How did you fail to detect that your star engineer is bored, tired, or seeking new challenges? In some cases, there is nothing you could have done - a chance meeting leads to something bigger, and suddenly, they have an offer. But in most cases, you could have seen it coming and knew in the back of your mind that you should do something about keeping them motivated.

  2. 💰What is the right thing for the engineer? Sometimes, the best opportunity does indeed fall into their lap, and the best thing you can do is encourage them to take it. People is a long game. If you're consistently doing the right thing for your people, you'll work with them again.

  3. 🙅🏽‍♂️Some times, the deal they are offered is genuinely not good. CTO might sound great, but the company is going nowhere and has been around for a year. Or Founding Engineer looks excellent; they are getting screwed on equity. In cases like this, I've helped my reports actually model these things out and understand how ownership, vesting, and dilution work. Incredibly smart engineers sometimes have a hard time building a spreadsheet, so I create one for them (which they then take and make 100x better and add many complicated factors).

  4. ❤️More than sensible advice and help (in the form of spreadsheets), they are also looking for emotional support in two dimensions: 1) knowing that you and other leaders at your company care about them and 2) they have a strong connection to their team and the mission here. Reinforcing these emotional points, along with the rational artifacts 👆🏽, leads to a 50% chance of saving the engineer from leaving your team.

Thank you for subscribing to my newsletter. I’m your host, Rushabh Doshi. After spending nearly a decade managing some of the brightest engineering teams at Facebook and YouTube, I’m taking a break and doing some writing, spending time with my family and figuring out my next thing. Please feel free to forward this newsletter to friends and colleagues who may be interested.

Hiring Engineering Leaders

This email is about the interview process for an engineering leader. Hiring involves a lot more than the interview part - everything from reviewing resumes, sourcing great candidates, getting them to come onsite, the interview itself, evaluation, offer, and close. In this post, I focus primarily on mechanics, propose a concrete interview process, along with sample questions for the non-technical parts, and propose a template that companies can use to build a custom process suited to their needs. This post is based on my long experience managing engineering teams at Google and Facebook and interviewing numerous amazing managers for various roles.

Your startup is going great. You have a cool product with hundreds of thousands of users, a strong engineering team, and amazing leaders of design, sales, and other functions. You want to scale your engineering team and are looking to hire your first engineering VP. You chatted over coffee with a few candidates and have convinced them to go through a formal loop. What are the types of interviews in your loop? What are the goals of each interview? Are there some questions that are better than others? I propose to answer these questions, focusing on the non-technical parts of the interview. First, we need to align on what the role is about, on diversity, and on having a great candidate experience.

The Basics: What does a VP of Engineering do?

Martin Casado's excellent post is the best summary of why you need a VP of Engineering and the value they should provide. A great engineering leader should be able to function across the following axes:

Business / Product impact

  1. Ensuring engineering execution is one of their most important jobs. “Execution” refers to repeated, on-time, high-quality delivery of things the engineering team is tasked to build. The leader should be able to balance offense (e.g., growing the product, building features, improving performance) with defense (e.g., reducing the bug load, rewriting systems to pay off bug debt, improving efficiency, and reducing cost).

  2. They should provide critical input into the product planning and development process. VPEs are a thought partner for other executive leaders in the company - the CEO, CPO, Head of Sales. They should have an opinion on relative prioritization and technology investments the company makes.

  3. Communication is a significant part of a VPE's job. They must be excellent at communicating upward, downward, and sideways. They need to manage the CEO, so the engineering team doesn’t get thrashed, they need to communicate to the engineering team, to keep them in the loop and aware of everything going on. They need to be able to talk to clients, to the sales team, to the customer support team. They must be a highly versatile communicator, able to juggle a large variety of audiences and contexts.

Team impact

  1. They are responsible for the continued growth and development of the engineering team. Senior engineers need hard challenges in the form of ambiguous but critical problems and leadership opportunities. Junior engineers need mentorship and challenging work appropriate to their level. The leader should be able to balance a team with the appropriate seniority mix so that everyone has opportunities to learn and grow. They are responsible for delivering feedback as well as for letting people go when things are not working out.

  2. Hire, hire, hire. If the engineering team is supposed to double or triple over the next 12-24 months, they need to be spending a substantial chunk of their time sourcing, interviewing and closing great talent. They should be able to figure out the org structure 12 and 24 months into the future and then hire toward that. They should be able to build up their bench by grooming or hiring the next set of leaders that can take their place.

  3. They must be able to lead the team when times are good and bad. Keeping morale up when things are rough, keeping the team focused on the highest priority deliverables, helping people feel good about doing some of the most challenging, hard, and impactful work they have done - this all falls upon the VPE.

An important note about Bias and Diversity

If you haven’t read Rachel Thomas’s excellent 3partseries on the diversity problem in tech and practical ideas on what to do about it, you really should. Diversity is a big topic for our industry and your company. The rest of this article can wait, please read the series.

The design of the interview process plays a crucial role in increasing the diversity of your company. Essential things to keep in mind:

  1. You are biased. I am biased. Everyone is. If you believe otherwise, take the Race IAT. Then take the Managing Bias class to get a little better.

  2. Without a corrective process, we tend to hire people like ourselves, we hire for confidence, not competence, and we are likely to tilt the balance in favor of candidates with pedigree.

  3. Sponsoring and attending Grace Hopper does not solve your diversity problem. Treating women and under-represented minorities at your company well, and fixing your hiring and promotion processes can build diverse teams.

I recommend a Diverse Slate Approach for leadership hires: implement the Rooney Rule for your company. In short, for any leadership position, you must consider at least one woman and one underrepresented minority candidate.

DSA is hard work. In a difficult hiring environment, this can be especially challenging. Adopting this is a first step, but an important one. It signals that you are willing to do what it takes to build a diverse workforce and are committed to increasing workplace diversity, even with some short term pain.

The Basics: The Candidate Experience

Treat every candidate with respect and gratitude for their time. They could be a current or future client. Even if they are not the right fit, you want them to walk away with a great interview experience. I have personally been on the receiving end of poor interview experiences (hostile interviewers, no food or drink, no time to stretch or reset my brain between interviews), and it was not fun. Make sure candidates stay hydrated (they are going to be talking a ton), are not hungry, and are offered frequent breaks to stretch or use the facilities. One interviewer even offered a walking interview (it was awesome!).

Process Overview

The process comprises of one or two screens to make sure that the candidates pass the sniff test and are sufficiently excited about your company to bring them in for a full loop, followed by a day or two of interviewing, following by sells. Reference checks are essential - I recommend asking candidates for references as soon as you have some reasonable signal and interest so that you can get moving on talking to their references as quickly as possible. I prefer asking candidates for their references and using those rather than doing back-channel references, a common valley practice that is rife with challenges.

  1. Screen

  2. Onsite

    1. Technical

      1. Code comprehension. Lightweight coding.

      2. Software design.

      3. Domain-specific deep dive. Optional.

    2. Management

      1. People Management.

      2. Strategy, Vision, and Execution.

      3. XFN Collaboration and Communication.

    3. Values

  3. References

  4. Sell


Key questions include digging into experience managing teams at various stages of growth, familiarity with your domain, with your company’s tech stack. Don’t forget to spend a significant amount of time selling your company and your vision and getting them excited about coming in. Keep an open mind at this stage and don't weed out candidates too early. If a candidate has a greater than 25% chance of passing your onsite interview, bring them in for a full loop.

Technical Interviews

The chances are that your company already has a process for technical interviews. I recommend tweaking the senior engineer interview process and using that for the VPE. If you need some help setting up a technical loop, please drop me a line (Twitter @radoshi).

For leadership candidates, I recommend focusing on:

  1. Code comprehension over code writing. They need to read and understand the code that the team is writing. They are unlikely to be coding the Next Great Feature.

  2. Good software design instincts over specific technologies. They should understand why you need a cache but needn’t go into the finer details about Memcached vs. Redis.

  3. Domain-specific deep dive. Product, ML, Infrastructure, DevOps, AdTech - each leader grew up in some background. You’re looking for depth of understanding in their field.

Leadership Interviews

I recommend 3 interviews to understand the candidate’s leadership style.

  1. People management.

  2. Strategy, Vision, and Execution.

  3. XFN Collaboration and Communication.

I found open-ended questions, such as “what is your management philosophy,” to be less useful in distinguishing great answers from mediocre ones. An Situation-Complication-Resolution style, as applied to interviews, is an effective alternative. Setting up specific examples, or asking for specific examples, gives you much firmer ground to dive into details. Continuing with the preceding example, to find out where they are on the directive / supportive spectrum, we could ask the following: “We have an engineer Alex, he’s been here 6 months. We hired him straight from university.” (situation) “He works hard, but writes buggy code and people have to clean up his mess frequently.” (complication). “What would you do?” (resolution). This setup gives you ample fodder to deep dive into how the candidate approaches these sorts of problems and where they lean philosophically.

People Management Interview

The goal of this interview is to determine if the candidate is an exceptional people manager. Can the candidate provide the team with career guidance, help them work through obstacles, and push them forward? Does the candidate have sufficient experience dealing with problems, or are they going to be learning it on the fly? Is the candidate going to be able to hire and scale the team? Are they going to be able to scale themselves as the company grows?

Sample questions

  1. Basic data

    1. Management history.

    2. Historical and current team sizes.

    3. Growth curves - did they build the teams or inherit them?

  2. Management mechanics

    1. How do they keep in touch with their team?

    2. 1-1 - what is the purpose, structure, and cadence?

  3. Engineer growth

    1. How do they assess an engineer's strengths and areas of growth?

    2. What do they focus on, and what is the process behind making that decision?

    3. How do they grow junior engineers? Senior engineers? TLs?

    4. How do you give feedback? Give an example where you had to deliver hard feedback to someone?

    5. Give an example of someone that wasn't doing well and what you did to help them improve.

    6. Have you ever had to let anyone go? What was the thinking and process behind it?

  4. Manager growth

    1. When does a team need a manager?

    2. When is someone ready to be a manager? How do they assess this readiness?

    3. How is managing a manager different from managing ICs?

    4. How is managing Directors / VPs different from managing managers?

    5. How do you know when a manager isn’t doing well? How do you debug? How do you help?

  5. Organizational leadership

    1. When do they go from an amalgam of engineers to a formal team?

    2. What is their ideal team size?

    3. How do they think of organizational structure? Is it necessary? At what stage? When does one re-organize the team?

    4. What are the mechanics of a reorg? Have they executed a non-trivial one?

  6. Team culture

    1. How do they build engineering culture?

    2. What is their weekly eng cadence?

    3. Do they do architecture reviews (why or why not)? Do they do regular engineering all hands (why or why not?)

    4. How do people in the team learn from one another and grow?

Strategy, Vision and Execution Interview

The goal of this interview is to determine if a candidate can set the engineering vision, determine a strategy, and execute on it. They need to understand company strategy and translate that into an engineering strategy. They need to be able to decompose complex, ambiguous directions into concrete projects. Every candidate ha a set of tools and processes they use to keep the trains running, to stay on top of things, and communicate upward, downward, and laterally. At a leadership level, communication is often the primary job, and you want the candidate to be exceptional in this regard. All good projects hit bumps at some point. What happens when things go wrong? How do they detect what’s wrong, debug it, and fix it? The ideal candidate is one that makes bold bets, has seen some of them fail, learned, and did something better next time.

Sample Questions

  1. History

    1. Describe a complex project that you ran, how much time did it take, how many people, was it successful, what went well, and what did you learn? (This is intended to be a warm-up, don't spend the entire interview diving into this).

  2. Inception

    1. Construct an ambiguous scenario where a new project is needed. Pretend you're the CEO and let the candidate ask you questions. Can the candidate quickly get into the heart of the problem you're asking them to solve (comprehension)?

    2. Can they come up with a sufficient first approximation of a solution? Can they decompose the problem into different tracks?

    3. How would they set up the engineering team to tackle such a project? How do you manage ongoing maintenance and bugs while tackling projects?

    4. How do you deal with morale impact of thrashing the team?

  3. Goals

    1. Goals discussion is significant enough to be pulled out into its section.

      1. Does the candidate ask about a project's goals?

      2. Can they create reasonable metrics that track success? The discussion can get pretty nuanced but is incredibly important. Without clear goals and metrics, execution becomes an order of magnitude harder.

      3. Pick a project they did that was successful. Dive into the project's goals, measurements of success, relationships to company success, decomposition into smaller projects, and execution of the entire thing.

  4. Project lifetime

    1. How do they track progress?

    2. How do they communicate progress?

    3. How do they know if things are going well or not going so well?

    4. If they aren't going well, what sort of corrective actions would they take?

    5. What would they do if they incorrectly estimated time, complexity, or resources?

  5. Conclusion

    1. How do they transition a team from one project to another?

    2. What do they do if an idea fails?

    3. What do they do if the project didn't complete on time and requires further investment?

XFN Collaboration and Communication Interview

Thanks to Connor Hayes for providing this section.

In this interview, we are trying to assess whether the candidate can communicate in a clear, concise, and structured way. Do they have the right attitude toward working with non-engineering functions? How do they maximize their work through other people? We’re also looking for grit and scrappiness - can they push through tough situations? Can they unblock themselves and get stuff done? Finally, we want someone that is going to be a thought partner for the company’s senior leadership: do they grasp abstract concepts quickly? Will they contribute to strategy and decision making?

Sample Questions

  1. Communication

    1. Observed through the structure of answers to the other topical questions.

  2. Collaboration

    1. What is the ideal working model for collaboration amongst various functions like Product, Data Science, and Design?

    2. Describe a lousy collaboration situation. How did you handle that? What did you do?

    3. Let’s say you were working with a PM who made a decision with which you didn’t agree. What would you do?

    4. What if the situation didn’t change, and you still disagreed? How would you escalate?

    5. What do you do when a product person gives you an unrealistic deadline for a project?

  3. Grit and scrappiness

    1. How did you get to where you are today? Tell me about the times in your life where you had to work the hardest and overcome obstacles.

    2. What is the most unfair thing that has happened to you in your career? What did you do about it?

    3. Tell me about a time when you were blocked on a product decision and weren’t getting help from Product. How did you push through?

    4. What’s the most challenging project you’ve worked on, and how did it go?

  4. Thought partnership

    1. Describe a strategic problem that the company is facing. Ask for their input and see how they reason through things.

    2. Let’s pretend we are 3 years into the future, and our company has gone out of business. What do you think are some possible causes?

    3. How could we account for these risks with what we build today?


Your company likely has a values interview, done by senior leaders, to assess whether the candidate has a similar set of values as the company. This interview typically probes into a candidates work ethic, their motivations, their excitement about the company, about the problem it is solving, and whether they would help take the company to greater heights.


Reference checking is an incredibly important part of the interview process. I recommend letting recruiting solicit references from the candidate, but having the hiring manager (CEO) do the reference calls.

The critical thing during reference calls is to elicit details about the candidates working style, strengths, and areas of development.


The goal of this post is to provide a VPE interview process that you can duplicate, customize, and implement to hire the best engineering leader for your company or organization.

I would love to hear from you if you use this process, or if you have suggestions on making it better. I'd love to hear about things that I have missed, but have proven incredibly useful for you. Leave a comment or DM @radoshion Twitter.

Loading more posts…