Escalate, Absorb, Flag

Earlier in my management career, I was an over-escalator. I escalated constantly. I’d like to formally apologize to my former director.

I thought I was doing exactly what good managers were supposed to do. I was keeping my director informed. If there was even a chance something might become important, I made sure they knew.

I wasn't wrong, but I also wasn't right. Most importantly, I wasn’t making their job easier.

Ultimately leaders don't just need information from their direct reports. They need judgment.

My director wasn't looking for a human notification system. They needed someone who could process ambiguity, solve what was solvable, and involve them at the right moment.

Though not my personal brand, I’ve also witnessed the other end of the spectrum - what I will for lack of a better name call the absorber. This is the person who gets reasonably capable and starts handling everything on their own. Even things way beyond what they could reasonably solve themselves. Nothing gets bubbled up to their manager or someone more senior in part because they’re afraid that saying there was an issue they didn’t solve means they weren’t capable or were somehow lacking. 

Most leaders hate surprises. Absorbing too much information creates them. 

There's a third category that sits between escalating and absorbing. I call it flagging. You reach out to your leaders and say here’s the problem and here’s what I’m doing about it. Here’s what I need from you (if anything). Flagging gives your manager context before they need to ask for it. If everything goes according to the plan you laid out, they already knew about the risk and saw you handle it. If things go sideways, they aren't learning about the problem for the first time in the middle of a crisis. Remember: no surprises!

The difference between flagging and escalating is ownership. When you escalate, you're asking someone else to own the problem or make the decision. When you flag, ownership stays with you. Awareness expands but you’re not handing off ownership of the problem. The added benefit of this approach is that it makes your work visible. All that effort you’re putting into problem solving is suddenly additional credibility building your reputation. Leadership sees the problem and sees you handling it. 

Imagine that I received two slack messages from engineers on my team. One message reads: "There's a dependency on Team B." And the message other reads: "There's a dependency on Team B. I've already reached out to them and we have a meeting tomorrow. If they can't commit by Friday, we'll need to talk about de-scoping Feature X."

If you were in my shoes which engineer would you consider more senior? Which engineer would you trust more? Probably the second engineer, and not because one has fewer problems than the other, but because one has demonstrated ownership. 

When a person thinks they're saying, "I have a problem." The manager hears: "I'm handing you a problem." Those aren't the same message. On more than one occasion I’ve compared managers to beavers. If a beaver hears running water they’re compelled to try and dam it. If a manager hears of a problem without a clear solution they’re going to try to solve it. By including what you're doing about a risk, the message becomes: "I have identified a risk and I'm actively managing it." That's an entirely different signal.

Every leader has different preferences, but the principle stays the same: communicate in a way that increases visibility without unnecessarily transferring ownership.

It’s not always easy to know which approach to take. Becoming more senior in your role doesn’t mean flagging is the right solution every time. But with enough exposure to problem solving, eventually you develop an instinct for which situations require which response. Some risks should automatically be escalated because they're high risk, irreversible, or outside your authority to decide. Some risks are simply part of your job - you can handle them and move on. Most risks live somewhere in the murky middle. In those cases it’s generally beneficial to flag them because leadership needs visibility into what's happening while trusting you to keep driving.

My standard gravitates towards: escalate when ownership needs to move, flag when ownership stays with you, and handle it yourself when you can resolve an issue and move on.

The goal isn't just to minimize what lands on your leader's plate. It’s to become someone your leaders trust with hard problems because you know the difference between solving them in a black box and communicating them upward.

While I am no longer the new manager escalating everything, I do look back on her fondly. She just needed a minute to figure out that what her leaders wanted from her wasn’t just communication, but judgment. 

Leading Before There’s Clarity

Organizational transitions create an unusual leadership problem: people need help interpreting change before anyone has complete answers.

As an engineer, organizational changes felt distant. I could wait for clarity before deciding what I thought.

Management changed that. Managers don’t just experience transitions. They help shape how other people experience them. At some point, people stop asking only what you think and start inferring meaning from how you react.

People weren’t watching me because they were evaluating me. They were watching me because they were trying to understand what the moment meant.

I remember commenting on a visible Slack thread during a major organizational transition. It felt strange because I realized people weren’t just reading my opinion. They were interpreting it as a signal.

Normally in large scale meetings I wasn’t in the habit of speaking up unprompted. I was either on an official panel, presenting, or participating in the Q&A. 

We all got on a zoom call. There were almost a hundred people in attendance. This time, when the Zoom call got quiet, I spoke. I shared my support for the person stepping into a bigger role. I knew that even if I didn’t have all the answers at that moment, I trusted this person to step into the role. I only said what I truly meant and yet it still felt deeply uncomfortable.  And after, I realized: I’m at the level now where if I’m not one of the ones speaking in those moments then who is?

Providing visible support can feel political or artificial, but silence reads as uncertainty faster than you expect. Speaking up wasn’t about pretending to have certainty or performing optimism. It was about helping reduce ambiguity. During transitions, people fill informational gaps with social cues. Their managers are some of the first people they look to. Visible support isn’t performance. It creates alignment. 

I also realized my audience wasn’t just my direct reports. Organizational transitions aren’t carried by executives alone. Every layer of management helps people make sense of change. Senior leaders announce direction. Middle managers translate what that direction means in practice.

I learned the longer you wait to engage, the more you’re absent from the conversations where direction is still forming. By the time certainty exists, many of the assumptions and narratives have already formed. The people who engage early don’t just react to change. They help shape how everyone else understands it. That’s not compliance. It’s agency.

The strangest part wasn’t speaking up. It was realizing I had crossed into a level of leadership where staying quiet would have communicated something too.

Leadership during transitions isn’t about having the answers first. It’s about recognizing that people start interpreting your behavior long before you have them.

The higher you move in an organization, the less your silence belongs only to you.

Empowerment Isn’t an Announcement

I once had a conversation with an engineering leader who was discussing a lack of empowerment among their reports. “You’re empowered!” they stated emphatically. 

This move reminded me distinctly of an episode of “The Office” where the boss Michael Scott tried to declare bankruptcy by shouting to the rest of the room, “I declare bankruptcy!” 

Loudly proclaiming something to be true worked in exactly neither of these situations. In both, the person displayed a complete misunderstanding of how the system actually works. 

Announcing empowerment is not the same as creating an environment where people can exercise it. The declaration feels like action but doesn’t change anything about the system that’s in place. Leaders often confuse stating intent with creating the conditions that make the outcome possible.

Often what’s holding a team or an org back from empowerment is a lack of safety and clarity built into the team infrastructure. Nominal authority without psychological safety is unusable. People need to know what they own, what the boundaries are, and that acting within them won’t get them burned. 

I’ve seen talented people afraid to act on initiative because of one negative previous experience. Teams remember where initiative became painful, and organizations teach empowerment through memory more than messaging. 

Another blocker to having an empowered team is not understanding clearly who owns the decisions. I’ve lost count of the number of times I’ve watched teams spend fifteen minutes trying to answer a simple question: who actually gets to decide this?

Now imagine those same people in situations where they are the decider and don’t know it. Ambiguous ownership kills autonomy quietly. Without explicit rights, people default to asking rather than acting — and that looks like disempowerment even when it isn’t.

The hardest source of disempowerment to diagnose is often the most invisible one: escalation cost. People may technically be allowed to decide but rationally avoid it because the cost of being wrong is too high. 

It takes a lot of intentional effort to build a space where failing is an accepted part of the process. 

Without a safe space to fail, calling out a lack of empowerment is infrastructure failure masquerading as individual deference.

I’ve also seen situations where someone was encouraged to operate more autonomously, took initiative, and then discovered the organization had a much narrower definition of acceptable autonomy than they realized. Not because the work itself was catastrophic, but because it created social or political friction. 

