Lara Callender Hogan

(This is an updated version of a post I first wrote in 2017. Given everything happening in tech today, it felt worth dusting off.)

The question “Why can’t they just…” has been a common refrain I’ve heard throughout my career. “Why can’t they just X” is, at its core, a great question—“why can’t they just find spending cuts elsewhere?” or “why can’t they just tell us what the technical strategy is?” or “why can’t they just tell engineers to write more tests?”—these are all valid questions that come from a place of deep concern.

I hear this from all sides of the same challenge. Let’s use AI mandates as an example:

• Engineer: “Why can’t they [senior leaders] just let us keep using the tools that we already know and are frankly more productive with?” and “Why can’t they [managers] see that just because they’re finding manager work more productive with these tools, it doesn’t feel the same way with engineering work?”
• Manager: “Why can’t they [senior leaders] understand that mandates don’t work?” and “Why can’t they [engineers] just try these tools out and see what happens?”
• Senior leader: “Why can’t they [managers] just get their teams moving faster?” and “Why can’t they [engineers] just get on board? This ship has sailed.”

There’s always a reason why we “can’t just X”. It’s often deeply hard to “just do X.” Maybe there are legal constraints or tax constraints; maybe we are working on it but changing X takes a really long time. Maybe we’ve already done X, but not in a way that’s landed with you.

Don’t fault the question-asker

By and large, those who ask, “why don’t they just” aren’t yet in the weeds with the problem, or haven’t had experience with this problem before. This makes sense: if you already had the experience in it, you would probably be trying to figure out why they don’t just, or you’d be actively working to fix it based on your past experience.

For instance, a coworker once shared with me his realizations about why reorg communications are incredibly hard; in the past, it was easy to say “why don’t they just”, but he once he became responsible for it, he saw why it’s much more nuanced and challenging than the tip of the iceberg he saw before.

Whatever is in the way of X typically isn’t any of the following often-cited guesses from people in my conversations about “why can’t they just”:

• A lack of understanding that X is a problem
• A lack of feeling urgency about this problem
• A lack of willingness to make hard decisions
• Disagreement at the senior level

The question “why can’t they just” is valid, because it’s coming from a place of concern, about something that is either deeply affecting someone’s ability to get work done, or affecting their trust in senior leadership, or affecting their trust in the company.

We shouldn’t avoid this question. So how do you face it head-on?

What to say in response to “why can’t they just”

Whenever I’m faced with this question, my response usually comes in three parts:

1. First, here’s my take based on my scope of authority. Here’s how this relates to my part of the org, the primary group of people I feel responsible for and accountable to. Here’s my stand on this topic, as the leader of this area. Here’s my opinion on it, here’s how I’ve thought about it, and here’s what I am or am not doing about it, with my core job responsibilities in mind.
2. Beyond my core scope of responsibility, here’s what I’m seeing others (often senior leaders) do or think. Here’s how I sense they’re approaching it - here’s what questions they may be asking themselves, here’s what they may be weighing. With my seat at that table, I can share some more insight into what is already being worked on, or what blockers are coming up.
3. Given all of that, where do you fit into this question? What do you have influence over, or how are you tackling this question? What data are you gathering? Where are you getting your hands dirty, where are you helping to enact change? In what ways do you not feel empowered to step up into this work? What can I do to change that?

By the end of that—after my personal take, what I’m seeing others do, and questions about what you’re doing—the conversation is usually in a really different place. I’ve owned my part of it, I’ve shared some light on what the person I’m speaking with may not be clued into, and I’ve asked some genuinely curious open questions to get their problem-solving brain engaged. I’m not saying “bring solutions, not problems” (because that doesn’t really work); I’m trying to collaborate on next steps.

This moves the conversation from “why can’t they just” into “what do we do now?” which gives you a solid jumping-off point. You can focus on where you each have influence and control, while still acknowledging the frustration about what you can’t influence or control.

If you’re asking “why can’t they just”

While it’s true that you may not feel empowered to effect the change you’re looking for, or want other leaders to just do the thing you think is right, I encourage you to think through that third set of questions. You do have influence, if not authority; your influence can take the form of genuine curiosity. The answer to “why can’t they just” might be a three-hour answer, because if there was a short answer, they’d probably have done it already. :)

Find someone to support you through this process (a coach, your manager, another person with influence/power at the organization). They may ask you challenging questions, and push you to do more research and listening, but in return they could give you their personal take and what they’re seeing other teams or leaders do. It’s worth finding that person; even one conversation can shift how you’re thinking about it.

Vicarious learning is a real thing: we absorb skills and knowledge by watching others, hearing about their mistakes, seeing what worked. This is why postmortems are such a great tool for building context, and seeing how other engineers problem-solve. I’ve been thinking about vicarious learning a lot lately, specifically about how engineers are learning to use AI.

There’s no shortage of AI content out there: workflow breakdowns, productivity revelations, time-savings stats. But when I talk to engineers, I’m hearing that they haven’t found a clear path to the “aha” moments that actually make these tools useful, other than finding their way through trial and error.

More worryingly, I’m noticing a widening gap between people who are enjoying AI tools and people who feel like they’re falling behind. If these tools really are the future (and despite my reservations, I think they are), I don’t want anyone to get left behind. The loudest evangelists tend to skew toward a pretty specific demographic. I want people who aren’t white cis men in tech to feel like they’re keeping up—and to actually be keeping up—not just operating out of fear.

So I spoke with a number of staff and principal engineers at various companies who are using AI daily to do their work, and are feeling pretty effective at it. None of them are what I would call evangelists; they are people who have felt reticent to adopt these tools, and still have some serious feelings about being complicit in the environmental cost and the politics around who’s building these tools and why. But now they’re using AI—Claude, mostly—to do the vast majority of their programming work.

My goal in interviewing them was to validate an idea I’ve been developing: that what teams might benefit from right now is a regular touchpoint with their team in which tips, tricks, and other “aha” moments about how their work is evolving are shared. (I detail how to do this below!)

I’m hoping that this might be a solid opportunity for vicarious learning, so that people can build these skills while also learning more about the system they’re working in.

The trial-and-error problem

The vast majority of the time, the people I spoke to only learn how to adopt these tools and where they might be useful through trial and error.

I kept asking: are you sharing tips and tricks with your teammates?

Their answer: kind of. At each of their organizations, there’s a version of a Slack channel where people are sharing longform posts about their workflows, or they’re asking quick hit questions like “How can I get Claude to do X?” But these engineers rarely read those channels these days, or their usefulness has had diminishing returns. Why?

The world is changing too fast. A workflow post from a week ago might already be outdated—three things it mentioned have since changed. Internal governance is shifting just as quickly, and engineers don’t want to craft niche solutions to problems that might be solved next week by a new internal tool or a devtools team update. And context is everything: tips from someone across the company may not be relevant to how your team works in your corner of the codebase.

The engineers I spoke with have strong internal networks and some colleagues that they do trust to share tips and tricks with, but nobody described a one-to-many setting in which they consistently learn how to use these tools more effectively. A few reasons why:

• The most vocal sharers can be the most enthusiastic or braggy, not the most practical.
• There’s a “secret sauce” vibe at some organizations—especially where leadership visibly rewards the fastest, most AI-fluent engineers. When productivity feels zero-sum, people hoard what’s working.
• Workflows built on these tools often carry some risk. Someone might be comfortable with a configuration they’ve built, but hesitant to recommend it to others in case it breaks their setup.
• Power dynamics are a factor; some folks (especially newer-to-the-industry people) are hesitant to say “I did this with AI” because they feel like a fraud, even when everyone around them is doing the same.
• And sometimes people just don’t know how a colleague will respond. Will they get a lecture about the state of the industry? A dismissive “duh, just use Claude for that”? The unpredictability makes it easier not to open the door at all.

By and large, the engineers I spoke with are adapting through trial and error and trusted one-on-one conversations. I think there’s a better way—one that makes this kind of learning feel normal, democratizes the information, and makes room for the full range of feelings people have about this stuff.

