27 Lessons from 8 Years of Management
Today marks my 8th consecutive year in management, and with it I’m taking a couple-month sabbatical as an individual contributor.
I’m no stranger to the engineer/manager pendulum. While the term was first coined (popularized?) by Charity Majors in 2017, I’ve been “pendulum-ing” long before then (17ish years)…this will be the 6th swing of pendulum. In spite of the familiarity of the maneuver, this time feels different. 8 years is a long time–this is my longest contiguous stay in management. On one hand it is exciting to get to be hands-on building things amidst a paradigm-shifting moment in tech. On the other hand, it’s hard to escape dread at the thought I might be throwing away years of “career progress” on a whim. Nevertheless, my approach to leadership so thoroughly depends on maintaining a real, honest-to-god understanding of how to actually build things, and the technical depth to offer creative solutions where others see none. It wouldn’t feel right to continue managing without a robust model update.
Now feels like the perfect time to chronicle some hard-won lessons from my most recent turn at the wheel; I’ve grown more as an engineering leader in the last few years than at any other point in my career, and these major transitions are a great time to do a pause-the-world GC cycle for my brain.
I tried to limit this list to the really revelatory experiences that I have not seen well-covered in the existing management canon. It still ended up very, very long so each idea is treated with quite briefly. If you found a useful nugget and would like to see it elaborated, hit up my inbox jim@lolno.com
My Recent Roles
First some background on what I’ve been working on so you can place these lessons in context. Over the last 8 years, I have…
Served as the head of engineering for a B2B OT security startup eventually acquired by Rockwell Automation, building their product development team from scratch.
Joined Google and managed the foundational storage systems that hold all of Google’s data, (blob, object, file, and configuration storage) in addition to distributed system primitives used by all products and services at Google (locking, leader election, time, key management).
Switched out of platform engineering and back into product engineering becoming one of the overall engineering leads for Google Drive.
During that time I’ve had to rebuild and re-establish myself in a new org–scaling from running a single team of 3 engineers to an org of 70+ not once but thrice! I’ve acted as the “pure people manager” and tech lead manager (TLM) role for which Google is notorious (infamous?). At times I’ve had 25 direct reports (oh my god), other times a proper pyramid of managers and sub-teams. I’ve received multiple promotions, and helped others grow from L3 all the way to L8. If you believe that “10,000 hour-rule” for mastery, I’m well past the 10,000 hour mark when it comes to management. I run a thriving management coaching business on the side.
None of this is to brag, but rather to establish…
This isn’t the ranting of someone who burned out and couldn’t cut it.
Most of my lessons are applicable to navigating and thriving at BigCo–the FAANGs of the world–you may find some portability of these lessons to other contexts but that is only incidental.
Without further ado, let’s dive in.
Org Dynamics
1. Small business experience does not prepare you to lead in a large enterprise.
It’s a story as old as time: director+ startup leader joins BigCo and gets “downleveled” to small team manager. I’ve heard this explained away as elitism or just differences of scale (a startup director might have 20-30 reports…while the enterprise equivalent is 60-120). I’ve run across plenty of these people at Big G and they all have a chip on their shoulder, seeing this fate is wholly undeserved. I was one of them…at least until I realized how much I had to learn.
Change management and project execution when you have to deal with tens-to-hundreds of stakeholders with different reporting chains and incentives is a much greater challenge than doing the very same with a small group that reports to you / was entirely hired by you / has to listen to you. It’s the difference between learning the rules of a game versus inventing the game in the first place.
Delivering impact now requires navigating an entire layer of organizational optics and processes which likely didn’t exist where you came from. Building alliances, managing perceptions, and creating opportunities for serendipity (luck) will contribute more to your success than pure brute force execution.
There’s specialized functions for everything (product, UX, design, marketing, support, SRE, etc) and you have to learn how to get what you need out of them without any formal authority and without seeming like a dictator.
You will work on timescales that seem unthinkable in a startup. A major initiative in BigCo might span 3-4 years. Your entire company could be born, live, and die in less than half that timespan. Maintaining the endurance to be consistent over such large time scales will push you to your limit.
Hiring, engaging, and motivating the typical BigCo employee is an uphill battle. You have less agency and autonomy to pick what you work on, you often need to sell very bright engineers on lame projects (aka cat turds), and you have fewer incentive levers under your control (titles, money, promotions). There’s little chance for “mission” to motivate and the median BigCo worker is more driven by status and wealth (tech has become a “prestige” field like law and medicine, you will be surrounded by people who are not here for a love of engineering).
This is not to say that startup/small biz experience isn’t helpful. You wear more hats and often build a more complete, ecological view of the value stream that is software engineering…understanding how “code” gets turned into “profits.” You’ll build product intuition, commercial sense, resourcefulness, self-reliance, and the ability to work with all manner of stakeholders that will set you apart from a life-long BigCo manager….but don’t delude yourself into thinking this means you’ll totally crush it as a director on day zero. Downleveling is a myth.
2. Org structures are a fun bike shed but reality will eat your perfect org chart for breakfast.
You’ve read Team Topologies (and An Elegant Puzzle, and Scaling People, and Thinking in Systems, and….). You quote Martin Fowler and opine about the “Reverse Conway Maneuver” daily. You have sat in poorly structured orgs and wondered why the directors and VP’s in charge are totally asleep at the wheel with teams that overlap / lack a clear mission. You think “when I’m in charge, we’ll get the org shaped up and everything else will follow!”
Ha ha, hahahaha, ha.
No no, I’m not laughing at you, I promise. I used to think like this, waiting for my chance to join the big leagues and run my own org where I’d show the power of proper org design.
Now that I’ve run four major (100+ people) reorgs in my life I’ve come to understand a really painful truth: 80% of the time, the shape of the org chart just does not matter as much as you think.
In my experience, a highly optimized org chart only stays optimal for about 3 months before something breaks:
A major shift in strategy, priorities, or objectives means you have a massively oversized (or undersized, or nonexistent) team for a given area/project/piece of infrastructure.
A staffing crunch forces you to raid one of your “perfectly crafted” teams and have someone pinch hit for another group. This keeps happening until your “org chart” is a spaghetti mess of dotted lines.
A TL or manager whom you built the org around quits on you, throwing the whole system into chaos.
A key playmaker gets antsy for more opportunities to grow and demands more scope / more reports and you can’t imagine losing them.
We used to get out of these messes by just…hiring more! Why change a team when you can grow an entirely new one!? Well those days are done–the money printer is broken–and you definitely cannot run a reorg every 3 months. Engineers benefit from stability in their working relationships. Once a team is bonded and works well together, your best bet is to “bring a problem to the team” rather than “bringing a team to the problem” even if it means subtly pivoting what a given group owns.
Naming teams sure is a bitch when you do this (I literally had a team that called themselves “the variety show,” hi Matt), but having a vague/inaccurate name is better than going through the Tuckman cycle constantly.
With this in mind, what really matters for organizational clarity and success is…
Clear lanes of accountability: every major area has a directly responsible individual (DRI) or single-threaded leader (STL) and those individuals are held accountable for results. With ultimate accountability comes ultimate authority to do what needs to be done no matter whose reports / teams are involved.
A conscientious and high-agency leadership bench: these individuals take action without waiting to be told and never assume it is “someone else’s job.” Such leads are self-driven and don’t let gaps in team structure and org process hold them back.
A sense of ownership: your team hinges a non-trivial amount of their self-worth on rising to the challenge. When teams feel like their work is their own, you receive an outpouring of effort, energy, and creativity that leads to better outcomes than any amount of micromanagement.
Strong interpersonal relationships and conflict resolution habits: the team is able to engage in creative conflict, disagree productively, and puts in active effort to improve their relationships. Things get messy when your org chart is messy, people have to fundamentally care about and respect one another if this is going to work.
Don’t get me wrong–there is great power in enabling productive non-communication so that each part of a large org can function independently and avoid conflicts. There are benefits to aligning management (and corresponding performance management practices) to the work actually happening. You can’t go to full blown self-forming teams and holocracy without leaving a lot of productivity on the table.
The point is that your team structures will always carry some non-trivial amount of “org-debt” and “misalignment” in exchange for stability of teams, retention of key talent, and enabling the flexibility to respond to emergent threats/crises/opportunities which are much more important to long-term success.
Another way to think about this is that if you wait long enough, some emergency will emerge that forces a reorg (e.g. a top manager wanting to go back to being an IC…lolsob) so there is little need for you to proactively initiate such destructive changes. You’ll likely prematurely optimize around a set of constraints, people, and goals that won’t hold in just a few months!
3. Cross-functional incentive misalignment is your number one enemy.
Different job functions–e.g. product, eng, UX, data science, etc–optimize for different things (duh). Unfortunately you have to work with all of these functions to get anything done in BigCo so you cannot simply plug your ears and insist eng is always right.
The most pernicious form of this I have seen occurs at Google: functional silos. Functional silos are entire reporting chains (managers reporting to directors reporting to VPs reporting to…yet more VPs lmao) of the same job function. An eng manager and a PM manager that co-own the same objectives don’t actually share a common ancestor until you reach the SVP or the CEO.
You might think “that’s fine, I can just…talk to the person…so who cares?” but the reality is that all of your closest collaborators work for different bosses. As much as we try to be our own person, success at BigCo largely means figuring out what your boss really wants. You are directly incentivized in the form of career growth//power to prioritize what they think over the collective opinion of your peer group. See where this is going?
I had the dubious honor of leading about one-third of Google Drive’s product portfolio, and with that came a veritable army of co-conspirators (product managers, designers, UX researchers, data scientists, support personnel, program managers, and enterprise account managers). We would spend days…weeks!…discussing/researching/analyzing to align on a direction and a strategy. Just when I thought everyone was aligned and we were off to the races, someone would blunder into the room and say: “I spoke to [director] and they really want us to focus on [some random crap]!” Boom. Complete reset. Weeks of progress and influencing undone. Back to square one. Just because of an off-hand, drive-by remark from a distracted senior leader.
Inevitably, I would reach out to this director and find out they had no intention of randomizing us and didn’t expect anyone to index so heavily on their opinion. Go figure.
To keep any group headed in the same direction, you need alignment one level up (at a minimum). What this means in practice is arming your boss with a viewpoint, facts/data/analysis to back it up, and sending them off to do battle with their peer directors/VPs/what have you. If you’re precocious, you could try directly influencing these organizational Aunts and Uncles…but more often than not all I got was confused looks, “why are you talking to me? Is your Dad home?” Hurray for hierarchy! Culture eats strategy for breakfast and all that tired shit.
I’m quite fond of how Microsoft does this (used to do this?) where different functions (the “triad”) would report together much lower in the org chart…sometimes as low as a “group manager” (M2) if not director (M3). There are still bugs that have to be worked out in that system but at least you have a fighting chance of keeping your group aligned.
4. You have to be just a little difficult to get things done.
If you haven’t gotten the clue yet from my writing style, I can be a bit brusque. There’s a method to the madness however. Not everything can be driven by consensus–do any of these scenarios sound familiar to you?
A peer team rejects a feature request that blocks a major project.
A dependency has a huge outage and doesn’t seem to be taking it seriously.
Your team spends all its time responding to questions and supporting users even though you have other priorities.
Your team keeps accepting unplanned work and feature requests to help out others, delaying a major deliverable.
You keep getting sucked into forced migration mandates because some other team “cannot” support a piece of legacy infrastructure any longer.
Your PM presents a totally coked up PRD for a feature you think is a waste of time. You do it anyways.
Your designer presents a mock which will double the engineering effort for a trivial UX optimization in your opinion. You do it anyways.
Your SWEs present an over-engineered design that makes a project 10x harder than it needs to be. You do it anyways.
All of these are scenarios where consensus is the easy way out. You avoid conflict and let the bad outcome persist. You tell yourself you’re “trusting the process” and empowering others to feel ownership…but what’s the difference between this and outright abdication? This is why I have such a bone to pick with “servant leadership” but I’ll talk about that more further down…
Sometimes you need to be the bad guy. You need to push back, be demanding, hold a higher bar, and not accept the facts as presented at face value. Another form of this is not letting others place demands on your time. There is a huge opportunity cost when a leader gets sucked into a never-ending circular debate or picking through pointless desiderata. A day spent thinking ahead and strategizing could save years of effort down the line. Sometimes you just have to make a decision and refuse to elaborate further. “No.” is a complete sentence.
To some this will be read as “being an asshole.” To others it’s “being assertive.” Honestly it’s a little bit of both.
I call this “calibrated aggression.” Calibrated aggression is necessary to think laterally and break through the web of lazy defaults, implicit constraints, convenient decisions, and post-hoc justifications that all too often shape our collective behavior. So much of our lives are implicitly ruled by conflict avoidance but you cannot afford to fall into this trap if you manage people.
The human mind displays a remarkable capacity for rationalization. This occurs when people create post-hoc explanations to justify their actions, even though they know (consciously or unconsciously) that these explanations aren’t the real reasons behind their decisions. Rationalization is closely connected to cognitive dissonance reduction, which is the underlying psychological mechanism that drives this behavior. When there’s a conflict between our actions and our beliefs or self-image, we experience cognitive dissonance–an uncomfortable psychological state. To resolve this discomfort, we often rationalize our actions by creating plausible-sounding explanations that make our behavior seem more reasonable or justified.
The key aspect of rationalization is that people often don’t realize they’re doing it. They genuinely believe the post-hoc explanations they’ve constructed. This is to say: you won’t even be able to tell you’ve fallen into people pleasing and conflict avoidance!
Leaders being overly agreeable foment the conditions for this collective psychosis and create utterly ineffective organizations where lots of work is happening but its the wrong work and everyone feels stuck doing it. Requirements are often flexible, goal posts can be moved, and stakeholders who seem utterly cantankerous are more pliable than they seem. All it takes is a little calibrated aggression.
5. “Tech lead” is a set of responsibilities, not a title you bestow.
I think everyone has been on a team where the official tech lead (TL) seems to be doing…nothing. Crazy nuanced design decisions? They aren’t the one making them. Technical debate boiling over during standup? They have nothing to say. Managers asking for the impossible and ignoring reality? They go along with it. Need something from another team? You’re on your own.
You might think this is a performance issue…well, it is, BUT the real root cause 9 times out of 10 is that the manager showed up, crowned the apparently most senior person TL and just assumed they would start doing the job. You might think you would never do that, but consider what happens when your current lead leaves: you immediately rush to name a new TL because, well, you need one…right!? So you carefully choose the highest potential impact player you have and…hope they just start doing the job without prompting. Gee wiz.
The consequence of this is stark. Key leadership tasks go unaddressed. Highly motivated team members become increasingly frustrated by the lack of support or by the extent to which they are doing the TL’s job without recognition. Any natural leaders will hold back (these people get activated by power vacuums–an internal locus of control coupled with a strong sense of duty encourages them to step up and grab the wheel so the ship doesn’t crash–having a bench warmer in the TL seat fills the vacuum and prevents this positive instinct from bearing fruit). In short, your team will suck and everyone will know + be mad about it.
The TL role is the single most important job on the team. Even more important than the manager. You cannot afford to have a bench warmer for a TL. To avoid this unfortunate fate, you must be unshakably confident your appointee is prepared and motivated to do the (sometimes thankless) job and all the grungy work it entails. I have found the best way to be certain is to leave the TL role unoccupied and see who steps up to fill the void. These emergent leads earn the respect and followership of their teams through skill and dependability, not title. Moreover, they take action without being asked and never assume “that’s not my job.” That’s ownership. REAL ownership. That’s your TL. By the time you place the TL crown on their head, it should almost feel like a formality. And if they stop doing the tasks demanded of a TL? Then they aren’t the TL any longer! You can’t expect someone to stay consistent over years and years–energy waxes and wanes as life throws you curve balls–make room for TL’s to step aside with grace and dignity when the time is right. This is much easier when they don’t need to be divorced from an official title.
To learn more about the fundamental traits of the best TL’s, check out The Captain Class by Sam Walker. Maybe one day I’ll do a post on how this maps to tech.
Skip-leveling 101
6. Code is DRY, people are not.
Much ink has been spilled about the importance of vision and strategy, and communicating that to your team: helping them connect to the why of their work and empowering the team to make better decisions on the ground, all while gliding collaboration and cross-team alignment.
To get your whole org on the same page, you carefully craft the greatest all-hands of your life. Truly a magnum opus of business strategy and showmanship. You practice, practice, practice. The day arrives, your org filters into the room, and you nail the delivery. In your head you’re flying high: I did it! I’m the best boss in the world. This will be the most inspired and motivated team EVER!
Fast forward, it’s a week later, you walk into a skip-level 1:1. Your report complains about the project they’re assigned to…they don’t get why it’s happening and it feels like we work on a smorgasbord of random junk that doesn’t add up to anything. You refer them to the all-hands recording, and repeat some of the key messages. You patiently answer some of their questions and help them understand the message. They leave at least pretending to feel better but you’re left scratching your head: “were they just not listening? Was I unclear? Did something happen I don’t know about to shake their confidence in The Plan?”
Here is a cold, hard dose of truth: you are not as important as you think you are. You are not the sun and moon and stars for these people. You are just one of their eight different bosses who are all constantly saying words at them and polluting the airwaves. Worse, the supposed “priorities” feel like they shift every other month. Any sufficiently tenured BigCo employee is completely numb to this and implicitly understands that their day-to-day life is no better if they get really invested in what the boss is saying today (in fact, sometimes it gets worse if you hang your motivation and happiness on a new direction that gets shot in the head shortly thereafter).
I’m a pretty good orator, but no rousing speech has ever created the singular focus, alignment, and energy that I want for my team.
The secret? Repeat yourself. Over and over and over. The magic number is 3. Repeat the same thing in 3 ways in 3 different venues and it will start to stick. Consistency of message is key. You want to evince “this time is different, you’re working for a team with clarity of purpose and direction that isn’t going to just totally shift in a few weeks.” Encountering the same idea at different times expressed in different ways increases the likelihood it will “click” with everyone eventually.
That all-hands is just one step, you have to keep going. There’s a time and place for one-to-many unidirectional communication…but don’t forget the importance of one-to-one bidirectional chats. After big town halls, I like to switch into “door-to-door salesman mode” and have a round of 1:1s. This gives me a chance to tailor the message to each person and answer their individual questions/doubts. Use memorable sound bites and consistent names for different initiatives and strategic pillars. As these ideas get repeated in different meetings/docs over many months, the team recognizes “this is all connected and part of the same thing.” Yvette Pasqua has a great talk on choosing the right communication medium as you lead your team through change.
7. Light one fire at time.
You are not the fire fighter in your organization…you are the fire starter.