Experiences like that train people quickly. Teams learn what kinds of risks are tolerated, regardless of what leadership says in principle.

When empowerment isn’t happening, there’s one explanation leaders reach for surprisingly often. It’s leaning on the idea that people don’t want to take advantage of empowerment, that they don’t want to be leaders. You can offer people empowerment but you can’t make them lead. 

Some people genuinely don’t want autonomy, but that’s also the most available rationalization. The harder question: did they not want it, or did they learn it wasn’t safe here? 

Teams don’t learn empowerment from mission statements.

They learn it by remembering what happened the last time someone acted without asking.

How Leaders Create Emotional Defaults

I once inherited a team where the manager and tech lead were known for getting into yelling matches in front of the rest of the team. The act of disagreeing didn’t bother me. Healthy teams disagree all the time. I was bothered by what the team had learned from watching it.

Every piece of bad news was treated like an attack from senior leadership. Every disagreement became a battle to win. Every problem became personal.

Long before I arrived, the team’s emotional norms had already been set.

It showed up everywhere. A roadmap change wasn’t interpreted as normal course correction. It was evidence leadership didn’t care. Feedback wasn’t something to learn from. It was something to defend against. Even neutral conversations carried an undertone of tension.

We often talk about managers shaping culture through hiring decisions, processes, incentives, and organizational design. We talk less about the role emotions play.

Nobody sat this team down and said, “Every roadmap change means leadership doesn’t care.”

Nobody had to.

They learned it the same way children learn whether it’s safe to ask questions at home: by watching the people with authority react over and over again.

Whether we mean to or not, teams learn how to react to uncertainty, setbacks, and conflict by watching us react first. 

Teams don’t just inherit processes from managers. They inherit emotional defaults.

I remember our first team retrospective. I asked what we could improve, and the room went quiet. Absolute crickets. Nobody disagreed with anything. Nobody offered feedback. They were so used to retrospectives turning into shouting matches that silence felt safer than honesty.

Earlier in my career, emotional regulation was mostly a personal skill. If I got annoyed in a meeting or frustrated by a decision, the impact was largely contained to me. Being a manager changed that.

I realized that people weren’t coming into one-on-ones looking for me to match whatever emotion they walked in carrying. If they were frustrated, my job wasn’t to become frustrated too. If they were anxious, it wasn’t to become anxious with them. Empathizing is one thing, but my job was to help them leave in a better emotional state than they arrived.

If I respond with frustration, I’m giving them permission to stay frustrated. But if I can shift to curiosity or next steps, folks tend to follow my lead.

I can’t do that very effectively if I’m being pulled around by the same emotions in real time.

When you’re a manager, your emotions don’t stop with you anymore. The team may already be frustrated, worried, or disappointed. The question is whether your reaction pours fuel on those emotions or creates space for something more productive.

I used to think staying calm was mostly about professionalism. Over time I realized I wasn’t regulating my emotions for my own benefit anymore. I was regulating them because everyone else was watching what they should do next. Eventually I learned that those reactions become norms woven into the fabric of the team’s culture. 

That doesn’t mean managers need to be polished all the time. In fact, people rarely trust perfection.

Sometimes that means acknowledging that a decision is frustrating before asking everyone to move forward. Sometimes it means admitting you don’t have all the answers yet. Sometimes it means deliberately slowing your own reaction so the team has room to think instead of simply mirroring your panic.

I’m also not saying that managers shouldn’t have emotions. Quite the opposite. Because our emotions help create the environment everyone else works in. The problem isn’t having emotions. The problem is forgetting that those emotions arrive amplified.

I used to think culture was mostly built through decisions: who we hired, how we planned, what we rewarded.

I still think those things matter.

But I’ve become convinced culture is also built in hundreds of tiny emotional moments that nobody writes down. Every time a leader reacts to bad news, uncertainty, disagreement, or failure, they’re teaching everyone else how those situations are supposed to feel.

That’s why emotional regulation stopped being a personal skill the day I became a manager.

When Your Work Stops Looking Like “Work”

I remember when I was learning to code someone put into words what a bunch of the junior engineers and I were feeling, which was how crazy it is to spend all day building something and at the end of it just have the same laptop on the desk in front of you. You can’t see what you built, you can’t touch it. It’s hard for the brain to understand that level of abstraction.

Eventually I got used to it. I learned to measure what I built in other, non-physical ways: the tickets I closed, the pull requests I merged, the dashboards I created, the incidents I resolved.

But then I switched into management and had the same feeling all over again.

I knew I was doing the work, but why couldn’t I see it?

I could finish an exhausting day and struggle to point to anything I’d “done.” My calendar was full. Conversations had gone well. A conflict had been resolved before it became an incident. A roadmap had become clearer. None of those things looked like work in the way writing software had.

It took me a while to realize the work hadn’t disappeared. The evidence had.

As an engineer, my work naturally produced things people could point to. Engineering organizations are built to recognize those outputs because so much of their tracking, reporting, and planning depends on them.

Instead of producing software, I was increasingly shaping the conditions under which other people could produce it. I was preventing unnecessary work, clarifying ownership, aligning stakeholders, sequencing priorities. If I did my job well, other people’s work improved.

Engineering creates software. Management changes systems.

Execution leaves evidence. Strategy often doesn’t.

That’s where the transition into management can feel surprisingly disorienting. Execution answers the question, what happened? Strategy answers the question, why did it happen?

Most organizational systems naturally measure the first. Not because strategy isn’t valuable, but because visible outputs are easier to recognize than good judgment.

Performance reviews, promotion packets, and status updates all depend on visible evidence. As a manager, you’re still expected to fill those containers even though more and more of your work happens before anyone else sees the result.

That’s why promotion cycles can feel especially unsettling for new managers. As your work becomes more strategic, it also becomes less naturally visible.

Part of your job becomes making your thinking visible. Not because you’re self-promoting, but because other people can’t act on reasoning they never see.

That’s also why more senior engineering leaders often ask different questions than engineers.

I’ve seen countless interactions where engineers become anxious because they’re being asked questions without understanding what senior leadership is actually trying to learn.

Engineers tend to ask: What shipped? What broke? How long did it take?

More senior leaders ask: Why this work? Why now? What didn’t we do?

They’re trying to understand the reasoning behind the execution, because that’s the layer they can use to make future decisions.

Ironically, strategy often becomes visible only when it’s missing.

A dependency wasn’t actually ready. Two teams thought the other owned the migration. A launch slips because a stakeholder constraint surfaced too late.

Suddenly the alignment work everyone took for granted becomes obvious in its absence.

Early in management I kept looking for evidence that I’d done good work. A finished roadmap. A completed project. Something concrete.

Over time I realized I was looking in the wrong place.

Strategy rarely leaves fingerprints.

I realized I wasn't missing evidence because I wasn't doing the work.

I was missing evidence because I wasn't leaving any.

So I stopped looking only for outputs and started documenting decisions. I started documenting the reasoning behind decisions instead of assuming everyone had been in the room. The tradeoffs. The constraints. The risks we chose not to take. The conversations that shaped the outcome.

None of those documents are the work itself. They're evidence that the thinking happened.

They help my leaders understand how I'm spending my time. They help my team understand why decisions were made. And six months later, when everyone has forgotten how obvious the answer felt at the time, they become institutional memory instead of institutional guesswork.

If you're a new manager wondering why you finish the day exhausted but can't point to what you accomplished, you’re not imagining it. But you're probably looking for the wrong kind of evidence.

You're no longer measured only by what you produce. You're measured by the decisions you enable, the clarity you create, the risks you prevent, and the environment you build for other people to succeed.

None of that is automatically visible.

So don't just do the thinking. Leave evidence that the thinking happened.

Before You Can Explain It

When I first became a manager, I thought I knew what performance problems would look like. Clearly they would involve someone yelling in a meeting. Maybe a policy violation. Definitely an obvious technical failure so glaring it couldn’t be ignored. I had a mental catalog of scenarios, and I was confident I’d recognize one when it showed up.