Aha! AI meetings

The format is a simple variant of classic “show & tell” meetings:

• Attendance is optional, but participation once you’re there is mandatory.
• Kick things off by explaining the goal in your own words.
  • Mine would sound something like: “This stuff is changing so fast. I wanted us to have a way to share what we’re learning as a team.”
• One at a time, everyone shares one “aha” moment they had in the last week due to working with AI in some way. “Aha” means “I was surprised” or “I learned something.” It can be the tiniest thing: a new way to save prompts, or realizing you had a totally wrong assumption about how part of the codebase worked—and only found out because you asked Claude about it.
  • “Here’s where I screwed up” is way better for vicarious learning than “Here’s why I’m awesome.” Encourage this! Model it!
• After each share, the group responds in whatever way fits your team’s culture: emoji reactions, jazz hands, a genuine follow-up question. The point is to signal: this was valuable to hear.
• Questions are encouraged after the applause. This is how learning happens.
• Everyone shares. Yes, even you, manager.

Depending on the size of your team, it should take less than an hour.

Be a good facilitator

• If questions are running long, move them to Slack so everyone gets a turn.
• If someone’s being vague—sharing the outcome but not the how—ask follow-up questions. You want to hear the “how” behind the “aha.” If they keep deflecting, check in one-on-one afterward. No judgment; it’s probably fear.
• If someone says they have nothing to share, say, “Sorry, everybody’s gotta share! It can be the teeniest tiniest thing.” Again, even YOU are going to share something.
• If someone repeatedly skips the meeting, check in. Some people are genuinely happy learning on their own, and that’s fine—this meeting is for people who want to learn vicariously. Not everyone does, and that’s okay.

The grumpiest people in the room will soften over time. They’re grumpy for real reasons: frustration with security or devtools constraints (I feel for the folks on those teams right now!), anxiety about what’s happening to their jobs, genuine ethical discomfort. A consistent, low-stakes, celebratory space for learning helps them too, even if it takes a few sessions for that to land.

By design, people will learn other stuff from these meetings, not just how folks are using AI. The person who demos how they found nine versions of a checkout function will be inadvertently showing everybody else how a part of the checkout flow works, and the value of repeatable patterns. The framing of the meeting is “learning AI,” but the outcome (especially for folks who don’t have all of the context built up for this part of the system yet) can be so much more than that.

Of course, all of this only works if people actually feel safe enough to show up and share.

Psychological safety

None of this works if people feel hesitant to share. And there are plenty of legitimate reasons they might feel this way:

• Their workflow feels like a competitive advantage they’re not ready to give up.
• Someone in the room has previously expressed frustration or anger about AI adoption, how leadership is handling this, etc.
• They’re afraid of being left behind—or perceived as being less experienced with these tools.

These are all valid. In a stack-ranked culture, you don’t want to hand your edge to the competition. In a team with mixed feelings about AI, you don’t want to upset a colleague who’s scared or frustrated. And when you already feel shaky about a new technology, it doesn’t feel safe to lead with your mistakes.

As the manager running this meeting, you should name this, explicitly, at the start. Here’s what that might sound like in practice:

• I have complicated feelings about this stuff. You might, too.
• Everything is changing so fast, and I want us to have a way to share what we’re learning so we can all adapt.
• It might feel weird to share mistakes, frustrations, or even joy in a setting where you’re not sure where other people are at. I know that you care about each other; I care about you, too.
• I’m hoping this helps lighten the load of adapting while everything is shifting. And I hope we can support each other through the normal feelings that come with this completely bonkers moment.

As the meetings unfold, watch how people are reacting to one another and what they’re sharing. Be visibly enthusiastic when someone shares a mistake they learned from. Celebrate vulnerability when you see it. Find something to celebrate in every “aha,” no matter how small. It will feel cheesy at first. It will get less cheesy. I promise.

Years ago, when I ran weekly demo meetings at Etsy, we did a little round of applause after every share—no matter how small. Even managers would demo something as mundane as a calendar invite they’d set up, and everyone would laugh and clap, because, ha, manager work. But it mattered. Everyone had a moment in the spotlight, everyone participated, and the power dynamic in the room flattened out a little. The whole team showed up every week because it genuinely felt good to be there. That’s what we’re building toward.

Conclusion

I learned a lot more from these engineers than I’ve captured here: about their feelings on AI, where their time is actually going, and what their day-to-day workflows look like. I’ll share more of that soon.

In the meantime: you have everything you need to run this meeting. Start small, go first, and make it safe to be a beginner. Let me know how it goes—I’m on BlueSky.

Many of us are feeling stuck. We’re managing through crisis after crisis, and we’re watching our leaders and our teammates burn out and not be their best selves. I don’t know anybody who’s thriving right now.

Day-to-day, you’re trying to make at least a tiny bit of difference. I see it! You’re working to help people get promoted, you’re running standups to make sure folks have what they need, you’re holding one-on-ones where you check in and see if your teammates are “okay”, for some definition of “okay.”

So what do you do when you’re working with a teammate who is stuck in a cycle of unhelpful or unproductive behavior? You’ve got empathy for them; you don’t want to be a jerk about it. But you still need this person to change course and start moving forward.

I’ve written about how to be directive without being a jerk before, but I’ve got a few more tips to share about approaching this conversation with care.

The “difficult conversation”

Difficult conversations during difficult times is all about balancing empowerment and direction. Imagine that there are levers to pull in every conversation—an empathy lever, a candidness lever, a quietness lever, a bottom-line lever. Your job is to figure out what tools will be effective in each conversation.

I’m going to use a made-up example to ground this in specifics. Let’s say that I need my teammate, Janet, to stop playing devil’s advocate whenever the team is developing a plan of action. She’s always asking “what ifs” to the point where we aren’t able to make decisions about what to actually do. She’s stuck, and the team’s stuck now, too.

We’re debating imaginary circumstances that might never come up because she’s worried about edge cases, and what a bad experience will do to our stagnating customer base. We’re going in circles. Silence would be better than what Janet’s currently doing. We need to ship this thing, and we can’t even get started.

I don’t want to be a jerk, despite how frustrated I am with her behavior. I just need her to stop playing devil’s advocate. So how do I help Janet get unstuck?

Avoid getting stuck by finding your ‘why’.

I need to make sure that I don’t get stuck, too. Without a north star for the conversation—something clear and objective and specific—I risk falling into a trap of endless debate with Janet, where I can’t help her see a new path forward.

Ignoring Janet’s specifics, what I am optimizing for, and why is it so important to me to have this conversation? What’s my most important outcome? What’s my “why”?

It’d be too short-sighted to say I’m optimizing for the team to have a plan when they come out of the meeting. This is a bigger issue than sprint planning. Really, underlying it all, I’m responsible for this team delivering. I need to help my teammates make forward progress so that they can deliver on what the business needs.

This is my why. This is me caring for my teammates: the business needs to continue to exist! We have a crucial product to ship, which will address some of the big feature gaps that our users have been asking for. Having this “making forward progress” goal crystal-clear in my mind will help me ignore all the extraneous context and beef and hubris and whatever else. This is my destination.

When you’re in this situation and trying to figure out your own “why”, really spend time asking yourself what you’re optimizing for, or what you’re trying to avoid. Am I optimizing for speed? Am I optimizing for avoiding layoffs? Am I optimizing for minimizing disruption? etc. Having your “why” clear in your brain will help you avoid being sucked into being stuck, too.

“Stop” isn’t useful without a “start.”

What’s my path to that goal? I need to get Janet to stop playing devil’s advocate during planning meetings.

But “stop” doing something isn’t really helpful, unless there’s a “start” doing identified. “Stop” shuts the conversation down, and usually amygdala hijacks the other person. But I don’t want a fight-or-flight version of Janet: I need Janet to stop asking “what ifs,” and start making decisions.

I need her to actively help narrow down on our plan so that we can take action, not continually increase the scope.

Bring it back to the why: I need her to do this because we are optimizing for making forward progress, so that we can deliver on what the business needs.

