As I get older, I increasingly think about whether I’m spending my time the right way to advance my career and my life. This is also a question that your company asks about you every performance…
As I get older, I increasingly think about whether I’m spending my time the right way to advance my career and my life. This is also a question that your company asks about you every performance cycle: is this engineering manager spending their time effectively to advance the company or their organization?
Confusingly, in my experience, answering these nominally similar questions has surprisingly little in common. This piece spends some time exploring both questions in the particularly odd moment we live in today, where managers are being told they’ve spent the last decade doing the wrong things, and need to engage with a new model of engineering management in order to be valued by the latest iteration of the industry.
If you’d be more interested in a video version of this, here is the recording of a practice run I gave for a talk centered on these same ideas (slides from talk).
Good leadership is a fad
When I started my software career at Yahoo in the late 2000s, I had two 1:1s with my manager over the course of two years. The first one came a few months after I started, and he mostly asked me about a colleague’s work quality. The second came when I gave notice that I was leaving to join Digg. A modern evaluation of this manager would be scathing, but his management style closely resembled that of the team leader in The Soul of A New Machine: identifying an important opportunity for the team, and navigating the broader organization that might impede progress towards that goal. He was, in the context we were working in, an effective manager.
Compare that leadership style to the expectations of the 2010s, where attracting, retaining, and motivating engineers was emphasized as the most important leadership criteria in many organizations. This made sense in the era of hypergrowth, where budgets were uncapped and many companies viewed hiring strong engineers as their constraint on growth. This was an era where managers were explicitly told to stop writing software as the first step of their transition into management, and it was good advice! Looking back we can argue it was bad guidance by today’s standards, but it aligned the managers with the leadership expectations of the moment.
Then think about our current era, that started in late 2022, where higher interest rates killed zero-interest-rate-policy (ZIRP) and productized large language models are positioned as killing deep Engineering organizations. We’ve flattened Engineering organizations where many roles that previously focused on coordination are now expected to be hands-on keyboard, working deep in the details. Once again, the best managers of the prior era–who did exactly what the industry asked them to do–are now reframed as bureaucrats rather than integral leaders.
In each of these transitions, the business environment shifted, leading to a new formulation of ideal leadership. That makes a lot of sense: of course we want leaders to fit the necessary patterns of today. Where things get weird is that in each case a morality tale was subsequently superimposed on top of the transition:
- In the 2010s, the morality tale was that it was all about empowering engineers as a fundamental good. Sure, I can get excited for that, but I don’t really believe that narrative: it happened because hiring was competitive.
- In the 2020s, the morality tale is that bureaucratic middle management have made organizations stale and inefficient. The lack of experts has crippled organizational efficiency. Once again, I can get behind that–there’s truth here–but the much larger drivers aren’t about morality, it’s about ZIRP-ending and optimism about productivity gains from AI tooling.
The conclusion here is clear: the industry will want different things from you as it evolves, and it will tell you that each of those shifts is because of some complex moral change, but it’s pretty much always about business realities changing. If you take any current morality tale as true, then you’re setting yourself up to be severely out of position when the industry shifts again in a few years, because “good leadership” is just a fad.
Self-development across leadership fads
If you accept the argument that the specifically desired leadership skills of today are the result of fads that frequently shift, then it leads to an important followup question: what are the right skills to develop in to be effective today and to be impactful across fads?
Having been and worked with engineering managers for some time, I think there are eight foundational engineering management skills, which I want to personally group into two clusters: core skills that are essential to operate in all roles (including entry-level management roles), and growth skills whose presence–or absence–determines how far you can go in your career.
The core skills are:
Execution: lead team to deliver expected tangible and intangible work. Fundamentally, management is about getting things done, and you’ll neither get an opportunity to begin managing, nor stay long as a manager, if your teams don’t execute.
Examples: ship projects, manage on-call rotation, sprint planning, manage incidents
Team: shape the team and the environment such that they succeed. This is not working for the team, nor is it working for your leadership, it is finding the balance between the two that works for both.
Examples: hiring, coaching, performance management, advocate with your management
Ownership: navigate reality to make consistent progress, even when reality is difficult Finding a way to get things done, rather than finding a way that it not getting done is someone else’s fault.
Examples: doing hard things, showing up when it’s uncomfortable, being accountable despite systemic issues
Alignment: build shared understanding across leadership, stakeholders, your team, and the problem space. Finding a realistic plan that meets the moment, without surprising or being surprised by those around you.
Examples: document and share top problems, and updates during crises
The growth skills are:
Taste: exercise discerning judgment about what “good” looks like—technically, in business terms, and in process/strategy. Taste is a broadchurch, and my experience is that broad taste is an somewhat universal criteria for truly senior roles. In some ways, taste is a prerequisite to Amazon’s Are Right, A Lot.
Examples: refine proposed product concept, avoid high-risk rewrite, find usability issues in team’s work
Clarity: your team, stakeholders, and leadership know what you’re doing and why, and agree that it makes sense. In particular, they understand how you are overcoming your biggest problems. So clarity is not, “Struggling with scalability issues” but instead “Sharding the user logins database in a new cluster to reduce load.”
Examples: identify levers to progress, create plan to exit a crisis, show progress on implementing that plan
Navigating ambiguity: work from complex problem to opinionated, viable approach. If you’re given an extremely messy, open-ended problem, can you still find a way to make progress? (I’ve written previously about this topic.)
Examples: launching a new business line, improving developer experience, going from 1 to N cloud regions
Working across timescales: ensure your areas of responsibility make progress across both the short and long term. There are many ways to appear successful by cutting corners today, that end in disaster tomorrow. Success requires understanding, and being accountable for, how different timescales interact.
Examples: have an explicit destination, ensure short-term work steers towards it, be long-term rigid and short-term flexible
Having spent a fair amount of time pressure testing these, I’m pretty sure most effective managers, and manager archetypes, can be fit into these boxes.
Self-assessing on these skills
There’s no perfect way to measure anything complex, but here are some thinking questions for you to spend time with as you assess where you stand on each of these skills:
- Execution
- When did your team last have friction delivering work? Is that a recurring issue?
- What’s something hard you shipped that went really, really well?
- When were you last pulled onto solving a time-sensitive, executive-visible project?
- Team
- Who was the last strong performer you hired?
- Have you retained your strongest performers?
- What strong performers want to join your team?
- Which peers consider your team highly effective?
- When did an executive describe your team as exceptional?
- Ownership
- When did you or your team overcome the odds to deliver something important? (Would your stakeholders agree?)
- What’s the last difficult problem you solved that stayed solved (rather than reoccurring)?
- When did you last solve the problem first before addressing cross-team gaps?
- Alignment
- When was the last time you were surprised by a stakeholder? What could you do to prevent that reoccuring?
- How does a new stakeholder understand your prioritization tradeoffs (incl rationale)?
- When did you last disappoint a stakeholder without damaging your relationship?
- What stakeholders would join your company because they trust you?
- Taste
- What’s a recent decision that is meaningfully better because you were present?
- If your product counterpart left, what decisions would you struggle to make?
- Where’s a subtle clarification that significantly changed a design or launch?
- How have you inflected team’s outcomes by seeing around corners?
- Clarity
- What’s a difficult trade-off you recently helped your team make?
- How could you enable them to make that same trade-off without your direct participation?
- What’s a recent decision you made that was undone? How?
- Navigating ambiguity
- What problem have you worked on that was stuck before assisted, and unstuck afterwards?
- How did you unstick it?
- Do senior leaders bring ambiguous problems to you? Why?
- Working across timescales
- What’s a recent trade off you made between short and long-term priorities?
- How do you inform these tradeoffs across timescales?
- What long-term goals are you protecting at significant short-term cost?
Most of these questions stand on their own, but it’s worth briefly explaining the “Have you ever been pulled into a SpecificSortOfProject by an executive?” questions. My experience is that in most companies, executives will try to poach you onto their most important problems that correspond to your strengths. So if they’re never attempting to pull you in then either you’re not considered as particularly strong on that dimensions, or you’re already very saturated with other work such that it doesn’t seem possible to pull you in.
Are “core skills” the same over time?
While those groupings of “core” and “growth” skills are obvious groupings to me, what I came to appreciate while writing this is that some skills swap between core to growth as the fads evolve. Where execution is a foundational skill today, it was less of a core skill in the hypergrowth era, and even less in the investor era.
This is the fundamentally tricky part of succeeding as an engineering manager across fads: you need a sufficiently broad base across each of these skills to be successful, otherwise you’re very likely to be viewed as a weak manager when the eras unpredictably end.
Stay energized to stay engaged
The “Manage your priorities and energy” chapter in The Engineering Executive’s Primer captures an important reality that took me too long to understand: the perfect allocation of work is not the mathematically ideal allocation that maximizes impact. Instead, it’s the balance between that mathematical ideal and doing things that energize you enough to stay motivated over the long haul. If you’re someone who loves writing software, that might involve writing a bit more than helpful to your team. If you’re someone who loves streamlining an organization, it might be improving a friction-filled process that is a personal affront, even if it’s not causing that much overall inefficiency.
Forty-year career
Similarly to the question of prioritizing activities to stay energized, there’s also understanding where you are in your career, an idea I explored in A forty-year career.
For each role, you have the chance to prioritize across different dimensions like pace, people, prestige, profit, or learning. There’s no “right decision,” and there are always tradeoffs. The decisions you make early in your career will compound over the following forty years. You also have to operate within the constraints of your life today and your possible lives tomorrow. Early in my career, I had few responsibilities to others, and had the opportunity to work extremely hard at places like Uber. Today, with more family responsibilities, I am unwilling to make the tradeoffs to consistently work that way, which has real implications on how I think about which roles to prioritize over time.
Recognizing these tradeoffs, and making them deliberately, is one of the highest value things you can do to shape your career. Most importantly, it’s extremely hard to have a career at all if you don’t think about these dimensions and have a healthy amount of self-awareness to understand the tradeoffs that will allow you to stay engaged over half a lifetime.
Read the original article
Comments
I've worked as an EM at four different companies, from large enterprises to small startups, and I think "the role of engineering manager" is a myth. Your role varies wildly from one company to another. In every company I've worked at, my job has never been the same:
In the end, engineering management basically requires you to counter-balance whichever of the four pillars your team needs most: Product, Process, People, and Programming.
- Too few people? You'll work on scope to make the deliverables meet reality. Since there's not much communication overhead, you'll be able to program.
- No PM? You now own the product pillar entirely. This takes a lot of your time: You'll need to validate features, prioritize the roadmap, and even talk directly with clients. None of the rest matters if your team is shipping features with no user value.
- Too many people in the team/company? Say goodbye to programming. You'll be responsible for careers, making everyone work cohesively, and navigating the org to get the right resources and support for your team.
- Reporting close to the CEO? You'll handle the bridge between sales, operations, client communications, and other functions.
The common thread is that your focus constantly shifts based on where your team's bottlenecks are. The key is identifying which pillar needs attention and adapting accordingly.
I feel like a lot of leadership positions are like this. I was a Principal Tech Lead at a 300 personal company and I did everything from PMing large tech teams, to collecting info from top users in spreadsheets, to building demos directly for the CEO, to building a key part of our tech used by over 100 other engineers.
I always told people I’d plunge the toilets myself if they were preventing the staff from working. I feel like the closer you get to top leadership the more your job becomes identifying and executing on whatever is highest value that you have the skills for.
> identifying and executing on whatever is highest value that you have the skills for
There's a hidden assumption there though, that you CAN actually do that. At least management skills mostly stick over time but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects. Which is why I continue to push back against suggestions technical managers shouldn't be engaged hands on. Apart from being incredibly hostile to their own interests (it will be central to you getting hired to any future role), it also impairs one of the most strategic aspects of the role which can drastically affect the value you can deliver internally in the future as well.
> but even a year away from hands on technical work is going to leave you likely stranded and unable to execute on the technical aspects
This is an interesting myth, but certainly a myth. I guess if we consider technical skill to be intimate knowledge of the latest fad framework, that might be one source of the myth. But that's not technical skills, just trivia about an implementation detail.
The fundamentals like networking, process and memory management, databases and SQL, all change slowly and are very long-lived career-spanning knowledge.
By tyleo 2025-11-244:46 Agreed, I haven’t seen this in my career at least. I’ve worked with contractors on a yearly basis who would take some time off and then hit the ground running.
If there’s any data supporting the opposite, I’d love to see it.
Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad. These were all born in the last few decades, so they are rather new, and they will stay for equally long decades. And the list goes on and on... So all of those skills in your list mean nothing when it comes to these fundamental technical tools. They require an understanding on a completely different abstraction level which is equally complex as of those that you listed.
So if you don't have the understanding of these technologies when the project requires it, you are obsolete and you have no right to be in a leading position. And such fundamental technologies are born continuously.
So this myth that you can have fundamentals and that's enough is definitely untrue.
> Kubernetes is not a fad. DynamoDB and MongoDB is not a fad. Golang is not a fad.
These are indeed good examples of things that are merely tools, not fundamental knowledge.
Time-transport me an expert C programmer from the 80s and I'll have them productive in Go in two weeks. It's all very familiar territory.
O send me a mainframe programmer from the 60s and they'll be up to speed on kubernetes in short order. Pushing your workload to a remote cloud (mainframe) won't be exactly be new to them.
Databases have been studied and their properties understood for a very long time.
Sure, the exact details vary a bit and the command line options are different, but that's not significant.
By rester324 2025-11-262:17 Yeah, that sounds logical. Some of the most popular technologies of this time are just teeny-tiny tools, but some of long obsolete technologies and their attached skills which have no correlation to anything recent is somehow fundamental and has magical properties in your view :D Thanks for the good laugh!
> Databases have been studied and their properties understood for a very long time.
No they haven't. Noone ever considered schemaless databases or column-storage databases or vector databases for half a century after the birth of computing. So that kind of knowledge (relational DBs, etc in the 60s and 80s) meant nothing in light of these new technologies, and required completely different skills and knowledge.
But it's clear you are not familiar with these technologies, so it's a waste of time to engage with you now
By roryirvine 2025-11-2410:301 reply If people think that not being hands-on for a year is unmanageable, then we as an industry are doing something horrifically wrong.
It would mean that no engineer could ever aspire to become a parent, take a sabbatical, further their education, or experiment with alternate career paths.
But I promise you that that is not actually the case. In fact, it is often the engineers who've stifled every other part of their life that are most likely to struggle in their mid-careers and beyond.
By zmmmmm 2025-11-2420:49 Yes, I don't mean actually taking time away - more organisationally, once you assume a role that is divorced from technical aspects and then try to come back to managing those without hands on experience. You will find that other more technically informed people rise up and start to become decision makers - you can't be authoritative any more and constantly have to ask someone else to give input on technical aspects since you aren't up to date with the current set of assumptions about it.
By saghm 2025-11-243:17 > I always told people I’d plunge the toilets myself if they were preventing the staff from working.
This is a lot closer to a literal interpretation of "shit rolls downhill, so a good manager will be a shit umbrella to protect their team" than I thought I'd ever see.
By camel_gopher 2025-11-247:071 reply You have to be careful of the perceived politics around this. Tall poppies get cut down. I still don’t totally understand why but sometimes taking initiative doesn’t sit well with the folks who want their trains to run on time.
By tyleo 2025-11-2413:43 I think this varies from person-to-person or maybe organization-to-organization. I've definitely seen variations in the health of organizations but I think you can break up the categories used to judge them, e.g., meritocracy, overtime frequency, planning accuracy, psychological safety, value of work, etc.
I'd say the place I worked felt above average in meritocracy. In other words, it felt like folks sticking out to take initiative were more often rewarded than punished. I don't think we were perfect in every category though.
By orionfollett 2025-11-248:171 reply At least in small companies, my experience is that being adaptive like this applies to ICs as well as managers. Although to be fair the environment I'm thinking of doesn't have any full time managers.
By tyleo 2025-11-2412:21 Yeah, I think true. The smaller a company is the easier and more important it is to think and act holistically.
By phillmv 2025-11-2419:32 i found this comment to be more insightful than the article
I worry a lot about fads in engineering management. Any time you proscribe process over outcomes you create performative behavior and bad incentives in any discipline. In my observation, this tends to happen in engineering because senior leaders have no idea how to evaluate EMs in a non-performative way or as a knee-jerk to some broader cultural behavior. I think this is why you see many successful, seasoned EMs become political animals over time.
My suspicion about why this is the case is rooted in the responsibilities engineering shares with product and design at the management level. In an environment where very little unilateral decision making can be made by an EM, it is difficult to know if an outcome is because the EM is doing well or because of the people around them. I could be wrong, but once you look high enough in the org chart to no longer see trios, this problem recedes.
The author really got me thinking about the timeless aspects of the role underlying fads. I have certainly noticed shifts in management practice at companies over my career, but I choose to believe the underlying philosophy is timeless, like the relationship between day to day software engineering and computer science.
I worry about the future of the EM discipline. Every decade or so, it seems like there is a push to eliminate the function altogether, and no one can agree on the skillset. And yet like junior engineers, this should be the function that grows future leadership. I don't understand why there is so much disdain for it.
By brightball 2025-11-2323:371 reply Process over Outcome is something that I think would be easy for anyone to proscribe to a process that they didn't like.
In my younger years, I was very cavalier about my approach to programming even at a larger company. I didn't particularly want to understand why I had to jump through so many hoops to access a production database to fix a problem or why there were so many steps to deploy to production.
Now that I more experienced, I fully understand all of those guardrails and as a manager my focus is on streamlining those guardrails as much as possible to get maximum benefit with minimum negative impact to the team solving problems.
But this involves a lot of process automation and tooling.
By p_v_doom 2025-11-248:56 The problem imo tends to be not that there are guard rails in place. It's that they are often build by people that only care about the guard rail part and completely forget that its supposed to be last barrier and that there are other things you can do before you get people to hit a guardrail
By jaredklewis 2025-11-2323:221 reply I like your thinking about this problem.
What if teams were integrated groups of engineers, designers, and product people, managed by polymaths with at least some skill in all of these areas. In this case, do you think it would be easier to evaluate the team’s (and thus the manager’s) performance and then higher levels of management would care less about processes and management philosophy?
By madrox 2025-11-2323:31 You're describing the GM (general manager) model, sometimes called the single threaded leader. This does work well in large scale organizations...especially ones where teams are built around projects and outcomes but exist for a finite time. Video game development tends to have this model.
I tend to believe in this model because when I've seen it in action, bad GMs are quickly identified and replaced for the betterment of the project.
It can be challenging to implement for a few reasons.
- It is difficult for a GM to performance manage across all disciplines. This model works best when you aren't interested in talent development.
- It's bad for functional consistency. GMs are focused on their own outcomes and can make the "ship your org chart" problem worse. It requires strong functional gatekeepers as a second-order discipline.
> I don't understand why there is so much disdain for it.
I do. It’s often done by people that become tyrants over their little fiefdom.
By madrox 2025-11-2323:20 That's usually a consequence of bad incentives. Either leadership is selecting for that kind of behavior in managers or they don't know how to properly unselect for it.
If a bunch of crap code gets shipped, it isn't always because the engineers are bad. Often it's because they were given a bad deadline. Same with EMs.
There are components of management culture which are fads, like the idea that one could be an effective manager, while not understanding what one's reports are doing, through some management-foo learned from books and blogs. The success of that fad is no doubt partially due to the economic climate. People want the tech industry money, but don't have the tech industry skills.
Leadership is timeless, humans have always organized themselves in groups with leaders, and we instinctively play the part of leader or follower according to the situation. Being a good leader just means allowing the group to accomplish something that would be less likely without one's guidance. Being a good follower is mostly a selection role, where one exercises judgement in choosing a leader to follow.
The mechanism for dealing with bad leaders has also changed relatively little: stop giving them your own resources, and put distance between you and them. In the workplace this is asking to switch to another team. You can dress it up with fake reasons, like you are interested in another project, or you aren't learning enough, whatever. The important thing is that it takes a resource (you) away from a bad leader and gives it to a better one. Iterate this process enough, and the incompetent leaders are outed through their inability to maintain personnel.
People don't do this enough, it's an easy way to signal to upper leadership who in management is bad at their job, without a direct accusation.
By robot-wrangler 2025-11-240:113 reply Yes. All leadership is supposed to be technical leadership. Outside of engineering-management, technical just means significant actual domain expertise. If you want an organization that can do stuff, you have to know stuff, there's just no substitute and everything else is basically fake. The "visionary", the "idea person", the experts at alignment / people / processes / ceremonies were always kind of mythical but to the extent they were ever real.. that kind of expertise tends to be removed in large orgs anyway because they are viewed as threatening by fakers who are better at maneuvering.
The fad is non-technical management, and the result is a general crisis in leadership that you can see everywhere across tech, politics, entertainment, whatever. Top leadership is out of ideas and just looking around for others to copy, or cruising on extraction/exploitation of value-creation that came before. It's a slow-motion disaster that's been picking up speed, which is why consumers, workers, and constituents are all pissed off. Seems like the shareholders will be effected soon, so then maybe it starts to change.
By Spooky23 2025-11-242:51 This is probably one of the most cogent analysis/descriptions of this topic that I’ve read. Thank you.
By DrScientist 2025-11-2412:35 > Seems like the shareholders will be effected soon, so then maybe it starts to change.
With companies at least there is direct feedback via company performance - companies led by people who know what they are doing do better than those that aren't.
And well led companies tend to attract and retain more talent.
The feedback in politics is much much slower - in part because often the people you are voting for are not really the people setting policy - that's all done by the party machine ( 20 somethings with no real world experience working as advisors ) - so changing the 'leader' often doesn't make much of a difference.
ie one of the things that is really annoying the electorate is it's really difficult to actually vote in leaders or policies you want because of the way the party system works - leaders change yet everything stays the same.
I mean in the US - who really though Kamala was the best candidate to run against Trump?
By adam1996TL 2025-11-241:45 [dead]
By rester324 2025-11-251:22 Well, I can see your point, but this assumes that engineers only care about their career and or personal relationships. But I know that many engineers care deeply about a project's success and project goals enough to endure bad leadership for very very long times, because they know from experience that the average leader is mediocre, so switching teams or companies is a gamble, and not all life situations allow people to gamble with their lives.