For the most part, that’s just not how it works.

Underperformance rarely arrives as a single event. It usually arrives as a pattern.

Looking back, I don’t think I recognized those patterns by noticing the engineer. I recognized them by noticing how my own behavior shifted.

The first time someone on my team was genuinely struggling, I didn’t have a lightbulb moment where I suddenly knew what was happening. Instead, I found myself asking a quiet question that lingered in the back of my mind.

Is something off here?

In the first moment I consciously had that thought I would have struggled to tell you why. Nothing had exploded. There wasn't a failed release or an angry customer. It was just the growing realization that every project involving this engineer seemed to require a little more attention than the rest.

I was checking in on their projects more often. I hesitated before giving them leadership opportunities that should have been an obvious fit for their level. I found myself mentally building contingency plans before deadlines arrived. Sometimes, without realizing it, I was quietly lowering my expectations just to keep the work moving. None of those decisions felt significant on their own. It was only later that I realized they were all pointing in the same direction.

At the time, I thought I was just being thorough. Looking back, I had already started managing them differently. That's the moment I've learned to pay attention to. Not because it tells me someone is underperforming, but because it tells me I don't yet understand what's happening.

My role in that moment isn't to decide whether they're underperforming. It's to understand why I've started responding differently. That's why I investigate before I coach.

If one person consistently occupies more mental space than everyone else - you’re wondering whether they’ll deliver, building backup plans before you need them, checking in just one more time - that’s worth understanding. Not because they’re guilty of anything, but because you’ve already started adapting around something you haven’t yet explained. If I ignore those signals, I don't avoid the problem. I quietly adapt around it.

Early on I thought performance problems would be obvious. I also assumed someone else would point them out if they weren't. I had already started managing that engineer differently, but because no one else was saying anything, I convinced myself I was imagining it. Waiting for external confirmation didn't make the conversation easier. It just delayed understanding what was actually happening.

Performance dips happen to everyone. We all have projects that go sideways. We all have weeks where we’re distracted or simply not at our best.

Underperformance is the pattern that continues after expectations have been clarified. After coaching has become specific. After someone has had a chance to adjust.

By then, the cost is rarely isolated to one person. Teammates have started compensating. The manager has started checking in more often, making backup plans, and lowering the bar just enough to keep things moving.

The danger isn't that you'll miss the problem. It's that you'll adapt to it.

You stop giving them stretch work. You check in more often. You assign someone else as backup. You quietly redefine what "good enough" looks like for one person.

That's unfair to them because they never get the coaching they need. That's unfair to the rest of the team because you've quietly changed the standard.

That’s why I pay attention when I catch myself managing someone differently. Not because I’ve reached a conclusion - I haven’t yet. But because that’s when there's still time to understand the problem instead of adapting around it.

Pull Requests Are Trust Infrastructure

I’ve lost count of the number of one on ones with direct reports I’ve had where someone complains about another engineer’s pull requests. “Theyre chasing perfection” or “they’re cutting corners” being the two extremes the feedback pendulum swings between. The engineer asking for more tests thinks they’re protecting production. The engineer pushing back thinks they’re protecting delivery speed. Both think they’re defending good engineering.

It’s easier than I’d like it to be to wind up with a team stuck in a pull request standards debate that won’t resolve no matter how explicitly you define the rules. Teams rarely argue this long about standards unless something else is going on underneath.

When technical standards debates get stuck, the problem usually isn’t technical.

If I hear a team is engaging in pull request standards debates, I suspect a lack of trust because pull requests are usually where trust problems surface first.

Why?

Because PR reviews force engineers to answer heavy questions about their teammates like: Do I trust your judgment? Do I trust your testing habits? Do I trust your production instincts? Do I trust your ownership boundaries? Do I trust your definition of “done”?

Those are organizational questions disguised as formatting comments.

Pull requests are one of the places where trust gets tested most visibly. They force teams to make implicit expectations explicit.

Teams with trust merge faster because they debate and rewrite less. Not because they review less carefully, but because they can review more efficiently. They spend their attention on genuinely risky changes instead of re-litigating every convention.

Teams with little or no trust relitigate everything, over-specify standards, and escalate to managers.

I’ve seen this show up as reviewers asking for excessive test coverage from some engineers but not others, or pushing back on PR size from newer teammates but not experienced ones. Even just spending longer reviewing one engineer’s code than another’s. Those aren’t really standards disagreements. They’re signals about where confidence hasn’t caught up yet.

No matter how many review guidelines we wrote down, there was still a disconnect on the team. Our documentation may have changed, but the underlying trust didn’t. I have seen managers help guide teams out of this scenario by calibrating reviewers, reinforcing shared ownership, and building reliability confidence across engineers.

One place I’ve seen this show up repeatedly is when newer engineers join. They should participate fully on the team, and that includes reviewing pull requests. But with a steep learning curve around identity engineering, new reviewers may not yet have calibrated around expectations. In one case we kept review participation broad but preserved a smaller group responsible for final merge confidence until context caught up across the team. Over time the extra layer stopped being necessary because the trust gap closed.

Then standards suddenly became easy again.

I’ve been having more discussions around pull requests lately than I have in a long time largely because of the effect AI has had on them. From AI generated code to increased number of pull requests to AI review - people want to understand what these changes mean for our standards. 

AI is changing how code gets written and reviewed. But it hasn’t changed the underlying reason teams struggle to agree on standards. Organizations regularly add automated reviewers to pull requests because they’re great at enforcing the exact standards engineers used to debate about. Review velocity expectations are shifting.

But the trust layer underneath review standards is actually becoming more important, not less. Teams still need shared trust about what “good enough” means. AI can accelerate code review, but it can’t replace trust.

Before AI, pull request standards debates often looked like disagreements about correctness versus speed versus style. After AI, pull request standards debates should become about what counts as trustworthy engineering work when authorship is changing.

Now teams are still asking the same questions about trust but with a different target. Instead of trusting their teammates they’re asking even bigger questions: 

Do we trust AI-generated code?

Do we trust the engineers on our team to validate AI output? 

Do we trust engineers to know what they didn’t write?

That’s not process friction.

In a code review context, it’s the difference between “I trust this code works” and “I trust the process by which you decided this code works.”

Fix trust first. Standards will follow.

Technical Debt Does’t Stay in the Code

We usually talk about technical debt as something purely technical, something only the engineering department cares about deeply. But the reality is it doesn’t stay there.

It spreads into planning cycles. It changes how teams estimate. It shapes who gets trusted. It alters escalation patterns. Eventually it becomes organizational structure.

Once upon a time, an engineering team owned a shared library that required updates across every consuming service whenever changes were made. Each change to the library required PRs with owning teams, triggered feedback loops across multiple services, and introduced coordination overhead measured in weeks.

Over time the engineers on the team avoided recommending solutions that depended on the library at all.

Eventually the library was converted into a service. The team had to make the case for time on our roadmap, showcasing the data of just how much faster we would ship every subsequent feature if we took the time to make this change.

The scariest part of this story is that before reducing the technical debt the engineers weren’t choosing the best solution. They were choosing the least expensive coordination path. And I couldn’t blame them. As their manager I also wanted to avoid that library.

I hadn’t realized how much technical debt was impacting the team. It wasn’t just an engineering “nice to have.” Technical debt had narrowed the solution space. At some point it had stopped being just technical debt and had become organizational debt — not because it was legacy code that annoyed engineers, but because it changed behavior across teams. Because technical debt had begun silently steering architectural decision-making.

On another team, only a subset of engineers deeply understood the system they were responsible for. This created implicit dependencies: reviews routed through those specific engineers, estimation confidence depended on them, roadmap sequencing depended on their availability, change safety depended on their presence, onboarding slowed, cross-team collaboration narrowed.