Bottom-line it.

“It’s critical that we start making progress on this project. I need you to stop asking ‘what if’s’ and start making decisions, so that we can deliver on what the business needs.”

Notice that these are really simple sentences, just the “bottom line” of the point I want to get across.

Bottom-lining is a really important skill in giving strong direction. If you ramble because you’re nervous, or you want to thoroughly explain, your point just won’t be clear.

Whenever you need to give some strong direction, get the whole thing down to just one or two sentences, max.

Wait, don’t say that yet!

Now, if I deliver this message as it’s written above, is Janet going to hear it? Nope. She’d probably push back, or worse, she’ll shut down.

She’s been playing devil’s advocate in our team meetings for a reason—she’s worried that we won’t catch edge cases, and we might be missing something huge with this plan.

So I’m not actually going to say this to Janet as a first step; I’m going to save this level of bluntness as a last resort if I really need it. What should my first try be?

Janet and I actually agree on the end goal here—that we need to deliver this for the business! We just have different reasons to worry. She’s worried that we’ll miss something big, and I’m worried that we’ll never get started.

Often, a person will push back when you give strong direction, because they don’t feel like their concerns are being heard. You’re trying to switch things up, but their hesitation or disagreement hasn’t been addressed yet.

Acknowledge concerns.

I’m actually going to start by acknowledging her concerns, honestly and authentically!

If Janet is in fight-or-flight mode, continuing to disagree or debate is not going to help me make forward progress. I’m going to reflect back the concerns she’s shared with me one-on-one and in team settings, because I want her to know that I’ve heard her! I’ll literally say to Janet:

“I know you’re concerned that we’ll miss something big. I also know you know how important this project is for the business. That’s why we need to make a change here.”

(If you don’t have a good guess about why your teammate is behaving a certain way, scroll down to some more resources on identifying your teammates’ concerns.)

Stay forward-facing.

Then I can turn this conversation to focus on the future. We’re not going to waste more time litigating what’s happened in the past.

We’re here to talk about what we’re doing from here on out, so that we can nail our most important objective: making forward progress. Delivering this for the business. I’m going to keep reinforcing this.

“Let’s decide what fires we are going to let burn. Let’s make decisions, and start tackling the work, so that we can hit our (mutual) goal of delivering.”

95% of the time, this is enough to help the other person to move forward. They might need to go have a think about what you’ve said (a day to think on it is fine!), but they’ll still agree to try out a new approach. And your one-on-one is a great time to process this and make these kinds of decisions together.

If they aren’t sold, that’s when you reach for your uncomfortably-blunt direction. If Janet doesn’t get on board with this collaborative version, and we keep going in circles during this one-on-one, I’ll use that very clear stop-and-start messaging. Or if I see her return to the same habits in our next team meeting, I’ll ask her to have an impromptu chat one-on-one right away, and I’ll use my stop-and-start messaging then.

This will feel uncomfortable.

Weirdly, I’ve found the prep for these conversations typically feels more intense than the actual conversations. Developing that blunt bottom line is hard. But when I settle in to the actual chat, and the person hears me acknowledge a concern they have, it feels like everything dials down a notch or two.

That’s, of course, if I get the concern right. :)

If you’re not sure what someone’s primary worry is, ask questions (here’s a shortlist of ones to try)! Reflect back what you hear (literally say “It sounds like [repeat what they said]—do I have that right?”). Again, this will take the temperature down a notch. Starting a tough conversation by reflecting back what you know the other person cares about (or is worried about) has never steered me wrong.

Again, imagine that there are levers to pull in every conversation: a curiosity lever, a bluntness lever, a humor lever, etc. Your job is to figure out what tools will be effective in each conversation, and keep trying different tools as you gather more data about what’s working and what isn’t. Each conversation will be different, and will require different tools.

I have a whole library of resources on how to adapt your approach based on what your teammates need, the project and business context, who you are as a leader, and what the organization needs. And a video course on switching between these tools, too. I hope these resources are useful to you today—or that you can keep them in your back pocket for the future.

I’ve been working with the rad team at Fly.io for the past few months as a fractional VPE, mainly focusing on management-y and culture stuff as the team grows.

One of the things I really dig about Fly.io’s company culture is how teammates use their internal forum for sharing questions about work, project progress updates, oncall recaps, and other stuff that I’ve traditionally seen live (and die) in email inboxes. I’m finding that the internal forum helps keep conversations going async (and out of Slack, which can be super lossy for folks in different timezones) and a little bit more evergreen.

I wrote a post on their internal forum last month about a topic that had been consistently coming up in 1:1s I had with folks: how lonely it can be if you’re working as a team of one. I realized that this post might be helpful to folks outside of Fly.io, too, so with their permission, here’s a lightly edited version :)

---

tl;dr: if you are a “team of one” and ever feel stuck/isolated, it’s totally normal (and encouraged) to lean on other folks here for help!

I’ve been chatting with a few different people about what it feels like to be a “team of one” at Fly.io. A “team of one” can mean anything from “I’m working solo on a project,” or “I am the only person tasked with thinking about this entire product area,” or “I’m venturing into a new area of the business and am gonna test to see if we want to build a team around this thing.” For many folks, this level of autonomy is fun and interesting!

ALSO, despite it being fun and interesting, being a team of one can—at times—be lonely or hard.

I am all about leaning on different types of people at work (and outside of work) as you tackle challenges, grow your skills, etc. (Here’s a whole metaphor for building a “Voltron”/crew of support!) But sometimes it can feel really tricky to find those people—and even if you know you can lean on somebody, it’s hard to know how.

Examples of how to lean on/get support from other folks within the company

In case it’s helpful to have examples (or inspiration, ha!), here’s a non-exhaustive list of the different ways you might be able to lean on somebody else for support, when you’re a team of one:

• Coaching! I’m biased; I had to put this one first in this unordered list. ;) Finding an external coach can be useful, but there are also plenty of people at Fly who are trying to practice their coaching skills! This means they’d ask you lots of open questions to help you figure out what you want to do going forward. You can think of it like dedicated introspection time, facilitated by another person.

• Feedback! People here are also trying to hone their feedback-delivering skills. Asking someone to give you feedback on your implementation can feel micromanage-y, so instead, you can ask for feedback on a different aspect of your project! For example, ask somebody what risks they’d consider if they were working on your project. Or ask them what open questions they still have about your project based on your previous updates. Asking for feedback on different parts of how the project is going can be really helpful to get some brainstorming happening.

• Rubber ducking! Sometimes, you just need to type out your plan, current thinking on your approach, order of operations, etc. to work out where you’re stuck. You can ask somebody just to be a rubber duck while you process with your typing words or mouth words!

• Pinging when you’re stuck! While it feels obvious to ping someone when you’re stuck, it can weirdly be challenging to do this when you’re a team of one. Consider identifying a person in advance who you can holler at when you’re stuck, and ask them the best way for you to notify them that you’re stuck! Crafting this minimal pre-work agreement can make it far easier to reach out when the time comes to get unstuck. When you ping them, you can tell them what kind of help you might be looking for: rubber ducking, feedback, coaching, etc. Or they can ask you ;)

• Ghostwrite messages! For some folks, the hardest part about being a team of one is the communication work. They’ll grind their gears trying to write stuff, and either give up on it or go quiet for a really long time. If this is you, find someone who can help you carry some of the writing load! The process of sharing your current status, what you’ve shipped, what’s important for people to know, etc. means you’re STILL doing the important thinking parts that updates require. Sometimes, offloading the writing itself is all that’s needed.

• High fives! It feels really good to see people using your stuff, but sometimes, what you REALLY need is a high five from somebody who knows the work it took to get something shipped. See if you can find someone to help you celebrate when the whole thing is wrapped up. Even if that just means some tada emojis in a Slack DM ;)

Finding a buddy

Now, how do you find a buddy to help you with this stuff? Some brainstorm-y ideas:

• Is there a senior-ish person at or outside your company who you’ve worked with before, and would like to be a high five buddy, coaching buddy, feedback buddy, or whatever it is you’re looking for?
• Could the Slack Donut app help you find someone new to chat with within the company?
• Should there be a #buddy-system Slack channel where folks can go to ask for a buddy?

If you’re wrestling with this feeling at work, I highly recommend you find a way to talk about it with your colleagues. Even just sharing this post could be helpful to kick off the conversation! I hope this can help you develop easier/more obvious support for folks who are feeling isolated with their work.

We face decisions every single day, big and small. Sometimes those decisions have tradeoffs that feel impossible to decide between, which naturally will feel particularly hard to settle on.

For example, let’s say you’ve been struggling to enjoy your current role at work, and you’re ready to make a decision about how to address that. You’re feeling some stress about the volume of work you need to get done every week, but you also recognize that you don’t have relationships or strong connections with your colleagues.

If you prioritize feeling more connected, you’ll have less time to check things off your to-do list. But if you focus on checking more things off of your to-do list, you won’t have time to foster those relationships that you also need to feel more satisfied at work.

So what do you do when two or more important core needs are competing? Unfortunately, you can’t solve it all. You ultimately have to choose what to prioritize. And whether you like it or not, sometimes you need to let some fires burn while you address a different issue.

Plus, we sometimes have lots of autonomy—too much autonomy!—over the things that matter to us, or those that will have a big impact on those around us. When you feel like you’re at an impasse with a big decision, or you just can’t decide between two important things, try this fill-in-the-blanks tool:

In order to [thing], I’m choosing [x important thing] even over [y important thing].

This tool can come in handy for both work choices (should I choose to optimize for speed, or quality?) AND for personal decisions (like choosing a new role).

Use this tool when you have two equally important things to choose between, and it’s feeling impossible to make the decision. If the tradeoff was easy, you wouldn’t be feeling so stuck! It’s time to make a decision that, for the time being, requires you to choose to focus on one of these very important things over the other.

Here are some examples of even/over statements that I’ve worked with coaching clients on:

• In order to feel some progress, I’m choosing to focus on the short-term even over making decisions that’ll last.

• In order to have a healthier work-life balance, I’m choosing to ship quick fixes even over building expertise**.

• In order to move my career forward, I’m choosing to take big risks even over maintaining work/life balance.

• In order to lead my team, I’m choosing to take a bird’s eye view of the work even over diving into interesting technical problems.

Each of those even/over statements names two equally important things. So how do you choose the order?

1. Start with the first blank: “in order to [thing].” What are you trying to accomplish? What’s the goal right now? What’s your core need? Not forever, not for future-you: today, what’s the outcome you’re looking for?

2. Flip a coin. Really! Make one of the important things heads, and the other one tails. Flip the coin and fill in the sentence with the result: “In order to [thing], I’m choosing [coin flip result] even over [other side].” How does it feel to say out loud? Does it feel right, or not?

3. Now do the reverse: flip your two important things. “In order to [thing], I’m choosing [other side] even over [coin flip result].” How does this version feel?

Believe it or not, this exercise can be really helpful in honing your spidey sense and coming to a decision. What is your gut telling you here? What do you want to try next—knowing that you can try something different later? Choose the one that feels better to say out loud.

Make it time-bound

One of the biggest hesitations that I see people have when we do this exercise is “but I can’t do that forever!” Using the example from earlier: if you want to enjoy your work, you can’t choose building connections over making progress on your work forever, just as you can’t progress on your work forever and never build connections. RIGHT?

RIGHT. We are choosing this even/over statement for today. And maybe tomorrow. And maybe for three weeks! It’s important to be specific about the time frame with your even/over statement, both as a reminder that it’s not for forever (you’ll choose something different in the future!), and to reinforce that you have permission to do this today.

If your brain really gets hung up on the other stuff you feel you should be doing right now, set yourself a reminder on a future date to check-in on your even/over statement. Put it on the calendar for 2-4 weeks from now. If you start to question your even/over statement, remember to look at the calendar and say, “Oh, I don’t have to worry about updating this for another two weeks.”

(And to make it even more meta: in order to be able to hone this skill of letting some fires burn, I’m choosing to stick with my decision for two weeks, even over revisiting my choice.)

Make a Post-it note version

Our brains are delighted by simple, memorable phrases—not lengthy sentences that are hard to remember in their entirety. So what’s the version of your even/over statement that would fit on a Post-It note? Try summing it up: [x over y.]

For example, this even/over statement is pretty long: “In order to feel better about my current role, I’m choosing to build connections with colleagues even over making progress on work.” The Post-it note version of this (which is handy for our brains!) is “connection over progress.”

Make your Post-it and stick it where you can see it. I like to put mine on the wall behind my monitor, or on the bottom half of my laptop next to the mousepad. I’ve heard that others write on the sticky side (upside down) and stick it on the top panel, peaking over the screen. Putting it in view helps me be routinely reminded of what I’m optimizing for right now.

If you find yourself hung up on making this decision, see if adding a date to a corner of the post-it helps. This date indicates when it’s time to revisit your even/over statement—so if that date is in the future, it can be an easy reminder that you CHOSE this current even/over path! And it’s time to stick with it; don’t revise it yet. :)

As I’ve learned more about how humans interact with one another at work, I’ve been repeatedly reminded that we are very easily influenced by the mood of those around us. It’s usually not even something we do consciously; we just see someone using a different tone of voice or shifting their body language, and something deep in our brain notices it.

If you’ve ever attended a meeting where there were some “weird vibes,” you know what I’m talking about. You couldn’t quite put your finger on it, but something about the energy of the room was off—and that feeling affected you, even if it was super subtle.

We’re wired to spidey sense this stuff; this gut instinct is part of what’s helped us stay safe for millenia. Our amygdalas are constantly on the lookout for threats in our environment that could be bad news. Plus, we tend to infer meaning from those weird vibes. Our brain is trying to make sense of the shift in behavior, so we’ll make some (often subconscious) guesses about what’s truly going on. We often even jump to the assumption that those vibes are about us.

Humans mirror each other

If I’m distracted in our one-on-one because I’ve got some stuff happening out of work that you don’t know about, it’s a recipe for misunderstanding. What you might observe is that I’m not making eye contact, I’m suddenly changing the subject, and my arms are crossed. How does your brain make sense of this? It decides that I’m upset with you—without any other information, it’s the most likely reason, of course. :)

Plus, humans, like most other mammals, mirror each other. When I change my tone or my body language, there’s some likelihood that your tone and body language will change in response. So now we’ve got a compounding situation—I’m having a bad day, so I’m giving off strange vibes, then you’re giving off strange vibes because you’re picking up on my bad day. We leave the one-on-one and go meet with other people, and now they’re picking up on our strange vibes.

This cycle is far more noticeable when someone is amygdala-hijacked. It’s tremendously easy to be caught off guard by someone who is overcome with a surprising emotion, and feel triggered by it ourselves. Again, this is just a normal defense mechanism—there is no judgment here.

Noticing a change in someone’s behavior

It takes a lot of practice to recognize when this pattern of shifting and influencing behavior is happening! But once you start paying attention to people’s patterns of behavior (what words do they use when they’re feeling upset? How does their body language change? Do they get louder or quieter? In what situations are they cracking jokes, and in what situations are they more quiet?) you can develop a stronger spidey sense when someone’s “vibes” are different than usual.

In my video course on Dealing with Surprising Human Emotions, I talk about how to recognize when someone’s behavior seems off, it’s just a signal—just data—that one of their core needs might be being messed with. (Or maybe they simply didn’t get enough sleep last night, or haven’t had coffee yet today!) You can try to see it as a weather vane that something has gone awry for this person. Because once you can transform these signals into data—and not simply mirror the weird vibes back—you have an opportunity to positively affect what happens next.

Thermometer vs thermostat

