Learning to be an operator
“Hey Mikey, I think he likes it.”
Two things happened last month. One was that my director, Dan Na was leaving the company. The second is that I really had no clue who Dan was in the greater technical management blogosphere. Here I thought that all the times he plugged his blog during his 1:1s was just shameless self-promotion, which it was but the content is, admittedly, good stuff.
It was only once Dan chose to leave that I figured out my sort of internal compass of where to take my career. In my heyday, I was working in multiple startups in the Bay Area, itching to move up. My goal was to become a director in 10 years. For many, many reasons (burn out, never traveling growing up, etc.), I decided to leave San Francisco and move to Europe for a year. Living abroad recontextualized a lot of how I felt about American Religious Workism and inculcated within me a fear of my job defining my identity. At a certain point, I equated fear of defining my identity with committing to any amount of extra work to advancing my career.
More importantly, I didn’t know how to advance my career. I had been a professional software engineer since graduating and I had been toying with coding since middle school. I didn’t really have a sense of how to toy with management. I sure as hell didn’t go to any Engineering Management classes because surprise, surprise, they didn’t exist.
Dan’s departure finally piqued my interest in the great blogosphere that is software engineering management which led me to Will Larson’s blog (these bloggers sure don’t like using their name in the URLs. Guess I’m guilty of that too). Looking at his most popular posts, I stumbled upon the post Writers Who Operate and the sea of ambiguity parted, like in Moana but also for Moses.
In my very first stint as a manager in the Bay Area, my manager was also new to management (oh the joys of startup life). The imposter syndrome at this point was at full throttle for the both of us, our management hierarchy strictly set based on our tenure in the industry (i.e. age). At my current company, I had been various flavor of “lead,” from Team Lead to Engineering Team Manager to now Team Manager / Tech Lead. I struggled mightily with balancing being technical and being a manager. Is there a golden ratio of when to have career discussions vs. when to code? Am I confined to writing RFCs for the rest of my career?
I’ve had managers require a quarterly career check-in, many of which felt forced and rote. I’ve had managers tell me to expect my calendar to explode with meetings, glad-hand directors and “move up,” whatever that means. I’ve had managers to tell me to explicitly stop coding. My coding activity was described by my managers as being “too technical.” When I was having career discussions, writing feedback and developing project roadmaps, I was told I wasn’t being technical enough. Right after reading Writers Who Operate I quickly jotted down the map that popped into my brain into my work notebook. If anyone has read The Stormlight Archive, this quickly became my rudimentary version of The Diagram.
From the bottom up:
Foundation: Technical knowledge and emotional intelligence are non-negotiables
Technical knowledge
The adage of “People don’t quit bad companies - they quit bad managers” requires some tweaking in the engineering management space. What does a “bad manager” mean here? In my opinion it means managers that lean too hard into the managerial aspects as an escape route from being technical.
Technical knowledge is leverage built through consistent credibility and beliveability. Without technical knowledge, an engineering manager is largely useless.
Common anti-patterns I see for non-technical managers:
Air traffic controllers - Managers that direct work in a way that maps a project to skillsets on the team. Frontend project goes to a frontend engineer, same for backend. The problem here is that projects are directed but not scrutinized. Is this the right project to work on right now? Is the approach correct? These decisions end up getting delegated AND abdicated which is a problem
Bureaucrats - In an admittedly uncharitable view of bureaucrats, this type of manager ensures, above all, that processes are followed. Need to develop a large project? Write an RFC. Frontend engineer decides to leave? Immediately backfill with the same job description. Make sure that that cool team over there writes a one pager when they request something to you! This seems to be the sort of smell that’s plaguing Intel
Pushing down, moving up - High impact technical decisions get pushed down to lower ICs and framed as “opportunities.” Awesome! Now you have free time to do the “real” managerial stuff, not that technical decision making. It’s a win-win right? Less responsibility for yourself and bonus points that ICs get saddled with more “responsibility”
Not my circus, not my monkeys - When projects under your purview falter, an RFC is poorly received or a project launch gets botched or pushed back, it’s far easier to blame the project lead or senior engineer rather than yourself
Yes-men/people pleasers - Whether an incoming feature request or project proposal comes in, people pleasers without a strong technical background are willing to believe the technical acumen of the person requesting the change. Many times these incoming requests come in with a suggested implementation or design. A bad manager will take these at face value and begin implementation sooner than it should be.
Emotional intelligence
I firmly, firmly believe that software engineering is fundamentally a human endeavor as much as it is a technical one. Code is read far more than it is written, documentation matters, gelling takes time, etc. As a manager, your output is a quality team first and quality projects come out of that team second
My first manager told me his two rules for 1:1s: 1) Shut up and listen and 2) Shut up and listen. Being an emotionally intelligent manager means fundamentally understanding the people on your team. What are they there for? What’s in it for them? What gets them up in the morning and what excites them?
Reading the room - In meetings, project kickoffs, meetings with execs, it’s important to gleaning the subtext underneath what’s being said. Who’s deferential to who? Is it deference or obsequiousness? Is a director taking up a lot of room, leaving the staff engineer little space to get a word in? What’s the elephant in the room that’s purposely being avoided? Which directors can you tell have a good rapport? Which relationships seem sour to you?
The meaty middle: Alignment is a lot of the job
Teams ideally should deliver the right thing at the right time to the right people. Good engineering managers have a consistent track record of delivery
The quality of alignment depends on the quality of the inputs
Meetings are (sort of) the medium - High Output Management considers meetings to be the medium through which things get done for managers
Types of alignment:
Aligning people with technical initiatives - In an ideal world, a manager will always be able to map an upcoming project to an IC’s career growth
Selling the project - In a less than ideal world, a good engineering manager should find ways to frame the project in the right light. A big part of this is basically perpetual optimism
Getting to yes - RFCs, roadmaps, strategy docs, etc. require alignment and buy-in. How do you build consensus?
Compromising
Lack of alignment smells:
Teams that can’t say no to anything
Teams that lack a coherent vision or mission
Teams with long-lived tech debt that never seems to be prioritized
Flimsy roadmaps that are changed often
A cherry on top: Occasional coding
Coding as a manager is complex because it’s often seen as zero sum. An hour of coding compared to an hour of writing feedback could be construed as bad time management.
However, technical knowledge is foundational for a reason: It provides the first principles, frameworks, and decision making required to discuss and estimate projects, prioritize tech debt, and act as a sounding board to non-technical teammates such as Project Managers, Product Managers, Designers, etc.
Coding allows you to incrementally build your technical base but it needs to be done thoughtfully. My two guidelines for coding as a manager:
Avoid coding on the critical path to delivering a project unless absolutely necessary. Breaking this rule demonstrates to the project team that when push comes to shove, you will step in and get it done instead of them. This saps ownership, morale and accountability.
Code orthogonally to your existing skillset. An engineering manager who spends a few hours a week exploring AI, e.g. trying Cursor, Claude, prompt engineering, etc. is significantly better informed about the space than an engineering manager who codes into the same codebase. They can provide realistic expectations about how much AI can help, the situations where it’s helpful and when it’s hurtful
tl;dr: The right coding should expand your technical knowledge base and bolster your believability.
What is the best part about all of this? All of these are skills that can be developed, just like coding. Before, I saw engineering management as some sort of Jumanji world where you come in as a senior engineer and you somehow come out as a Director. Now I see that the learning loop is:
Figure out the holes in your grab bag of skillsets. Much of this can be based on the gap between your current skillset and your organization’s career ladder
Read a book. Divide lessons into ones you’ve already learned and ones you find scary and align with the gaps
Find opportunities to exercise scary lessons. Build reps, rinse and repeat
Strengthen the neural pathways that help solidify that lesson in your brain
Find the next gap
Books on my reading list
High Output Management by Andy Grove
Resilient Management by Lara Hogan
The Manager’s Path by Camille Fournier
Team Topologies by Manuel Pais and Matthew Skelton
P.S. Thank you to Maalvika for indirectly convincing me to post for the first time.