When faced with this scenario, resolving it became my top priority. Our velocity was a snail’s pace, but equally important there was no space for a marketplace of ideas. No one knew enough to contradict those with deeper knowledge. As a manager all I could think about was a clock ticking until one of these critical engineers left the team and our ability to ship ground to a halt.

This wasn’t just a knowledge gap. It was an organizational dependency structure created by technical complexity. Technical debt wasn’t just shaping delivery time. It was shaping authority and risk ownership. In critical legacy systems the solution is usually a combination — chip away at technical debt while simultaneously investing in learning for newer engineers, until I no longer heard that ticking clock.

None of these stories looked like technical debt problems at first. They looked like roadmap tradeoffs. They looked like staffing risks. They looked like cautious estimates. It took me time to realize they were all the same story. The library story is about debt shaping what gets built, the knowledge story is about debt shaping who gets trusted.

By the time technical debt reaches that point, it isn’t just slowing teams down. It’s shaping how the organization works.

Technical debt doesn’t just live in the code. It becomes the org chart.​​​​​​​​​​​​​​​

Explaining the Why Reduces Manager Overhead

Moments where leaders don’t take the time to explain the “why” create overhead.

I understood the value of explaining the why early on, but it took me longer to feel what it changed on a team I managed. 

When I think of my teams there’s one scenario that I think highlights the impact of sharing the why, which is urgency without context versus urgency with context. Asking an engineer to do a task urgently can go a lot of different ways. The engineer may re-triage mentally or second-guess the interruption cost to their current work or ask follow-ups or delay slightly. Asking an engineer to do a task urgently hits differently when I explain to them that it’s a security issue. Armed with the “why” they reprioritize immediately, act confidently, and stop needing confirmation from me about what they need to do next. They already know what to do because we’ve pre-aligned on how to handle security issues and as their manager I need to show them I trust that they know how to handle the situation accordingly.

This was the progression that surprised me most. By explaining why, I’m empowering my engineers to make decisions on their own and act in alignment with the goal we’re solving for. Context lets engineers make aligned decisions without waiting for me. If they understand why, they don’t need me in every room and every decision. That’s when context becomes a scalability mechanism. I have more bandwidth to do the work that only I can do. Someone made a decision I hadn’t explicitly authorized — but it was the right one. I was able to set the direction and have engineers execute inside it. That's when I realized context had replaced approval.

Managers often try to solve for alignment with increased structure. They had specific actions they wanted their team to take, and they were doing everything they could to make it as easy as possible for them to just get on board with the plan. I've watched managers build templates, checklists, recurring reminders, and dashboards to encourage behavior they never explained in the first place. They never explained to their direct reports why they wanted the specific actions they had asked for. They had created an entire system to compensate for missing context.

There is a high emotional cost to missing context around the work we do. Without context, changes feel like they’re happening to people. 

Lack of context creates resistance overhead on the team. It can feel like whiplash to have a plan laid out in front of you only to have it swapped out for something else with no idea why that change was made. On a healthy team engineers can and should feel a strong sense of ownership over their team’s roadmap. Making changes without context can be incredibly destabilizing. Engineers without context hesitate, disengage, escalate more, and even question the legitimacy of the changes. Slowing down to explain the why replaces all of that with ownership, and that’s a cultural overhead reduction. 

A lot of times explaining why can feel like overkill. Do the engineers even care? Am I wasting my breath taking the time to go over the same details across all of my direct reports’ one on ones?  But I always come back to the same conclusion: I’d rather give my engineers insight into how I’m thinking about something basically every single time. It lets them know that what’s happening around them isn’t random, that there is a plan and a strategy. It helps them understand the direction we’re driving in the long term. Explaining why makes people feel included in direction, not controlled by it.

Explaining why does not make my decisions as a manager optional. I don’t want it to sound like what I’m suggesting is that if you just explain things more then everyone around you will suddenly agree.

Alignment and consensus are not the same thing.

Sometimes I can’t share the why with total transparency — like team personnel changes or blunt operational truths — but part of management is navigating that storytelling. Giving people enough insight to feel empowered without burdening them with information they don’t need or can’t have is an important skill that takes time to hone as a manager. 

Managers, myself included, often have to explain organizational decisions we don’t necessarily agree with. But that’s not the point. The point is finding integrity and value aligning with that direction. Okay, we’re going this way now — how are we as a team showing up for that? 

One of my former managers who I learned a lot from always had multiple variations of a plan, and was always really open about sharing his vision and what he was building for his teams long-term. It made me feel really good, like I was trusted with that insight and like I was building something with him and my peers beyond the day to day tactical moves. It made the road in front of me feel exciting instead of like a dark path through the woods where I couldn’t see the end. That’s the feeling I want to imbue on the teams I manage. 

Providing teams with context looks like communication work, but it’s really scaling work. When teams understand intent, they stop waiting for instructions. Over time, the role of the manager shifts from answering questions to setting direction.

Explaining the why doesn’t just help your team move faster. It changes the shape of your job.​​​​​​​​​​​​​​​​

Hiring Is the Last Thing I’ll Delegate

Someone asked me once if I wanted to hand off hiring for an open role on my team. It was well-intentioned. I was stretched thin, and handing it to another fully capable manager would have been a reasonable thing to do.

I couldn’t do it.

To understand why, you would have to understand what hiring actually is. It looks like a process: a question set, a scorecard, a debrief. But that isn’t the whole story. It’s a series of judgment calls that only you can make for your team, and you’ll live with them long after the decision is made. The person you hire is still there six months later, a year later, shaping the culture and velocity of your team in ways you can’t fully control after the hiring decision is made. Every other call you make as a manager has a close. This one doesn’t.

There was a time in my past when another manager hired engineers for my team. I was on leave, and they did a genuinely good job. But I came back and inherited the consequences of someone else’s judgment calls. The good ones and the bad ones. When it didn’t work out, I was the one in the room having the hard conversations, doing the coaching, making the calls that follow. It was a lot of trust to place in a peer for something I had to live with long after they moved on to their next focus.

So when the offer came to delegate again, it hit a nerve. Hiring had to stay mine.

Part of that is ownership. But part of it is that judgment in hiring isn’t transferable. It takes years to build, and most of us learn it by doing.

Early in my management career I joined a part of the org that was aggressively hiring. It felt like all I did was interview. I remember watching a senior engineering manager who had clearly done this hundreds of times. He was calm, precise, never rattled. And I just kept thinking: how?

The answer was repetition. There was no shortcut.

What repetition gave me, eventually, was pattern recognition. I can hear now when a story glosses over something. When the logic doesn’t quite hold but the candidate is hoping I won’t press. When someone can’t go as deep as they’re implying they can. Early on I wasn’t hearing those things as easily. I was taking the stories at face value.

It also taught me that while I’m evaluating a candidate, they are absolutely evaluating me. How I run the interview, what I ask, how I react when they tell me something unexpected — all of it is data they’re collecting about what it would actually be like to work here. I’ve been in interviews where the interviewer kept a straight face and flat affect the whole time. I am physically incapable of it. I react to what people tell me. I let the conversation move where it needs to move. I get thanked by candidates for this more often than I expect to. That’s not me going easy on them. I’m just not creating artificial stress that obscures the actual signal. If someone performs badly because they’re terrified, I haven’t learned anything useful and neither have they.

The best hire I ever made reminded me why hiring is so difficult to hand to someone else. I recognized it in the interview. Every question I asked, they answered without assumptions. They clarified before they dove in. They were engineering for the future, not into a corner. That’s what I’m actually looking for. Not a list of traits but a way of thinking. Curiosity that refuses surface-level answers. Grit that shows up not as toughness but as the willingness to say: here’s where I failed, here’s what I’d do differently. Engineering is failing and trying again. Anyone telling me their tests always pass hasn’t worked on anything hard yet.