I like to use the metaphor of a thermometer and a thermostat for this idea. If you’re looking for signals about how someone is feeling, it’s kind of like you’re trying to take their emotional temperature. You’re being a thermometer. When they’re subtly giving off weird vibes—they’re frowning, answering your questions with fewer words than normal, etc.—you’ve noticed that their temperature is different. When their amygdala is hijacked, you might see large changes in their behavior (they’re picking a fight with you, going completely silent, skipping your meeting, etc.)—in the thermometer metaphor, they’re running a fever, and you’re picking up on it.

And since we know that one person’s behavior change can cause others to change their behavior in response, we can think of it like they’re being a thermostat: they’re setting the whole temperature for the room. Even if it’s unintentional on both sides. It’s just how we’re wired: to mirror the “vibes” that someone else is giving off.

Rather than let that cycle play out subconsciously, you have an opportunity to become the thermostat as soon as you notice that another person’s temperature has changed. You get to set the new temperature of the room, in a positive and healthy way.

Being the thermostat

Once you’re able to start noticing when someone’s amygdala-hijacked, or simply that the vibes are off, you can reframe and use “be the thermostat, not the thermometer” for good. Since humans tend to mirror each other, you can intentionally change the energy in the room, setting the thermostat to a more comfortable temperature.

Naming what’s happening

One way to reset the temperature is to say out loud, with your mouthwords, that you’ve noticed that the energy has shifted. Here’s a how-to blog post on naming what’s happening in the room.

As I mention in that post, there are a few risks to doing this, so you should use your best judgment on whether or not naming what’s happening in the room would be helpful in the moment. You won’t always get it right! Avoid projecting your feelings onto others, or putting them on the defensive, that would make the temperature of the room even more uncomfortable!

If you’re noticing a major shift in someone’s demeanor, instead of guessing what’s going on for them (like “you seem upset”) ask an open question about what they need or how they’re feeling. This way you’ll know if you need to get your thermostat hat on.

Choose your tone and body language

When naming what’s happening or asking open questions, keep what you say short and sweet, and remember to use a calm tone and open body language. I’ve written about this before, but it’s definitely worth recapping here, because this is a huge component of being an effective thermostat!

1. Gently nod at the pace they’re talking at, or slightly slower. It shows you’re following and tracking what they’re saying.

2. Make soft eye contact. Hard eye contact is intense, eyes wide—it’s a little creepy. Soft eye contact is more like a Tyra Banks “smize”—a subtle relaxing of your facial muscles that shows you’re not ready to pounce as soon as they’re done talking. Don’t worry about keeping constant eye contact. Research shows you can break eye contact every 3 seconds naturally, then connect again, and this still feels attentive and affirming to the other person.

3. Lean in, but not too much. When we’re uncomfortable, we sometimes unconsciously tip away from the person in whatever way we can. This can send a signal that you’re uncomfortable or trying to get out of this conversation ASAP, or even that you are asserting dominance. Make sure you’re squarely facing the person—or if you’re on video, squarely face the camera—and lean in slightly. Even as little as 1” will do the trick! If I’m on Zoom and sitting at my desk, I like to make sure my elbows or wrists are evenly resting on it.

4. Be intentional about the tone that you’re using. You’re responsible for communicating that you want to hear what they have to say, and that you’re here to support them. This intentional choice, in combination with your body language cues, will communicate to the other person that you are actively listening. I’ve found that even a subtle change in my tone—like going a little quieter if the other person has gotten a little louder, or adding a little bit of joy to my voice if they seem unsure or a little bit stressed—can reset the temperature in the room.

There’s a lot more to say about active listening; you can read more in this blog post! Your whole goal here is to set or reset the temperature of the room by modeling it with your tone, body language, and word choice.

This skill of intentionally choosing your body language, tone, and words can help the other person move out of whatever “weird vibes” they were giving off earlier, as they can now start mirroring yours. But if it’s a more drastic scenario, like this person is in an amygdala-hijack mode, this approach can also help them feel more heard, understood, and confident that you are decidedly not mad at them.

Usually, this skill does the trick. You smiled a bit, told a little joke that made them chuckle, nodded at the pace that they spoke to indicate you’re listening, and their mood started to change. You’ve just acted as the thermostat in a healthy, intentional way. But in case this doesn’t work, or if this person is in a more lizard-brain state, read on for some additional tools you can try.

Offer a break

If it feels like the other person has been amygdala-hijacked, or if they are decidedly stressed or distracted and you sense that there’s no way that the rational, logical part of their brain will be able to return in the next few minutes, use a back-pocket script to offer a pause in the conversation and a plan to return to it later. Some of my favorites to use are:

• “I’m not sure how y’all are feeling, but I think I could use some more processing time on this. Could we reconvene again tomorrow at 2pm?”
• “I know how much we want to come to an agreement on this decision today, but my spidey sense is that we might need some more time to think on it. How about we sleep on it and check in again tomorrow?”
• “I really want to support you on this and make sure you feel good about our next steps. How would you feel about us taking a break now to spend some more time thinking it through, and chat again at 4pm?”

You’ll notice that the phrasing is intentionally trying to avoid putting someone else on the spot, or make them feel attacked. Your gentleness can help set the new temperature in the room.

What I learned/What I’ll do

If you’ve contributed to a big shift in the temperature by creating or escalating an awkward or tense situation, you have an opportunity to own your role as the thermostat here. Because if you never acknowledge it, you’re going to risk developing a forever-antagonistic relationship with them.

Sure, they should just be a grownup and get over it, right? But this does not happen in practice. (When was the last time you, yourself, actually did that?) People hold on to this stuff! Your life is going to be SO MUCH HARDER if you don’t clear the air after you amygdala-hijack someone.

In the Dealing With Surprising Human Emotions video course, I talk with Jason Wong about this template that we both learned from Paloma Medina :)

“What I learned…”
“What I’ll do…”

For example, “What I learned is that that last email didn’t do a good job explaining the changes, so what I plan to do is start a forum for folks to post their questions and our CEO will answer them every Tuesday.”

When said with heartfelt authenticity, this phrase tells people that their needs, feelings, and concerns are not irrelevant. It allows people’s bellies to relax because their needs have been acknowledged. You can begin the work of recovering from the amygdala hijack, because you’ve reset the temperature in the room.

My parents actually taught me to “be the thermostat, not the thermometer”. It’s not always easy, that’s for sure. But by being aware of these cycles, we’re more likely to remember to use our thermostat power for good (not just give up or bail out when you notice someone else is running hot).

Next time you find yourself in a conversation that’s exuding some off vibes, or even an intense one, if you use a combination of these tools, you’ll be giving others the opportunity to mirror the temperature you set right back to you.

“What we recognize is what we reward.”

I first heard someone say this in 2013. My leadership team was deep in a heated discussion about how to get more engineers to consider mobile web when building out new features. An absolute given now, it wasn’t then.

At my organization, I was simultaneously trying to convince my fellow managers to think about how their new features might work on mobile devices and ideally, add UX improvements for the mobile experience to their roadmaps. Mobile wasn’t quite a thing yet, so this was an (extremely) uphill battle.

A senior leader was asking about all the different ways we might reinforce this new development approach on teams. Sure, our CTO could get up and say things like “mobile-first” repeatedly at our next All Hands meeting—but how could we encourage more folks to start building for mobile web over time, as the norm rather than the exception? I can’t remember who said this phrase, but it has informed my management philosophy since.

We often reinforce behaviors accidentally. When we mention someone’s impressive project in their promotion email, ask a team to demo their upcoming release at a meeting, or add a Slack emoji high-five response to a comment, we are implicitly recognizing something we like about their behavior. And even though it’s usually unintentional, we are signaling to those around us that we want to see more of that behavior.

“What we recognize is what we reward.” This sentence suddenly illuminated the reinforcement of behaviors all around me. I was inspired to brainstorm a list of actions leaders can take that reinforce what we want to see at work. What are all the public and private mediums we use to signal—intentionally or not—what kind of approaches, attitudes, or projects we value?

Brainstorm your recognition options list

Take twenty minutes and draw a table like this: columns for team and individual recognition, and rows for public and private recognition. Then fill in all of the different ways your organization recognizes people. Monetary, non-monetary, all of it!

