Why Be a Manager

A friend asked recently why I got into engineering management & if I regretted that choice like so many other people he knew have. I had to reflect on this a lot & want to share my experience in the chance that it helps others make their decisions.

First, the basics: EM usually means writing little to no code, though this varies. I've seen some organizations push for a more hands-on "player/coach" model where you're still managing people while contributing technically. This seems to be becoming more common as companies look to reduce headcount costs, so it's worth keeping in mind. "Team Lead" is much more hands on, sometimes doesn't involve people management, & orgs almost always have one or the other.

What drew me to the role was actually frustration with how software teams relate to their processes. So often it feels like processes are imposed from the outside rather than deliberately chosen. I kept wondering: why these processes? Has anyone actually analyzed whether requiring approvals on all PRs is worth the cost? As I dug into these questions, I became fascinated with how teams can build software more effectively & efficiently, & I developed some ideas I wanted to test.

I'd ask my managers "why did you make this decision?" not to second guess them, just out of genuine curiosity. The problem was I kept getting unsatisfying answers, which pushed me further toward wanting to be in a position where I could actually experiment with these questions. Part of what I hadn't articulated to myself at the time was how much engineering culture often rewards code over software. Code is visible; it's easy to tie to output. But shipping actual software, the thing users interact with, is almost everything except writing code. It's defining strategy, taming ambiguity, sequencing work, negotiating deadlines, & aligning people who all see the problem differently.

And here's the thing: engineers are often capable of owning much more of this than we give them credit for. They can write product specs. They can talk to users. They can make design decisions. They can sequence their own work. But traditional processes box people into smaller roles to minimize risk, & in doing so, we lose the innovation that comes from engineers deeply understanding the problem space. Someone has to hold that wide view—the part that doesn't fit into Jira tickets or GitHub diffs—& I believe that should often be the engineers themselves, with managers creating the environment where that's possible.

One thing that surprised me was realizing that leading the team is really only half the job. You also become that team's representative in the organization, & your team's success depends heavily on your ability to navigate the political environment. It's political in the neutral sense: navigating incentives, expectations, & constraints. & your team feels the consequences of how well (or poorly) you operate in that environment. It's a dimension of the work I hadn't fully appreciated before stepping into the role, & it takes up way more time than I expected. This is also one of the weightier aspects of the role: you're responsible not just for your own work, but for creating the conditions where others can succeed. That responsibility sits differently than individual contribution.

What Kind of Manager I Want to Be

Over time, I've developed some strong opinions about what effective engineering management actually looks like. Not everyone will agree with this approach, & that's fine—there are many valid ways to lead teams. But this is the model I'm working toward.

The core principle: my job isn't to make product or technical decisions. It's to build a team capable of making excellent decisions without me. This is harder than it sounds. It means resisting the urge to jump in with "here's what we should do" & instead asking questions, providing context, & coaching people to see around corners themselves. It means giving feedback on specs & proposals not to drive toward my answer, but to help engineers identify where to cut scope, improve quality, or consider edge cases. The goal is that engineers are driving, & they come to me when they need help, not permission.

This approach only works if you're optimizing for engineers who thrive with autonomy & ownership. I'm not interested in building teams that need heavy process & guardrails to function. I want to work with people who, given a loosely defined problem & the right support, can drive it to completion. That doesn't mean everyone needs to be senior—far from it—but it does mean filtering for people who want that level of ownership & then growing them into it.

A huge part of making this work is building systems & leverage. If I notice a pattern—say, engineers struggling with a particular type of technical decision—I don't just coach individuals. I think about what system, tool, or process would make that easier for everyone. Maybe it's better documentation. Maybe it's automation. Maybe it's clearer decision-making frameworks. The best solutions often involve actually building something: scripts, tooling, abstractions that make the right thing easy. This is where the systems thinking really comes in—you're constantly asking "how do I 10x the team's effectiveness?" rather than "how do I do more myself?"

Creating focus time is another critical piece. Engineers do their best work when they have long stretches of uninterrupted time to think deeply about problems. My job is to protect that. That means being thoughtful about meetings, communication patterns, & how we coordinate work. It means taking on the interrupt-driven work myself—the urgent questions, the cross-team coordination, the organizational navigation—so the team can focus. If engineers are spending most of their week in meetings or context-switching between tasks, something has gone wrong. The goal is that they can spend the vast majority of their time in flow, building.

All of this requires holding the team to a high standard & not shying away from getting into the details. Even with the best people, there's always room for growth. My job is to help them see it, clearly & kindly, so they can keep getting better.

Beyond the systems & strategy, the other aspect I find deeply rewarding is the coaching & mentoring. I have a strong sense of fairness, & it bothers me when people who deliver real value aren't recognized or rewarded accordingly. Being an EM gives you the opportunity to advocate for your people, help them grow, & ensure their contributions are visible. There's something satisfying about clearing obstacles so talented people can do their best work & advance in their careers.

My approach to coaching centers on radical transparency. If someone is doing great work, they should understand why—what specific behaviors or outcomes made the difference, how it connected to team goals, what that suggests about their growth trajectory. If someone is falling short, they should know exactly what that means & what success looks like—not vague feedback about "communication skills," but concrete examples of what good looks like & how to get there. Growth shouldn't be a guessing game. Being clear about expectations, feedback, & recognition is the most respectful, fair thing you can do. It means difficult conversations sometimes, but it also means people know where they stand & how to move forward. & seeing people rise because of that clarity, watching them take on challenges they didn't think they were ready for, is one of the most gratifying parts of the job.

So How's it going?

Do I regret making this choice? No. I find this kind of work more rewarding personally than IC work. But I want to be absolutely clear: it's not a harder job than being an IC, & it's not in any way better. They're different kinds of work that suit different people. Some of the best engineers I know would be miserable doing what I do, & that's completely fine. Management is simply the work that fits my particular mix of interests & skills.

On the practical side: EM compensation typically sits around Staff Engineer level, maybe slightly lower depending on the company. Some people are also drawn to management for the decision making power & yes, having influence over promotions & performance does make people listen to you differently. But in a healthy organization, that power is checked, & Staff Engineers should actually have more technical decision making authority than an EM anyway.

I didn't choose management because it's a higher calling or a better path. It's simply a type of work I'm good at & find rewarding. It scratches different itches: the systems thinking, the people development, the behind the scenes work that makes other people successful. If this post has a thesis, it might be that management is work centered around clarity, fairness, representation, & helping people do the best work of their careers. For me, that's been worth the trade off.