As my judgment improved, I found myself trusting a simple rule that I’ve kept ever since: if it’s not a hell yeah, it’s a heck no.

I arrived at this after an early debrief where I could tell the team wasn’t excited about a candidate. Nothing disastrously wrong, but nothing clearly right. They were visibly afraid we were going to hire this person just to fill the seat. They weren’t wrong to be afraid. That’s exactly what happens when you let the length of the search decide for you. You’re tired, the role has been open too long, and “good enough” starts to feel like a real option.

It isn’t.

A hiring mistake doesn’t stay contained. It spreads into the team’s velocity, the culture, your own calendar.

But the harder truth about hiring, and the one that took me longer to sit with, is what it feels like when the answer is no.

Sometimes the candidate in front of you is incredibly kind and is clearly trying so hard. They genuinely want the role. And they’re not the right fit for what the team needs right now. That’s devastating. I can accept I’m making the right decision, and it still never feels better no matter how many times I have to do it.

Early in my career, I wasn’t carrying that weight alone. I shadowed that senior engineering manager. We’d talk constructively about how the interviews went. There was a sounding board.

Now I do these interviews alone.

I sit down after the interview and I fill out the scorecard by myself. The weight of the decision is mine to carry.

What I’ve learned is that if it’s in my head, it can be harder to see clearly. So I write. Writing is how I find out what I actually think. I write what they did well and what they didn’t, and then I sit back and read it over. The decision gets clearer on the page than it ever does in my head. There’s something clarifying about having to put it into words.

I’ve been the tired EM. The one whose script is so memorized that my mind starts to drift mid-interview. I know what that feels like.

But I always pull my focus back. I have to. Because the person sitting across from me took time off, prepared, and is trying to show me something true about themselves. My team is counting on me to actually see it. The scorecard is mine to fill out alone. I owe them my full attention — and I owe my team my honest judgment, even when it’s hard to give.

Hiring is one of the highest-leverage things a manager does. The person you bring in changes the team. For a long time.

That’s why, whenever someone offers to take it off my plate, I hesitate.

There are plenty of things I’ll delegate as a manager.

Hiring isn’t one of them.

Translation, Not Transmission

I once knew a manager who told his team when he’d started applying for jobs elsewhere. He was really proud of how transparent he was with the team. What he was actually doing was making this everyone else’s problem. No one on the team knew exactly when he’d be leaving or who would replace him or what it would mean for the team. They only knew they had a manager who was jumping ship. What did it mean for them? No one knew. 

Radical transparency sounds virtuous. In practice it’s often abdication dressed up as honesty.

I often write about managers as translators. The role of a manager isn’t to pass raw information directly from the organization to our teams. That’s what email is for. The role is to filter information, contextualize it, and deliver it in a way that sets people up to do their best work. A pilot hitting turbulence doesn’t walk out of the cockpit to tell passengers whether or not it makes them nervous. They let the passengers know there’s turbulence ahead and roughly what to expect. That’s not withholding information. That’s professionalism. 

But the opposite failure is just as dangerous.

A leader who tells people everything is fine when they can see the water rising hasn’t protected anyone. They’ve just destroyed the one thing that actually keeps a team functional in hard times: trust. False certainty isn’t kindness. It’s a lie with good intentions. People make real decisions based on what managers tell them — whether to stay, whether to push back, whether to panic. I don’t get to decide those stakes are too small to matter.

These aren't opposite ends of the same spectrum. They're two different ways to fail your team. One through too little judgment, one through too little integrity. Being a leader requires both.

There’s information that’s mine to hold, not theirs to carry. Knowing the difference is the job. When I know something I can’t share yet, like a team change, a decision still being finalized, I don’t pretend it isn’t happening. I just ask myself a different question: how do I take care of my team right now, with what I’m able to do? If an engineer is transferring teams and that can’t be announced yet, I can still make sure there’s a transition plan. I can make sure the roadmap reflects the capacity change. I can do my job in ways that absorb the disruption before it hits them.

That’s what translation actually looks like. I take in the noise, I filter it, and what comes out the other side is clarity or at least steadiness. Not false certainty. Not chaos. Just a manager doing the hard, invisible work of holding what needs to be held and sharing what needs to be known.

How I Think About Career Anxiety in the AI Era

The headlines lately are relentless. People are guessing left and right what AI is doing to the tech industry, to society, to the world. Junior engineers questioning what they just got a CS degree for. Senior engineers wondering if the job they fell in love with still exists. People with rent and families and plans, watching an industry reshape itself in real time. A layoff isn’t just a financial event. It’s an identity event. And the fact that it’s virtually unpredictable makes it harder to hold, not easier.

I’m not writing this from a place of having figured it out. Anyone who tells you differently is bluffing their way through this. I have small children and a decade in this career and I read the same articles as everyone else. The articles that say we won’t need engineers, and the ones that say we won’t need managers. 

Someone asked me recently how I approach the anxiety of this particular era. How do I sit with not knowing what’s coming?

I told her I think about two things.

The first is that history repeats itself, and not always in the ways we fear. When ATMs were introduced, people predicted they’d replace bank tellers entirely. The opposite happened. The number of tellers actually increased. The cost of running a branch decreased so banks opened more locations. Tellers’ role shifted. The technology changed the shape of the job, not whether or not it existed.

Maybe that’s what this moment is for engineering: not destruction, but a transformation. A shift in what engineering looks like, instead of an elimination of the people who do it. I don’t know that for certain. But history gives me enough ground to stand on that I can stop catastrophizing long enough to breathe.

Which brings me to the second thing: I have no control over this.

That may sound bleak. I mean it as an act of radical acceptance.

When I really sit with the fact that I cannot predict what happens next — not to the industry, not to my company, not to my role — the vice-like feeling in my chest loosens. The anxiety doesn’t disappear but it changes shape. It stops feeling like a problem I need to solve and starts feeling like weather I need to dress for.

So I try to prepare for multiple possible futures. I try to leave doors open. I don’t need to walk through them necessarily, but I can keep them unlocked. For me, options change how uncertainty feels. And then I try, as much as I can, to just go along for the ride.

It’s a roller coaster a lot of the time, but the history piece is what reminds me the track doesn’t end in a cliff. It just goes somewhere I haven’t been yet.

I can’t promise certainty, and I won’t. But I can say this: hope isn’t a plan. It isn’t nothing either. Hope is what keeps you moving when the ground won’t stop shifting.

1:1 vs 1:N Impact

I became a manager of my first engineering team. I got pulled into team ceremonies and alignment meetings and lots of one on ones. Before I knew it the calendar was full. I was being so productive. I was helping so many people.

New managers default to 1:1 work because it feels like so many of the things we want it to feel like: concrete, responsive, visible, fair, and controllable. 1:N work on the other hand feels abstract, slower, riskier, and sometimes invisible. The work that helps one person immediately often feels more real than the work that helps ten people eventually.

So people over-optimize for the wrong layer of impact without realizing it.

I used to talk a lot, when folks asked me about why I wanted to be a manager, about wanting to exponentially increase my impact. That I would scale my impact on the org through those who reported to me by helping them be better more effective versions of themselves. To some degree I did accomplish this, but mainly by leveling up my engineers as individuals.

When I first took on managing two teams, I didn't scale myself. I was treating having two teams like I had the same attention and bandwidth as back when I had one. The same attendance at meetings, the same cadence of one on ones with direct reports. Nothing had changed except my bandwidth was at an all time low.

That’s the moment I knew this didn’t work.

Not because something broke. Because nothing broke, and that was the warning sign.

Many managers assume scaling only starts when things go wrong. But often the real signal is: everything is working and I still have no time left.

I was running a marathon like it was a sprint.

I went into management wanting to make a 1:N impact but had never actually made the shift.

My calendar made that gap visible. Anyone who looked at my calendar could see how I was operating (or wasn’t). The calendar told the truth about my leadership scope. 