Don’t just fill in the ways that you reward people; write down all of the ways that team or individual behaviors, attitudes, approaches, etc. are acknowledged in public and private settings.

Team Recognition Individual Recognition Public

Presentation at a company meeting (like demoing work)

Project launch @all announcement emails

#celebrations or #high-fives Slack channel mentions

Awards for an individual

Shoutouts in a group environment (Slack channel, company meeting, thank you in a launch email)

Assignment of a “lead” role on a project

Promotion announcement

Private

Announcement (email or in person) within a team, celebrating team wins

Spot bonus

Non-monetary acknowledgement (words of appreciation in a 1:1; being given more autonomy)

Promotion without an announcement

Sponsoring individuals outside of the team’s work (nominating them to write a blog post or speak at a conference)

Once you’ve filled in this table with your own organization’s approach to recognition, dig into the effects of this list a little more. Ask yourself:

• Where are there gaps? Which boxes have less items?
• Which items in this list are unique to your company?
• How do people at your company expect to be recognized?
• Where are there standards in place (e.g. the list of things you should mention in each promotion announcement, and who that promotion announcement should be sent to), and when might leaders use their discretion?
• Look at recent places where people have been recognized/acknowledged. What behaviors were (intentionally or unintentionally) reinforced through that mention?

Identify the behaviors you want to see

If you’ve ever worked with an asshole who got a promotion, you know how infuriating it can be to see bad behavior overlooked—or even encouraged. When we acknowledge someone’s behavior in public, even if it’s in a tiny way like adding a Slack reaction to their comment, we are (often unintentionally) rewarding it for all others to see.

Humans, like most other mammals, have some hard-wired instincts to mimic each other. And since we can subconsciously pick up on what’s important to people in power when they recognize or acknowledge others, we might start to mirror that behavior, too.

So, leaders, you have a big opportunity here: if you want to encourage new approaches, new patterns of behavior, new outcomes, how might you reward that behavior by recognizing it in public?

This will take some intention, and some practice—and through the process of figuring out what new behaviors you want to see from your team, you might also notice what bad behaviors are being unintentionally reinforced.

Unintentionally rewarding behavior

I once worked at a company that had a string of six consecutive promotion announcements for infrastructure engineers to staff level. For a long period of time, nobody working in product engineering received a promotion announcement to the whole engineering organization; those promotions were announced just to their direct team members, if they got an announcement at all.

What did this communicate, however unintentionally, to the organization? That infrastructure work was more valued by leadership than product work. Engineers began to brainstorm ways to move to the infrastructure part of the organization, or to do more refactoring projects for their product features.

But when we as leaders intentionally recognize the behaviors we want to see, a lot of good can come from it. Some examples:

• My old performance team at Etsy named a monthly “performance hero”; we celebrated folks working on product teams who significantly reduced page load time to their area of the site, and had a dashboard on the wall showcasing their name, face, and incredible performance graph to all who walked by.

• Etsy also gives out a “three-armed sweater” award to the engineer who had a spectacular mishap in the last year as a way to explicitly celebrate a culture of learning from incidents.

Recognize what someone does, not who they are

Something to keep in mind: be sure you’re drawing attention to, and recognizing, what someone does, and not who they are. If we get praise for something we do (such as paying attention to detail), we attribute our success to our own efforts, which we can control. (This also signals to others the behavior they can do, too.)

If we get praise for what we are (e.g. “clever”), we attribute success to a fixed trait that we possess, and send a signal that personality traits one may have, or not have, are the only way to be successful.

Leverage those avenues for recognition

So how did my efforts to get my colleagues to care about building for mobile play out? Through a mixture of recognizing the behavior we wanted to see (celebrating other teams’ wins at All Hands meetings by demoing how their feature rollouts worked on mobile devices), making it easier to build for mobile (we built a device lab that made it more fun to test stuff), asking our CEO and CTO to reinforce the importance of mobile-first work in a variety of communication mediums, putting up a big dashboard showing our growing mobile userbase, and, of course, scheduling a hack week to help folks dip their toe in to mobile web development… we got there.

Recognition as reward is one tool for behavior change, but it is a powerful one. You don’t have to do something as big as an official reward or celebration! Each line item in your recognition table is an opportunity for you to reinforce the behaviors you want to see.

Whether you’re inviting a team to present their work at an All Hands, sending a loaf of banana bread to a team member who really helped out their colleagues on the support team last week, or acknowledging someone’s work by making a donation in their honor, you’re signaling what behavior you’d like to see more of. Have fun with it. :)

Congrats, you’ve made it through your first 2 months as a new hire in a leadership role! You’re in the home stretch of this initial season.

You took advantage of the first 30 days in the role to build trust by employing “sponge mode.” You asked lots of questions, genuinely listened to your teammates’ answers, and avoided enacting any sweeping, permanent changes to the way work gets done.

Then you leveraged what you learned during those first 30 days by announcing and running two experiments for change. These experiments were born of the concerns you heard that were most important to folks on the team and carefully constructed to identify tradeoffs. You promised to communicate the results of those experiments next.

So, here we are!

Gather the results of your experiments

As the experiments wrap up, check in on those measures of success that you identified and shared with your team. Document the information that you were able to glean: how did each experiment impact metrics, sentiment, and the other things that your teammates care about?

You might have a jumble of notes; that’s okay! Group your running list of experiment outcomes, measures of success, and surprises into the following areas:

1. The themes you heard from your teammates in your first 30 days (or how the experiment was crafted to directly address concerns)
2. Results tracked to your success metrics (quantitative and qualitative)
3. Surprises and new learnings that came up along the way
4. Open questions you (or others) still have that should be answered before any lasting change is decided upon

If either of the experiments weren’t a success, it’s not only okay, it’s great info. With whatever the results show you, you can decide what to do next. Maybe you’ll want to craft a new experiment or maybe the success is that you know that whatever you were experimenting with isn’t the right move after all.

In addition to measuring those success metrics, note any surprises that came up along the way. These may have been things you are surprised by, or things that other folks shared surprise about as the experiment was running. (There are some examples in a footnote if you need them!)

Decide on changes

Take the work you did above (experiment outcomes, measures of success, and surprises that relate to the themes you heard from your teammates in your first 30 days) and decide: what lasting change(s) will you decide to implement and announce as a result of these experiments?

Maybe you’re going to announce something disruptive like a reorg, or brand new roadmap. Or maybe you’ll announce a chance to processes like sprint planning. Large or small, fill out this template for each change:

The What
Here’s what’s changing:  (If it’s relevant) Here’s what’s not going to change:  The Who
Here’s who’s impacted by the change:  The When
Here’s the timeline for the change:  The why
Here’s why this change matters to folks:  Build trust
Here’s some concerns or tradeoffs we're acknowledging:  Future-proof
Here’s what you’ll be continuing to measure or check in on going forward:  Follow-up
Here’s who to reach out to with feedback, concerns, or questions about this change going forward: 

I’m using our communication plan template as the foundation for this table. You may not share all of the information in this table with the whole team, but by walking through this template, you can feel better-prepared for communicating the change and navigating the response.

Communicate the experiment results

Choose a medium that feels normal for your organization and appropriate to the scale of the change: a part of an all hands meeting, a special meeting just for this information, a launch email, whatever feels right. If you’re not sure about what medium is appropriate, get a gut-check from a trusted colleague.

Kick things off by recapping what the first experiment was and what you were measuring (both measures of success, and any issues folks were concerned about). Then share the results of this first experiment. Include:

• The metrics/quantitative data results
• Relevant surprises/lessons learned
• If applicable: Open questions you still have that should be answered before any lasting change is decided upon
• The next change, or series of changes, based on the outcome of the experiment (If nothing is being implemented either because you’re going to adjust and set up a new experiment, or you learned the experiment means nothing should actually be implemented, say that here.)

Here’s an example outcome you might announce:

“We’ll use this new candidate assessment rubric going forward. We’ll consider this a living document that lives on our wiki; I’m excited to continue to adapt this document for the organization as we learn more, and hire for different kinds of roles, too.”

Add anything else from the template above that you think would be helpful for folks to hear. Remember, you’re still building trust with the team.

Go through the same recap for your second experiment, then open the floor up for your teammates to ask you questions. This is crucial to maintaining that trust you’ve built so far! You’ve prepared for hesitancy, pushback, and concerns using the template above. My #1 tip is to continue to tie the change back to the themes you heard from folks in the first 30 days.

That said, change is scary! It might take some time for your teammates to get on board with the change(s); here are some tips on navigating your colleague’s resistance to big news. Additionally, make it clear how folks can share feedback with you (or the person who will be responsible for any change going forward).

You’ve got this! I know bracing yourself for teammates’ reactions to change might make you want to tiptoe through this process, launch changes without this prep and communication approach, or avoid making these decisions altogether. But as a leader, you’re responsible for making informed, intentional changes that help your team—and as you learned in your first 30 days, your teammates are already hungry for some things to evolve. :)

Remember, these first 90 days are the best chance you’ll get at building a strong foundation of trust with your team. When you approach organizational changes with active listening skills, measurable experiments, and proactive communication, you’ll find yourself in a much stronger position to lead this team going forward.

In summary

First 30 days: sponge mode

1. Hold one-on-ones with everybody
2. Identify 1-2 overarching themes you’ve heard
3. Convey what you’ve absorbed
4. State how people can communicate with you going forward

Keep in mind: you’re not changing anything yet, just listening

30-60 days: experiment with two ideas for change!

1. Craft two experiments
2. Develop your communication plan
3. Implement your experiments

Keep in mind: you’re not changing anything yet, just experimenting

60-90 days: decide on and communicate change

1. Gather the results of your experiments
2. Decide on changes
3. Communicate the experiment results and any changes you’re implementing
4. Follow-through with future comms and check-ins

** Some examples of what might have been a surprise:

• You didn’t realize how much page load times varied for your users around the globe; the experiment highlighted this additional issue as you measured users’ checkout flow progress.
• You learned how delightfully easy it is to run an A/B test using the tools that your team has already built. You can thank them for this work!
• Members of your experimental working group shared their surprise about how challenging it can be to create quick feedback loops with their teams.

Woohoo, you’ve made it through the first 30 days in your new leadership role, and you didn’t change a thing! Congrats—you’ve been building trust by soaking in information and helping folks on your team feel heard and seen.

At this stage, you now have some ideas for how your teams accomplish and communicate their work, what the roadmap looks like, how performance is assessed, and a number of other things that you want to implement.

But wait—before enacting any lasting change, it’s crucial to connect the dots between your ideas for change, and the themes you heard from your new teammates during your first 30 days. To help your colleagues get on board with potential future changes, communicate your ideas using time-bound, specific experiments.

Craft two experiments

Before enacting big organizational changes in your new leadership role, narrow (all of) your ideas down to two possible changes and develop a time-boxed, measurable experiment for each. Maybe you prioritize the changes by size of the lift, going small first, or maybe it’s the urgency you heard around one change or another.

We’re intentionally limiting this process to two experiments because tons of change at once will be scary and confusing for folks. We’re also going to limit the experiment timeline to 2-3 weeks; the goal is to be able to gather data at the end of your first 60 days in your new leadership role.

Here are is an example of a change you might want to make as a new leader in this organization, and an associated experiment as inspiration:

• To try to deliver more value to our users, we’re going to experiment with using earlier prototypes in user interviews.
  • Who, when: We’ll run this as an experiment with Feature Team Zebra for three weeks, in collaboration with our UX team.
  • Success metrics: We are going to measure user sentiment about the interview process, and gather feedback from the designer and engineers on the team about how it felt to show users an unpolished version this early. We’re also going to compare the information we gather from these user interviews to past user interviews and see what’s different about what we learn.
  • We’ll report back with our findings in a presentation at the next all hands meeting.

If your change is really big

You might be stumped: what if the change you want to make would take longer than 2-3 weeks, or worse, it’s an irreversible change?

Think about the process to make this change from start to finish: how can you run an experiment on one of the early steps towards the change?

For example, making a new hire is a big irreversible change. Can you run an experiment on what the job description says, how you conduct your interview panels, or implementing an assessment rubric?

How to choose experiment metrics

Choose measures of success that directly tie to the goal of the experiment and help people get on board with it. You can use these to address concerns from blockers/stakeholders. For example, “we know that [this] is a concern, we’re experimenting with [experiment], so we will be tracking this with [this metric].”

It’s obviously ideal if your metrics are quantitative; however, because we want to help folks who might otherwise feel hesitant begin to feel more okay with the experiment, your measures of success might be qualitative. You can also do both.

For example, “At the end of the experiment, I’ll be asking folks on the team these four questions about what they learned, and what was surprising. I’ll share the good, bad, and the ugly themes from those interviews with the whole team. :)” This can be a great way to help people feel a little bit more open to trying something new, because you’re leaving room for them to share their feedback afterward, which makes them feel included while something is happening outside of their control.

(If you want to be extra prepared here, or you run into some surprising emotions from others, I recommend reading one of my previous, and always applicable, blog posts on the topic).

Develop your communication plan

It’s important to let your organization know about the upcoming experiments, both to give folks a heads up about how they might be impacted, and to help your teammates feel heard and seen. Remember, these experiments aren’t just a way for you to enact change; they are another opportunity for you to build that foundation of trust with your group.

Use whatever timing and medium is typical for leadership announcements, like the next routine all hands meeting, roadmapping meeting, your week-in-review recap email, etc. Here’s an overview of how to create a communication plan for your news. (If you want more on communication, here are all my resources on the topic.)

Unless you have evidence that the managers who report to you are strong communicators, communicate these experiments yourself to the relevant groups. It’s great to give your managers a heads up first, but you should be doing the heavy lifting of communicating any changes for now. Again, this is an opportunity for you to follow-through and build trust with your organization.

What to communicate

Give a brief intro that references themes you’ve heard from the team—the ones that you shared broadly at the end of your first 30 days. Share that you’re excited to run two short, time-boxed experiments to see how we can make progress on those themes.

As you describe the experiments, make the metrics of success and the timeline tremendously clear. Again, we’re all about creating predictability for folks, and we want to help them connect the dots to the concerns or desires for change that they voiced when you onboarded. Don’t ask folks to read between the lines of your ideas; be explicit!

Acknowledge any tradeoffs that may come up while running these experiments, based on themes you heard in sponge mode. Again, you can reinforce that the metrics of success are a way to address concerns that folks might have: “we know that [this] is a concern, so we will be tracking this with [this metric].”

Some people might not want this change because of the tradeoff or another reason; you can proactively acknowledge that we’re making [XYZ tradeoff] for [ABC] purpose to achieve [DEF] goal. An example: “I know that [roadmap predictability] is important to folks—I agree; it’s important for us to have a shared vision and less disruption so that we can make progress. That said, [delivering user value] is our core focus for these next 30 days; we’re going to have some surprises and changes to help us deliver on that goal.”

Implement your experiments

It’s time to kick off these experiments.

Set up a way to keep track of the metrics you outlined as you go, whether that’s a spreadsheet, Google form for qualitative feedback, or a dashboard. Keep notes on anything you’re learning that would inform permanent changes. (Don’t make the permanent change yet! You’re just keeping notes right now!) Perhaps you are seeing things you’ll need to adjust in subsequent experiments.

If anything shifts mid-way—like something happens outside of your control that necessitates adjusting the timeline—be sure to communicate this change to those who will be impacted.

At the end of your first 60 days

Prepare to share the results of your experiments. Check in on those measures of success, and note any surprises that came up along the way. Begin thinking about what takeaways you want to turn into lasting change for your organization, and if there are any new experiments you might want to run, now that you’ve gathered some interesting insights.

We’ll talk more about how to share these results in the next post.

In summary