No one had ever told me when that transition would be required. I realized the skills that helped me succeed before weren’t the ones I needed next. Being great at supporting individuals is not the same as being effective at leading organizations. I had to stumble into the problem to realize I needed to claw my way back out, one updated meeting invite at a time. 

When I finally started scaling differently, my calendar changed. My one on ones got shorter and less frequent. I stopped being the person who solved problems and started being the person who set the conditions for others to solve them. I didn’t have to be in every room or every meeting to know that the strategy I planned was being executed properly. I needed to build a structure and a team to support that. This was the first time I understood that scaling my impact didn’t mean working more. It meant changing what kind of work I was doing.

When I wanted to become a manager I dreamed of how much greater my impact would be if I expanded the potential of all the people who reported to me. Then I started dreaming even bigger. I was planning in terms of systems and repeatable frameworks. That’s when I stopped measuring my effectiveness by how many people I was helping directly and started measuring how well I was truly scaling my impact. 

Managers are not evaluated on how helpful they are individually. They’re evaluated on what becomes possible because they exist.

When Output Stops Being a Signal

It used to be easier to tell who the strongest engineers were on a team, often just based on output. They were the ones shipping the most, moving the fastest, and getting the most done.

AI is making that harder to do. It made it easier for everyone to produce output, even non-engineers, which means output got a lot noisier as a signal.

To be clear, I don’t think output is or has ever been our best signal. I’ve never loved using Jira metrics as a proxy for performance. I’ve always cared more about whether we shipped what we intended, when we intended to.

But AI makes it harder to ignore.

On one of my teams, an engineer systematically cleared a backlog of low-level tech debt in a single sprint. That was real, valuable work. But when I looked at the metrics alongside an engineer who spent the same sprint on one high-impact change, the numbers showed a major disparity even though the impact to the team was huge in both cases. Output has never been a great signal. AI just made that harder to pretend otherwise.

Some of the most impactful engineers I work with don’t have the highest Jira velocity. They spend time building internal tools, reviewing others’ work, and keeping the team aligned to the technical direction. Their impact shows up in everyone else’s output, not just their own. If I only looked at tickets closed, I’d have undervalued them, which means I’d be optimizing for the wrong things.

It has also become increasingly possible to have two engineers shipping similar amounts of work and operating at completely different levels. One who uses AI to move faster but validates decisions and simplifies the design. The work holds up. The other who uses AI to generate most of the implementation. It passes tests, gets approved, and ships. A few weeks later, it’s the source of follow-up work, edge cases, and confusion. On paper, they look equally productive.

I think a lot of people are focused on “AI slop” and the obviously bad work being passed off as good. I’d argue that while that is a real concern, the bigger risk isn’t even the obviously bad code. It’s the work that looks reasonable - solid PRs, passing tests, sensible structure - but work that’s built on shallow understanding.

It’s easier to skip the deep digging that used to build real intuition, and that gap shows up later in edge cases and design decisions. You can get to something that works without fully internalizing why it works.

I’ve even felt this myself. Early in my own AI usage, I once relayed an inflated estimate to product leadership based on that kind of exploration, only to realize later that most of it wasn’t relevant. It felt so convincing in the moment. 

We’re all learning how to use AI. Mistakes are bound to happen. I use these tools too, but as a manager, I’m often in situations where I have to rely not only on my own ability to use them but on my direct reports’. I’m one degree removed, which puts a lot of trust in a skill we’re all still figuring out.

For a long time, output was an easy “out”. A rough proxy for capability. It was never perfect, but you could argue it sort of worked.

It works even less reliably now.

We need to avoid hyper-focusing on output and spend more time evaluating the things that are harder to measure: how engineers make decisions, whether they can explain why something is the right approach, whether they improve the system around them, not just their own output.

None of this is about AI being good or bad.

It’s about what it changed. Output is easier to produce, which means it’s less useful as a signal.

The difference between engineers hasn’t gone away. It’s just harder to see at first and more expensive to ignore later.

That means more direct conversation about decisions, more investment in code review as a teaching tool, and more weight given to the engineers whose impact multiplies others rather than just their own.

When output stops being a signal, judgment is what we need to pay closer attention to.

Thought Leadership Is Just Solving Problems Out Loud

I’ve had more than one conversation with engineers considering management where this idea comes up — the idea that thought leadership requires some sort of profound revelation, or some kind of anointing process before you’re allowed to participate. Thought leadership is an aspect of management that becomes more expected the higher you go, and is often explicitly called out in leadership role descriptions. Feeling like you couldn’t possibly be a thought leader can make the expectation itself feel like a barrier to entry.

But here’s the most delightful secret: we’re all just figuring this out as we go along.

So if no one innately knows all of the answers, maybe thought leadership isn’t claiming to have the answers. Maybe it’s really just finding a problem you’re excited to solve and solving it while keeping others in the loop who might benefit from seeing how you approach it.

New managers often resist visibility. Hell, I often resist visibility. Even the engineers I manage resist visibility. Just watch how fast they avoid eye contact when I ask them to write an internal blog post or share a demo outside of our team.

People sometimes say engineers avoid visibility because they believe their work should speak for itself. I don’t think that’s quite right. I think we’re just used to solving problems in code. Once the solution works, it’s available to everyone. Anyone can read it.

As a manager, solutions don’t work that way. Some of the work is still code, but a lot of it isn’t. Adjusting to a leadership role meant I had to get comfortable being uncomfortable and share my solutions — my ideas — on a wider platform. It’s a lot like opening a pull request, just with a much larger audience. Both require you to be in the position of saying, “I may not have the perfect answer, but here’s my best shot. Let me know how we can iterate toward something even better.”

The first thing I did that got any real attention as a manager was an internal blog post about driving your own career: career development, conversations with your manager, and promotions. It was a topic I felt really strongly about because people were so often confused or blindsided by the process. Why not try to pull back the curtain a bit? A lot of people ended up reading it and sharing it and referring to it years after I hit publish. It was a real problem I was trying to solve. I didn’t think of it as thought leadership. I thought of it as documentation for a system people were struggling to navigate.

Publishing something that wasn’t code felt strangely vulnerable at first. Code review was familiar. Sharing my thinking about promotions and career development felt much more personal because there wasn’t a compiler to tell me whether I was right.

But what surprised me was the response. Not because I had perfect answers, but because someone finally said out loud what they were confused about too.

I’ve watched incredibly talented engineers and managers struggle because nobody outside their immediate team understood how they thought or what they were solving. Visibility isn’t just about recognition. It’s how organizations learn where trust and leverage already exist.

Visibility isn’t about positioning yourself as an expert. It’s about making your thinking accessible to the people around you. When people can see how you approach problems, they can learn from it, challenge it, and build on it. That’s where influence actually starts.

Most thought leadership doesn’t start with authority. It starts with friction.

As engineers, we’re so good at finding and solving problems. The next evolution of that is finding and solving problems that matter to other people. And not even necessarily solving them. Take your best shot, share your best guess. Thought leadership doesn’t start when you have answers. It starts when you decide a problem is worth solving out loud.

Make the Damn Time

Early on I thought strategy was something that would happen once things calmed down. Things never calm down.

For something that is so clearly important to the role of leadership, it’s kind of amazing how little time a lot of managers dedicate to it in our day to day work. 

I made some pretty classic mistakes when considering strategy. At first I thought it was just something that happened around the other work as a sort of natural side effect of everything else I was doing. That couldn’t have been further from the truth. My early management was defined by reactive, day to day problem solving. It was super grounded in tactical thinking. I figured that because I was being intentional and thoughtful I was operating at a higher level. I would’ve said I was being strategic or thinking strategically and I’d have been wrong.

Management is a much lower stakes game of Emergency Room where new problems are constantly rolling through the double doors and it’s your responsibility to triage those issues. Not solve every single one at the same time, but prioritize and mitigate fallout. 

If I wasn’t actively making time for strategic thinking, there was always other work that would take its place. 

If I was not prioritizing strategic work I will never “just have the time.” 

I began to think of strategic thinking as a defended resource. Not something that happens when the calendar clears, but something that only exists if you protect space for it.

Strategic work is what gets you out of firefighting mode and back to shaping how your team actually operates inside the organization. Because I don’t think anyone really dreams of becoming a manager to fix a team’s broken ticket refinement ceremony for the fifth time in your career. You become a manager to impact a piece of an organization. And that requires strategy. 

So make the damn time!

The question isn’t whether strategy matters. It’s how you make time for it when your calendar already feels full. How do managers actually create space to lead instead of react? 

It’s a loop that reinforces itself. You can’t think strategically because you don’t have time, and you don’t have time because you’re not thinking strategically. At some point something has to give so you can put time on the calendar. Actually blocking it off. 

I started small in my quest to make time for strategy. I found already open blocks on my calendar and reserved them for myself. It wasn’t long before I needed more. I was hooked. It was time to seriously reassess what I had committed to in terms of my time. Were my one on one meetings too frequent? Was I attending recurring meetings that had outgrown their value? I adjusted as needed. Then ruthlessly blocked my time. 

As of this post I have three main blocks on my own calendar that I defend ruthlessly. I have an operational alignment block where I make sure my week is set up to achieve my highest priority goals. I have a deep work block for the to do items that need more than ten minutes between meetings to accomplish. And I have a strategic block. Maybe for others this is a walk outside or a block of time with just your thoughts and a notepad. Because I don’t do well with wide open blocks of time and no clear call to action I have a strategic thinking template I use. It’s a great launching off point each week to get me focused on what’s potentially working or not working about how my teams operate or what the org is prioritizing. From there I can choose my own adventure about which problems to solve but that initial template is what I need to get in the zone. 

Strategic thinking isn’t something managers earn time for later. It’s something to defend now so later gets easier. Strategy didn’t start happening when I became a more senior manager.

It started happening when I started protecting time for it like it was part of the job because it is.

No One Trains You To Be a Manager

One of the stranger surprises about becoming a manager is how little structured support there can be once you get there. Maybe if you were lucky, as an engineer you had a manager who offered some coaching when you told them you wanted to become a manager. But it’s not like engineering where you took classes or honed your skills over years of practice before someone paid you to do it. You never took a class on how to manage people. There’s no real training to prepare you for how to be a manager. 

A totally normal conclusion to draw is: well my manager will teach me how to manage. By the time I actually became a manager, my boss couldn’t be my mentor. They could be my professional coach just like any manager should be, but their time is limited and their motivation in my development had to fit business needs as well as my personal goals. The conversations I could have with the person rating my performance could never be completely unfiltered. Plus once I became a manager I was expected to be a manager - not a manager in training. The expectation was that I was already performing at that level not below it. 

I had to learn on the job and I had to learn quickly because management comes with increased scope and impact. Getting it wrong now would happen on a much bigger platform.

I turned to books for a lot of early management guidance. If someone else has already learned these lessons, why not learn from them faster? There were some leadership style workshops a couple of employers offered. But that was really it. And a lot of those books and workshops were truly helpful. But what I wanted and often needed was less playbooks and more guidance for the specific situations I found myself in or the dynamics unique to my organization.

As an engineer, most people enter the workforce with a certain baseline of engineering knowledge but over the course of your career you learn predominantly from peers. You learn by reviewing code together, watching others solve problems. Once you transition to management, you go from being on a team and learning on the job but with lots of support and oversight from your peers to a much more solo experience. Managers typically have fewer peers, fewer shared problems, and fewer safe practice spaces. That doesn’t mean management is unsupported work. It does mean the support structures change, and most of them become ones you have to build intentionally instead of inheriting automatically.

As a solution to this exact scenario, one recommendation I encountered was leaning into your “first team” of managers or those few who report to the same leader you do. I used to love that advice. As a newer manager it felt extremely comforting to think I could recreate some of the team dynamic I had been missing when I first transitioned into leadership. Having the recommendation point to an easily identifiable group was a bonus. 

Sometimes though this isn’t the built in solution we need. Maybe you can’t go to the managers closest to you hierarchically. Are they people you feel safe being vulnerable with? Are you all vying for the same opportunities? Do they want to be on a first team with you?

Those first team manager relationships do matter. They’re essential partners in the work. But they aren’t always the people you turn to first when you’re trying to figure out how to grow as a manager.

The managers I’ve learned the most from over time haven’t always been the ones closest to me in the org chart. They’ve been the ones willing to share their experiences openly or compare notes. Sometimes they help me — advice, perspective, support when something doesn’t go the way I expected. Other times I’m able to help them in return. They’re the people I reach out to first when I’m trying to make sense of something new.

Not only did I discover there was limited structured learning once I became a manager, but the difference in isolation was a serious adjustment. The higher you go the more that isolation is a factor. I couldn’t turn to the team I was managing and tell them what a hard day I just had with performance conversations, or a difficult chat with the VP. Having a network of other managers I could turn to combat that feeling in a way that made the job feel more sustainable - and usually even more fun. 

You don’t get to choose who your peer managers are. 

But you can choose who you learn from.

You can choose who you watch closely. Who you ask questions of. Who you reach out to after a difficult conversation. Who you pattern yourself after when you’re not sure what the right move is.

Early in management especially, that network matters more than people admit. 

One of my favorite mentees who became a manager last year told me recently that he’s finally starting to reach out to other managers outside his immediate peer group. He said it’s made a huge difference in how he approaches the role. He sounds less like someone trying to survive day to day inside one small space and more like someone operating as part of the organization’s leadership team.

That shift is subtle, but it matters. Those relationships don’t just provide advice and support. They change how you understand the organization itself and where your work fits inside it.

Building that network is one of the first real leadership skills most managers develop, whether anyone tells them that’s what they’re doing or not.

Friendly, Not Friends

One of the earliest pieces of management advice I got was simple: be friendly, not friends. It sounds obvious. But it takes time to understand what it really means.

Friendly means approachable, respectful, and invested in someone’s growth. Friends implies shared loyalty and shared decision-making power. Managers can offer the first. They can’t offer the second.

Most of us spend our entire lives learning how to belong to groups. We learn how to get along with classmates, teammates, coworkers. We learn how to read a room. We learn how to be someone other people want to work with.

And then one day you become a manager.

The dynamic changes whether you want it to or not.

Friendship assumes mutual support, vulnerability, openness, and shared motivation. Management changes the conditions those things depend on.

I was fortunate that my first management role was with a team who only knew me as their manager. I’ve seen engineers struggle much more when they transition into managing former peers. But this trap isn’t limited to that situation. It shows up any time a manager focuses too much on being liked instead of being clear about their role.

Most of us are wired to want to belong to the group we’re working with. Especially at work. It’s where we spend most of our time. Learning how to get along with coworkers isn’t optional. It’s a survival skill.

That’s part of why this shift feels so uncomfortable when you become a manager. You don’t suddenly stop liking the people around you. But the role requires a different kind of relationship with them. The minute you become a manager there needs to be a boundary there. The dynamic has shifted whether you intended it to or not, and pretending it hasn’t usually makes things harder for everyone involved.

Managers are often privy to information the team cannot or should not be aware of. My friends don’t keep secrets from me. My best managers knew when to let me know something and when to be a shield.

You also don’t have the same motivations. Yes, you can want the best for someone as a person. But your performance depends on their performance.

It’s similar to another boundary new managers sometimes struggle with: you’re not their therapist. People bring real life with them to work and those things matter. But your role isn’t to solve them. Your role is to support them as professionals inside the environment you’re responsible for shaping.