First 30 days: sponge mode

1. Hold one-on-ones with everybody
2. Identify 1-2 overarching themes you’ve heard
3. Convey what you’ve absorbed
4. State how people can communicate with you going forward

Keep in mind: you’re not changing anything yet, just listening

30-60 days: experiment with two ideas for change!

1. Craft two experiments
2. Develop your communication plan
3. Implement your experiments
4. Prepare to share the results

Keep in mind: you’re not changing anything yet, just experimenting

You’ve started in a new role: congrats!

Throughout my years as a coach, I’ve seen lots of my clients land in a new leadership role as a director or above, and make a well-intentioned but enormous mistake: they make a big change within their organization before building up trust with their teams.

I’m eager to help you avoid this classic pitfall! Let’s break it down into how you should think about enacting change in your first 30, 60, and 90 days as a senior leader.

First 30 days: sponge mode

We’re calling your first 30 days “sponge mode” because your primary job during this period is to soak up information.

This means, for your first month, you should be in listen-only mode. I’m serious! These first 30 days are the biggest opportunity you’ll ever have in this role to build trust with your teammates. Don’t squander this opportunity by coming in and enacting change right away.

I totally understand the desire to kick off your new role with a few tiny changes to team processes, meetings, roadmaps, etc. You might be eager to to do this because you want to:

• prove you were the right choice for the role,
• demonstrate progress or your impact as soon as possible, or
• build trust and strengthen these new relationships by enacting the changes your teammates want to see.

This might come as a surprise: no matter how well-intentioned you are, enacting change within your first 30 days could jeopardize your trust and standing. So if you feel any of those reasons eating at you, please pause. Spend these first 30 days sitting in on team meetings and talking to everybody on the team.

Hold one-on-ones with everybody

Schedule one-on-ones with everybody on the team, your new cross-functional peers, and other stakeholders around the company. Some folks call this a “listening tour.” Yes, this will take up a lot of time; it’s worth it, I promise.

At this stage, you don’t need to have figured out your one-on-one cadence with your direct reports and cross-functional partners; you’re just scheduling one-off 30-minute meetings to be able to talk to everybody and soak up a ton of information.

As you send out the calendar invites for these initial one-on-ones, include a sentence or two about the goal of the meeting to give folks a sense of predictability, and help them prepare if they want to. I like to write something like:

My goal is to talk to everybody in the [Product] team, so that I can onboard and get as much context as possible in my first 30 days! In this meeting, I’ll be asking you what stuff in our department is working really well, and what stuff you’d like to see change. I’ll also be happy to answer any questions you have for me!

During each one-on-one, follow these steps:

1. Introduce yourself, and give a quick recap of what this one-on-one is about. Something like, “Nice to meet you! I’m Lara, and I’m eager to chat with you about how the organization works, what the roadmap for our department looks like, our team processes, etc.”

2. Ask question #1: “I’m curious: when you think about [the Product team] as a whole and how it works, what change do you want to see?”

   Give them lots of space to share; some folks might have lots of ideas, and others no ideas at all. (That’s okay!)

   If they ask you for examples, you can say, “I’m intentionally asking a really broad question to see what comes up. Maybe you have ideas on how code reviews work, or our career ladder, or our communication patterns. It could be anything! What comes to mind for you?”

   Reflect back what you’re hearing them say just to make sure you have it right.

   Then ask some of these follow-up questions to more deeply understand their answer:

   • “Got it. What do you see as the risk if we don’t make that change?”
   • “What feels most important to you about this?”
   • “If we make that change, how would that impact you/your crew?”
   • “Who else would you recommend I chat with about this?”

3. Ask question #2: “Alright, time for the flip side: what’s working so well that we shouldn’t change?”

   Just like with the first question, leave lots of space for them to share. Reflect back what you’re hearing them say to make sure you have it right. And ask follow-up questions to more deeply understand their answer.

4. As you wrap up the one-on-one, let them know when they’ll next hear from you, and how they can get in touch with you if they have follow-up questions.

The one exception to sponge mode

The only exception to the first 30 days sponge mode rule is if someone’s health or safety is threatened.

A coaching client once called me two weeks into their new role and said, “I’m so sorry, Lara, I broke the #1 rule for the first 30 days. I had to make a change. Someone broke their leg skateboarding near the machinery, and so I had to make a new rule that there will be no skateboarding near equipment.”

You’re likely not going to find yourself in this particular situation. But you never know! Anything of this ilk is truly the only thing you should change!

Big changes might still happen in your first 30 days

Sometimes, enormous changes will happen within your first 30 days that are outside of your control. The CEO is fired. A round of layoffs has already been planned. Your lead engineer quits. HR revamps how compensation and promotions are handled.

You’re along for the ride. You can nudge these changes based on your experience and skills: help leadership implement a communications plan, flag potential pitfalls to decision makers, ask questions and give feedback.

But please please please do not enact new change until after you’ve been in sponge mode, gathered the data, and started building these relationships. I know it’s tough—and the process will be imperfect—but you’ve got this.

At the end of your first 30 days

You’re going to share what you’ve learned with the entire organization. To do so, take a look at what you’ve absorbed in sponge mode and synthesize it.

Identify 1-2 overarching themes you’ve heard.

Consider what you heard in your organization-wide one-on-ones, and find the common threads. Plan how you’ll communicate these themes in a way that will be heard. Keep these themes future-focused; you’re working towards aligning on what the future will look like, rather than dredging up feelings and pitfalls of the past.

You can plan to use broad language like, “team cohesion is the #1 most-requested thing for us to focus on” or “as an organization that’s scaling quickly, we could use more predictability around roadmap changes and a unified vision to align us across teams”. Ideally, these themes will resonate with the folks in your organization—you’re representing what you heard in your one-on-ones, and this will immediately build trust. Demonstrate what a good listener you are! :)

I recommend you avoid providing very specific examples of past events to illustrate these themes, because it’s likely that each person experienced them differently. If folks disagree with or misunderstand your examples, you risk amygdala-hijacking folks, which means they’ll be tuned out for the rest of the meeting. You’ll also risk the trust you’re trying to build. There likely will not be enough time for nuance in this meeting, and again, you want to stay future-focused.

Convey what you’ve absorbed.

Share the themes you’ve heard in your first 30 days with your whole organization. I highly recommend doing this in an all hands meeting; it really helps when people can see your face, hear your voice, and ask you questions in real time at the end.

The goal of this recap is to help your teammates feel heard and seen. Reminder, the goal is NOT to kick off changes! We’re not at that stage yet :)

Be open to the feedback you hear. Maybe you misinterpreted, maybe someone thought of something else after you met with them.

Consider this a meeting for reflection—a step often skipped by leaders—which will help you build that foundation of trust. Don’t waste it.

Optional: share wins.

If it feels relevant, you can share wins you’ve already seen around those themes, driven by folks on the team. (I’m not talking about wins driven by you or other leadership.) By verbally recognizing the work that you want to see more of, folks can begin to sense what you will be looking for going forward.

Optional: hint at changes you’re considering to address those broad themes.

You can tease examples of experiments you might run or changes you’re considering to address those broad themes. Tread lightly—again, you’re still in listening and relationship-building mode. (We’ll talk more in the upcoming 60 days post about experiments!)

Required: state how people can communicate with you going forward.

Be tremendously specific, and make sure you can follow-through with any communication mediums and cadences that you are committing to. You will erode trust if you need to reschedule lots of these one-on-ones or Q&A meetings. Some examples of clear communication expectations:

• “I’ll have office hours every Tuesday; you can ask me questions during those office hours by sending them to me via Slack before or during the meeting.”
• “I’ll be setting up routine 1:1s with you all every N weeks; please reach out to me via Slack anytime if you have a question or want some information between 1:1s.”

Again, stick to that plan. Follow through!

And when this plan inevitably needs to change in the future (hopefully after your first 90 days!), proactively communicate to the whole organization any updates about how folks can reach you.

In my next blog post, I walk you through the 30-60 day period of a new senior role.