I was recently talking with another manager who was new to the role and struggling to get their team to not only buy into their plans, but to act on them. As we talked through the situation, it became clear they were still proposing their ideas like they were optional, like they required group consensus to become real. It made complete sense why they were operating that way. Most of us spent years learning to work that way as peers. And when the boundary between peer and manager still feels blurry, it’s easy to keep acting like one of the group instead of the person responsible for the decision. But management changes what your role in those conversations is. Sometimes your job is to invite input. Sometimes your job is to make the decision. And sometimes the plan is simply the plan.

Friendship also assumes equality. But once someone reports to you, the power dynamic changes whether either of you acknowledges it or not. They can’t disagree with you the same way. They can’t be fully candid the same way. They can’t give you the kind of unfiltered feedback real friends give each other. It stops being an even relationship. The relationship stops being equal the moment you become their manager, even if nothing else changes.

Early in my management career I let this boundary blur once. It didn’t create a crisis, but it changed the shape of the relationship in ways that made it harder to do the job well. Our 1:1s became less focused. Expectations were harder to reset. It became harder for me to show up clearly in the role I was supposed to be playing. That experience changed how seriously I take this advice now.

Sometimes when the boundary shifts too far, the relationship starts to carry expectations it can’t support. Conversations drift away from the work. The manager becomes a confidant in ways that make it harder to do the job clearly.

This relationship shift can feel uncomfortable but it’s necessary for clarity and fairness.

It’s hard. I have and do manage some awesome people and maybe in an alternate timeline we’d be friends but that’s not the one we’re living in.

Managers can be warm. Managers can be kind. Managers can be trusted. Managers cannot be peers to the people they manage.

Managing Engineers Through the Age of AI

I want to write about AI. Transitions like this don’t just change what we build. They change how engineers experience the work itself. I don’t worry about what AI is doing to our delivery timelines. I do worry about what it’s doing to our engineers. Even more specifically, what it’s doing to our most senior engineers. 

From what I’ve seen so far, lower to mid level engineers seem more open to adopting AI in their day to day workflows. As junior engineers, they’re still forming their engineering identities. They’re flexible. As senior engineers, they’re pragmatic and outcome-focused which aligns nicely with using AI to achieve greater outcomes. 

I’ve seen something different with staff engineers. The engineers most unsettled by AI aren’t the least capable. They are often the ones who have spent the longest learning how to be excellent. As staff engineers, identity tends to be anchored in how systems get built. Staff engineers often optimize around architecture clarity, technical taste, solution-path efficiency, and authorship depth. AI shifts the value surface away from those signals. A lot of staff engineers are initially reluctant because we trained them for years if not decades to find the most efficient path to a solution. Then we introduced AI as a new tool. Like any other new tool, there’s friction to learning to use it. 

We’ve seen transitions like this before. When search engines like Google first became widely available, people weren’t immediately sure how to use them well, and some environments even discouraged relying on them. Today it would be unthinkable to say you weren’t using search as part of your workflow. AI tools are starting to follow a similar pattern.

When that friction shows up, staff engineers often want to just write the code themselves because historically that was the most efficient solution. But as managers, we need them to get through the friction of adopting AI because the other side is actually faster. That’s destabilizing in a very specific way.

For these engineers, the hardest adjustment isn’t technical. It’s emotional. They didn’t fall in love with reviewing generated code. They fell in love with writing it. There’s a real, often unspoken, grief there because the way they’ve excelled at working is no longer what’s being asked of them. Part of the loss is stylistic too. What happens if the thing you fell in love with was writing code itself? Making dumb variable names. Refactoring. Trying to get code to compile. The dopamine hit when it finally does. When the test passes. When the div is centered on the page. Some of that is starting to go away now. So when we see that not all engineers are racing to adopt AI, maybe some of those engineers aren’t resisting AI. They’re adjusting to the realization that the work they spent years learning to do well is no longer the work being asked of them. 

That’s not resistance. That’s coherence.

It’s also organizational whiplash. And managers are the translators of that whiplash.

The hardest part of managing engineers through AI isn’t choosing tools. It’s helping people navigate the moment when the way they learned to be excellent stops being the way they’re asked to work. My job isn’t to convince engineers AI is good. My job is to help them move through the transition without losing their sense of competence along the way. And once they get through that transition, I’ve seen those same engineers become some of the strongest adopters. When they start using AI at the level of systems and architecture instead of just code generation, the hesitation usually disappears.

Transitions like this don’t just change workflows. They change how engineers measure themselves. Managers have a responsibility to recognize that shift, name it when it’s happening, and help people move through it without treating hesitation like failure. The engineers who learn to work this way won’t be the ones who abandon craft. They’ll be the ones who redefine it.

Promotions Aren’t a Scorecard

I’ve spent years thinking about promotions from both sides, working toward them myself and later supporting engineers through them as a manager. One thing that’s always surprised me is how little most people understand about how promotion decisions actually get made.

Don’t let anyone sell you the lie that titles don’t matter. Promotions matter. They affect compensation, responsibility, recognition, and sometimes access to rooms whose doors were previously closed to you. And yet most of us don’t understand how they work—not just inside our own companies, but as organizational decisions at all.

Promotions aren’t scorecards. They’re system decisions shaped by impact, business need, and available budget.

Impact is the piece you have the most control over. It’s also the piece most people are familiar with, though often not in the way organizations actually evaluate it. Impact is not simply the work you get done. Your work will not speak for itself. Instead, your work needs to make an impact - on people, on systems, on outcomes. If your work leaves no impression behind, it effectively didn’t happen. And that’s where I’ve seen a lot of talented people spin their wheels. People who are constantly busy or working so hard and don’t understand why it’s not enough. Maybe it is enough effort but misplaced. Your work needs to meaningfully connect to your career ladder. What is your org looking for in terms of impact? Are you delivering 1:1 results when your org is expecting you to scale your impact 1:N? 

Impact alone isn’t enough. Promotions only happen when the organization needs more people operating at the next level. Sometimes this is obvious. New scope appears, teams grow, or priorities shift. Sometimes it’s less visible. An organization may already have enough people operating at a given level for the work it needs to do right now. This can be one of the hardest parts of promotions to accept because it’s the least personal. You can be ready and still need to wait for alignment between your growth and the organization’s direction.

Budget is the third factor. Promotions change compensation, and compensation lives inside planning cycles whether we like it or not. That doesn’t mean promotions are arbitrary. But it does mean timing isn’t always fully flexible. Sometimes strong promotion cases wait for the next cycle simply because organizations make compensation decisions in batches rather than one at a time. I learned this lesson myself when I was working toward a Lead Engineer promotion. I had the impact and the support, but what I didn’t understand at the time was the role the budget played. Others were ahead of me in the promotion queue that cycle. So I kept expanding my scope and visibility. By the time I came up again for the next round, I had support from multiple senior engineers, architects, and even a VP from another pillar asking the same question: how is Liz not already recognized at this level?

This lack of understanding doesn’t just affect individuals. It also affects managers supporting someone through the promotion process. ​​Many managers are unprepared for how little control they actually have over the final promotion outcome. As a manager, you’re not responsible for driving someone else’s career. Managers create the conditions that make growth possible.

From the manager's side, promotion advocacy depends heavily on credibility. Over time, it becomes harder for a manager’s promotion recommendations to carry weight if they repeatedly put forward cases that aren’t aligned with organizational expectations.

If you only control one third of what makes a promotion possible, it’s dangerous to tie your professional identity entirely to achieving one. That can be infuriating and demoralizing. So you focus on what you can control. You can control opportunities, alignment with expectations, visibility of your work, and readiness for the next level. If you feel like you’re sprinting toward promotion and things will slow down afterward, think again. That pace becomes the new baseline.

Promotions aren’t scorecards. They’re decisions shaped by impact, business need, and budget. You control only one of those directly. So focus there.