“Does this ever get easier?”

It’s a question I’ve been asked probably a dozen times by first-time managers, directors, and even VPs.

I’ve watched exceptionally experienced leaders mishandle situations they’ve mastered before. Even run-of-the-mill things like writing OKRs, executive status updates, bootstrapping new projects, and delivering negative feedback. No matter how much experience you collect, you can’t just run on instinct—it will never feel truly “easy” the way riding a bike, touch typing, or other sorts of muscle memory do.

The root cause isn’t that “people are hard,” or even that each level you ascend exposes new challenges. Both are true, but the deeper problem is the sheer breadth of any management1 job.

Most of what you know is cold

Leaders must deal with nigh on thousands of insane situations; I trauma-dumped an entire listicle with 142 of them. Each problem individually isn’t even that complicated, but there’s just so. damn. many. of them! Most leaders already carry the right mental models somewhere, but any given one may go untouched for 6+ months.

Worse, small permutations can completely change the ideal approach. Consider an example: at some point you’ve probably had to alter a peer’s priorities or stop a nearby project that is interfering with one of your own. No big deal—a productive escalation to resolve conflicting priorities is literally the ABCs of management—except you might also be dealing with one of a zillion different complications, including…

• The project in question is someone’s “promo project” so the other manager will defend it with their life to avoid attrition.

• Your boss and their boss are actively feuding over something else entirely, and this escalation will give your enemy ammunition.

• The other project is halfway done, and sunk-cost fallacy is clouding everyone’s judgment.

• Your engineers were wrong about the technical needs here and got you all gassed up about nothing.

…on and on the list goes.

There are some really dark corners—when did you last deal with an export control audit or a coordinated disclosure of a zero-day in your product? As a result, at any given time, probably 70% of the leadership skills you’ve previously mastered have gone stale from disuse.

No matter how experienced and well-read you are, it will feel like flying by the seat of your pants. You’ll be in a meeting with 15 people, the discussion will take a surprise turn, and there won’t be time for a study break—you’ll have 500ms to intercede and say something intelligent. There will always be this vague feeling of “I know I could do this better…”

Mastery requires maintenance

You need to keep renewing and applying key concepts to stay at the top of your game. That’s why I think of leadership skills like soil: it compacts and hardens unless you work it. You can’t endlessly plant new ideas; you need to till the soil to keep the ground workable.

I’m sitting here in the airport reading Alex M. H. Smith’s No Bullsh*t Strategy—this is probably the 18th “strategy” book I’ve read in my career. You would think we’d run out of interesting and novel things to say on the subject by now…and you would be right. It’s a lovely book and earns my recommendation—it just doesn’t say anything I haven’t heard before, and that’s fine. The point of continually re-reading and reflecting on these business books is not to receive novel insight; it’s really about keeping the core patterns alive so they are readily available when you need them.

Then, when a situation pops up at work, the effort to recall what you read and apply it cements the concept permanently: consolidating memory traces and improving recall.

Teaching is even better. When I mentor another leader, I can’t merely recognize the right answer when I see it. I have to reconstruct the model, explain why it works, turn it into steps, answer objections, and watch whether the other person can actually use it. If they never mention the framework again, that’s useful feedback too: perhaps I didn’t understand it as well as I thought, or perhaps I packaged it badly.

Writing this blog is, in part, the same exercise.

This works so well because of the Retrieval Effort Hypothesis, which posits that greater mental effort exerted during retrieval yields stronger, more durable memory retention. The exertion of continuously reading, reflecting, applying, and teaching keeps the framework available the next time you need it.

Early on, you’ll spend a lot of energy trying to climb the skill curve and patch over missing experience rapidly…but at this late stage in my career, I’ve changed my intellectual habits. I’m less concerned with constantly searching for novel ideas because there is plenty of value in encountering an old idea at the right time, thinking about it again, and putting it back into circulation.

Managers have a peculiar problem: it is extraordinarily difficult to know whether you are actually good at managing people.

Your reports generally do what you ask. Your difficult conversations mostly end in agreement. People rarely tell you that your advice is terrible or your communication style is making them miserable. It is tempting to interpret all of this as evidence that you’re pretty good at the job.

Which brings me, naturally, to bowling with small children.

I was babysitting recently, and we decided to go bowling. It was…an experience.

I grabbed a couple of bright pink eight-pound bowling balls off the rack and set up the bumpers. In the first few frames, they were timid, rolling the ball granny-style down the lane. It crept so slowly I wondered if the ball might get stuck. On the ponderous journey down the lane, the ball bounced off the bumpers once or twice and managed to knock down a few pins.

Once the kids realized the bumpers guaranteed no consequences, they got more…spirited…chucking the ball overhand. I winced after every cacophonous crash into the wooden planking.

By frame six, all composure had been lost. I had four overstimulated goblins, and their exuberance was feeding back into itself like an ouroboros fueled by Sprite and screaming.

They were positively launching the ball as hard as they could at the bumpers just to watch it ricochet back and forth. Pins exploded into haphazard split configurations I did not think possible. All hope that any one of them would “learn to bowl” was lost.

As I prayed for the game to end before someone broke something, I realized I had been watching a remarkably accurate simulation of people management.

(I am a sick, sick person and do not belong in polite society.)

The kids thought they were bowling. They weren’t. The bumpers were doing far more of the work than they realized.

Managers have bumpers too.

Weber’s Got a Gun

As the manager of a team, you possess positional authority. That is, you have an innate capacity to influence or compel behavior through rules, rewards, and coercion. It is a form of hard power, distinct from the charismatic authority you derive from your relationships, personality, and ability to win friends and influence others. I’m loosely summarizing Max Weber’s Tripartite Classification of Authority.

Students of modern management theory will tell you they don’t rely on hard power because command-and-control doesn’t work—nobody wants a micromanager! They motivate their teams through autonomy, mastery, and purpose. They cultivate relationships and build deep mental models of their reports to better understand and support their continued growth. Servant leadership and all that jazz. They would attest that most, if not all, of their influence derives from charismatic authority. Why else would they spend all that time getting to know you in 1-1s and reading up on the latest pop-psychology!?

I hate to break it to you, but you’re bowling with bumpers.

That positional authority you supposedly “don’t use” is doing a lot of work behind the scenes to influence behavior. Every radically candid, non-violent, crucial conversation you have that ✨magically💫 ends well owes as much to your formal authority as to your interpersonal skills. It’s actually pretty obvious if one could hear how transparently awkward they sound most of the time!

Delusions of Grandeur

When we attribute our cat-herding success to exceptional empathy, communication acumen, and adroit people-reading, there is a lot of self-deception at play.

The deception begins when we assume that the lack of feedback implies exceptional performance…but that isn’t what it means at all. Your boss rarely observes your day-to-day interactions closely enough to judge them, while your reports have excellent information and terrible incentives to share it.

When was the last time a subordinate vehemently disagreed with you or delivered real, honest, direct feedback? Go on, think hard, I’ll wait.

Most managers cannot think of anything except a few times when someone rizzed them up about “learning so much from them” or some such vacuous blather.

The really severe disagreements and deep cuts I’ve encountered all came from low performers—people who were being actively managed out and whom I had already written off as “just not getting it.” How suspicious that the only negative feedback signals we encounter tend to come from untrusted sources and are easily ignored!

Simply possessing hard power is enough to coerce and to create an echo chamber that reinforces our self-image and confidence in our own superiority. We are all doing the managerial equivalent of hurling bowling balls into the gutter, blissfully unaware of the invisible bumpers that ensure we get a strike.

No Country for Candid Men

I have attempted to “fix” this so many times.

• Directly asking for candid feedback: doesn’t work. It just stresses your reports out, and they inevitably dress up some strength as a faux weakness, like a bad answer to the “What is your greatest weakness?” interview question.

• Carefully self-deprecating to set the tone that you are feedback-oriented: reports will either try to puff you up (“no you’re not like that at all!”) or they will interpret this as a signal you are aware of the issue but can’t/won’t actually improve.

• Anonymous feedback surveys: anything delivered here is usually obfuscated to the point of being inactionable. Just as useful feedback to a report needs specific situations and behaviors (wahoo for SBI), useful feedback to you does too.

• Asking for feedback about extremely specific moments: this one actually sort of works, assuming you follow through on improving. If you don’t, or quietly disregard the feedback, then your reports will stop responding honestly. Moreover, you cannot do this all the time—it gets annoying—and it relies on a rare level of self-awareness to know “I should ask about <this specific interaction>; I’m not sure it went perfectly.”

Beyond your specific choice of tactics, you will deal with employees who are constitutionally unable to be direct. Maybe they are from a “guess” (high-context, indirect feedback) culture. Maybe they gave real feedback to some prior manager who snapped and lashed out, and now they are permanently scarred. Maybe they are in a compromising situation that makes the risk/reward of upward feedback not worth it (e.g., visa sponsorship).

Subordinates who trust you enough to be brutally honest are extremely rare, often cultivated over many months/years of collaboration, and are worth their weight in gold. This is half the reason new leaders import their own cronies from past roles: it can sometimes be the only way to avoid flying completely blind!

Waiting for the Exit Interview

At its core, the real problem is a disrupted and delayed feedback loop—the time between “oopsie I said something insane to my employee” and “something bad happens” can be weeks/months/never. Your inability to connect bad behavior with consequences that come many months later means you’ll never figure out what went wrong or how to improve.

I remember very poignantly a 1:1 where I showed my manager a list of things I had accomplished over the prior week. As one of the uber tech leads for Google Drive, I often got pulled into lots of emergencies and cross-org technical discussions rather than working on “one big thing,” and this week was no different. I had resolved a major production outage, prevented a major security vulnerability from shipping in Gemini, unblocked the (now launched) Help Me Organize feature, and solved a we’re-totally-fucked, extinction-level bug impacting enterprise users. After walking through all this, she said, “Some feedback for you: this is great work, but I can’t really reward you for any of this. You need to work on more visible priorities.”

And that, my friends, was the beginning of the end. I had saved our (her) ass four times that week and wasn’t expecting anything for it beyond “thanks, carry on”—and got something very different instead. I would exit the company five months later.

I showed no distress or dissent in the moment; in fact, I agreed for a litany of reasons:

• As a key power player, there was an enormous opportunity cost to not working on the major revenue drivers.

• We needed to build a deeper bench of tech leads and couldn’t rely on the same two people all the time. The only way to do that is to trust them and let them fail if need be.

• I am no stranger to the politics required to land senior promos as a former manager of managers (…of managers of managers of managers—kill me), and it was in our collective interest to get more Drive leads elected into upper leadership.

From her side of the table, the conversation probably looked like a successful coaching interaction. To this day, she probably has no idea it was that 30-second discussion that started the domino rally of my exit. It wasn’t an obvious, bombastic disagreement… but as someone who believes deeply in serving our users above all else, it was clear our values weren’t fully aligned. As a result, when a recruiter pinged a couple months later, I was receptive and took the call. The folks on the other end were very persuasive, and the rest is history.

That is the fundamental problem with managerial feedback loops. You can say something damaging on Tuesday, receive nothing but apparent agreement on Wednesday, and discover six months later that the person has quit. By then, there may be no observable connection between cause and effect—and quite possibly no feedback at all.

Retracting the Bumpers

If you care at all about actually being good at your job (or, IDK, a good person even), your prime directive is to figure out a working feedback loop: a way to know in real time whether you’re truly connecting with and influencing your reports or just straight up coercing them.

This is hard. As I mentioned above, you can carefully curate your direct reports to prioritize bluntness and mutual trust, but that isn’t exactly scalable. Also, people won’t necessarily jump ship on your schedule (damn you, Matt). Turning new reports, aka strangers, into close confidants is a labor of love that takes 6-12 months of concerted effort and a lot of luck.

At an absolute minimum, you need a few trusted truth-tellers: individual contributors others confide in, but willing to share what they hear with you. This has worked absolute wonders for me no matter how high up in the org I get. Even now, I have regular 1:1s with a couple hand-picked engineers three layers down! I know what you’re thinking: “snitches get stitches,” but there is a way to approach this that is supportive rather than tattling. There’s a big difference between “Sally thinks you’re a smelly loser” and “Sally interpreted what was shared at the all-hands differently than you intended and it really demotivated her.”

Barring that, there is always the nuclear option. Give up your hard power. Go back to being an IC.

Even a Staff/Principal IC only has a modicum of positional authority since you no longer sign anyone’s paycheck. Even better, the expectation that you have Big Huge Org/Company-wide Impact™ means you’ll be forced to influence dozens of peers who have no incentive to listen to you.

As an IC, the bumpers come down. If your communication is confusing, people remain confused. If your proposal is unpersuasive, nobody adopts it. If people don’t trust your judgment, they stop involving you. The failures that positional authority once concealed become observable again.

• If you’re going to lots of meetings and dispensing lots of advice, but none of your ideas ever leave the “concept” phase, then you’re probably failing.

• If others are taking your ideas and running with them, or managers are throwing resources at you, or you find yourself getting the green light to start more projects than you have time for, then you’re probably succeeding.

This is another reason I adore the engineer/manager pendulum and have been a practitioner for going on 18 years—nothing like returning to the dojo and honing your skills.

Whether you’re an IC or a manager, a reliable signal is how often peers come to you unprompted for advice (and whether they follow up for yet more advice afterward). Whether it’s technical assistance, help with a cantankerous manager, formal mentoring, or one-off career advice, it’s all a sign that you’re credible. You simply cannot fake this level of trust. Bonus points if they work somewhere else because then there is even less incentive to stroke your ego.

If you want to know whether people follow you, first make sure they are free not to.

You get to the room 5 minutes early…because you always get there 5 minutes early. The lead chair is already taken by a laptop, its owner still in the hallway laughing at something you can’t hear. You take the chair with the broken tilt lock and will spend the rest of the meeting fighting to maintain some semblance of good posture—a metaphor for what’s to come.

Sarah pulls open the roadmap. “So we’re thinking Q3 for the migration,” she says, and you notice the we—how it includes you the way a photograph includes its background.

It’s already been decided, you can tell by the confidence of the performance: no questioning inflections of the voice, no pauses, slides not even on screen long enough to read. Worse, you can tell everyone else has already heard this by how they are barely paying attention, reading email.

You have a concern. You raised it in Slack, in the PRD, in the hallway on Tuesday. Each time you have tried a different phrasing: “maybe they just don’t understand what I’m saying,” you think. You raise it again now, fourth time’s a charm: “The auth service isn’t going to hold up under—”

“Totally hear that.” She’s already typing. “Let’s take it offline.” The VP of Product is here and, in the presence of true nobility, the help are not permitted to speak unless spoken to. You have taken a dozen things offline in recent memory, and none of them have ever been discussed.

Sarah barrels on. A table showing deliverables is flashed with a column for the owner. The list is exacting and labyrinthian, and it’s the first time you’re seeing it. “So, here’s what Eng is going to deliver by Q3.” What Eng—not your name, just the role, the livery, the uniform that will go on being worn long after whoever’s currently inside it has been quietly replaced—is going to deliver, the verb servants get. You deliver a tray. You deliver a package. You deliver a message you didn’t write.

Top of the hour, the meeting wraps. Everyone looks at you expectantly. You say “sounds good” because the personal cost of dissent is too high. You mean it, almost. You have become very good at meaning things almost.

Are you the tail wagging the dog or the dog wagging the tail?

If you’ve spent any time around FAANG, the story above probably feels like a bizarre role reversal. At top tech firms, engineering runs the show. The general manager of any given product line is on the engineering ladder and was promoted up from the SWE ranks. Budgetary control and binding decision-making authority rest entirely with SWE leaders. PMs in this world must beg, borrow, and steal any scrap of authority they can get their hands on. The influence they wield comes from relationships… or, in rare cases, pure rational authority, wherein the product leader is simply smarter than their engineering counterpart and can win most arguments.

The engineering-product partnership is not equal. Not even a little bit. I got my first taste of what it feels like to be on the other side of this when I switched into finance from big tech.

At the low- and mid-tier of the finance world, your business analysts and product managers rule the roost (the PM:Eng ratios at these companies are completely fucked, like 1:3). For the first time in my life, I was sitting in executive decision-making forums and felt vestigial. It was incredibly clear the room had only a passing interest in my opinion on any given matter—that my input would be taken under advisement but that I had no role beyond consultation. Once an analyst or PM made a decision, my 100% compliance and acquiescence were assumed. Formal power doesn’t change this. As a VP, product counterparts came seeking my approval but never my input. Any question or feedback I offered was treated as a puzzle to be solved and then set aside so the original plan could proceed unmodified. My role was reduced to a headcount vending machine and a name that could be wielded like a weapon to force my team’s compliance.

Even within my narrow lane of ownership (technology), if I made a decision on my own about purely engineering matters like architecture, PMs would take great umbrage with the fact I had not sought their consent and alignment. Complex and emotionally charged interactions would unfold where I would be expected to justify myself—the PM’s right to oversight and control over all matters affecting “their product” was assumed and absolute. Oh, and by the way, literally nothing was safe from PM control; we also had “platform PMs” who owned the internal engineering systems.

“Holy shit, this is horrible,” I thought to myself. And then it dawned on me, “Is this how my product counterparts felt back at Google?” Yep. 100%. This was a very poignant maybe-we’re-the-baddies moment.

Whether it’s product dominating engineering or engineering dominating product, I have never witnessed a truly equal partnership. I know they exist somewhere, but it’s the equivalent of finding a four-leaf clover…in the middle of a hurricane…wearing a blindfold.

Mutually Assured Destruction

XFN doesn’t stand for “cross-functional,” it stands for eXtremely Fucking Nonsensical.

Like, here is this person who I rely on for substantially all of my most critical job responsibilities through daily, verging-on-hourly interactions… and despite that, 90% of these relationships are the most corrosive, disorienting, and baggage-laden in your life.

• The PM’s career progression is almost entirely decided by what the EM ships, how quickly, and how well the system actually works. Effectively, none of these things are in the PM’s control.

• The EM’s career progression is almost entirely decided by what opportunities the PM identifies, whether those materialize as “business impact” once delivered, and whether the Eng Dir/VP actually give a shit. Effectively, none of these things are in the EM’s control.

• Each party has a distinct management chain with pairwise product-engineering relationships laddered all the way up the org chart…each in various states of disrepair leading to conflicting directives and proxy wars.

• Neither party can succeed without the other, but behind closed doors, both would tell you emphatically that the other side is completely useless and obstructive and we would all be better off without them.

• AI has gifted us a new battleground to play out this enmity, with PMs chucking AI slop PRDs over the wall and EMs vibe coding creaky piles of shit that barely work. Attention to detail has not just exited the building; it has boarded a plane to another continent and is halfway across the Atlantic.

• There’s no clear decision maker…on anything. That PM might have 10 years of IC SWE experience and a CS PhD and will challenge your shitty architecture decisions. That EM might have founded 2 startups with successful exits and will veto a tepid, limp-wristed excuse for a product strategy. Try to escalate, and the next 3 layers of management have the same problem. Your nearest shared node in the org chart is some SVP who is so disconnected from the details you might as well roll a d20 to make the decision.

I know this characterizes the relationship as exclusively hostile, but that is basically the default: any slight misalignment whatsoever will present to either party as obstructing one from doing their job. The whole thing can be summarized as two people holding each other at gunpoint screaming, “Move and I’ll blow your fuckin’ face off!”

Someone is reading this thinking, “No! My XFN relationships are great, and we work so well together! This guy is just a Bad Person.” I am, yes, but also I’m glad you’ve figured out how to cope; congratulations—but that’s all it is: cope. I too can figure out how to keep the wild dog from biting my face off, but wait a minute—why is there a wild dog in the middle of the cubicle farm biting faces off in the first place??

Peeling the Onion

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 EM and a PM that co-own the same objectives don’t actually share a common ancestor until you reach the SVP or the CEO.

Each layer will have a different political reality, and it will directly shape your quality of life. For example, when I worked on Google Drive, our product director was literal furniture, and everyone (PMs included) knew the only thing that mattered was convincing the Eng director….but that didn’t extend to the VP level. The Product VP and Eng VP had an effective, loving, co-equal partnership, and you had to win over both. Go up one more layer and the Eng SVP was the only person who mattered. Add in sister orgs and the confusion multiplied. There were product leads in these other orgs so powerful they could upend our entire roadmap with a single email, while their Eng counterparts were basically sitting in the corner eating glue.

Getting anything done meant navigating multiple layers of people who mostly hated each other. It’s like peeling an onion. The more layers you peel, the worse it stinks, and now for some reason you’re crying.

You might think, “That’s fine, I can just talk to my partner, and I’m sure we can work things out,” but the reality of working for different managers will thwart you. 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?

This is why cross-functional relationships are characterized by so much manipulation. The distinction between influence and manipulation is that the latter is done without the other person’s interests at heart. Your career advancement at the expense of your peer’s, collective truth-seeking, or what’s right for the customer is the very definition of “not in their interest.” We’re so good at lying to ourselves that this doesn’t even cross our minds; we equate what will get us rewarded with what’s best for everyone.

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/whatever. 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.

Til Death Do You Part

But to be fully couched within the comfort of a friend is a mode existence with severe implications. To please you perfectly she must understand you perfectly. Thus you cannot defy her expectations or escape her reach. Her benevolence has circumscribed you, and your life’s achievements will not reach beyond the map she has drawn.

—Jonathan Blow’s Braid

How strange it is that this person is basically your work husband/wife—whose abilities and compatibility with you will fully determine the extent of your accomplishments—and yet you have no choice in the matter?

Influencing this is a quintessential part of cross-functional hell.

My myriad bosses over the years have never failed to bring up the topic, “How is <some random PM> doing?” or “What do you think of <some bozo>?” where the context clues and tone make the subtext incredibly clear: “I want to get this person replaced and need ammo.” In a previous job, every 1:1 was basically a dirt-gathering session, and it was an open secret that when a PM got fired, it was because the Eng director wanted them gone. The crazy thing? That was probably rightly so, as otherwise we would have been sabotaged by deadweight.

I was blissfully unaware of these backchannels as a line manager, but once I became a manager-of-managers, that changed. Literally every single 1:1 with my product counterpart began with the weekly Airing of Grievances where I would hear about insane shit my reports said or some random engineer who—according to the PM’s exceptional technical judgment 🙄—seems to be “moving too slow.” I would, of course, return the favor by putting on blast the latest coked-up PRDs and product reviews that were total shit shows. My role shifted from building products to playing recess monitor, and I had no choice in the matter: abdicating this responsibility meant leaving my org’s success to chance.

Any leader worth their salt has to master the skill of backseat managing their cross-functional partner’s hiring and firing decisions. I’m sorry to burst your bubble. This is happening quite literally nonstop at every single layer of the org chart. Someone, somewhere is gossiping about you and it is directly and irrevocably altering the trajectory of your career. You cannot opt to ignore this if you ever want to be anything more than a low-level IC.

You’re being hired into a marriage where the average case scenario is you will at some point get divorced, and the custody battle over the kids (aka who gets to stay on the team and who gets reorged to Timbuktu) will permanently traumatize you.

In an alternate universe, product and engineering leads would be hired as couples. A matched set that you already know works well together and has established strong working habits, compatible worldviews, and knows how to have tough conversations. But no, we live in a world where hiring managers try to play matchmaker.

Breaking the Nash Equilibrium

So if you “get what you get”, how do you make things work? How do you navigate the criss-crossing layers of cross-functional dysfunction with their conflicting priorities, mismatched incentives, and mutually assured destruction?

As much as I’ve characterized this as a futile prisoner’s dilemma, I’ve had legitimately wonderful cross-functional relationships… relationships where 1+1 actually makes 3 because we amplified each other’s strengths, covered our weaknesses, and had unbreakable trust, which meant disagreement was safe and productive (miss you, Ryan, Hari, Liz, Andrew, Luke…may we cross paths again someday).

Getting there involves some luck—not much you can do with a totally incompatible personality, ethics, or life priorities. Still, assuming none of that gets in the way, I’ve learned a few things over the years which directly contribute to building the ideal product-engineering partnership.

Do what you say and say what you mean.

This one is pretty simple. Actually follow through on your promises and never use doublespeak. If you say you’ll prepare a report by Tuesday, then get it done by Tuesday and make sure it’s high quality. The bar is so low it’s subterranean, and this alone will differentiate you from your peers. In roles like product that are dependent on others to do a substantial amount of the actual building, you can quickly become everyone’s favorite go-to collaborator. In the early days of the relationship, 100% consistent reliability will open the door to deeper trust.

Furthermore, never mislead, selectively omit facts, or cover up what you really think. You are trying to demonstrate with your deeds that you are totally above board and trustworthy. This also means challenging directly and having some uncomfortable conversations, but believe me when I tell you that beats being nice all the time, covering up what you really think, and then surprising your partner at the last minute. I will take a disagreeable person who displays trustworthy competence and integrity over a smiling imbecile that just wants everyone to “feel good.”

Day Long Jam Session

Take your XFN partner for a day-long 1:1 offsite. I usually attach these to the formation of a new team, a reorg, or the initiation of a multi-quarter initiative. The agenda is fairly flexible and contextual, but it’s always built around deep diving and aligning on key principles, decisions, and actions for whatever Big Thing you’re about to embark on together. To make things more exciting, I also plan a couple “over the top” exercises like card sorting or journey mapping…design-sprint-type stuff. These activities rarely happen, either because they are considered too time-intensive or because the team is so unfamiliar with them that they would never work at scale. Still, the intimate 1:1 environment is perfect for working around all of the above. Throw in a long lunch break somewhere nice and a couple field trips to top it off (I love taking people to my bougie coffee house where they can try single-origin pourover for the first time).

Something really magical happens when the two of you get away from the bustle and the prying eyes, and with enough time to let conversations expand to fill the time they need rather than artificial 30-minute blocks—when you can drop your polished professional persona, the need to maintain consistency with past proclamations, and the demand that every meeting resolve productively to a set of decisions and action items. Real vulnerability and intimacy can occur, and with them, myriad opportunities to show you can be trusted with fragile ideas, self-doubts, and all the messy stuff we sweep under the rug when doing battle in the Corporate Coliseum. Each of you will get to know how the other person thinks, what they value, their fears, and their aspirations.

No one I know does this. I always get excuses like “We’re too busy,” or “I’m not sure I’m comfortable inviting my product partner to something like that,” or “OMG what would we even talk about all day?” But this little trick has a 100% success rate at taking relationships to the next level. If I ever found myself in an environment where something like this was impossible, or my product partner wasn’t willing to play ball, I would seriously re-evaluate if that was the place for me and probably leave shortly thereafter—it’s that essential to establishing bidirectional trust and alignment.

Word Vomit

You ever have something important to say but aren’t quite sure how to phrase it? Maybe you’re worried about implying implications and hurting the other person’s feelings…so you stay quiet. Important disagreements and frictions go unresolved, and the psychic burden of all those loose ends and quiet resentments builds until one of you bursts.

To solve this, the two of you agree to create a container—a safe space to air your concerns—where the other person agrees to hold off on their immediate reaction, not read too much into the exact phrasing, and listen to understand and collaboratively sort out what you really mean. It’s a bidirectional acknowledgment that “I don’t know what I’m trying to say, but I need to say something; let’s figure it out together,” and for both parties to explicitly probe and test conclusions/implications rather than assuming the meaning you inferred was the intended one.

When one of these moments arises, you trigger the container with a key phrase. Known for my elegance and way with words, I always use “I need to word vomit.” If the other person acknowledges, you proceed. If they don’t accept the invitation, then you need to wait for a better time—maybe tempers have flared, and they aren’t in a productive headspace.

If this sounds very intimate, that’s because it is. You are applying a technique straight out of couples counseling and need an extreme level of comfort with your XFN counterparts. As a result, this technique may be out of reach for many of you. That’s especially so if you pair up with 5+ XFN partners—Dunbar’s Number guarantees you won’t be able to maintain enough of these deep relationships. Every interaction you have will be shallow and transactional. It’s why hyper matrixed environments are truly, deeply, and irrevocably structurally fucked.1

Disagree in Private, Support in Public

Never disagree with your XFN partner in group settings—save the debate for your 1:1.

That doesn’t mean you have to go out of your way to offer unequivocal support and endorsement—if you truly disagree (maybe they surprised you with a hot take mid-meeting), then stay quiet or talk around the issue. Anything but challenging them directly in front of the group.

A public disagreement can be disastrous. At an individual level, it triggers major status and relatedness threats that trigger fight-or-flight responses. The group may include their superiors or your subordinates, which puts both their professional standing and credibility at risk. Worse, your subordinates will pick up on the misalignment and create downstream chaos.

Look, I’ll be the first to say this is the path of cowards and anyone who can’t handle public disagreement is weak, their bloodline is weak, and they will not survive the winter. Unfortunately, there are, like…10? companies on Earth where the culture will support this sort of behavior. Unless you work at Bridgewater Associates or some shit, this is not a winning strategy.

Influence over Control

This one is from Unlocking Leadership Mindtraps. It’s gooey, HBR-style fan fiction, but god I wish I read this much, much sooner in my career.

Ask yourself not “what do I control” but rather “what can I influence?” Control is an illusion. Even if you had zero XFN partners and absolute authority within your domain, you are limited by the extent to which you can program the meat machinery that constitutes your team. More power changes nothing—new CEOs frequently express surprise at how little control they have. They climb all the way to the top to find out there are always more stakeholders (the board, markets, customers) and more constraints (resources, people, culture).

Humans have an instinct to seek control over their immediate environment for safety, which helps explain why the desire to control is so strong. However, attempts to directly manage complex, interconnected outcomes such as company culture fail because these systems emerge naturally rather than by following orders. Enforcing strict rules often results in unintended consequences and increased stress when things go awry.

Especially once you mix in a dozen XFN partners, you must shift from dictating specific outcomes to providing direction. Then ask yourself what conditions or support you can create to help that vision come to pass. You will have to deal with implicit limits that come with this mindset. Some things (and people) are outside your realistic influence. All you can do is nudge the system towards a slightly more optimal course one day at a time.

Ask “What Do You Need From Me?”

In The Effective Executive, Peter Drucker points out that in knowledge work, a specialist’s output is basically useless until someone else picks it up—your job isn’t done when you close the task, but once you figure out who touches it next and what they actually need to make it work.

Try asking your PM, “What do you need from me, in what form, and by when, to do your job well?” in your next 1:1. They will completely short-circuit because nobody thinks like this. XFN relationships usually flow the exact opposite direction (“what do you owe me? why is this late? why do you suck so bad?”)

This flows in both directions, too—you have to shift how you view your coworkers and start asking what they are genuinely great at and how you can use that contribution to maximum effect.

Most companies are terrible at this; org charts and rigid job ladders dictate what someone does day-to-day. That’s how a brilliant engineer can end up wasting half their week writing status updates just because that’s what “Tech Lead” has meant historically.

If you can do both things—ask what people genuinely need from you, and deliberately figure out how to leverage their contributions—your relationship will stop being adversarial by default. You will achieve what no amount of “alignment meetings” or process tweaks ever will: real honest-to-god collaboration.

Liberté, égalité, fraternité

Dealing with matrixed orgs and cross-functional partners is awful. Why do you think “builders” (a mythical chimera of Engineer+PM+Designer+PMM all rolled into one) or going “founder mode” (ignoring all boundaries and just doing everything yourself) have captured the zeitgeist so completely? This shit sucks so bad that even these Twitter Thought Leader Acid Trips sound more appealing.

In 2026, things are only getting worse as now there is a whole layer of anxiety about how AI will enable “Engineers to reclaim the PMs job” or “PMs to replace Engineers” (let’s not even talk about designers and researchers; people are 100% convinced those job families are donezo, which is the stupidest shit I’ve ever heard). Things were already hard enough, but now it truly is a zero-sum game—someone is leaving in a body bag.

I think we’ll all find out real quick that it’s actually very hard to be an excellent strategist, product designer, marketer, backend developer, and SRE all at once. Especially not when quality/craft increasingly matter for winning in the market. In the (admittedly rare) times in my career when our XFN cohort was able to move in unison towards a shared goal, the things we built were truly incredible—among the proudest accomplishments of my career.

The tips shared here—reliability, radical honesty, maintaining a shared front, creating containers for disagreement, letting go of control, and playing to mutual strengths—can help you recreate those winning environments, but there are limits. You can’t just “be super agreeable” and suddenly expect everything to work out. There will be cultures and people you can’t work with, and rather than make everyone suffer, you need to raise your hand and opt out. When interviewing for a new job, you must also demand to interview your XFN partners and be brutally honest with yourself: do you want to interact with these people every day for the rest of your career? This is even more important than assessing whether you vibe with your manager and your team.

Have fun out there and play nice everybody 😊

It’s been a particularly existential week.

I’ve had not 1, not 2, but 3 separate people call me, spiraling and thinking about leaving their careers. Google just laid off more friends. The Algorithm has decided to jam-pack my feed with posts about quitting, changing careers, reinventing yourself, and how the “corporate deal” has changed. I’ve written about the epidemic of professional ennui before, but it’s only getting worse. The age of the Millennial Midlife Crisis is upon us.

On top of that, on Sunday I scattered my Mom’s ashes—talk about existential. It was a beautiful ceremony: a field of wildflowers next to an alpine lake high in the Rockies. This has been 7 years in the making and brought me a peace I didn’t know I needed. When confronting death, you really start to think about purpose: how you’re spending time, legacy, what’s really worth doing when it all ends the same way—ashes to ashes, dust to dust. Sitting by the lakeshore, I wrote her one final letter. Much was said, but at the end I committed to using the gifts she gave me to live fully on my own terms and do something that makes her proud. The clock is ticking.

You might think, given the context, that I’m all aboard the “quit your job and surrender to where life takes you” camp. Hell, I have entire posts that talk about passion.

Nope. Life is a little bit more nuanced than “corporate = drudgery” and “startup = freedom.” I’m actually deeply worried the feed is gaslighting all of us into feeling like we’ve made a deal with the devil, selling our souls for a salary + benefits, and that having a bad day at work or a stupid coworker should be cause for full-blown existential depression.

Here’s where they get it wrong, what is really going on, and what to do about it.

The deal hasn’t actually changed.

The folksy pastiche about staying at the same company for 40 years and retiring with a gold Rolex is just a bedtime story. I have literally known zero people for whom this is how it worked. Not my parents, not even my grandparents. For all of them, life was a continual, clawing-tooth-and-nail climb out of poverty full of curveballs, mid-life pivots, shitty employers, broken trust, and everything else you can think of. I’m sure someone had a happy ending at some point, but people also win the lottery…don’t hold your breath.

Beyond this, some feel betrayed because ascendancy up the corporate ladder is seen as an inevitability if not a guarantee. All one needs to do is show up, do a good job, and, every few years, you’ll be offered a promotion with more money and a bigger team. lol what? There are only so many manager/director/VP jobs. If you want to lead an org of 200, you are, by definition, occupying a 1-in-200 role. You must enter the coliseum and brutally murder 199 other combatants armed only with a PowerPoint and a Kanban board. The IC ladder is no different—a company only needs so many principal engineers.

You have always had to outperform and outcompete your peers for progression. Layoffs have always been a thing and have occurred at remarkably consistent rates for decades. Be excellent or perish.

Productivity expectations have always increased

Speaking of things that haven’t changed: new technology has always caused an increase in baseline productivity expectations, repurposing of outmoded labor, and exhortations to “adopt or perish.” It’s been the same for the last 10 technological revolutions.

This has happened no less than 5 times within software engineering alone, and the industry hasn’t been around that long:

1. Punch Cards to Terminals

2. Assembly to Compilers

3. Line Editors to IDEs

4. Desktop to Web

5. Humans to Agents

AI is not some rare, once-in-a-lifetime, extinction-level event. It’s just the first paradigm shift you’ve had to deal with since becoming a paid, working professional. That does not imply such changes are easy or simple—not by a long shot—but they are de rigueur when careers are 40+ years long.

The people I know who are actually excited are those who have been through one of these transitions before…basically elder Millennials and Gen X. I seriously wonder if the death of junior engineering roles has more to do with this effect than any conviction that only seniors will know how to walk the AI dog.

The deal has pretty sweet kickbacks.

Division of Labor

Corporations enable us to divide-and-conquer the work needed to, ya know, make actual money. Don’t like outbound sales? Great! You don’t have to do it. Don’t like dealing with customer support tickets? Pass. Pandas scares you a little? Make the data weenies deal with it.

If you want to narrowly specialize in performance optimization for assembly subroutines in low-level kernel code, you can do so and probably have a mid-six-figures job doing it. I have worked with engineers who can’t write a single coherent sentence of English. Putting them in front of a customer would be like conducting a CIA psyop…on the customer. And yet, they are marvelously effective technical contributors with thriving careers rather than burdens of the state.

Some people don’t like confining themselves to a single box their whole life, and that’s fine! The structural rigidity of BigCo can be a virtue in disguise. Ladder changes and job rotations allow you to try out entirely new jobs/careers without having to go back to school or break into another field. All the better that it’s in the big leagues with experienced mentors readily available, and not just playing pretend at an internship or as a “side hustle” (shudder).

Big goals demand big teams

It’s certainly possible for a small, nimble team to achieve great things. One person can change the world. But it’s also true that some things require a large group of people cooperating, no ifs, ands, or buts.

A planet-scale SaaS company will operate in thousands of jurisdictions, negotiating deals across the globe with dozens of data center and network infrastructure operators, and needs a multicultural go-to-market team capable of acquiring customers across segments and regions faster than they churn. Get too big, and regulators will slow you to a crawl (the EU’s DMA and Germany’s FCO anyone?)

Every company started somewhere; technically, you can iteratively build your way towards becoming the next Google…but that’s easily a decade+ of effort with no guarantees. Meanwhile, if you want to make a difference in the lives of billions, you can join a corporation that already has the teams, structures, capital, and customers in place and be living your dream by this time next week.

An engine of upward mobility

The American Corporation is an amazing engine for social mobility, and in an age where big tech is at the top of the corporate heap, nothing comes close to a FAANG job in its ability to lift individuals out of poverty and set them on a path to lifetime security and abundance.

I know new grads have it rough right now, but I can’t stress enough how much of a historical oddity it is that one can make such huge leaps in a single generation.

I come from a family of blue-collar hourly wage laborers with nary a college degree to be found. I was literally homeless for part of my childhood. By modern professional standards, I was a hick with a keyboard. Now, on the other side of undergrad + a pretty brief corporate grind, I am fully post-economic. I get invited to donor galas alongside Fortune 500 CEOs. I know which fork to use in a formal place setting and can tie a tie without a YouTube video. I even own a bidet. Incredible.

Brain Trust…assemble!

The mobility on offer extends beyond wealth generation. The best corporations have fastidiously curated their talent, and you will be surrounded by a veritable buffet of interesting people: Ivy League grads, eccentric geniuses, silver spoon elites, international talent from every corner of the Earth, connoisseurs of esoteric hobbies, and everything in between. At a minimum, they’ll be ambitious and conscientious, which counts for something. I have worked with both Turing Award and Fields Medal laureates, the sort of people I would have never met in a zillion years otherwise.

Even if at times you feel surrounded by smiling imbeciles in your current job, I promise the grass isn’t always greener on the other side. Being an early-stage or even solo founder is a very isolating experience—you have no one to talk to while your self-worth is continually punched in the gut. Once success strikes and you start hiring a staff, there won’t be much money to go after The Greats. At my last startup, I spent years wading through a sea of contract-to-hire oafs—water, water everywhere but not a drop to drink.

Speaking of who you surround yourself with, your immediate colleagues constitute a highly selective group implicitly filtered for similar intellectual interests, abilities, socialization habits, and pastimes.

For example, when you join Big Tech, you enter Nerd Heaven. No matter what your special interest or autistic hyperfixation du jour, there are easily hundreds of people at work who share it. Dungeons and Dragons, 3D printing, anime, particle physics, you name it. For folks who felt out of place growing up, it’s often the first time they felt “at home” anywhere.

More than happenstance is driving this: engagement in almost all forms of civic life has declined steadily since the 1960s. Voter turnout, attendance at town halls and school meetings, religious practice, membership in civic organizations like the PTA, labor unions, the Elks Club, and even informal socializing such as having neighbors over for dinner parties or playing cards. It’s all declined.

The need didn’t go away—it’s encoded in our very biology to seek tight-knit social groups. If your neighbors don’t know your name, your family’s a plane ride away, and the Elks lodge shut down in 2009, then the people you eat lunch with five days a week, who’ve watched your kid grow up over Slack, who show up when your parent dies, are your community1.

For many, their place of employment is the only community center left standing.

Alienation in the workplace

I never thought I’d defend corporate life so vigorously 🙃

I’ve experienced my fair share of disillusionment. Political infighting, ladder-climbing psychos, backstabbers, one actual officially diagnosed sociopath, 5-year-long projects that were utterly pointless, outright discrimination/sexism/ageism, an endless string of unforced errors, empty suits, rampant coasting, you name it.

None of it is endemic to big companies, so I’m usually screaming inside my head, “Really people?! Do you want things to be bad? Do you enjoy working like this?” I deeply believe in respecting the opportunity, so the constant shrugging of shoulders and faux-charming conceits “what do you want me to do about it?” send me into apoplectic rage.

I’ll still go on record and say it’s worth it—that there’s a version of BigCo that doesn’t have to be mind-numbing and soul-destroying. It could even be…great.

That said, I don’t think we’d be seeing such a wildfire of depression, quitting, disenfranchisement, and corresponding think pieces if there wasn’t something going wrong. So what is it about these jobs that is just so distinctly unfulfilling?

The answer can be found in Self Determination Theory.

No Autonomy, Accountability Theatre

The median corporation is really just a gigantic machine for avoidance of accountability.

Nearly every meaningful decision is turned into a “group decision”: quarterly planning, hiring committees, architecture review boards, code reviews, design crits, etc. Go figure dogshit leaders can never be fired; it is frankly trivial to launder bad calls as either a blameless consensus or to create so much fog of war you can’t even see your hand in front of your face.

So long as you follow the standard process and do all the reviews, nothing can ever come back and bite you. Likewise, this very same mechanism makes leaders extremely gunshy about exceptions because an exception carries a name—it sticks out and demands consequences if proven wrong.

So even when an obvious decision is needed for the good of the business, it won’t happen. You’ll get sent to prepare a mountain of slide decks and go through 15 rounds of review while customers suffer and projects fail, all so your boss can CYA.

More than just a means of implementing capital punishment, accountability is also the spice that makes our labor feel worth it…like our existence has real import and consequences. When you alone can make a decision that materially changes the course of a team, you feel the burden and weight of responsibility…but the good kind. More “weighted blanket” than “Sisyphean boulder”—a delicious nectar that is one part self-worth and one part self-efficacy (“I matter, I’m so good at this someone trusts me”).

Absent this level of responsibility, everything feels pointless.

No Relatedness, Surrounded by Strangers

I know I talked a big game about corporations creating like-minded communities and a sense of belonging…but you can also find yourself surrounded by people you do not like one bit.

1. Not all firms excel at creating culture and imbuing their members with an identity. In the absence of a clear mission/purpose and real social bonding, all that’s left is a brutal, animalistic survival of the fittest.

2. Even when the company does succeed at establishing a strong and distinct culture, did you choose your employer wisely? Does it reflect your own interests and values? We often betray ourselves and “act the part” to get a job, not realizing we’ll have to maintain the charade forever.

3. The culture shifts over time, especially when an industry or company matures into a “prestige job” (think: doctor, lawyer, and now, software engineer); you start to see more people showing up exclusively for the clout and the paycheck. They lack any passion for the work, and will hold their nose, opting out of the culture entirely, leaving you surrounded by fakey fakers.

This can literally trigger your fight-or-flight response. Spending half your waking hours with maxed-out anxiety is bad, mmmkay?

Even when the social dynamics are going alright, you’re not out of the woods—be on the lookout for contempt loops.

For years I misdiagnosed my own frustration as an authority problem. More scope, 1 more title, 1 more direct report, and surely the friction would go away. It never did, because the actual problem was values mismatch. I have a strong conviction for intellectual honesty: say what you mean and do what you say; candor is non-negotiable, politeness is optional. Meanwhile, in any large org, communication isn’t optimized for truth; it’s optimized for consensus—hedges, “let’s take this offline,” six-paragraph emails that bury a one-sentence decision under padding.

My values put me in a permanent minority position. Showing up daily to a conversation everyone else is having in code, watching a decision that should take 5 minutes get slow-walked through 3 weeks of flowery non-answers, and having to choose between violating your values or sticking out. This constant tug of self-betrayals is what’s known as egodystonia. It creates a doom loop with an inevitable outcome:

• A values mismatch means you can never fully sublimate your ego into the group, because sublimation requires believing the group’s norms are correct.

• That gap curdles into contempt—first for the mealy-mouthed email, then the person who wrote it, then the whole culture that rewards vagueness.

• Contempt doesn’t stay hidden. It leaks out as behavior: you say the blunt thing in the meeting everyone else was tiptoeing around, you reply-all with the direct version of what someone spent a paragraph dressing up, you stop RSVPing to the “quick sync” that’s really just a venue for softening bad news.

• That behavior marks you as blunt and difficult. The tribe—the one thing that was making the rest of BigCo bearable—starts closing ranks. Social rejection turns into yet more contempt and the loop begins again.

There’s no equilibrium here. Just rising pressure between how you believe people should act and how you’re expected to, until something gives: you get pushed out, you quit, or you spend the next decade sanding down the very traits that make you good at what you do.

No Mastery, Cargo Cult Behavior

Let’s talk about the actual work itself. Not in abstract—think very precisely about the various microtasks and actions that compose your day. Everyone wants to be good at what they spend their time on—to feel mastery and with it a sense of self-determination.

To do that, you start out by observing what other, successful people are doing and reason that if you do the same, good things will happen.

At first it’s just acculturation to corporate life. For example, you learn that there are certain phrases and ways of speaking which instantly set people at ease and give you some amount of influence. I remember my boss at Two Sigma uttering the phrase “let me lay out a strawman for next steps” as a preface to basically telling a room of peers/more senior people what to do… and they actually listened. I started using the phrase myself, and it just kept working. Magic.

You keep going; soon much of how you approach the job is based on mimesis rather than parthenogenesis:

• Every new project that crosses your desk gets a PRD, a design doc, and a work breakdown structure…even when it’s straightforward.

• Every status update gets sterilized to only good news. Anything going wrong gets compressed into an optimistic sound bite about “following up.”

• Every meeting gets a running doc, action items with named owners and due dates, and a “parking lot” section for future recurrences.

When you break into management, the number of things you have to do quadruples, and each has a typical approach or standard framework practiced by 99% of your peers:

• The team runs off 2-week sprints replete with sprint planning, retrospectives, and story points.

• You publish a team newsletter because “visibility” is a nuclear arms race.

• Every strategy gets flattened into 3 OKRs and a handful of suspiciously tidy KPIs.

Eventually, you’ve mastered the dance steps of leadership. Your slide decks are perfect, your OKRs pristine, your KPIs only go up, and you can deliver a standard stump speech for everything from selling a new hire to delivering a PIP to explaining your strategy.

And yet, you’re stuck. Every single cycle, the same story: meets expectations, good work, keep going.

The problem is that while you can perform the dance, you can’t actually say why you’re doing any of it, or why those particular actions are fit to task or particularly effective for creating results. You are subconsciously evaluating yourself by how much you sound, look, and act like other managers, rather than by how well you deliver actual, impactful business results. Bezos warns of this in his 2016 letter to shareholders, calling it management by proxy.

We keep building wooden planes, but the promotions do not come.

You will go through the motions of performing these actions completely disconnected from the underlying work, and even if your mind doesn’t pick up on it right away, your body will. You will feel the pointlessness of your labor—the simulacrum within the simulacrum. And one day, you will consciously realize all of your hours are really just enacting a giant kabuki theatre about office work rather than taking the shortest route to solving real problems.

Nothing makes this stick out more than when I try to describe what I do to my friends and family, all of whom work at smaller employers. They don’t understand, and their bewilderment is all the more unsettling because these are experienced professionals. Reactions range from politely changing the topic to “is that it? what else?” Your sense of mastery will be entirely diminished, and with it a gnawing self-doubt will begin to eat you up inside.

Agency at BigCo

You don’t have to quit corporate to avoid all this badness; there is a mindset that lets you seize the richness of your environment and the opportunities it offers. You will awaken to find yourself beneath freer skies. The answer is agency.

As the kids like to say, you can just do things.

I will never forget a week last year when my boss was on vacation during which I had the conn for Google Drive. By the time she got back, I was convinced that I would be fired. During that week I had (1) pivoted one of her pet projects, (2) made a backroom deal with the PMs to shitcan our entire roadmap and sold it all the way up to the VP level, (3) agreed to use Drive’s SWEs to help ship a project for her mortal enemy because it was what’s best for the customer, (4) caused a non-trivial outage, and (5) angered Sundar by blocking Gemini CLI from launching a massive security vulnerability. I was fully clenched walking into our next 1:1, waiting for the axe to fall.

And then…nothing happened. Everything was fine. “Thanks for handling all of that while I was out.” What!? So I just kept doing things like that—following my instincts, using my best judgment of what’s best for the business, and not asking permission. It kept working, and I kept getting rewarded.

Agentic behaviors that freed me include…

• Stop asking permission; if you know you’re right, then go do it. Be willing to bet on yourself and own the consequences2 if you’re wrong. If you absolutely must, use “I intend to…” statements and then go do it.

• Say what you think you cannot say (h/t Claire Hughes Johnson). I don’t have enough fingers and toes to count the number of times I’ve been crazy blunt, and afterward someone takes me aside and says “THANK YOU for finally saying what we were all thinking out loud.”

• If you don’t believe in what your team is doing, change it. Just pushing through and hoping the next project is better makes you an ultra-coward squandering the lives of your people.

• Tell your peers and superiors what to do (nicely). Don’t equivocate or hold back; figure out who needs to act and then ask them directly, “Chelsea, can you put together a PRD for this idea by next week?” People assume this is rude or outside their authority, so they ask the air instead: “Who’s taking point on writing the PRD?” Crickets.

• Demand honest-to-god accountability. If your boss won’t stand up at a podium and say “Jim is the lead for Project Foobar,” then refuse to engage. I’ve played that game of “unofficial” leads and “no titles” before. It all sounds good and egalitarian on paper, but it’s not, and it creates frustration for everyone involved.

• Become a polymath. Engage with topics outside your wheelhouse. Take an interest in finance, sales, marketing, business development, operations…all of it! Learn the actual domain your company works in, and you’ll suddenly find your work is a much more target-rich environment.

• Most importantly, find a project that is important to you and just do it. Clear your calendar, block your time, don’t ask permission, and don’t let other people’s problems distract you. Feel the joy of actually crafting something with your own two hands.

Moreover, this amazing thing happens when you stop following a script, pretending, and putting on airs. People connect with you. Real collaboration happens. Honesty and truth. I have this shorthand equation which explains it:

When you stop optimizing for appearances and “winning the game,” it zeroes out the self-interest dominator. Your lack of tact and any semblance of self-preservation makes you both unthreatening and predictable to others, and as a result, your presence puts them at ease. Cheat code unlocked.

On the whole, it turns out you have a lot more autonomy than you think at BigCo. It actually makes sense when you think about it: as a manager, I’m not all that interested in bossing you around, but if you ask my opinion, I’m gonna offer it…so stop asking all the time. If you’re right, you’re right. If you’re wrong…wellllll, at least you lived your life with integrity and bet on yourself.

And if the company decides to fire you for that? So be it. Then that wasn’t the right home for you. You probably learned a lot and have an interesting story to tell. There are many more worlds yet to be conquered. I hear startup people have a fetish for agency; one of them will hire you.

Drawing the line at self-betrayal.

Before throwing in the towel, though, you should try to find the real barriers, rather than the imaginary ones. That thing driving you to misery? Maybe you can ignore it! Have you tried? Practice some agency 😉

But if you find that, no, in fact, there are aspects of your job you can’t simply ignore, then it’s time to make some Grown Up Decisions. If you’re shoveling the Augean Stables, there is no virtue in pretending it smells like roses.

Your worst sin is that you have destroyed and betrayed yourself for nothing.
— Fyodor Dostoevsky

It took years of experience and lots of nasty surprises to find my true values…to figure out why I hate something even though my brain is screaming “you should want this! you should really REALLY want this!” But once my values were crystallized, it became incredibly easy to see what sorts of jobs work for me and which ones don’t. If a job demands you betray your own values, then it’s time to hit the bricks.

At the end of the day, I’m still gonna quit…eventually. I’m collecting 401(k)s like Pokémon cards. It is my nature to seek challenges and new experiences, and I increasingly find the corporate jungle gym is out of fun problems. I’ll pump this well dry and move on to the next one. But that isn’t a rejection of BigCo. The only real question is whether the job in front of you requires you to be someone you’re not, and whether you can live with the answer.

By the lake I promised my mother I’d use what she gave me and live on my own terms. I don’t think that means anything as dramatic as walking out. Most days it means saying the blunt thing in the meeting, or doing the project without asking. Small refusals to betray yourself, accumulated over a career.

The clock is ticking. Spend it as yourself.

When you become a manager, you become the custodian of a living, breathing system composed of your team, your software, your tools/processes, your customers, and your stakeholders. “Being technical” and knowing your craft remain important—your 1st job is, after all, to deliver working technology that solves customer problems—but ultimately, a new responsibility takes over.

Managers continuously nudge a complex sociotechnical system into increasingly optimal states. Your game loop shifts from “find a JIRA ticket→write some code→ship the fix→repeat” to “identify the biggest problem or opportunity holding back your team→launch an intervention→reinforce and land the change→repeat.”

The fix for any given issue could range from process changes (“let’s adopt agile!”) to technical shifts (“service-oriented architecture is the future!”) to team adjustments (“we can use a Reverse Conway Maneuver to fix the architecture!”) to personnel interventions (“the toxic 10x’er has to go”).

Some think moving up the management ladder is about how many people report to you or having accountability for a larger piece of the pie. Even I’ve written about moving up from teams to units to business functions to products to enterprises. In reality, these are just side effects of becoming increasingly sophisticated at systems-level1 problem-solving…being able to diagnose and intervene productively in scenarios that increasingly involve skills/domains outside core technical skills, as well as more moving parts (people, orgs, stakeholders, markets).

There is one mistake I see managers continuously make, no matter how experienced they get. I see it in newbie line managers, I see it in veteran directors, I see it in C-Suite executives, I see it in SMBs and large enterprises, I see it in a boat, I see it with a goat.

They fail to match the problem-solving technique to the type of problem being solved. You can’t put a Band-Aid on a broken leg and expect it to do much.

Continuous Disappointment

Consider a classic example: adopting CI/CD.

You might think at this point the solution is pretty formulaic. Because self-hosting is so last decade, buy a hosted solution (CloudBees, GH Actions, Travis, CircleCI, whatevs). Configure your favorite linters. Write some integration tests, maybe screw around with Cypress for UI testing. Start using feature flags; hand-rolling is fine to start, or, if you have a trust fund, use LaunchDarkly. Hire a masochist (Terraform HCL expert) or two. Start tracking flakiness, pass rate, and build time…optimize optimize optimize.

While this is roughly correct at a high level, the distance between adoption and embrace in a real software enterprise is enormous. Technical enablement is maybe only 10% of the actual problem, and you are in for a wild ride dealing with the remaining 90%.

Back at Two Sigma, we had a slavish obsession with unit testing. Teams would regularly strive for 90→95→99% line coverage with not a single integration test in sight. There wasn’t even a platform for running the damn things. Stunned, I audited every single outage in the last 5 years and found that a staggering ~70% (IIRC) could have been detected with simple integration tests. “Simple” here is defined as “A 1st- or 2nd-year new grad would think to write this test case unprompted.” Hook, line, and sinker. We brought together a core group of trailblazers running their own shadow-IT Jenkins instances, built a business case, secured funding, and built a proper CI platform for the firm. Mission accomplished, yay?

Not yay. Climbing the adoption curve was a struggle.

• Some teams were just not willing to take the perceived productivity hit of slow-running CI tests, claiming their ultra-fast, high-coverage unit tests were sufficient even after showing them hard data that their system, specifically, was responsible for a disproportionate number of outages.

• Others wanted CI, but many systems were just flat-out not designed to be started outside of production, had hard-coded DNS names or encryption keys, and a zillion other issues, making hermetic test instances unobtainium.

• Engineers on the ground felt they would be unfairly penalized at performance time for slowing down their projects to produce better tests.

• In cases where teams were bought into the theory, we’d sometimes run into the objection “but who cares? I still have to verify that everything works post-deploy manually.” I didn’t want to fight the release automation battle yet, so I explained the virtues of keeping software in a ready-to-release state (even if you don’t choose to deploy it immediately). Some clown had the gall to ask if I really understood what CD was and if I had read Jez Humble’s Continuous Delivery book. Yes, I had, because this definition literally came straight from the book. Bad-faith arguments are a strong sign you’re dealing with more than a technical problem.

We eventually overcame all of this, but it took so much more than pure technical enablement. A new training curriculum as part of onboarding. A team of forward-deployed SDETs2 to help with the thorniest adoption hurdles. A revised career ladder to explicitly award software quality work in perf/promo. A whole bunch of time to accumulate wins. Recruiting revered staff+ ICs as change agents/promoters. Continuous advocacy and reinforcement from senior leadership. Hiring a critical mass of younger/newer developers who were born CI-native.

None of these issues was unique to Two Sigma’s environment. For some reason, this has been a continuous (pun intended) theme of my last four jobs in a row. I shit you not, I am working on implementing CD in the year of our lord 2026. I deployed my first Jenkins+Selenium cluster in 2011. What’s old is new again; time is a flat circle, etc.

Even companies that should know better already…like Google. Core infrastructure was released only four times a year. Releases were given fancy names and treated like pets. A rollback was the emotional equivalent of having to put down your dog. It was dark, man. Even as we modernized (reusing much of the same playbook I developed at Two Sigma) and increased the frequency to monthly (wowee), the compromise was that everything had to be developed on a branch and merged to main en masse. This was the company that popularized monorepos and trunk-based development with this ACM article for Christ’s sake! Again, we overcame all of this (and released ~weekly, even the most low-level core platform infra).

So what’s going on here? Why is this so hard?

CI/CD is just a microcosm of a broader class of problems, the sort of problems where psychological, social, and philosophical factors weigh just as heavily as the technical.

I’ve seen this same dynamic in issues as varied as Agile adoption, embracing AI, instituting SRE practices, you-build-it-you-operate-it, implementing design thinking, and shifting to JTBD/scenario-focused engineering. The companies with the longest average employee tenure or the highest prevalence of boomerangs were always the slowest in any given adoption curve. There is a social dynamic at play if the surest “fix” is to wait for a generational change of the guard.

Identifying Adaptive Challenges

There are really two classes of issues an org leader will deal with: technical and adaptive. Some issues are even a little bit of both simultaneously. The correct problem-solving techniques depend on which one you’re dealing with.

An adaptive challenge is unclear to or experienced differently by each stakeholder. There is no known solution, or existing solutions are not widely accepted. No amount of execution excellence can ease the passing; progress requires collaboration (not compliance) from those facing the problem to rationalize new roles, identities, beliefs, habits, skills, and relationships. Through collective sensemaking, a solution is “discovered” rather than “designed.”

First introduced by Ronald Heifetz in The Work of Leadership (2001) and refined in Leadership on the Line (2002):

Adaptive work is required when our deeply held beliefs are challenged, when the values that made us successful become less relevant, and when legitimate yet competing perspectives emerge. […] Adaptive problems are often systemic problems with no ready answers.

On the other hand, a technical problem is solvable with expertise, authority, and tools. The problem can be clearly defined, the solution is generally known (or discoverable), and the main issue is one of execution. Existing tools and techniques fully answer the case.

That doesn’t mean technical problems are “easy”; some technical problems can take years to solve. I have been on the butt end of infrastructure migrations that consume years of my life (Python 2 → 3, Mesos→k8s, Puppet→Ansible, various esoteric internal things, the list goes on)…none of these were adaptive; someone just had to have the tenacity and attention to detail to get it done.

Context matters; the devil is always in the details: the same problem won’t consistently bucket as “technical” or “adaptive.” When I worked on Google Drive, we were migrating our UI from one API server (the same one that serves the public Drive v2/v3 API) to an internal-only API—a “backend-for-frontend” (BFF), as it’s known. This was so much more than a lift-and-shift; it was an org-wide reckoning about how we build software: when should an API be general-purpose and flexible vs. tailored to the UI? If it’s single-purpose, who maintains the API, the infra team or the feature team? Are there parts of the BFF code that only core maintainers should be allowed to touch? What computations should be performed on the client, on the API server, or in the storage layer? Should we adopt server-driven UI (SDUI)? These questions affected how ~400 SWEs delivered their work and struck at the core beliefs about what makes software maintainable, scalable, and reliable. Debates over how to utilize our shiny new BFF layer are raging to this day; half the team is still cursing my name for building that contraption (haters gonna hate, etc).

Adaptive problems have more at stake than mere professional pride and delivery deadlines. Heifetz continues:

Adaptive change is distressing for the people going through it. They need to take on new roles, new relationships, new values, new behaviors, and new approaches to work

Back to CI/CD adoption, it’s clear this is an adaptive challenge, as it requires system participants to grapple with multiple simultaneous core belief updates, including…

• Risk-taking tolerances and acceptable deviance.

• Fast failure and fast recovery over slow+rare failure.

• The ideal test pyramid and probabilistic thinking.

• Philosophies of software design and systems architecture.

• The omnipotence of the product manager/business stakeholder.

• The inherent value and “street cred” of ancillary work, such as test automation.

• Reliance on automation rather than on subject matter experts.

No amount of technical enablement will make alignment come quicker. It’s an outright category error to assume as much. Stop smacking the screw with a hammer (code) and get out your screwdriver (organizational psychology).

Adaptive challenges are more common than you think.

Leaders have a track record of providing leadership in the form of solutions, that is, defaulting to technical problem-solving. This tendency is quite natural because many executives reach their positions by virtue of competence in taking responsibility and solving problems. It avoids the mushy, slow dialectic that adaptive problems demand (bias for action and all that jazz) or the challenging confrontations that can arise from uncomfortable truths (conflict aversion is a plague).

Good leadership still requires decisive technical action when teams cannot decide what to do…but you might be surprised how rarely the solution is purely technical. If it were, someone lower down in the org chart would probably have fixed it before it ever reached your desk.

Here’s just a taste of a few more problems that tend to show up as technical but are actually adaptive:

• Monolith to Microservice Migrations

• Shift-left Security / Privacy / Accessibility / QA

• Platform Engineering and Golden Paths

• Cloud FinOps

• InnerSourcing (Cross-Team Contribution Models)

Though no single actor wills it, we often slip into a technical problem-solving posture simply because of the distressing nature of adaptive issues. Heifetz again:

[Employees] often look to the senior executive to take [Adaptive] problems off their shoulders. But those expectations have to be unlearned. Rather than fulfilling the expectation that they will provide answers, leaders have to ask tough questions. Rather than protecting people from outside threats, leaders should allow them to feel the pinch of reality in order to stimulate them to adapt.

Your AI Adoption Program is a technical solution to an Adaptive Challenge.

I remember being floored during a Q&A with my team when someone very earnestly asked: “Will leadership provide additional support and training for using AI in our development workflow?” I’ve worked through this at two separate companies now (and from the sidelines at one more that hired me to consult). Various flavors of this question keep getting asked, and I Just. Don’t. Get. It.

What happened? Is this not the industry where 75% of living practitioners were self-taught by just screwing around on the computer? Go pop Codex open and see what happens…it’s not that hard. I sat through a live two-day training with Anthropic’s best and brightest FDEs, expecting to have my mind blown by the Secret Ninja Techniques of the AI masters… but it was the most drooling “the-circle-goes-in-the-round-hole” thing I’ve ever experienced, with such brilliant takeaways as “you should use skills.” I don’t even want to know how much we paid for that.

When a historically smart, self-starting cohort known for their wherewithal starts acting completely helpless, you know you’ve got an adaptive challenge on your hands.

And yet, many companies are approaching this as a purely technical problem. Give everyone Claude Code + Cursor, figure out a security policy so someone doesn’t accidentally --dangerously-skip-permissions the company into a week-long outage, throw a few all-hands on the calendar, and call it good.

I can hear your protestations now, “No, Jim, we’re doing it right! We’ve created workshops and training materials and set aside time for engineers to practice using these tools and…” Shhh. Shhhhhhhh.

If you leave with only one takeaway from this article, let it be this. Training is a technical solution, not adaptive. Training—no matter how well designed with tabletop exercises, worked examples, gamified achievements, and New World Kirkpatrick—only conveys knowledge. It accelerates the acquisition of technical know-how but does little to shift beliefs and habits.

You need look no further than the actual behavior that is emerging in the wake of AI rollouts to realize that no one knows what they should be doing:

• Tokenmaxxing as a self-protective measure. Staff can’t figure out how to meet sky-high productivity expectations while real bottlenecks sit unaddressed (slow processes, infra no longer fit-for-purpose, way too many cross-functional partners and sign-offs), but they do know you’re watching, so flailing ensues.

• Vanity projects like “skill-sharing portals.” Despite the primary benefit of LLMs being personalized software, they pattern-match to previous-generation ways of thinking, which dictate that duplication is a vice and reuse is a virtue.

There is a vast, unexplored landscape of adaptive issues that these companies need to discuss. Like right now.

• I just wanna be that guy: some see this as a once-in-a-lifetime opportunity to become “the guy” who made <big important thing> happen. Paradigm shifts don’t happen every day! So they spend all their energy trying to be the Big Visible Thought Leader…even though their heads are completely empty and it is the deaf leading the blind.

• Mourning a lost identity: AI is an equal-opportunity destroyer. SWEs who relished craft and geeked out over programming languages are seeing ~half their skill set become obsolete. PMs who treasured human interaction, attention to detail, and effective writing are being told to slop it up. I had this pastoral image of my “retirement” job as some no-name L5 senior SWE… slinging code, closing tickets, not a thought in my head. That job no longer exists.

• Labor dispute: confidence and trust in company leadership are at an all-time low. Employees might be excited to embrace a new way of working, but are unsure if they are signing their own death warrant or that of the friend sitting next to them. It is assumed that executives are sitting in these meetings peddling doublespeak while updating the layoff spreadsheet in another tab (we’re not, but you won’t believe me anyway; that’s how bad it’s gotten).

• Imposter syndrome: this is undoubtedly a Big Scary Change, and there is much to learn. The anxiety and uncertainty over “can I do it?” is palpable. People who were previously self-assured and confident in their abilities—and thereby able to put work on the back burner, start families, and live life—are being sent back to school.

• Dizzying pace of change: speaking of living life, AI development best practices are moving a million miles a minute. First we were “vibe coding,” then “agentic development,” and now we’re “loop engineering.” Claude Code? Pssht, no, I use OpenCode! Wait, you use OpenCode? Pi is the real power user’s choice. Opus is the best coding model; no, it’s GPT 5.5; no, it’s Fable; no, actually, open-weight models are where it’s at; have you tried Gemma? Why aren’t you using Qwen? (Ignore the fact that my code comments are randomly in Chinese) Fuck, I’m tired from just typing that. It’s a timely reminder that people want to do more than be terminally online, refreshing Orange Website like it’s the last chopper out of Nam.

Consider this: have you and your PM counterparts sat down and had a frank conversation about what this new tool means for your respective jobs? Not the usual water cooler crap and theorycraft, the deep cuts:

• How many SWEs do we really need on this team? How many PMs do we need? Or designers? Or managers? It’s gotta be fewer, but then that means…?

• Are we all destined to become amorphous “Builders” who do all of the above?

• What are your personal hopes, dreams, fears, and anxieties? Who’s trying to cross the chasm and who’s looking for the next off-ramp?

• Why do we do that process? I know it’s so-and-so’s job, but is it really necessary?

• OK, we’ve had this tool for a year now; our activity has gone up, but the number of features shipped and revenue acceleration are flat…what does that mean?

Can you even imagine having such a conversation in your org? I can’t. We’d either exchange polite corporate nothings and talk around the real issue, or it would devolve into a death match, complete with protracted trench warfare.

Because we’re collectively unable to engage in the required truth-seeking exercise, the adaptive problem at hand remains unaddressed3. Our fear of conflict confines us to addressing only the anodyne, fruitless technical aspects of the issue.

Obstacles to Effective Adaptive Problem Solving

Patience

Do not underestimate how long it will take to address an adaptive challenge. To start, just think, mechanically, what even has to happen when implementing an organization-scale change.

1. Info about the change has to reach everyone impacted.

2. Those people must understand the change (lots of repetition).

3. They must believe the change is real, won’t go away, and can’t be ignored (even more repetition).

4. You must mobilize a team of change agents and program managers to shepherd each step.

5. A supermajority of potentates, leads, and other influence brokers must be convinced and bought in. When those people leave, new joiners must be re-convinced.

6. The technical adjustments required to support the change must be made.

7. The bugs in your grand design and the hitherto unknown edge cases must be addressed.

8. The team must embrace the change, not get discouraged if things go poorly at first, and iterate until they “get good” at the new thing you’ve introduced.

9. You must address stragglers and holdouts, often through coercive measures such as performance management.

10. The change must be continuously defended against distractions and competing change initiatives, often requiring defensive architecture such as outcome-driven metrics and OKRs that convince leadership to Let You Cook.

It doesn’t take much imagination to see how this can require dozens of months, verging on many years, once you reach a nontrivial scale (~250+).

The Overton Window

A concept from political philosophy, the Overton Window is the range of subjects and arguments politically acceptable to the mainstream population.

The window shifts over time. Social Security in the US was unthinkable in the 19th century. Still, it became common across the industrial world and in the 1930s eventually emerged as an acceptable solution for managing the welfare of elders. The window has continued to shift, and nowadays, Universal Basic Income is being discussed seriously. Time will tell if this ever crosses the threshold to “acceptable.”

The same phenomenon is alive and well within our engineering organizations. For almost 5 years, I have been a proponent of eliminating code reviews: they were never about finding bugs—that’s what tests were for—and once you have 3+ people on your team, you need a different 1-to-many vehicle anyway to achieve the cross-training and knowledge sharing that code reviews are supposed to facilitate. The idea is so extreme that most think I’m joking…it’s completely unthinkable. Nowadays, with AI code-review agents and software dark factories, the concept is approaching acceptability, even if it is still a bit radical.

The real job of change agents within a company is to detect where the window is and then move in accordance with it. Acting outside the window will lead to ideas never getting off the ground and, in the worst case, outright ostracization, permanently damaging one’s credibility.

Some adaptive problems will find their solutions outside the window for a given organization, guaranteeing failure to evolve. If you find yourself in such an environment, you must begin the slow work of shifting the window through selective hiring, adjusting incentives, and using modest incremental changes as a sort of foot-in-the-door effect.

Change Budgets

There is a fixed physical and emotional capacity for the human beings in your organization to deal with change. I’ve written about this extensively of late, but the bottom line is that:

1. We are hard-wired to prefer routine and predictability. Change creates uncertainty, a major trigger for our fight/flight response.

2. Coping with change is a somatic process that requires extensive biomechanical effort. Humans need time and energy to rewire their brains.

3. The members of your organization are often adapting to multiple overlapping changes across their professional and personal lives.

4. Once an individual’s capacity for change is reached, they will begin to defend the status quo vehemently.

Cross-Org Influence

Many leaders find it “easier” (lol) to implement changes within their reporting chain. Not only is this the group where you have the strongest social/emotional bonds, but there is also a hard power relationship. Your employees are incentivized to go along with whatever you say, and even when they don’t, you always have the option to employ coercion.

Unfortunately, no team is an island and likely interacts with dozens of other orgs, each with its own culture and beliefs.

Ignore these other groups at your own peril. Almost all material adaptive challenges have some bearing on cross-org interactions and norms. For example, fully embracing agentic development also means getting comfortable with more experimentation: shipping MVP-quality features, seeing what works, and removing/rolling back what doesn’t…and doing this with much less oversight. If your PMs require 20-page PRDs that have been reviewed within an inch of their lives, and expect to sign off on any and all production launches, then no amount of exhortation for the dev team to burn more tokens will change the status quo. Your engineers will be living through two conflicting sets of incentives (make my boss happy, piss off my PM; make my PMs happy, piss off my boss).

Despite your positional authority, humans are built for relationships and will go to great lengths to avoid antisocial behavior and the risk of rejection. In practice, I find that fear of peer rejection is a more powerful motivator than fear of reprisal from one’s manager.

We shouldn’t really be surprised by that fact: managers are constantly coming and going. From switching teams to forced reorgs to folks leaving jobs, strictly hierarchical relationships have a very clear beginning and end. On the other hand, peer relationships are eternal. Even as you move throughout your career, social networks endure and create leverage. No one will remember what you did, but they will remember how you made them feel.

To solve an adaptive problem, you need to broaden your view from “the team” to “the value stream” and address every person on the critical path of delivery. Cross-functional peers, sister teams, technical dependencies, suppliers, and staff functions (HR, finance, comms, IT, etc). As the saying goes, if you take care of the corners, the room will take care of itself.

In-Group Norms

Social identity is the portion of an individual’s self-concept derived from perceived membership in a relevant social group. From an individual’s perspective, these group memberships perceptually divide the world into two categories: in-groups and out-groups.

Cliques are just one extreme manifestation of this, but in reality, research has shown people can form self-preferencing in-groups within minutes, and such groups can form even based on completely arbitrary, invented discriminatory characteristics, such as preferences for certain paintings.

Group membership exerts much influence over day-to-day behavior:

• People are differentially influenced by in-group members. That is, under conditions in which group categorization is psychologically salient, people will shift their beliefs to align with in-group social norms.

• People will go out of their way to maintain in-group status and defend the stability of their identities. Group valence predominates and can hold individuals firmly in place even when doing so causes significant personal harm.

Can you see where this is going? “Management vs. labor” is one of the most classic in-group/out-group divides in human history. If your staff does not see you as “one of them,” it will be an uphill battle to exert any amount of influence. In fact, rejecting your ideas by default and generally resisting top-down management may even be an in-group marker. This was certainly the case at Google when I worked in storage infrastructure. It was a point of pride that the individual contributors flat-out refused any form of hierarchical management and made their own decisions. This culture dates back to the very earliest days of the company, when Larry and Sergei were still just PhD students. In academia, everything is subordinated to truth and rationality, including efficiency (stop talking, we need to get shit done) and pragmatism (don’t fire me, bro).

Behaviors, patterns of speech, manner of dress, beliefs, philosophies, attitudes, etc can all serve as salient in-group markers that signify to other group members that you belong. If you do not tend to the entire social network, normative pressure will keep your team locked firmly in place. Leaders have effectively three choices here:

1. Become recognized as an in-group member. When you see a leader break ranks and talk candidly (read: negatively) about something the company is doing, that’s basically what they are doing. By dropping their executive presence for a few moments, they go “hey, I’m one of you, I’m just required to put on this mask, see?” This is also why leaders promoted from within often start with a leg up over their externally recruited peers.

2. Earn street cred. The 5 Levels of Leadership is my go-to framework for thinking about this. Your goal is to gain credibility through deeds and to earn the followership of your staff by shifting from someone they are forced to follow to someone they want to follow by virtue of what you’ve achieved together, what you’ve done for them, and the values you represent.

3. Recruit change agents. Find respected in-group members who agree with you and have them champion the required changes. Failing that, convert and recruit change agents by practicing some spycraft, specifically MICE (money, ideology, coercion, ego) and RASCALS (reciprocity, authority, scarcity, commitment, liking, social proof)

One Size Fits All

Managers often return to the scene of the crime past successes. Maybe you’ve solved a couple adaptive challenges in your day. You join a new company and, lo and behold, they have the same problem! You unbox your old toys and get to work. Does it work?

Maybe! Err, well, probably not?

In a technical problem, it’s pretty straightforward and formulaic: if W is a problem, X is important to you, and you utilize Y platforms, then use solution Z. In adaptive challenges, the primary substrate you are modifying is human beings and social networks. As a result, it is much harder to confirm the conditions are exactly the same from one context to another. That means the techniques you bring to bear may react very differently within this particular group and not have the intended effect.

One of my all-time favorite books, Orbiting the Giant Hairball, has a wonderful metaphor here. It’s like sculpting. I don’t expect to be able to do the same thing with marble as I can with sheet metal, clay, or even alabaster. Each material exerts different demands on the artist and can only hold certain forms. Before acting, understand what material your company is made of.

4 Levels of Adaptive Problem Solving

Let’s recap to close out:

• There are two distinct types of problems you will encounter as a leader: technical and adaptive.

• Adaptive problems are tricky because you can’t just “solve” them by leading from the front; the whole team has to engage in a collective truth-seeking exercise to redefine their roles, relationships, habits, and beliefs.

• Most people are accidentally using technical techniques (like training) on adaptive problems (“how does our engineering function embrace AI”)…because it’s easy and comfortable.

• There are lots of surprising social and psychological nuances to solving adaptive problems: patience, social norms, peer pressure, culture, etc.

Now that you know what an “adaptive challenge” is, you have a whole new skill to master…hurray! Reflecting on my own progression, there are 4 key “breakpoints” in my development as I became more effective at adaptive problem-solving.

Level 1: Doesn’t recognize adaptive problems at all.

• Symptom: frequently utters “Why can’t we just…” and proposes simple technical solutions. Blames the user when adoption stalls.

• How to Level Up: must make a subject-object shift, moving from being part of the system to observing the system.

Level 2: Recognizes adaptive problems, but runs one-size-fits-all solutions.

• Symptom: treats change management as a checklist, copying approaches from previous jobs or public intellectuals. Genuinely confused when the identical play gets wildly different results.

• How to Level Up: fall in love with the diagnosis, not the cure. Every org fails differently, so study how this one works (who trusts whom, what people fear losing) before choosing an intervention. When I was at this stage, I drew on some of the human-studies skills from my university days and conducted an ethnography which led me directly to…

Level 3: Diagnoses accurately, but relies exclusively on incentive alignment and structural force.

• Symptom: every solution routes through perf criteria, promo rubrics, OKRs, mandates, or a reorg. It works, but what you’ve bought is compliance, not belief, and the change only holds under continuous pressure. The org will regress the minute you leave.

• How to Level Up: give the work back to the people (Heifetz’s actual prescription). Stop supplying answers and start orchestrating productive conflict: ask the tough questions, protect dissenting voices, regulate the temperature so distress stays in the productive zone, and let the group discover the solution.

Level 4: Problems get solved without the leader’s fingerprints on them.

• Symptom (of mastery): when the work is done, the people say “we did it ourselves.” Eventually, the org starts metabolizing new adaptive challenges before they ever escalate to you.

Good luck out there!

I’m here to give you the exact opposite message: slow the fuck down.

Don’t react too quickly to any single event. Think before you speak. Dispense mandates, principles, and strategies with parsimony. Inject latency between conversation and alignment, alignment and action.

I’m not saying this for exclusively humanistic, it-doesn’t-have-to-be-crazy-at-work reasons (although, it really doesn’t). Outright AI psychosis aside, I too salivate over shipping faster. Eric Ries’ Lean Startup is a prized possession. Though I am trapped within the belly of the beast (Corporate America), I relish decapitating bullshit ceremony and obstreperous process wonks. My bloodlust knows no bounds.

There are purely practical reasons to slow your roll.

When speed sabotages your organization

I have always prided myself on my ability to translate direction into action. Give me a hill to conquer and I can draw up a battle plan, organize the troops, and march in a matter of hours. It usually only takes me a few minutes to grok what my manager is saying, decide if it’s a good idea, and commit. Naturally, this has made me a perennial favorite and worked in my favor as an engineer, then tech lead, manager, and beyond.

Now as an executive it’s become a liability.

Our senior leadership had big ideas for the future structure of our teams. Larger spans of control, middle managers that owned tangible areas with concrete goals+strategies, fewer contractors and more FTEs, geo-aligned teams to encourage realtime collaboration. No one was losing their job (yay), just fixing the structure (double yay). All good stuff that effectively addressed very real problems observed over the past few months. I was bought in nearly instantly so when the mandate arrived to start implementing, I got to work.

Within 72 hours I had…

1. Designed the destination org structure.

2. Secured buy-in and excitement from my Directors.

3. Conducted a round a Nemawashi with all 15 of my product management counterparts (yes, you read right, one-five. Every Friday I take 15 shots in salute to the joy that is matrixed organizations…I then wake up and it’s Monday again…what gives!?)

4. Aligned on impacted projects and roadmap reprioritization.

5. Constructed an exhaustive run-of-show.

6. Began implementation.

Disaster struck after we had finished abut 25% of the reorg, cancelled a couple projects, reassigned about a dozen contractors, and gotten managers comfortable with their new scopes. The reorg mandate would change substantially. Parts that we were previously free to defer to later suddenly had deadlines just weeks out. Span of control targets went from suggestions to strict requirements. Contractor targets went from “you can keep a few as needed” to “you can keep none.”

The result was chaos:

• Product partners did not see this as a 2nd, separate change but rather Engineering changing the terms of the deal after it had been inked, blowing up their roadmaps.

• Managers who were previously told “nothing would change” were suddenly being told they needed to switch into entirely different roles in different orgs.

• Changes originally sequenced around graceful cutover points in project schedules now required development pauses and roadmap slips.

The resulting escalations would consume about a month of my life and we’re still dealing with the fallout of this months later.

The craziest part? Had I literally just done nothing and basically ignored my boss, all of this could have been avoided. We would have communicated a single, consistent change to everyone involved. There would still be heartburn but most of the turmoil was caused by the rug pull, not the change in and of itself.

Situations like this aren’t limited to organizational changes either.

A couple years ago, we were working on enabling Gemini to take action within Google Drive (think: move+rename files, organize folders, upload files, etc). Our tech lead at the time wanted a separate microservice for these APIs for a variety of reasons: they were highly privileged internal-only endpoints that needed different semantics from our public API, they would be used as part of long-running background tasks and needed different runtime management characteristics, general separation of responsibilities, and a tighter/faster SDLC to meet the demands of these super-P0 AI projects.

As 2nd chair, I mobilized the team. We grabbed our 2 best and brightest engineers and sold them hard on this exciting opportunity to build an entirely new server from scratch and earn major clout and career uplift contributing to Drive’s top OKR. They completed the POC in record time (I think it took like…2 weeks…to get into production, something unheard of at Google).

It was at this point that the truth surfaced. Our tech lead hadn’t actually built any real consensus for this direction and was just trying to force things through, coming into direct conflict with our senior leadership team in the process. The POC didn’t help convince anyone like he had hoped so the SLT declared the project dead and that we were going in a different direction.

I then had to go back to these superstar engineers, break the news, and ask them to help me clean up and delete everything. It was a really soul-crushing and discouraging experience for these folks who, by the end, had burned an entire quarter on this boondoggle. I would spend the next ~6 months going out of my way to retain these 2 with special assignments, growth opportunities, and extra attention.

Once again, had I just done nothing and let the natural architecture review process chew up and spit out my tech lead’s scheme all of this could have been avoided.

Organizational Rug Burn

Upper management moves at the speed of light.

Please, pick your jaw up off the floor. Don’t believe me?

What do you think we’re doing in all those meetings all day long? Back rubs and celebratory ass slaps? OK well there are definitely a few drum circles and networking events (shoot me with a gun). No, there’s a reason your 1:1 is rescheduled over and over for urgent meetings until a month later you finally have a 15-minute sync that can only be described as “disappointing.” The reason is that I am a Terrible Boss, but also that my calendar is wall-to-wall knife fights whose outcome will impact the lives of O(100)’s. An executive is a machine that turns alcohol coffee into decisions. Now multiply this by the 3…or 4…or 5 (fuck) layers of VPs at your company.

If every single one of those “decisions” turned into action (immediately or ever), nothing would ever get done. Teams would just be changing gears from one mandate to the next. The company’s PPO premiums would skyrocket from the intense whiplash and emotional exhaustion.

In their infancy, decisions are in constant flux, flip-flopping as the news traverses the org, backchannels open, and executives scurry between offices like a really bad episode of Scooby Doo. Even when there is seemingly alignment, one hand doesn’t know what the other one is doing leading to clashing directives. In one poignant example, we got our whole org to rally around a goal to ship all binaries twice-a-week, just for our C-Suite to sponsor a similar initiative from the other side of the company which instead said the target was P90 merge-to-deploy <24 hours. Our teams came to us asking “well, WTF is the actual goal?” Naturally, we played it off like this was all by design, that there was no conflict here, and nothing stupid just happened. lmao.

This is all to say you need time1 for the World’s Shittiest Version of Paxos to reach stable consensus or your teams will experience reversals and conflicting demands. Your personal credibility will be left holding the bag because, well, from the perspective of the team you are the living incarnate of The Company. Good luck ever convincing your team to do anything after two or three instances of “opps, nevermind.”

The Neuroscience of Change

The core issue here is that of change budgets. There is a fixed physical and emotional capacity for the human beings in your organization to deal with change. Multiple biological systems conspire to enable the mind to cope with change but also make us initially resist change.

• Amygdala: wired to all major sensory nerves (optical, aural, olfactory, etc) and hypersensitive to change as a potential source of threat. The Amygdala triggers the famous fight/flight/freeze response and can even be triggered by social cues such as others around you experiencing fear.

• Entorhinal Cortex: maintains the mind’s mental map inclusive of both physical space and social networks including power relationships (hierarchy, dominance, competence) and affinity (trustworthiness, love, intimacy).

• Basal Ganglia: turns repeated behaviors into habit loops composed of cues, routines, and rewards. Habits take less mental energy to engage than novel behaviors.

• Habenula: restricts the flow of serotonin and dopamine (“feel good chemicals”) to discourage behaviors that tend to lead to punishment, suppressing both motivation and even physical body movement. In effect, it’s the chemical implementation of “fear of failure.”

Our brains are made to adapt to novel situations so we can change but it takes time and the expenditure of physical energy to suppress amygdala hijacking, form new mental maps in the entorhinal cortex, rewrite habits in the basal ganglia, and overcome learned helplessness in the Hebernula.

The combined effect of this biological machinery is change curve:

The speed by which an individual moves through this curve is both context dependent and highly personal (see the Change Style Indicator if you are a fellow psychometric-enjoyer).

Because of the acclimation time, concomitant change is the norm not the exception. Most leaders (myself included) vastly underestimate the number of overlapping change curves playing out in their organization. Over the years I have made remarks to my myriad bosses about “lots of changes overwhelming the team” and 100% of the time received a reply to the effect of “WTF are you talking about?” This speaks to the very different personality profiles of executives who, as a cohort, tend to be high in openness to experience, low in neuroticism (Big 5), and thereby more comfortable with risk/uncertainty leading to a certain amount of change blindness. The reality is little more overwhelming than anyone realizes…how many of you are dealing with one or more of the following?

• A new job or role.

• A new manager.

• A switch to a different work station or workplace.

• A new leader of your function or organization.

• A change on your team (losing or gaining coworkers)

• A change in another department or team that affects you.

• A shift in process, policy, or procedure.

• An implementation of new or different technology.

• A drive to capture a new client or market.

• A move into a new regional or global territory with different cultures, laws, customs, or perhaps languages.

• A merger or acquisition.

• A geopolitical shift that affects the common market.

Not to mention personal changes occurring at home (births and kids growing up, aging parents, partner or friend drama, even just mundane crap like remodeling projects).

The human body cannot sustain never-ending change—it’s just too exhausting—so people begin to make choices: opting into some changes and opting out of others. Worse, your staff will learn to “perform” embracing change while in reality doing nothing because they assume (know) the change won’t stick. Half of the time I am just pretending to give-a-shit at work and it has always worked in my favor 🤷‍♂️

Think this isn’t happening in your org? Think again. A 2015 cross-sectional study of 513 middle managers found change fatigue prevalent in 47% of study participants.

When you thrash your team around by mobilizing changes too quickly, you create the conditions for change fatigue. Once you’re unable to mobilize your team, the death spiral has begun.

Pace Layer Violations

Beyond the human hardware upon which your decisions are realized, there are also structural and systemic reasons to slow down—what I think of as an “organizational speed limit.”

There is a natural tension that exists between stability and adaptability. Companies, organizations, teams, products, and infrastructure are all examples of persistent systems that must continuously absorb and even incorporate shocks.

• A company that fails to respond to a significant shift in consumer preferences will cease to exist.

• A team that cannot retool and incorporate new technology and professional methods will be replaced with one that can.

• A product which cannot be modified or extended to adapt to emergent customer problems will be outcompeted.

• A piece of infrastructure which cannot support the team’s productivity or product’s agenda will be deprecated.

These different components of a software enterprise form “layers” each with different scales, different rates of change. Fast-adapting layers act as buffers to help absorb change, only letting changes filter down to lower layers if they stand the test of time and scale. Slow-adapting layers provide a stable foundation enabling the continuity of everything above.

For example, your core infrastructure should provide a highly reliable, predictable set of platform primitives. If your core database engine changes in response to every single new product feature, your enterprise will quickly be subsumed by surprise outages, performance degradation, and development delays.

When I worked on Google Drive, there was an increasingly large need for complex async, eventually consistent processing (e.g. what happens when you share a deeply nested folder hierarchy with hundreds of users simultaneously?). We kept bolting on hacked up nightmares to our storage layer to support new features (DLP rules, labels, expansive ACL propagation, ownership transfers, etc) but eventually the system became unusable with async propagations taking days or silently failing. Our SLO dropped below 99.9% and enterprise customers were screaming.

Eventually, we built an async processing platform with a small set of core primitives including guaranteed processing semantics and multi-level priority queues. The processing engine changes almost never and most product needs are met by combining existing, stable primitives. Since then it’s been smooth sailing with >99.99% availability and rapid convergence on even the largest accounts.

Consider another common axis of change: team structures. Teams that successfully make it through the Tuckman Cycle become well-oiled machines. Shared performance standards, mutual accountability, codependence, and common goals unite workgroups and make them more than the sum of their parts. Thanks to effects like Transactive Memory (effectively, groups learn who knows what and how/when to call upon each other in the course of Getting Shit Done), a fully bonded team of 10 will produce more effective output then a random sampling of 10 SWEs.

Hence team structures should be only somewhat adaptable, reconstituting new teams only when strictly necessary (i.e. wrong skills for a major shift in direction). Instead, leaders should bring new problems to existing teams rather than forming new teams altogether.

This will lead to the appearance of strange bugs—back to Drive, we had a “Search” team and a “Sharing” team that for years worked on neither search nor sharing—but the consistently elevated productivity from keeping teams together will speak for itself.

I’m not quite sure what layers precisely exist in our domain, or even if the answer is universal, but it looks something like this:

While each layer is somewhat independent from the others, each layer influences and responds to the layers closest to it.

Markets evolve in response to mercurial and shifting consumer preferences (“fashion”). Company executives attempt to grapple with the evolving structure of Markets and translate that into coherent direction and product offerings. Teams are structured to optimally(?) implement said products. Infrastructure is built or bought which enables the many possible futures of the business.

All durable dynamic systems have this sort of structure—from ecology to business to markets to cities. It is what makes them adaptable and robust. Pace Layers first appeared as “shearing layers” in How Buildings Learn: What Happens After They are Built (1994) and was generalized to all persistent systems in The Clock of the Long Now (1999).

Reduce Speed: School Zone Ahead

Back to our parable: executives and middle managers who are too responsive to the layers above them, who move too quickly relative to the layers beneath them (products, teams, infrastructure) create a shearing effect. The slower layers cannot adapt quickly enough to absorb the shock of change and the enterprise effectively rips itself in half.

When I rushed to implement my boss’s ideas for organizational design and product direction, the slower layers were only halfway through grappling with those changes before different marching orders arrived.

Some wiseass will comment that change is inevitable, going too slow is more dangerous, and this is all working as intended. But that is absolutely the wrong takeaway. The job of management is implement human judgment within a moral context to integrate social activities. When you just passthrough any and all changes/shocks occurring above you, there is absolutely zero judgment being applied. It’s outright abdication of responsibility dressed up as urgency.

In response to new information, a discerning executive will develop a principled opinion, pressure test assumptions, probe and assess their team’s readiness for change, and implement a measured and methodical change management strategy. You’re paid to engineer, not gamble. Your actions affect the lives and livelihoods of real humans, you have a moral imperative to think carefully.

At an absolute minimum, leaders should understand the consensus dynamics of their organization.

• Who are the real power brokers that need to sign-off on something for it to become “real?”

• What exigencies and environmental factors could reverse this decision unexpectedly?

• How long does it take for rough consensus to form and who has a tendency to jump the gun?

• Historically, has there been tangible benefits to being on the bleeding edge?

• Who is sponsoring this decision and how much political capital do they have?

This will allow you to implement an effective filter and avoid organizational fads.2

So, does AI actually change anything?

Unfortunately, yes…I’m no luddite. Let’s use Pace Layers to understand the effects:

• Fashion: the amount of Business Fiction being published about AI is staggering. Need I say more? People will not shut the fuck up.

• Markets: new competitors have emerged that are moving 2-5x faster with much lower cost bases (2-3 SWEs instead of 20-30 for the same offering).

• Products: customer demand has visibly shifted. Some product categories now have AI features as outright must-haves even if the actual usage/adoption is nonexistent. RFPs are a bitch.

• Teams: coding is no longer the bottleneck and what used to require teams of specialist roles (SWE, PM, UXD, GTM) collaborating via structured artifacts (design docs, PRDs, crits, playbooks) are now being replaced with hybrid roles or even monocultures of amorphous “builders” who do a little bit of everything.

The “speed limit” of the slower layers (teams, products) is increasing and with it the pace at which executives need to translate ideas to action is also going up. In short, you cannot just operate business-as-usual.

Personally, I remain a bit uneasy about all of this. Notice anything missing above? Infrastructure hasn’t really experienced a tangible “speed up.” No, the armies of startups slinging slop and hyperscalers lining their Clouds with niche offerings (that conspicuously never exit beta/preview 👀) do not count. Agentic development may have solved coding but is decidedly dog shit at systems architecture: leaky abstractions, sky-high coupling, and incoherent ontologies.

But that’s not even really the issue. It’s not that platform development needs to speed up, but rather, are the current platform primitives and abstractions the ideal substrate for a product development ecosystem that is moving so much faster? We’re driving Ferrari’s down dirt roads. Someone needs to invent asphalt and start paving roads ASAP or we’re going to keep crashing our shiny new supercars.

A few of my long-time readers are working on “the platform primitives of the future” but it hasn’t really made it much further than theory. The companies actually building this stuff are largely flailing and just pushing narratives that dress up incremental improvements as breakthroughs. So far the towering intellects of Silicon Valley have contrived such genius ideas as:

• GitHub but what if it had at least one 9 of availability?

• Firebase but what if it barely worked and regularly loses your data?

• Step 1: Wrap everything in an MCP CLI; Step 2: ????; Step 3: Profit!

• Fuck object stores, filesystems are back baby!

• Generate a metric ton of Markdown, err no HTML. But wait, what if we call all those Markdown files a Wiki!?

• Run everything on the Edge for…reasons?

• Yikes, GPUs are expensive, never mind put it back in the datacenter.

• Get a 2nd mortgage to give your CI/CD provider even more money.

The only proof you need that we’re completely out of ideas: for some reason Docker and Kubernetes have survived the AI apocalypse relatively unscathed.

At the end of the day, platforms still need to be, well, platforms—I always go to Ian Nowland and Camille Fournier’s 4 traits of a platform: discerning product taste, software leverage that abstracts complexity, multitenancy, and operational excellence. We have strayed far from the light.

There is no happy ending to this rant. We need to rethink both our SDLC’s and platform primitives so that the infrastructure layer can keep pace with everything above it. Until then, we’re all going to be flying by the seat of our pants which just underscores my original point: slow the fuck down.

Your job as an executive is to be extremely discerning in what changes you unleash on the layers below you and to not assume Claude has somehow overnight obsoleted the decades of hard-won lessons and accumulated datapoints for what makes an organization thrive.

It’s every professional’s worst nightmare: you take a new job and totally faceplant. Except it’s never that straightforward.

Back in February I took a new role leading a large engineering team at Capital One. A slightly bigger org, ownership of a P&L, tech that was largely standard COTS and OSS rather than a rats nest of bespoke internal contraptions and duct tape…in addition to the anticipation of trying something new after 3 years in the same role. I can’t abide boredom and routine (why the hell do I work in corporate gigs?? Novelty seeking is both sustenance and also my most self-destructive habit) so the excitement was palpable.

Being That Sort of Guy, I would obsessively prepare in the weeks before. Making sure my office was arranged Just So (“executive presence is having a pretty Zoom background” —Peter Drucker or something), fine tuning my meal prep and fitness routines to accommodate a much busier executive calendar (so many failed overnight oats experiments), rereading all of my favorite management books (spoiler alert: everything is just a more belabored take on High Output Management), and preparing heaping piles of Google Docs/AppScripts/Sheets and Obsidian templates. I was basically vibrating at 60Hz at all hours waiting for my first day.

Fast forward a couple months: I’ve unpacked, changed the name on the door, gotten down to business…and I am in the Pit of Despair. There was no epic cataclysm, explosive fight with a peer, or project meltdown…just a pervasive unease and a vague feeling that I am failing. Interactions ending in enmity rather than camaraderie, obvious opportunities drifting past unactioned, delegated projects coming back a few weeks later on fire.

If you thought Imposter Syndrome was an artifact of early career, think again. In fact, late career it feels so much worse because at this point you’ve proven to yourself (and others) that you’re pretty good at this engineering/management thing and a non-trivial amount of your self-worth is probably built on that. That isn’t to say this was all in my head: these were real failings…an (un?)fortunate consequence of becoming a senior leader is the buck does in fact stop with you. Intellectually, I could articulate what needed to happen and how to do it, but I could not bring myself to do it.

In an effort to course correct, I began comparing my approach and style of leadership to those of my many managers past and present, looking for patterns and gaps that could explain why I was bouncing off my new role rather than integrating successfully. I wasn’t expecting this to yield much more than “we’re different people” but instead I found a surprisingly useful analogy that partially explained my troubles. It’s a bit off the deep end but bear with me.

There are 4 classes of technical executive—

• Warriors: goal-directed individuals that lead from the front. They have maniacal focus on particular results and ends. They drive their teams to deliver, getting as “hands-on” as it takes and wearing any hat. They demand excellence and produce professional progeny that go on to do great things. Impatience is a virtue.

• Priests: group-oriented individuals who focus on configuring the environment for success, shepherding their constituents through change, and bearing the culture of the organization. They don’t disregard results so much as let the results come naturally as a consequence of the environment they build. Impatience is a disaster.

• Mages: technocratic leaders that emphasize domain expertise and creative problem solving. They lead their functions as the unequivocal brains of the operation. The innovations they bring into the world create durable competitive advantages for years to come. They run on their own internal clock, patience and impatience have nothing to do with the matter.

• Merchants: ductile leaders that build alliances, find mutual value across boundaries, and creates leverage through relationships rather than force, expertise, or culture. They tap into the latent potential of those around them and no one will even realize it’s happening. Once again, patience/impatience are inconsequential, they operate off the clock of the organization1.

Each class works well in different situations.

Warriors can make big goals happen against all odds and defend your castle when competitive pressure is high. Priests can keep your money printer printing by leading large groups through important changes and much needed evolutions. Mages can invent the future and unlock the next major step change in capital productivity. Merchants can unlock opportunities and impact by activating the collective in a way that no Warrior/Mage/Priest could hope to achieve.

Maybe more interestingly, individuals can switch classes as they move through life.

Reflecting on my own story, I started out as a Mage, moving up the ranks as a technical encyclopedia and master distributed systems engineer. My early teams were highly specialized functions, R&D groups, and low-level infrastructure that lived or died by sheer technical foresight.

Once my problems got big enough, I needed a team-of-teams to get them done, and I respec’d as a Priest. I learned how to implement large-scale org changes, use incentives and process design to generate outcomes, and fine-tune sociotechnical systems to meet the demands of the business. The largest success of my career came as a Priest: transforming an org of ~1200 to ship with 2x higher velocity, 25% less overhead, 32pp more job satisfaction, and one more 9 of availability. It took 3 years of nonstop (but careful) effort to slowly boil the frog and change the culture.

As I departed that role, I was hungry to execute at the speed of tech (rather than the speed of people) and put all my accumulated expertise to the test. After holding roles across PM, SWE, SRE, DS, UX, BigCo and startup, what could I accomplish if I ran the whole show? What if I “eat what you kill?” This was when I took on the Warrior class and my troubles began.

Each class has a role to play

Your class matters but so too do the classes of your leadership team.

Warriors tend to leave a trail of dead bodies behind: angry peers, disgruntled employees, cultural debt. Even some lesser known detritus like vestigial teams working on dead-end projects and maintenance-mode tech. The Warrior has ignored these groups because they are not on the critical path and “pick your battles” is the motto of all Warriors. To succeed, Warriors need a leadership team filled with Priests who tend to the masses.

When I was part of Google Drive, this was my role. At our helm was a true Warrior that instilled obsessive focus on critical goals (e.g. swarming entire teams of 10-16 engineers on a single project at a time) and personally leading the product design, org influence, and technical solutioning for our top couple objectives. I ran behind her, translating mandates into vision, supplying context, tending to the gritty technical details obstructing delivery, and leading the less glamorous infrastructure groups needed to keep everything online.

The Priests in this scheme illuminate the strategic insight of the Warrior, making their mission heard and felt across the org and helping bring the whole team along for the wild ride. They tend to the process, organizational, and technical debt that hinders the mission and create the efficiency/resiliency/constancy required for an organization to prevail.

On the flip side, a Priest might create a well-oiled, highly-retentive organization but needs Warriors and Mages to ensure the group actually achieves something meaningful to the business.

The Merchant is particularly suitable in large organizations but would struggle in smaller startups. The Merchant is willing to make friends and change their own mindset towards either of warrior, priest or mage depending on the problems and situations in front of them. The journey matters more than the destination to the Merchant.

The only thing to avoid is multiple levels of leader with the same class. Warrior clans burn out their teams and create cultures of fear. Mage clans produce over-engineered monstrosities that permanently increase the cost of doing business. Priest clans devolve into adult daycare complete with back rubs and story time. Merchant clans impact is limited by the Overton Window and can paradoxically lose influence for being “too political.”

Build the team you need to succeed

If you are an executive and find yourself hiring a new leader, choosing which class you need (and figuring out the true classes of your candidate pool) is paramount. There are lots of faulty intuitions and traps waiting if you half-ass this.

Consider some common scenarios that might lead you to hire a new leader.

Execution Swamp
Money goes in, nothing comes out. The lead seems too soft, too checked out, too ineffective. Your instinct is to hire a Warrior who will come in and show ‘em how it’s done.

Resist this urge with all your might. It will not work. The thing is, no one comes to work wanting to suck at their job. If an organization is failing to execute collectively, the problem is going to be a complex, nuanced combination of systemic factors, individual performance problems, and technical issues that have been deferred far too long.

Warriors will quickly become discouraged by the magnitude of the change required to achieve anything, impatient at the slow rate organizational-change-at-scale unfolds, and will create secondary disasters by applying too much brute force to a delicate operation. Instead, grab a Priest who will carefully orchestrate an organizational pivot with their trademark combo of personal and professional care.

Engineering Hairball
The systems are chronically over engineered. The brain trust has successfully turned your simple web app into a distributed replicated cache replete with CAP theorem problems. Or the inverse: your majestic monolith ain’t cutting it anymore. Incidents are piling up and nothing is getting better. Either way, the issue seems to be a lead who doesn’t know any better and lets their team get away with this shit…maybe even sponsoring some of these gaffes.

Your instinct is to hire a Mage who will up-level everyone’s technical acumen. This too, will not work. The Mage does not actually know how to scale their expertise. They will become a bottleneck at best, or frustrate and scare off all your talent at worst, and won’t even realize it. The Mage lives by the credo “technically correct is the best kind of correct.”

In a truly nightmare inducing scenario, the Mage will fall victim to full-blown Second System Syndrome and make everything worse. Their inherent genius will enable them to sell you on the idea, none-the-wiser. You’ll wake up 4 years later in the middle of an unfinished migration from hell unsure what just happened.

What you really need is a Warrior. Their obsessive focus on results and slightly aggro approach to the job will put an end to any unnecessary science experiments. The complexity perverts (they call themselves “architects”) will become frustrated and quit of their own volition. Meanwhile, a lean core of doers will emerge and rise to the top, basking in the warm glow of the Warrior’s sun.

Urban Sprawl
You have 3 different workflow engines, 5 different release tools, and 9 little fiefdoms each with their own petty overlords. The lead seems unwilling or unable to make the group behave like a single team, bring duplication into check, and focus their efforts into a cohesive strategy.

Your instinct is to hire a Priest: they will unify the group, bring about process and incentive change, and simplify the sprawl into an optimized value chain with fulfilled and energized workers. Will this work? lol, no. Your Priest will be overwhelmed by the complexity and won’t know where to start. Their model of cause-and-effect will be wrong and resulting organizational interventions will be mismatched to the actual problem. Completely stuck, they will lean on their strengths and turn the problem into a group brainstorm with the same predictable results as design-by-committee.

In these scenarios, you need a Mage to end around the kingdom building and incentive gaming. Their outsized capacity for complex and complicated scenarios (word up Cynefin) will allow them to conceive of technical solutions that can outcompete the fiefdoms’ bloatware. Free market forces will take it from there.

Picking your next role

This framework cuts both ways. Just as you’d use it to staff your leadership team, you can use it to evaluate the role you’re being asked to play.

Having just come up with this while puttering around ORD waiting for my connection, I’ve never actually put this to the test, but I suspect this could be pretty helpful for picking your next job.

During interviews, get some grounding on the situation you’re walking into, map it to the appropriate class, and ask yourself if you want to do that for the next couple years.

You can also use it as a bit of a shit test for your new boss: do they know enough to look for the right class? Before accepting any offer, ask your would-be-boss, “Why me? What do you think you’re going to get?” Their answer says everything and you need to read a lot into what they say. Every single word carries meaning. Even if they are someone you’ve worked with before and you know they are good, do not skip this step. They might have known you 2 or 3 class changes ago and it is extremely difficult to override/update the impression left by your past self.

Oh and if you’re wondering how things turned out for me, after figuring out I was playing the wrong class, I adopted some of the habits of a Merchant after which there was an immediate improvement in my effectiveness. I didn’t completely change how I lead and there’s still some friction—I very much believe you have to play to your strengths and remain true to your core values. There is such a thing as role-personality fit (see various reflections of this such as founder-market fit Wes Kao’s founder-message fit) so you must seriously ask if you specifically are the executive that the situation demands or if everyone would be better off letting that opportunity go to someone else.

The qualifications of someone who will do well managing teams of hundreds with multiple layers of management are not at all obvious and look nothing like your traditional type-A resume.

Big logos, ivy league degrees, business school at the likes of Wharton/Booth/Kellogg/Sloan/Stern/<old dead guy’s name here>, even flashy launches and landing impressive OKRs. All of it “helps” but none of it is what makes you truly prepared.

Maybe you’ve been leading a 20-30 person org for a few years now with a string of successes under your belt. You are poised and professional, can present at an all-hands or executive project review without stumbling, and managing your team feels like it takes only one-quarter of your total brain power. Everything is on auto-pilot. You ask your boss for a bigger opportunity: that new P0 company imperative or a larger org or something like that.

His reply? “You’re not ready.”

What follows will usually be some stilted, sweaty feedback conversation where your manager tries to explain what you need to do to become ready…all while everyone in the room is distractedly thinking “shoot me, shoot me with a gun, right now.” None of it sounds convincing or like something you haven’t already done: the feedback will be polite nothings like be more visible to VPs, have more org-wide impact, build a brand1.

First off, if you follow any of this literally you are doomed to fail. You’ll burn cycles doing some performative “horizontal” initiative2 thinking it checks the box and still get denied. Feedback extracted under duress is just not fully thought out. Moreover, most members of upper management are holding back because they don’t know if you can handle the hard truth, nor do they really know how to express the things you’re missing without landing themselves in front of HR.

This post is the unfiltered answer: the experiences, capabilities and proof points that are the real determinant for who gets propelled into middle- and upper-management.

If you have to ask, you’ve already failed.

I’ve been managing managers (of managers of managers) for the last couple years now. I have some version of this “I want more” conversation every other month. “Yea buddy, get in line” is what I really want to say.

Every single person in my shoes is busy as hell and desperate to delegate away 40-50% of the things on their plate. The implication is that if your boss thought highly of you, they would be actively pushing more scope onto you in advance of asking for it (and often before you personally feel ready). If it doesn’t feel like you’re getting DDoS’d by your manager, then you are not their favorite child.

The naive response in this situation is to ask them: “what can I take off your plate?” But this just puts them on the spot. Here’s what races through my mind…

• Oh gosh, um, let me somehow zoom out in the next 5 seconds and think about ALL THE THINGS in my work life. Now I need to filter this down to things I think you can actually do well…

• …and that are important enough that it will show real growth.

• …and that I have not promised to someone else or have someone better suited in mind.

• …and that I think you will actually say “yes” to and put your full effort behind.

All of this while you’re staring at me expectantly. Please don’t do this. If you absolutely have to approach this way, send an e-mail in advance of your next 1:1.

A better approach is to be more observant of your boss, your org, and the company. Take notice of what is occupying everyone’s time, where things are falling through the cracks, and the problems everyone is ignoring. Pick one and then tell your boss: “I’m interested in doing more, I’ve noticed <X> is a recurring challenge, I think it’s valuable to solve now because <Y>, and I plan to approach as follows: …”

This works so well because it puts effectively zero demand on your manager. They can simply nod and say “make it so.” Besides making your executive feel like Jean-Luc Picard (which can only be a good thing), it also demonstrates that you are someone who seeks challenge. What you’re demonstrating is creative dissatisfaction, an all important prerequisite to even be considered for upper leadership. Senior executives are expected to constantly look for ways to improve the company’s products and processes.

Famously, the “seeking challenge” phase was the last step in Kraft’s Leadership Corridor, the development methodology that made a cheese company into one of the premiere factories for producing executive talent that would go on to become CXO’s across the Fortune 500 (case study).

Be like the cheese people, seek challenge.

Experience dealing with everything the job can throw at you.

Part of ascending the ranks is handling more. More people, more orgs, more projects, more problems, more situations you were previously shielded from. You have to deal with these things directly but also increasingly through your management team…all with complete independence.

I don’t mean the “normal stuff” like aggressive deadlines, competitive pressure, staffing turnover, or new technologies. I mean the crazy shit: job abandonment, leadership coups, layoffs, acquisitions, deathmarches, feuds between your boss and their peers, etc.

This has two implications:

1. You must be confident enough to handle these things on auto-pilot without days and days to research, discuss, and prepare. You must be able to walk into the most fucked up situation you’ve ever seen and go “huh, alrighty then” and one-shot it.

2. You must be able to teach other managers how to handle these things, perhaps for the first time and without taking on too much yourself. You must be able to project the strength, certainty and warmth to put others into a positive and productive state of mind so they can rise to the occasion.

You won’t be able to do this without lots and lots of experience. This isn’t meant to be an ageist thing (you can collect experience fast or slow, this is the reason I could break into the executive ranks in my 20’s). You may be great at generalizing concepts, but these will come at you so fast and so hard there will be no time to invent solutions from first principles.

There is no replacement3 for witnessing first-hand how these situations play out, how they react to certain interventions, and the playbooks world-class leaders and beacon companies have developed. This sort of exposure gives you not just concrete examples to follow, but builds your intuition and sensemaking capacity.

• Entering into a situation and figuring out what must have happened for the situation to have turned out this way, as well as which way the situation is headed unless something changes.

• Seeing how the things one does connect to other things that happen elsewhere.

• Being able to tell when things are subtly out of the ordinary, when things are about to go wrong, or when everything is in place for things to go right.

• Knowing techniques to extract feedback from a situation to improve one’s mental models, rearranging or combining steps in procedures to be more efficient.

• Being able to come up with alternative processes on the fly based on understanding of the situation.

• Keeping track of how well one is doing, and which the areas are in which one needs improvement the most (this is the reason experts don’t always need mentors the way beginners do).

The 142 Horrors of Management

Without further ado, here is a selection of situations and experiences you must have navigated previously to be considered “ready” for upper management (or were proximate enough to pick up the know-how 2nd hand):

1. Employees that abuse company-, state-, and federally-protected leaves to avoid accountability.

2. Employees that just straight up disappear without a word aka job abandonment.

3. Employees that weaponize HR/employee-relations/ombuds complaints against their manager to neuter performance management.

4. Getting sued by a competitor, customer, or employee.

5. Inheriting employees that were never given necessary feedback and puffed up by prior managers…now disappointed to not be showered with praise, promotions, and elevated ratings.

6. Managers that were given too many reports too quickly but aren’t willing to admit they are drowning.

7. Managers that skip standups, delay or cancel 1:1s, and generally spend all their time “away” from their team.

8. Managers that are badly calibrated and have fundamentally misled their entire team about the performance bar: failing to deliver feedback, inflating ratings, setting inappropriate growth expectations, and letting poor performers flourish…none the wiser that they are in for a reckoning.

9. Managers that ignore/violate company policy out of self-interest, creating other secondary issues, all while concealing everything from you4.

10. Managers that don’t explain the vision or strategy to the team and just say “we’re doing X because the big boss said so” cratering employee engagement.

11. Managers that foment resentment for company leadership and direction by constantly projecting their disillusionment and personal issues.

12. Managers that don’t know how to code or even how their own systems work or outright refuse to “be technical.”

13. Convincing a team of managers to also code and contribute directly even though the people leaderships parts of their job take 60+ hours per week.

14. Cross-functional partners (PMs, designers, customer support, account executives, whatever) that are doing their jobs badly and it’s affecting your team.

15. Support functions (SRE, Developer Experience, QA) that are run poorly but also tax all incremental headcount you receive. Negotiating and renegotiating headcount allocation to these functions.

16. Cross-functional partners with radically different priorities and no interest or incentive to align with you and the engineering teams more broadly.

17. PMs micromanaging your team and stepping on the toes of your engineering managers. Bonus points if the PM is really bad at engineering management and its actively making the team run poorly.

18. PMs/TPMs creating excessive processes and ceremonies that slow down your team and create the appearance of work without actual progress or results to show for it.

19. PMs without any product strategy and unwilling to take any feedback or let engineering fill in the missing strategy.

20. PMs with a terrible product strategy that engineering leadership politely ignores while doing their own thing.

21. Engineering leaders letting a PM’s “pet project” get staffed knowing full well it’s a terrible idea and not worth the team(s) that will be sacrificed to make it happen.

22. Large market-, location-, and macroenomic-driven decreases to compensation. We’re talking 10-40% decreases in total compensation.

23. Withholding yearly bonuses due to individual or even company-level performance misses.

24. Delivering and backing performance results you do not agree with.

25. Shielding an employee from adverse action that is wholly unjustified and an overreaction to a minor mistake that caused no harm5.

26. Trying to retain a critical employee who walks into your office with a counteroffer for >=100% of their current total compensation.

27. Critical vendors and infrastructure providers going out of business.

28. Critical open source dependencies going closed source, changing licenses, or losing all maintainers.

29. A sev0 security vulnerability is discovered that is being actively exploited.

30. A security researcher is threatening to publicly disclose a sev0 vulnerability faster than you can possibly fix the issue.

31. You have permanently lost or destroyed customer data with no choice but to beg for forgiveness (and/or spend $millions on data recovery services that don’t work half the time).

32. A major whale ($xxx millions in annual revenue, important logo or reference for customer acquisitions) is threatening to churn. You build what they want and they churn anyways…all under your watch.

33. An employee is using their elevated production access to steal/exfiltrate customer information or just to find funny stories to gossip about and earn street cred.

34. An employee is using their elevated production access to stalk their ex-girlfriend (yes this really happened).

35. Finding out one of your employees is a spy for nation-state actors and was effectively raised in a lab to infiltrate your organization.

36. Dealing with audits by government and public-private partnerships where failure can result in going out of business or losing hundreds-of-SWE-years to closing perceived noncompliance.

37. Interpreting compliance standards and government regulations. Determining how they impact your business, and organizing an effective response.

38. Rolling out a necessary breaking change to your product or API that affects hundreds or even thousands of customers and partners. Landing this without destroying your entire business.

39. A forced migration mandate that comes at the exact wrong time when your team has no resources or the “new thing” doesn’t meet any of your needs. The owners of the platform aren’t willing to compromise or meet your needs.

40. An internal platform you depend on decides it’s deprecated and their VP tries to dump it on your lap and make it your problem because “you’re the biggest user, so you maintain it!”

41. You inherit a team of lifers (people who have been at the company for 10+ years) and must somehow break and change all of their accumulated bad habits.

42. You inherit a team with serious issues (operations, reliability, code health, velocity, etc) and must design and land a turnaround effort in a fixed amount of time with no formal support from leadership and partners actively escalating every mistake.

43. You inherit a team with a terrible reputation with partners and stakeholders. The bad reputation immediately poisons the entire org against you and all of your ideas.

44. You have a very good idea but, because it’s vaguely similar to someone else’s previous boondoggle, you can’t convince anyone to give it a try.

45. Employees dealing with personal crises including divorce, death of a partner, miscarriages, or medical disasters.

46. Employees that are having back-to-back children and go on a string of paternity/maternity leaves lasting 3+ years.

47. Employees experiencing psychotic breaks. I have had multiple employees have their first schizophrenic episode at work (the typical onset age is mid-to-late 20’s after all).

48. Employees that show up to work drunk…and then openly admit that fact in the 9 AM standup while slurring their words.

49. Employees that become violent or irreconcilable after receiving bad news…having to covertly page security while trying to talk them off a ledge.

50. Employees that have brought weapons into the workplace (large knives, guns) and make vague allusions to having/using them in tense conversations.

51. Employees sexually harassing each other. Employees from different reporting lines harassing each other. Harassment cases being brought forward 2-3 years after the fact and HR being utterly unwilling to acknowledge or take action.

52. Manager-report sexual relationships…even fully consensual, loving relationships that turn into marriages. Moving employees around to fix/prevent conflicts of interest.

53. Employees dating each other, breaking up, and then not being able to work together or remain civil. Bonus points for a full-blown employee love triangle.

54. Employee accidentally screen shares pornography, at best permanently destroying the vibe of the team and at worst leading to a sexual harassment claim.

55. Employee that pays personal bills on the corporate credit card. Employee that submits an expense report from a strip club.

56. Employees that steal intellectual property as part of exiting the company.

57. Employees who WFH and are married to employees of competitors who also WFH.

58. Talking to the press, representing the company in a paper of record, speaking at a conference, or talking directly to high-profile customers who are both technical and non-technical.

59. Dealing with the leak of a top-secret feature months before launch due to something stupid like a string or enum constant compiled into a binary.

60. Back-to-back major/huge production incidents that get covered on the front page of a major publication (NYT, The Verge, Bloomberg, etc). Orchestrating and leading a major turnaround effort to solve such issues even when there is no executive appetite for funding such a large initiative.

61. Convincing someone to take a new role on a different team, or a role they are not excited about, because it’s what’s best for the company.

62. Joining a new org and immediately having your job changed to something else you would not have accepted otherwise.

63. Reorganizing a team to comply with org design mandates (depth, span, location, etc) you do not personally agree with.

64. Inheriting a large org (100+) and being immediately forced to conduct a reorg with zero context or personal on-the-ground knowledge of the new team. Landing said reorg in less than 30 days without disrupting any in-progress projects.

65. One of your peer leaders quiet quits and you’re forced to dotted-line manage their entire org so that your own project/goals don’t implode.

66. One of your peer leaders is so bad, all of their directs are coming to you for mentoring and coaching…doubling your effective number of direct reports.

67. A peer reneges on a commitment that dooms one of your projects because a new SWE or PM leader came in and flipped the whole roadmap upside down.

68. A peer tries to convince your manager you should report to them instead. A peer tries to convince your manager to steal one of your teams and give it to them.

69. A peer renames one of their teams in a way that creates an implicit land grab, overlapping with part of your scope and creating uncomfortable conversations about reporting structures and project ownership.

70. You become the boss of one of your peers who is upset they were passed over for the same role and does not respect you.

71. You elevate a member of your team, enraging their peers who believe they should have been picked instead.

72. You delegate a high-impact project to a trusted report. Your other reports become jealous and upset, believing they were entitled to that project.

73. You own legacy systems that no one understands. There is a major incident in said system and the whole response team is just guessing-and-praying their way through the incident.

74. Your boss or a peer commits the org to a massive initiative without consulting you, while also supplying a cost estimate and delivery timeline that is wildly out of alignment with reality.

75. In response to a resource crunch, your boss says you’ll just have to reprioritize your roadmap to make it work. They refuse to help soften the message with their cross-functional peers leading to an outright war between product and eng.

76. A critical employee has their promotion shot down by committee and you have to find a way to retain and keep them engaged.

77. Said employee gives up and effectively goes cold fish, falling from HiPo rising star to PIP in a matter of weeks.

78. A peer tries to promote a “toxic 10x’er” that will inevitably destroy the company, it’s culture, and team morale. Everyone is on board with the promo and you’re the only person in the room advocating against them.

79. Running a product discovery process, design sprint, or POC spike, leading cross-functional peers to define an entirely new direction or initiative without formal support or sponsorship from the org.

80. Fixing a broken product/technical strategy when you don’t have formal authority over the strategy. Bonus points if your boss thinks capital-S “Strategy” is a waste of time.

81. You launch a feature and the user feedback is poor, the data shows conflicting results, and the press lampoon your product. You must successfully pivot and recover in a matter of weeks or your boss will pull the plug cementing defeat.

82. An executive forces you to launch a low-quality, unfinished feature and whitewashes the narrative for their own gain. You are left cleaning up the mess and will get no rewards for that because “the project is done!” so all of that is invisible work.

83. Your boss or a peer lies to you, convincing you that “the CEO said we must do X” or “we have an important VP-level review coming up” causing you to burn personal credibility to get things done faster.

84. Your boss is fighting with a peer leader and using your team or project as the battleground…delaying decisions, pushing back delivery dates, removing staffing, and generally doing anything other than worrying about the actual customer.

85. Your company enacts a hiring freeze and zeroes the travel/fun budget causing massive employee anxiety. As people quit, you don’t get any backfills.

86. You must layoff >=10% of your workforce, and also pick the victims on your own with less than 1 week to turn in your homework.

87. You must outsource an existing function staffed by FTEs. You are personally responsible for identifying, selecting, and managing the outsourcing agency.

88. You must rebuild an existing team in a cheaper location (India, Brazil, Poland), including somehow bootstrapping a hiring pipeline in those locations with limited support.

89. You must close an entire office and either relocate employees or force them to WFH. You must not only deal with the mechanics of the staffing changes, but also all the procedural aspects of evacuating a building.

90. Your directs are not growing fast enough so you hire in a more senior leader so you don’t drown. You must somehow convince your existing staff that layering is not the end of the world nor does it cut off their avenues for career growth.

91. Your boss quits, is laid off, or fired unexpectedly, forcing you to rebuild credibility with an entirely new cast of stakeholders. Bonus points if it leads to you getting reorged under a peer that you and your boss previously hated and with whom you were in open conflict.

92. A manager on your team quits or goes on extended medical leave, forcing you to manage 20-30 direct reports. Bonus points if it overlaps with annual performance reviews, promotions, and compensation planning.

93. Your boss quiet quits and just starts passing everything off to you unfiltered. You are now on the hook for way too much and half of it makes no sense.

94. Purchasing COTS, including negotiating a contract with the vendor, running a proper bake off, dealing with dog shit account reps and sales engineers, and getting the budget approved when no one in your org has bought something externally in 10+ years.

95. Buying or renting physical datacenter space. Figuring out the mechanics of actually paying for this in your labyrinthian purchasing organization.

96. Prepurchasing cloud capacity and trying to forecast compute demand for a feature you haven’t launched and have no historical data to anchor your estimates. Getting it wrong would be a disaster (underbuy == can’t launch; overbuy == go bankrupt).

97. Determining a production incident is actually caused by a Cloud issue, and escalating an incident to AWS/GCP (who are famously super accessible and not prone to just ignore you / blame the user / route you down endless phone trees).

98. Building personal connections with high-ranking engineers in AWS/GCP so you can call in favors when the above inevitably happens again.

99. Going full Karen on a vendor when they breach SLA or otherwise screw up your business and extracting an ounce of flesh (discounts, favorable renewal terms, SLA penalty kickbacks, etc).

100. Creating an industry alliance, taking control of, or otherwise influencing a standards group to ensure it supports your business objectives.

101. Leading a total rewrite and migration of a mission critical system.

102. Taking over a struggling rewrite/migration project that is multiple-years late and actually finishing the thing.

103. Inheriting a project that costs 50+ SWEs and has been running for 3+ years that you fundamentally disagree with and somehow navigating the sunk cost fallacy when sunk cost is measured in the hundreds of millions of dollars.

104. A new policy is implemented, causing a multi-year initiative to get blocked during launch readiness review and threatening a multi-quarter delay.

105. The annual employee satisfaction survey reveals deep dissatisfaction and unrest that you were otherwise not seeing in day-to-day interactions.

106. A product launches just to immediately discover a P0 bug or security vulnerability. The launch had so much PR and fanfare attached to it, it’s impossible to rollback.

107. You discover a major bug or data issue that has been hiding for years that calls into question hundreds of decisions and assumptions.

108. Determining when to utilize contractors. Selecting suppliers and managing contingent workforces. Firing contractors that do not meet your expectations.

109. Having a recruiter lie to you and misrepresent a candidate’s credentials in order to get their friends hired.

110. Hiring someone only to have a completely different person show up on day one because they paid someone to take the interview for them. HR will not let you fire them, meanwhile they fall short of expectations and require constant management.

111. Negotiating with a peer to take ownership of a legacy system.

112. Negotiating with a sister team to let you contribute a feature/fix to code they own.

113. Getting an item prioritized on a peer’s roadmap when they are under strict orders to say “no” to everything.

114. You get a new manager with a totally different approach to management that you know will not work (you tried it before), but who gives you a strict deadline to refactor your team and ceremonies anyways.

115. A report gets into a fight with a peer. The relationship decays to the point that neither party is willing to negotiate or compromise.

116. You flag to a peer manager some rude, hostile behavior towards your team. The manager suggests that your team deserves it because they are incompetent.

117. You have a team full of Ukrainians when the Russia/Ukrain conflict breaks out. You have a team full of Jewish people/Palestinians when the Israeli–Palestinian conflict heats up. Nothing in manager training prepares you for an employee answering “how’s it going?” with “my hometown blew up.”

118. You have a team of Indians who are covertly implementing caste discrimination in the US.

119. You build a platform that would be useful across the company and must convince your peers to adopt said platform.

120. Someone else builds a platform they think would be useful, but it’s not and would be a waste of time to adopt. They attempt to use an org-wide mandate to force the issue.

121. You make a promise or commitment to a peer assuming you can make it happen…only to have your boss overrule you or suggest the exact opposite.

122. Your peers have technical beliefs that are antithetical to everything you know about building good software. Convincing them of anything is an uphill battle.

123. Someone claims credit for something you or your team did. Attempting to call that out just makes you the problem.

124. Your report has a completely skewed view of reality and assumes the worst in everyone and everything. Bonus points if this was the result of an unchecked rumor circulating through the org.

125. Your report is underperforming but fundamentally disagrees with your feedback.

126. You have a very senior report (senior staff/principal/whatever) that has needed to be fired for years but has been smart enough to out-maneuver the last 5 managers who tried. It’s your turn.

127. You have a manager that needs to be fired but, because their team is relatively competent and carrying them, it’s difficult to produce sufficient evidence to convince HR.

128. Your employee has saved up 3+ years of vacation and takes it all at once, disappearing for an entire quarter.

129. Your HRBPs only quote policy at you and don’t actually collaborate to solve problems.

130. Acquiring companies including running technical due diligence. Running due diligence when the company is clearly trying to cover up problems so you don’t buy a lemon.

131. Getting acquired including answering due diligence questions. Having your CEO pressure you into concealing problems so you don’t blow up a deal.

132. Planning and leading post-acquisition integration projects.

133. Running a successful offsite that isn’t just an excuse to expense a bunch of fancy dinners and liquor.

134. Bonding a new senior leadership team and creating psychological safety amongst the most competitive subpopulation in the entire corporate world (middle managers).

135. Upskilling and developing the capabilities of a large team; scaling beyond individual 1-1 coaching.

136. Hiring and importing external talent to inject necessary cultural attributes, technical know-how, and leadership traits into the team.

137. Building your own hiring pipeline when centralized recruiting and sourcing let you down.

138. Running your own bootleg interviewing process when the centralized interview process is too lax and passing bad candidates.

139. Detecting and filtering out internal transfer applicants who are evading performance management.

140. Detecting when a peer manager is trying to pawn off a terrible employee onto your team and actively concealing performance problems.

141. Company- or org-wide pivot into a new area, product line, or strategy requiring a complete overhaul of team priorities and responsibilities.

142. A venomous snake gets into the office and somehow it’s your problem because…manager?

Dear reader, I have dealt with every single one of these in the last ~5 years (that’s >30 per year…and a lot of these happen on a recurring basis). I literally made this list by just mentally recounting all my screwed up experiences. This is not theoretical. You must be both intellectually capable, resourceful, connected, and emotionally prepared.

Oh, by the way, thanks to ✨GenAI✨, do all the above while also pushing 5-10 PRs a week because something-something-managers-are-technical. Lord have mercy on us all.

So, returning back to the original premise. When you ask for greater scope and a larger role, what I’m really judging is whether you can deal with all these things without my help. I’m using previous situations you’ve handled to benchmark how you show up when the going gets rough and how well you’ll ad-lib your way through the inevitable novel curveball.

There’s a lot of vibes and assumptions built into that snap judgment, and trying to compress that down into actionable feedback is borderline impossible.

Passing the “can you hang?” test

Even if you’ve done all of the above, there’s still one more hurdle to clear. This is the fuzziest and most damning criterion of them all:

Can you hang? Do I actually want to talk you? Does talking to you lower or raise my cortisol? Do your fellow senior leaders want to talk to you? Or do we all just tolerate you in exchange for some amount of finished work product?

Look, I know this sounds horrible. Please don’t cancel me, this isn’t my invention but rather just how the world works and I’m trying to give an honest blueprint for breaking through the glass ceiling.

Getting promoted into senior leadership means I have to spend A LOT of time with you. Your peers have to spend A LOT of time with you. The job is mostly upwards and sideways: aligning with peers and leadership on where we need to go and anticipating problems that would stop us. If I have to filter myself, or code switch, or do a lot of breathless exasperated preaching to get you to do anything, or generally put on a performance in front of you, that’s exhausting. Why would I opt-in to that fate?

Moreover, for my job to be possible, my closest confidants need to largely be on the same wavelength as me about what the job is, how to approach it, and what excellence looks like. I don’t have time to teach or convince you. That doesn’t mean being a “yes man” but we better hold a lot of shared beliefs, principals, and context so we can approach disagreements from a common lexicon.

A corollary to this: can you talk to my boss without embarrassing me? Everything you say or do reflects on me…especially if I’m the one who promotes you into senior leadership. On multiple occasions I have been Slacked by my boss with a screenshot of some coked-up nonsense a report has sent them along with “?????”

Last, but certainly not least, is remaining cool under pressure. You must have extreme emotional regulation and reserve your outbursts for private moments and safe spaces. You lose all credibility with key stakeholders and peers when you appear tilted. Your team will become anxious and distracted. I will start filtering and censoring what I share with you to avoid multiplicative hysteria which will be the beginning of the end.

Being in senior leadership means getting a steady drip feed of nightmare-inducing news delivered to your inbox. To thrive, you must value conflict as inevitable in relationships, comfortably hold conflicting/opposing ideas in your head, and flex your approach/beliefs/identity depending on the situation. Fewer than 1% of the population has the emotional regulation to do this according to some adult development theories.

When will you be ready?

1. You are dissatisfied by the status quo and actively seek challenges to do what’s right for the company. You can identify these opportunities and pursue them without anyone spoon-feeding you.

2. You have accumulated a repertoire of experiences handling the dark side of management. You can juggle tens of these things simultaneously and even delegate/coach your managers through handling most of them.

3. You show up as a true peer to other senior leaders and your boss…someone they seek out as a source of calm, support, and camaraderie…someone with whom they look forward to scheming and have confidence can turn talk into action.

Everything I’m describing here is judged in the eye of the beholder which is why there is some truth to the importance of visibility, reputation, and brand. That said, getting fixated on appearance management and self-promotion misses the real issue: the gap in experience and demonstrated ductility in the face of disorder.

No single project or moment will flip the switch from “not ready” to “ready.” Take stock of the sorts of experiences you’re missing, and then seek out the discomfort of confronting such situations head on. Switch teams and switch companies if you have to; do not wait for your manager to deliver these opportunities on a silver platter.

If you’ve spent five minutes in a C-suite meeting, you know the drill. Sales is scrutinized. Marketing spend gets interrogated. Then the group reaches the R&D line item, the multi-million-dollar software engineering budget, and everyone just… blinks.

Engineering is the ultimate “black box” in financial accounting. We produce an intangible asset that traditional balance sheets struggle to value. So we use weak heuristics to allocate our most expensive resource: engineering talent.

During the ZIRP era, nobody cared. We threw seven engineering teams at problems that needed one and built a maintenance death spiral. But the party is over. Margins are being compressed, AI is turning software into a commodity with actual COGS again, and “cutting the R&D fat” is the new favorite pastime of private equity.

Before ZIRP, there was at least an attempt at scientific management: heavy project management, estimating frameworks, and cost-accounting machinery (IBM Rational, anyone?). It still failed to make software organizations legible; it mostly added bureaucracy.

As of 2026, our industry still lacks a standard control system.

The DuPont Alchemists

To understand how to fix this, look back to 1912. DuPont developed what became the DuPont Equation.

Before this, Return on Equity (ROE) was a single output metric: useful, but not diagnostic. DuPont decomposed ROE into factors that cancel algebraically but reveal what is actually driving performance.

By looking at Profit Margin (Efficiency), Asset Turnover (Productivity), and Financial Leverage (Equity Multiplier), a manager could see exactly where the engine was knocking. If ROE was down, was it because they were bad at selling, bad at using their factories, or just under-leveraged?

More importantly, it helped you determine the most basic truth of business: Are you actually doing better than just selling everything off, liquidating the furniture, and sticking the money in a boring S&P 500 index fund? If your ROE is lower than the market average, you’re just playing a very expensive game of “make-believe business.”

While you could use ROE out of the box, it misses key dynamics of software economics. Its diagnostic utility for a software division is limited.

Software is a Factory, Not a Lab (Sorry)

Before I show you the math for software, we need to clear the air.

Most people—including many engineers—think software’s value is found in some abstract concept of “innovation.” They think we are in a laboratory, mixing chemicals and hoping for a breakthrough. That’s nonsense.

Software is a produced good. It’s a weird, magical good with near-zero marginal cost of reproduction, but it’s a produced good nonetheless. Once you build the system, serving the 10,000th customer should cost almost nothing compared to the first. The unit economics are hard to beat. This is my read of Marc Andreessen’s seminal Why Software is Eating the World.

The catch: you only realize those margins if your engineering is actually good.

High-quality engineering is not about “clever” code; it is about systems that are cost-effective to operate, adaptable to new demands, and easy to expand without a rewrite every 18 months. If the architecture is brittle, you lose the software advantage and end up hiring people to compensate for what the code should do. Your “software company” will have the margins of a manual car wash because you’re hiring armies of SREs just to keep the lights on.

We are not chasing “innovation” for its own sake. We are chasing margin expansion and preservation. The goal of an R&D division is to widen the gap between revenue and the cost to the machine. Even more paramount, we must be widening the gap between revenue and the cost of expanding the machine. Software cannot afford to be static.

Software is not a permanent asset; it is a depreciating asset. In fact, it’s one of the fastest-rotting assets on the planet. The moment you ship code, the world starts conspiring against it.

• Competitors launch similar or better features (e.g. Apple’s “late-mover” advantage).

• Customer tastes change without warning or cause (e.g. viral trend cycles and generational dynamics).

• New players can move more freely without the burden of accumulated feature complexity and tech debt, granting them both velocity and margin incumbents will struggle to replicate.

• Platform paradigms evolve and force rebuilds (e.g. from desktop apps to web apps).

• Technological breakthroughs raise user expectations for what software must do (e.g. you can’t become a billionaire just shipping a “database with a CRUD UI” as was the case in the early 00’s).

If you stop moving, your software doesn’t just “stay the same”—it becomes a liability. To stay relevant, you have to continually add features and capabilities just to maintain parity with the market. This is the “Red Queen’s Race” from Alice in Wonderland:

“My dear, here we must run as fast as we can, just to stay in place. And if you wish to go anywhere you must run twice as fast as that.”
― Lewis Carroll

The Equation: Return on R&D

To measure the health of a software division, we look at the relationship between Free Cash Flow (FCF) and Operating Expenses (OpEx).

Like the DuPont model, the terms cancel out, leaving us with a clear picture of how much cash we are generating for every dollar of operating spend. It solves three specific problems:

1. The Allocation Crisis: it answers the question, “should the next million dollars go to Marketing or R&D?” If Return on R&D is falling, adding headcount without a plan is like pouring water into a bucket with a hole in the bottom.

2. The Fog of War: we can track a thousand engineering metrics (sprint velocity, story points, deployment frequency), but most are local signals. Remember The Goal? The Goal is to make money. This equation gives you the bottom line for the technical organization.

3. The VPE Stress Test: it makes R&D organizations comparable. You can evaluate whether engineering leadership is building a scalable engine or growing an inefficient cost center.

1. Operating Efficiency (The Overhead Trap)

This measures your Run the Engine (RTE) or Keeping the Lights On (KTLO) overhead. OpEx captures things like support, cloud bills, rent, and non-capitalized payroll. CapEx is the investment in the software asset itself. This ratio tells you how much operations overhead is being generated for each unit of software produced. If this number is high, your software is a thinly veiled shell around a bunch of humans–it requires a massive operational apparatus just to exist.

Examples:

• Out in the industry: legacy banks produce “new” features, but the sheer weight of “Asset Drag”—the human and server cost required to keep 40-year-old COBOL systems running on mainframes alive—means OpEx is massive relative to new software output.

• How this showed up in my own experience: I advise an early-stage startup, Swell. Its first incarnation was a teletherapy app for military members and their families. The product handled onboarding end-to-end—psychometric profiling, intake questionnaires, therapist matching, scheduling—and hosted the sessions themselves over video.
  
  Growth was respectable, but the operation was leaky and painfully manual. Users would no-show the first appointment and burn therapist capacity. Others dropped out mid-scheduling. If a therapist needed to reschedule, it triggered a torturous game of phone tag. And despite having “onboarding” in the app, the team still needed a human phone call to verify insurance, collect consent forms, and put a credit card on file for copays and no-shows. It got us to market faster, but it didn’t scale
  
  In practice, chasing funnel drop-offs, collecting billing details, untangling scheduling, and handling insurance snafus consumed 1.0–1.5 FTEs—in a company with only a couple of employees. That overhead ate scarce capital (fewer dollars for engineering) and drained the founder, who was also acting as de facto Chief Product Officer. Product development slowed, which meant the system never got the automation it needed to stop leaking in the first place. When Swell later pivoted upmarket to an “employee benefits” provider, the manual OpEx didn’t magically disappear—but the payoff per customer was much higher, so the same operational pain became temporarily tolerable.

2. Free Spend (The Innovation Ratio)

This captures how much of your R&D is discretionary. Software CapEx splits into Growth and Red Queen (maintenance/parity) spend. Some investments are pure revenue defense. Example: “Competitors added an AI assistant, so we need one to stay viable in RFPs.” That may not expand margins, but not doing it can accelerate depreciation and sales decline.

This also includes forced migrations (e.g., cloud deprecations or replacing a critical OSS dependency). For this equation, I treat these as CapEx not OpEx because if you freeze time the software could theoretically keep operating in perpetuity without that spend.

Ideally, most CapEx is Growth CapEx: dollars allocated to your differentiated product strategy that should drive outsized margins in the Product Investment Yield term.

Examples:

• Out in the industry: early rideshare wars between Uber and Lyft. When Uber made it easier to find your driver at a busy airport by introducing a “chat with driver” feature, then Lyft had to respond in kind–otherwise users would over time choose the lower friction experience leading to churn. This isn’t a growth feature–there is no moat or differentiation–it’s pure defense.

• How this showed up in my own experience: At Verve (now part of Rockwell), we built a kind of SIEM for industrial control systems—what the industry lumps together as “Operational Technology” (OT). The product had surprisingly strong product-market fit despite being almost offensively simple. At its core, it automatically inventoried industrial assets and produced reports: what devices you had, their patch status, and known vulnerabilities. For many industrial operators, this was a brand-new capability—and in the wake of Stuxnet, CISOs were suddenly demanding answers. Before long, regulations like NERC CIP weren’t just encouraging this kind of visibility; they were effectively mandating it.
  
  But even with pull from the market, we kept getting dragged into bad comparisons. We’d walk into RFPs and find ourselves benchmarked against generic SIEMs and IT patch-management tools, then lose on superficial reasoning (“How is this different from Splunk?”) or checkbox feature gaps (“Dragos has anomaly detection—why don’t you?”). The anomaly-detection demand was the most maddening. It sounds incredible in a slide deck, but anyone who has built one knows the dirty secret: there is no universal “find all the weird stuff” equation. These systems are typically noisy, they generate endless inactionable alerts, and they can become net-negative operationally—especially in environments where every false positive costs real time and real risk. They’re also expensive to build, tune, and maintain.
  
  Eventually we caved and shipped basic dashboards—not because they were strategically important, but because Sales needed a box to check. These things barely worked and weren’t meant to actually get used (much like the food in Swedish bars) but they had to be there or our sales would have flatlined.

3. Product Investment Yield (The Product-Market Fit Test)

For every dollar of growth spend, how much sales revenue did you generate? If this ratio is low, you are likely building the wrong things, mispricing them, or failing to sell them effectively. “Clever” engineering that does not solve a customer problem does not compound value. Everything you build must enhance the value proposition of your product either by capturing new users (increasing TAM) or by increasing revenues extracted from the existing users (increasing LTV and willingness to pay).

Examples:

• Out in the industry: specialized ERPs like Epic Systems in healthcare. They spend heavily on R&D to keep up with regulations and cover more of the healthcare lifecycle. Deep lock-in and regulatory capture have created strong pricing power which means each unit of Growth CapEx can return outsized revenue.

• How this showed up in my own experience: at Microsoft, I helped build Shielded Virtual Machines in Hyper-V: a capability that let a VM run on a host without the owner of the server—or any of the software on it—being able to see inside. The goal was to make the host untrusted by design. We leaned on then-new platform primitives like TPMs, cryptographic attestation, and a rigorously verified from-scratch microkernel (the “SMART kernel”) so a shielded VM would only boot on hardware that could prove it hadn’t been compromised and was running genuine, unmodified Microsoft firmware and code end-to-end.
  
  This was peak “rise of cloud” (circa 2015), when plenty of enterprises still insisted they could never move their most sensitive workloads off-prem. Even today you see variations of the same trust problem—companies refusing to run on infrastructure owned by a direct competitor (e.g. retailers refuse to use AWS). Microsoft’s thesis was straightforward: if we could make the host provably trustworthy (or at least provably measurable), we could pull security-conscious customers into Azure and also equip third-party hosting partners to do the same.
  
  It was a truly stunning effort: years of engineering, collaborations with hardware manufacturers, new industry protocols and standards, and a huge go-to-market motion with OEMs, hosting providers, tech reporters, and MSPs like Acenture…it was probably the most innovative thing I ever worked on. And yet, it totally failed from a market perspective. We didn’t sell more Windows Server licenses because of it, at least not relative to the huge CapEx cost. Today, when you Google for this feature, all that comes up is some crusty old TechNet documentation (that I helped write lolsob). I’m not sure any normal human ever used this thing.

4. Growth Efficiency (The Reinvestment Buffer)

This measures how much discretionary cash the business retains after operating and reinvestment demands. The efficiency with which sales convert into free cash depends on OpEx overhead and Red Queen CapEx. High-quality engineering should lift this ratio over time as marginal delivery cost per customer drops. Importantly, just improving sales income does not improve this ratio (the sales income is also part of the FCF calculation). The only way this ratio goes up is when leverage/margin go up.

Examples:

• Out in the industry: Atlassian (Jira/Confluence). Atlassian is a great illustration of the Reinvestment Buffer because they built a business where scale doesn’t require a proportional increase in humans. Their product-led, low-touch distribution and standardized cloud delivery mean a new customer is mostly incremental compute—not incremental headcount. When that machine is engineered well, revenue turns into discretionary cash at a high rate. Atlassian’s reported free cash flow margin (FCF/Sales) has reached the kind of territory—37% in FY24 Q4—that lets them fund R&D, acquisitions, and platform rebuilds without “turning off innovation” or begging capital markets for oxygen.

• How this showed up in my own experience: When I worked on Google Workspace, we shipped a brand-new video editor: Google Vids. This was the first new “editor app” we had launched since 2008—and it targeted the heaviest document type you can support: video. Now add the thing Workspace is famous for: real-time collaboration. And to make it even more ambitious, Vids was designed as an AI-first editor—helping users generate voiceovers, narrator avatars, and even transform boring decks into videos (still boring, just rendered at 30 FPS).
  
  On paper, this should have been a generationally expensive initiative. Worse, it wasn’t obvious there was easy TAM sitting on the table. Most remaining headroom was locked inside large enterprises that wanted to switch but couldn’t stomach retraining entire organizations. The bottleneck wasn’t “we lack a video editor.” In the naive model, the outcome is predictable: flat sales and a big dent in free cash flow.
  
  The reason it didn’t play out that way is that Workspace had a structural advantage: over many years we had invested in a robust editors platform—the shared substrate that makes it possible to run five or six different collaborative editors without reinventing the universe each time. That platform wasn’t narrowly optimized for docs and spreadsheets; it was built to accommodate very different workload shapes, from slides and vector drawings to richer media. Because that foundation already existed, building Vids was plausible—and more importantly, plausible without letting Growth CapEx explode. It still wasn’t “easy,” but the cost curve was governed by reuse rather than reinvention.
  
  That’s the punchline: platform investment is a growth-efficiency amplifier. It increases your reinvestment buffer by making large bets cheaper to place. Instead of spending like a startup every time you ship a new product surface, you get to compound prior CapEx into new revenue opportunities—in our case, higher LTV through premium capabilities, and potentially more seats as video becomes a default medium for business communication (Loom, anyone?).

Putting the Equation to Work:

When you run these numbers, the “shape” of the equation tells you exactly what kind of mess you’re in:

1. The Legacy Death Spiral: high Red Queen CapEx, low Operating Efficiency, and flat Sales. You are spending all your money just to keep a rotting asset alive.

2. The PMF Crisis: high Growth CapEx but low Product Investment Yield (ratio < 1.0). You are building things people do not buy. That is usually a product strategy or go-to-market problem, not a pure engineering problem (see Brian Balfour’s Four Fits Framework).

3. The Mechanical Turk: low Operating Efficiency (OpEx is huge relative to CapEx). Your software is buggy and unreliable. Every feature you add just makes things worse. You are hiring armies of SREs and support staff to do the work the code should be doing.

4. The Competitive Pressure Cooker: high Growth CapEx, but your Red Queen spend is climbing even faster. A hot market with many competitors is creating tons of pressure to expand; a venture capital proxy war is waging with you and your company on the frontlines. Zero to One talks about this (“competition is bad”) and Blitzscaling is a wonderful case study of the dynamics in such markets.

You can play with the variables in this sandbox I made to get a feel for how this works:

Return on R&D Interactive Sandbox

Edge Cases and Alternative Formulations

Grow First, Profit Later

This equation can be “punishing” for companies that aggressively reinvest for future growth (Amazon is the classic example). If you recycle nearly all FCF into Growth CapEx, Return on R&D can look weaker than a mature incumbent.

You have two options: “pro-forma” planned growth CapEx to estimate steady-state return, or take the reported hit. I prefer taking the hit. Until growth CapEx becomes sales, you do not know if the business is healthy. Some of that growth spend may actually be Red Queen work in disguise.

Complex Financials

There is a surprising amount of “opinion” encoded in figures like profit. That may be acceptable for board and analyst reporting, but it is weak for operating decisions in engineering.

Because software is intangible, capitalization and depreciation choices are often judgment calls. For a platform investment, you might value it using build hours, unlocked deal volume, or a fixed share of R&D salaries. Each method yields a very different number.

Another similar phenomenon: it’s become shockingly common to count inbound revenue (aka receivables) as part of revenue. This is really common with large material transactions (datacenter hardware) and, especially, enterprise software where Net 90 invoices are increasingly common. The problem is: This. Isn’t. Actual. Money. Not yet at least. Nvidia has been using this trick on their financial reports which inflates revenue figures and pumps more air into the AI Bubble which surely won’t implode and kill us all in the process. No siree.

No word on if any of these receivables ever turned into dollars. Oh well, I’m sure everything is fine.

Bottom line, if your business features a lot of delayed payment cycles or complex financial engineering, factor all that crap out. Maybe instead of pure free cash flow, you use (Net Income + Amortization + Depreciation – Maintenance CapEx).

No Visibility into Dollars and Cents

Even in established companies, getting real dollar visibility is hard. Public companies may restrict these numbers as material non-public information, so engineering leaders receive proxy metrics or redacted reports.

At Google, I managed a budget of >$60MM annually using a proxy metric called “SWE-hours.” How much did it cost to host Google Drive this month? xxxx SWE-hours. I knew more about the precise cost of our team t-shirts than I did the actual infrastructure. I’ll spare you further sarcasm–all deeper ironies aside it mostly worked and provided a stable operating signal. I did eventually flip a table and get access to the actual dollars, but it wasn’t a huge improvement over the proxy.

If you can’t get the dollars, use Time. A reasonably accurate accounting of “Engineer-Weeks” spent on Growth vs. Maintenance, combined with a standard “fully-loaded cost per engineer,” will get you 80% of the way there. If you have 100 engineers and 60 are on “Growth” projects, use that 60% ratio. It’s not perfect, and capitalization inconsistencies will haunt you, but an “inaccurate” number that you track consistently is infinitely better than the giant pile of nothing we have today.

Normalizing for Comparison

Comparing this metric over time or across companies only gets you so far. “The number is higher, therefore I’m doing better” is incomplete.

Software is about leverage over time. If investment decisions are sound and the product is well engineered, margins should improve as recurring work is automated away.

So the deeper metric is the first and second derivative of Return on R&D (rate and acceleration of improvement). If margin growth is flat year over year, you may be sustaining performance but haven’t really increased the efficacy of the engineering organization. Maintaining growth is good–don’t get me wrong, it might even be the appropriate strategy for your company depending on where it is in the product maturity curve–but then you have to seriously ask yourself what value you’re generating as an individual manager.

Finally, I’ll note the the math on some of these terms can become confusing if you take them without additional context. For example, Product Investment Yield can go to infinity as Growth CapEx goes to zero (which would typically be considered a bad thing, especially if it’s because you ran out of money, not because you found a product that prints money without investment). You could…

• Make sure to counterbalance this with compensating metrics like the raw Growth CapEx dollars. I’m not advocating that you ONLY look at these metrics anyways…it’s all part of a healthy balanced breakfast WBR.

• Use “% of R&D Spend allocated to Growth” which makes the term vary only with the proportional allocation rather than absolute dollars invested. I do this in the simulator above.

Putting This Into Practice

Most engineering conversations fail because they’re held in two incompatible languages. Engineering talks in systems; finance talks in cash.

Return on R&D is a translation layer. It takes the messy reality of platforms, reliability, tech debt, and forced migrations—and expresses it as a set of ratios that explain why the cash machine is (or isn’t) working. It doesn’t replace technical judgment; it makes technical judgment allocatable.

Here’s the key takeaway: you don’t win by maximizing any single term. You win by preventing the two classic failure modes:

• Spending into a Product Investment Yield void (building things nobody pays for).

• Spending Growth CapEx on top of a decaying asset (where Red Queen and OpEx eat everything you add).

If you’re a VPE, this becomes your operating cadence:

• Monthly: reconcile Growth vs Red Queen vs RTE.

• Quarterly: pick one term to improve and one term to defend.

• Annually: evaluate whether margin is compounding (the derivatives), not whether the roadmap was “delivered.”

And if you’re a CFO, it tells you when engineering spend is investment versus liquidation: when the equation’s structure says the machine will widen margins—or when it says you’re feeding a black hole.

The goal isn’t to measure engineers. The goal is to measure whether the software factory is becoming more leveraged—and to make that trend visible before it becomes irreversible.

If you’re reading this blog, you’re probably the sort of person who has heard the advice to Give Away Your Legos. It’s the notion that as your company scales, your job responsibilities will change very rapidly and necessitate letting new hires take over teams/projects/problems/functions that used to be your job, freeing you to go after the Next Big Thing™. The metaphor of “giving up your Legos” captures the notion that this will be an emotional process…just like letting someone play with your Legos as a kid. Will they break it? Will they build on to my super cool tower the way I want them to? Will they ever give them back? It’s hard to give up a team or function to which you dedicated yourself or maybe even built up from scratch!

Crazy startup rocket ship isn’t the only place where Legos must be given away. Anyone who has ascended the corporate ranks has encountered the need to let go of past responsibilities as a necessary prerequisite to doing the next-level-up job. You can’t focus on strategy and direction for a whole org if you’re still busy managing day-to-day execution.

What no one really talks about is how this comes up even when your company is shrinking. Hiring freezes, layoffs, chronic headcount crunches, forced stack ranks, and priority lists where most of it ends up on the cutting room floor. This is the new reality of tech and even the largest, most successful companies aren’t immune. In even these situations you will be faced with give-away-your-legos moments…but with a catch: there won’t be anyone to pick up your old responsibilities. Screw giving them away, you are straight up throwing your Legos in the garbage and it feels so much harder than just transitioning that work to someone else.

I really struggled with this recently. For years I was the overall technical lead of Drive’s serving infrastructure…everything ranging from the backends and networks that transfer/sync/deliver your data, streaming and transcoding, file viewing, to the APIs that power both 1st and 3rd party applications and the ecosystem of partnerships around that. Then the GenAI revolution happened. Over night we went from peacetime to wartime: all headcount was directed at AI investments, projects were cancelled, and teams were reorganized to ensure we could quickly secure Workspace’s role in the future of productivity. As a key technical lead and respected executor, I too was asked to drop what I was doing and dive in––specifically to help improve our search capabilities as both a critical user journey and a technical building block of RAG. The expectation was that I would completely drop my old responsibilities and focus full-time on the new problem. But here’s the catch: there was no one to take over in my stead. We wouldn’t hire a backfill, the local EMs were stretched to capacity, and no one waiting on the bench was even remotely close to being able to handle the role.

Without a clear successor, I was being asked to take my precious baby (platform and ecosystem) and drop it on the floor without a second thought. Those projects and teams would continue just without the support, guidance, and clarity of an uber technical lead. Good luck everyone! “Not on my watch,” I thought. All I needed to do was keep an eye on both things simultaneously. Jump in if any fires start, coach the EMs and TLs, review designs, all while pushing the envelope on search/AI…sure there might be a couple long nights but juggling a bazillion things is my professional brand. This should be doable…right!?

The result was very predictable. I spent 90% of my time tending to my old job and making sure everything was still going well while the search/AI work dragged on. The rest of the search tiger team moved on without me and I stopped getting invited to the meetings (not maliciously, mind you, people just literally forgot I was suppossed to be working on this thing). My boss’s feedback was equally predictable as she looked over my accomplishments week-over-week: “this is all valuable stuff so you can keep doing it….but it isn’t what’s most important to the business and I can’t really reward you for doing it.” Even then, I still couldn’t find the emotional energy or willingness to let go of my old demesne.

Why was this so hard for me? There was no one to take over. Letting go is one thing, but taking something you built and nurtured for years and leaving it in the woods to fend for itself is something else altogether. But this is exactly what the business was trying to do…intentionally! We had jointly agreed that the GenAI “moment” was an existential threat and that we couldn’t keep operating the status quo. A new product strategy was developed and my old domain was not relevant: this required some hard prioritization decisions where things like “partner ecosystem” fell below the cutline…lots of great Drive<->3P SaaS integrations weren’t going to propel user engagement and retention when entirely new ways of working were being pioneered by our competitors.

In a sense, there were two hypotheses we were testing simultaneously:

1. If we focus all our energy into AI transformation, does the market respond? Can we compete and offer something users find useful?

2. Can we put ecosystem/platform/APIs into maintenance mode without affecting our SUPER1 metrics? Do we really need a dedicated senior staff technical lead to keep the train on the tracks or can this area be run more efficiently?

By failing to throw away my Legos, I prevented the business from confirming or refuting either hypothesis. I won’t go so far as to say we “made no progress,” but we certainly did not gather any new information about whether our AI strategy pivot would work.

Successful Careers Thrive on Discomfort

Failing to give/throw away your legos leads directly to stasis. As in my story above, I was out of alignment with the business and not directly working on our top priorities. Go figure, that meant the center of attention (and with it the resources and growth opportunities) went elsewhere.

It may sound odd to talk about growth when we’re specifically analyzing a company that is in contraction, but any well-run org goes through periodic cleanup cycles. Cycles where unnecessary or overgrown functions are reaped, processes are tweaked with efficiency in mind, and anything deemed no longer serving the strategic focus of the system is expunged…all so that organizational energy is being directed disproportionately towards those activities which generate progress (i.e. market success). Rocket ship or not, you will encounter this eventually.

Failing to come along for the ride risks becoming obsolete or even outright vestigial (layoffs ahoy). Whatever good will and influence you built while Being Awesome at The Old Thing will go to zero. You’ll find your peers who did answer the call rising in the power rankings and next time a major opportunity rolls around you won’t even be asked/considered. After all, you’ve shown you can’t give up what you already have anyways. Diamond hands is not the right strategy here.

This means embracing discomfort….

• The discomfort of doing something new you’re not sure how to do just yet.

• The discomfort of having to re-prove yourself over and over.

• The discomfort of watching what you built previously struggle along without you.

This stuff is hard, it directly triggers multiple fundamental pathways in our brains that detect social threats. I call these the SCARFI threats (a very slight extension of David Rock’s social threat model):

• Status: going from King of the Hill to The New Kid is jarring. What if you fail? What if you never reclaim your crown?

• Certainty: the new thing is full of ambiguity, it’s not clear how it will turn out or whether this will be a positive experience.

• Autonomy: you used to be trusted to run your area, but now you’re just “part of the team” and your boss has likely taken a special interest in ensuring things go well.

• Relatedness: you’re likely being forced to work with new people and with it must handle the social anxiety of learning others’ ticks and tells while trying to build a real relationship.

• Fairness: what if the new thing fails for reasons outside of your control? What if someone else with more context or experience in this area wanders in and out shines me? Do I really have a fair shot at succeeding?

• Identity: you view your old role as a core part of your identity. “I’m the API guy!” Your sense of self and place in the social fabric is being forcefully rewritten and only time will tell if you like “the new you.”

Your brain will be screaming at you the whole time “turn back! defenses activate!” This is not your better nature speaking and the only way forward is cold rationality.

Chuck and Run: Overcoming SCARFI

What people usually want to hear is that you should carefully hand off everything––ensuring that any people you leave behind have clear instructions and extra support when the inevitable fire springs up. While you might not have a successor, surely softening the landing is the responsible thing to do…right!?

Wrong. This is the exact instinct that gets you into trouble and it’s little more than a post-hoc justification for your bad behavior.

Our instinct is to control everything, including how someone does our old job after we’ve moved on. But the truth is, the business is evolving. What’s really happening here is the company has to re-evaluate what is truly existential and what is nice to have, what actions and investments really move the needle exponentially vs. linearly, etc. This isn’t the sort of thing you can usually figure through arm chair analysis––you throw your best people on your hardest problems and see how much it moves the envelope. Meanwhile you suffocate and starve everything else. For a new operating model to emerge you can’t keep the old one on life support.

One of two things will happen: it will crash and burn badly or… it won’t. That’s tautological but what really matters is the magnitude of badness. There is a degree of acceptable loss in any enterprise: slightly higher costs because no one is optimizing the AWS bill, customers complain the return process is a little clunky but it’s rarely used, a P1 bug takes an extra week to resolve but nothing implodes because of it, etc.

If all goes well, it’s probably because either…

1. That thing doesn’t matter as much as you think it did (yay, you discovered you were wasting your time and now you’re not, rejoice), or…

2. Someone who was coasting will step up and surprise you, filling the vacuum, uncovering latent capacity you didn’t know you had (build that bench, baby!)

Either way, you leave with new information about how much that thing matters, whether you have key person risk, and all of it confirmed fact rather than speculation and doubt which are prone to self-confirming biases. More information is always better than less.

Do not carefully place your Legos on the shelf for the next person, coming back every few days to clean off the dust and give them a polish…throw them directly in the trash and GO!

A mentee recently came to me for advice: they had doubled the size of their team (and even added a layer of management) and were struggling with intense whiplash… bouncing from low-level execution management to coaching junior engineers to high-level architecture to org-wide influence, all in the space of a single day, and somehow being expected to also have time to think deeply and come up with novel strategic solutions to our org’s biggest problems. Oh, and while you’re at it, make sure to provide polished and perfect exec comms and upward management to control the narrative/perception of your team’s work… now across twice as many things. Cool, cool, cool.

The exact numbers don’t really matter, the problem is that as your scope grows there comes a point where it no longer all fits in your head. You can’t keep all the details straight while making sound decisions, commitments start to slip, your personal ETAs go from days to weeks, those “important but not urgent” tasks seem to never happen, and you start to collect regrets: bad decisions, moments where you were a total grouch, or slipped into outright command-and-control leadership. Whether that’s happening to you at 30 reports or 20 or 10, you have to change tactics before you implode.

Managing at scale is being subjected to 12 straight hours of meetings where every 30 minutes is about a totally different topic, with a totally different stakeholder, and every conversation is an active two-way exchange (no boring all-hands you can just tune out while you read emails). Here’s a random Thursday morning (not even a whole day) plucked off my calendar:

• 1:1 with a disgruntled skip report who wants to get promoted.

• H2 Roadmap session with Product.

• Design discussion about a new testing framework.

• HR consultation on a serious case of misconduct.

• Postmortem review from a huge incident we had last week.

• Status readout to VPs to decide if we shitcan an entire project.

• Coaching session on exec communication with one of my directs.

• Negotiating a stand off between the feature and platform teams.

• Emceeing a fun event for my distributed team members (thank god for skribbl.io).

• Deciding on the final set of metrics we’ll use for next quarter’s OKRs.

You no longer have the luxury of carefully preparing talking points for your status updates, good coaching questions for your 1:1, practicing the delivery of some hard feedback, or boning up on some technical details before a complex design review…you just have to walk in with <30s to change gears and nail it, first try, every time, completely cold. Maybe you also noticed there’s no time blocked off in there for deep thinking, writing docs, responding to emails, or any personal TODO’s. Yikes.

We’ve all heard the same, namby-pamby advice that you just need to “delegate more.” God, I’m so tired. Your reports might also be at capacity. You might not have anyone physically able to handle such tasks (i.e. a shallow bench). You might not even be able to concretely articulate the task/deliverable/goal, just a vague sense “something needs to happen.” You don’t see any way to just say no to the request. Whatever, the point is that delegating isn’t always an option.

Now don’t get me wrong, delegation is good (I have a whole post queued up about this topic), but delegating more without changing the way you work is a faux solution to a different problem altogether.

I’m no stranger to this situation: I once went from 5 to 30 direct reports in a matter of weeks, and then managed that group for a whole year as more and more orphaned teams, maintenance-mode systems, and employees were moved under me all without any option to add additional management layers.

I didn’t just double my working hours and do more of what I was already doing…I had to do something completely different. Rather than treating strategy, politics, and execution as three different jobs to juggle, I instead approached them as one integrated flow. The resulting system, dubbed management by model, transforms the 12-hour meeting block from huge time-suck to massively productive, prevents micromanagement, ensures most of your cognitive cycles are spent on high-level strategic interventions rather than tactical minutia, and might just let you reclaim your nights and weekends.

The Management by Model (MbM) Framework

The entire framework rests on one simple assumption: you were given this job for a reason, you’re probably pretty good at Getting Shit Done even if sometimes it doesn’t feel like it (imposter syndrome is a thief of joy). An obvious corollary to this that you Know Things™. Things like…

• …how work needs to be organized and tracked to ensure it actually happens and happens transparently.

• …the different systems/tools you need to build anything useful (and which dependencies to avoid like the plague).

• …how long things roughly take and an ability to create estimates that are more accurate than a PRNG.

• …which teams and stakeholders with which you must communicate when working in any given area.

• …the technical and business experts you can (or should) consult for a variety of different problems.

• …how much wiggle room there is to skirt process, skip steps, cut corners, and take chances.

• …what “high quality” means in your org and the definition of success beyond just “the project is done.”

• …the sorts of things that will make your boss / boss’s boss / boss’ boss’s boss grumpy and how to massage the message.

• …the signs that a project is doomed to fail or group cohesion is disintegrating.

With this knowledge in hand, you can construct in your head a platonic ideal for any given project: the abstract, perfect, conceptual model of how the work should be proceeding if all is well. You can likely do this automatically and without much effort (again, see: “you are good at things, you have this job for a reason”).

Like any model or virtual twin, you must carefully choose which details to include or exclude. When an architect builds a balsa wood model of a skyscraper, they are modeling mass and flow. They need to show where the load-bearing columns are, how the light hits the atrium, and how people move from the lobby to the elevators. They do not model the pattern of the wallpaper in the bathroom or the thread count of the curtains. Including those details doesn’t just waste time; it clutters the model so much you can no longer see the structural flaws. In your management model, you need to see the load-bearing walls (e.g. critical dependencies), not the wallpaper (e.g. code style).

Model in hand, you can continuously check whether work is proceeding in accords with that model, and when diffs are found, concoct a minimal intervention to nudge the system back into compliance or update your model to accommodate this allowable deviation).

By correcting deviations, the execution takes care of itself while you are free to focus on the broader strategic picture and stakeholder management so that the execution engine you build can be directed at the highest leverage opportunities. To implement this in practice, you need to implement new practices across 3 key constituencies.

Part 1: Manage Down with the “Diff” Method

The Trap: you manage by tracking all of the activity on your team and continuously get involved in nearly every discussion, decision, setback, and cross-team negotiation. You feel compelled to ensure everything from the lowest level code structure decision to team-level goal setting is a 10/10 on the quality scale. You think your success will be judged by all of these details and never want to be caught by surprise with a setback or slip.

The Mindset Shift: leaders work on the system not in the system. You need to stop tracking progress and individual activities and start tracking deviations. Teams fuck up, your career won’t end if there’s an occasional outage or a timeline slip (in my experience your “career” won’t be impacted either way, tbf). What matters is that the way the team responds is appropriate and automatic (i.e. does not require you).

The Protocol: form a rigorous mental model of how your system (people + code) should behave. Any time you encounter a diff (like a lack of expected progress, missing conversation, design docs that imply the code works differently than you understand it, etc) then dig in hard. You can use this to buff your understanding of the tech just as much as you can to find+fix team/process/execution problems making it doubly effective.

To effectively detect deviations, you need to set up a series of tripwires, gates that occur naturally throughout the rhythm of work where you can look for deviations. This could be things like…

• A weekly sprint or kanban wherein committed tasks taking longer than expected will stand out.

• Paying attention to the oncall / production chat. Is the team expressing the right amount of curiosity when things break or flake? Do they try to fix problems without being asked?

• Review all postmortems…do they include action items that proactively detect similar events? Prevent them from happening again? Is the root cause conclusive and correct or a giant hand-wave?

• Check the approvers on design docs. Were the right people included? Are key stakeholders and system owners off team appropriately engaged?

• Even the much maligned OKRs can be somewhat useful. Do proposed OKRs describe actions or outcomes? Are those outcomes believable? (no you won’t double the size of your user base in one quarter) When end of quarter rolls around, did the team at least start work on all of their proposed OKRs? If the team pivoted to different goals, did they do so because they learned something or circumstances changed…or was it because something is going haywire with either the planning or execution process?

• Be curious in 1:1s about how people are working together. Are there topics that keep coming up (indicating unresolved issues)? Do people share compliments and kudos about each other unbidden or is it all negative? Ask people “what can I expect to see from you in the next two weeks?” and let them answer without your influence or steering.

These are just examples and none of them are smoking guns which indicate 100% “there is a problem.” These are simply your signs that its time to get curious and dig in…to actually spend some of your own precious energy. The best part is that most of these things cost nothing…they are all checks you can perform passively by reading email / looking at Jira / going to your regular 1:1s and team meetings.

As your team scales (30->50, 1->2 layers of management) the design of your tripwires will have to evolve in sophistication. Most of these examples would apply to a manager of a large 10+ person team or with at most 1 layer of management under them.

Example: we all know that PR throughput is a horrible metric for measuring developer or team performance, but when used through the lens of MbM it has new utility! Each of my teams has a very distinct “flavor” to their work: some do greenfield projects where the expected velocity is high free from the burden of tech debt, some are deep infra groups where careful design and research are key for reliability, others are right in the middle shipping features in legacy codebases where we can expect some setbacks and rework. Every week, I receive an automated email that alerts me when someone has not pushed any code in a long time; the time span varies by team…e.g. 1 week for the greenfield group and 2 weeks for the infra group. These engineers are NOT in trouble! I don’t even tell people I have this data it never gets brought up / written down / shared. This is just my own private nudge to pay extra attention in standup and ask some leading questions in our next 1:1 to understand where the time is going or if something about their approach is off. Many times it’s innocuous…like at the start of quarter when we’re beginning new projects and the TLs might be in multiple weeks of scoping+design with their product counterparts. Other times it uncovers problems that require intervention. Two memorable examples:

• The flagged individual had lots of pending PRs (just nothing actually submitted). It turned out that code reviewers were very slow in responding and almost all these PRs were stuck waiting on 2 key tech leads. This led to establishing team norms around responsiveness in reviews (same-day turnaround), and cross-training to avoid bottlenecks in high-traffic components.

• In another case, it turned out the individual was busily designing a robust, reusable architecture to support a new feature but it had been more than a month and they were still just writing writing writing. However, the feature in question would never need that level of extensibility/modifiability…the entire thing was a one-off customer request and not an area of investment where we’d be continuing to iterate and enhance past the initial launch milestone. A quick and direct solution was the only thing that would be ROI positive; after filling in this important context, the engineer changed their approach and quickly moved onto implementation with a more pragmatic design.

By having an accurate model of how much “non-coding” work my different teams do, PR throughput becomes a marvelously effective tripwire for finding stuck engineers and problematic team behaviors!

Part 2: Manage Up by Solving, Not Inventing

The Trap: you try to impress your leadership with “new” ideas and sophisticated chainlink strategies (often in the form of 20-page visionary documents) that show you can conceive of and execute ideas valuable to the business. You believe it’s key to do something large and strategic that others recognize as your original idea.

The Mindset Shift: success is defined by the velocity at which you solve your boss’s problems. Creating new work unattached to current reality is just creating a whole additional problem (“more work I don’t have the resources to fund, and a report who will be mad if I say no”). In any sufficiently mature organization, the top problems and opportunities are already known and your focus should be on applying your organization to addressing them.

The Protocol: understand deeply the incentives, goals, and desires of your immediate management team. That includes…

• What problems are they worried about? What issues are getting dumped in their lap from higher up?

• How are they personally spending their work time? What meetings and projects do they make time for vs. skip?

• What are their (often secret) hopes and aspirations? Are they trying to get promoted? What will it take to land that promotion? What is the “next job” they want? What are they hoping to put on their resume when the dust settles?

• What public commitments and strong positions have they taken recently? Consistency of message is key in exec circles and they are likely repeating the same 2 or 3 talking points in every meeting. Not only does this establish momentum you can draft behind, but it also tells you what “no-go” positions to avoid…ideas and statements that would contradict or weaken the message they have been trying to send for the last N weeks.

Once in alignment with the boss’s incentives, your job is to create the environment needed for their strategy to unfold successfully. You will do this via resource allocation (e.g. ruthless prioritization), role assignment (e.g. granting authority and auspicious titles to similarly aligned lieutenants), and putting in place constraints/invariants that shape how the work happens (e.g. “all teams are full stack teams by default”).

Example: one of my team’s owned the backend API and frontend libraries that powered ~all feature development in Google Drive. I inherited a multi-year migration to a new API architecture that was intended to vastly improve the feature velocity of the whole org. Midway through the migration, I conducted a round of user interviews with various feature developers across the org and discovered they did not find the new solution developer friendly. While faster than the old thing, it fell far short of our goal of enabling rapid 24-hour iteration cycles with full-stack feature teams making contributions freely to the backend to keep work moving. I could have used that data to push for a large “developer velocity” program to fully land on the original vision, or slowed down the migration to ensure the quality was high, but I didn’t. Why? Zooming out to my boss’s level, nearly 40% of our SWEs were occupied across 3 different multi-year grungy infra migrations with no user-visible impact. In the intervening years, other existential problems were identified that desperately needed attention (i.e. reliability, competitive pressure) and feature work had slowed to trickle from the resulting staffing crunch. Pressure from upper management was high to ship ship ship, and we were slowly losing headcount to other orgs that did a better job of delivering user-visible impact. What my boss most needed in that moment was to get some of these migration projects off the books as fast as possible so she could update priorities to reflect the new opportunities and new problems that needed attention. Locking 100+ SWEs onto projects solving problems identified 3+ years ago killed our ability to be responsive to new information. So instead of making my migration even bigger, I focused on containing the scope and pacesetting: we finished the migration in 18 months (down from a projected 28-36 months). The goodwill I earned from this directly propelled me into a higher leadership position with even more opportunity for impact (oh, and btw, with this increased authority I was able to eventually get that developer velocity work prioritized…you have to play the long game).

The name of the game is resource allocation based on political physics.

Part 3: Manage Out with Shareholder Politics

The Trap: you try to be helpful to absolutely everyone. You constantly field random one-off feature requests from sister teams. When you hear that someone might not agree with what your team is doing or how they are doing it, you go out of your way to address that stakeholder’s issues. When planning time comes around, you have a laundry list of cross-functional requests you try to pack into the team’s quarterly commitments to support your myriad peers. You internalize just how much others depend on your team and what you build, and don’t see any way out of this…when your boss tells you to say “no,” you cannot fathom how that would even play out as there is no alternative.

The Mindset Shift: rather than managing stakeholders you need to manage shareholders. The metaphor to publicly-traded companies is an apt way to realize that some stakeholders just don’t matter, while others can be absolutely existentially critical. A power-interest grid will help you identify the true shareholders in your enterprise:

Someone with a lot of shares (think: voting rights) has high-interest and high-power. Maybe they’re your top internal customer and their success depends on using your platform to ship a product. Or they could be your immediate manager who sees your area/project as key part of their portfolio and career ambitions.

There are also those with a lot of formal authority (think: class A shares) but are content to let things play out without helping or undermining you. Your CTO may be fine letting her VPE’s figure things out without meddling.

Others have a few shares but not enough to really influence anything. That ivory tower architect 4 teams away has strong opinions about what database your team uses but spending any effort appeasing them is going to be a waste.

Finally there’s everyone else with neither power nor interest (think: the general public). They have little reason to interact with you and may occasionally grumble and groan but neither party truly cares enough to do anything about it.

The Protocol: take inventory of the shareholders in your world and chart them on a power-interest grid. Ask yourself questions like “if I overdelivered for this stakeholder, would it matter?”, “who has the ear of senior leadership?”, and “if this stakeholder didn’t like my very much, how much would it matter?”.

• Closely manage and invest in your relationship with high-power, high-interest shareholders. Regular 1:1s and 100% follow-through on every single commitment is key.

• Keep the high-power but low-interest shareholders satisfied. They may require extra attention when things aren’t going well to establish confidence, maintain independence, and/or receive additional support.

• Ensure the high-interest but lower-power shareholders are informed so they don’t suddenly become a source of problems. Consider amortizing the cost of managing this group with Customer Advisory Boards.

• Spend no effort on the low-interest, low-power shareholders.

Example: earlier this year, we tried to ship a UI refresh of our file viewer. As a common component used across hundreds of frontends, the launch would proceed in phases with different parts of the product getting updated over the course of the year. On our 2nd launch, the accessibility lead for our area blocked the launch citing failure to meet modern accessibility standards. This wasn’t a surprise to us: we were refreshing a 10+ year old UI that needed significant updates to become compliant and as such had placed that work out-of-scope as there was limited appetite to increase the size/cost of the project. Despite filing the appropriate exemption paperwork, the accessibility lead was adamant this needed to be addressed. Key to navigating this situation was figuring out where this shareholder fell on the power/interest spectrum. Their interest was ostensibly low (they literally ignored this project for more than a year, which is why this blocker emerged during launch and not at one of the myriad earlier reviews or when we filed the initial exemption paperwork) but power was high…very high. Not only did they own the approval for this launch, but they had the ear of our VP. Ignoring them or forcing our way through the blocker would blow up, made worse by the fact that over the next year we’d need to go through this same review and same fight for every incremental launch month over month! As such we formed a compromise where a few critical surfaces would launch to start collecting real user feedback, and after that we would address all the accessibility issues before proceeding to the remaining long-tail of launches. Our launch was unblocked, user feedback was extremely positive, and everything has proceeded peacefully since.

Putting MbM into Practice

At the heart of Management by Model is a principle of energy conservation. First is personal energy conservation: limiting interventions to systemic problems and only getting into the details enough to understand the system; avoiding overwork by aligning to your boss’s incentives above all else; and removing distractions by filtering out irrelevant shareholders. Second is organizational energy conservation: ensuring work is proceeding in an low-friction and effective way by shaping the environment, constraints, and communication pathways.

The goal is to lower the incremental energy cost (time, people, ) of each unit of progress, and the amount of energetic input you must personally provide to make that happen…without slipping into outright abdication and absenteeism.

Keeping Your Model True to Reality

None of this works if your model of how work gets done is a fiction. Even if you came up on the IC ladder, your model will always drift the longer you stay in management. Model updates don’t come for free like they did when you were hands-on pushing PRs every single day. Consider…

1. Most of the information you receive is at least partially filtered or colored to sound better. Everyone wants to look good in front of their boss.

2. Any information you do gain is free of the texture and intuition that comes from actual lived experience. It’s one thing to hear “feature flag rollouts can be a little toilsome” and another altogether to experience the 3AM debugging session screaming “WHY WON’T THIS BOOLEAN JUST FLIP TO TRUE $#%$#(*%&”

At my core I remain an engineer, so I keep my mental model fresh by picking up the keyboard—but I do it carefully. I target the toil: flaky tests, noisy alerts, and cleanup tasks that sit off the critical path. This is a strategic protection of the team’s time. If an engineer pauses a major deliverable to fix these annoyances, they dilute their portfolio with a smorgasbord of invisible work that is hard to defend in a performance packet. I, however, can absorb that “run the engine” overhead with impunity. Since management impact rolls uphill, I can afford to do the unglamorous work that clears the runway for the team’s visible wins, while gaining valuable insight for updating my management model It’s a win-win-win!

When we have production incidents, I love to dive in and help debug…root causing can be wonderfully illuminating (word of caution, I am a systems engineer by training and have SRE experience so I am actually useful…don’t show up and start asking basic/obvious questions or distracting first responders with crackpot theories).

The same model drift problem occurs with shareholders. The key players will change over time. Being thick as thieves with the EM of your sister team is great, but a reorg could send them far away. A deadline crunch can make even the most helpful partners turn feral and tell you to buzz off. People (and even entire orgs) will fall in and out of favor with executives and other power brokers at completely unpredictable times. That Director of PM you’re spending all your energy appeasing will become a political pariah overnight….you might not know anything has happened/changed! It’s not like your VP is going to pop into the quarterly all-hands and say “oh, by the way, ignore any requests you get from the Platform org…it’s a total shit show and our CTO is not happy with them, we don’t want to be associated with that mess.” The protégé you’ve been mentoring for the last year will have their promo denied and fail to acquire any useful power or influence you can call upon. Womp womp.

To keep your shareholder model up to date, you need to put effort into establishing a network of trusted confidants that have eyes and ears in rooms you can’t access. You need to sow many such relationship seeds because some will fail to sprout, or the plant will wither in a drought.

Joining a New Company

All of this is why joining a new company in a middle or upper management role can be fraught with peril. You have absolutely no model of how work gets done in that environment. Relying on the model from your prior employer is a recipe for misfires ranging from overpromising to not-a-few pissed off employees.

When considering taking a new management role, ask your interviewers and hiring manager what they are looking for in the would-be occupant of this role. Are they looking to import a new way of working or missing experience? Does the company have a culture of curiosity and a commitment to truth? What’s the change budget? Maybe the whole reason they want YOU is to come in and bust things up…if so, fire away, use that legacy model baby!

That said, that probably isn’t reality. Most of the time, the team you inherit probably has some really solid virtues and your job is to tune and optimize without capsizing the entire vessel. Chesterton’s Fence and all that jazz. Some approaches I’ve taken to rapidly naturalizing and building a model of my new workplace include:

• Construct a value stream map.

• Fix a bug (yes, even as a VP).

• Do a round of listening sessions and 1:1s with TLs and key talent that are more than 2 or 3 hops away.

• Set up regular coffee chats with the 2nd-to-last person to join the company whose a little further along finding their feet.

• Identify all the critical roles in your org (specific jobs / titles that must be occupied and performing well or the org fails at its mandate).

I wrote a whole article that elaborates on these and many more tips…check it out!

People Bugs

MbM won’t help you if most of your staff are constantly screwing up, your tripwires will go off constantly and you’ll drown in concurrent deep dive interventions.

Hence when it comes to talent management, especially for your top lieutenants, you’ll have to adopt a somewhat brutal “up or out” mentality. If they can’t OODA, address any skill gaps, and adjust their approach to deliver what you need, it’s time to have a frank conversation about alignment and roles that might be a better match. Then you can find someone else whose recent experience means they do what’s needed “off-the-shelf.”

I don’t like giving up on people. Just writing that paragraph above gives me a stomach ache. People can change, they can learn! I literally run a management coaching business after all (hello, welcome). That said, when these senior+ folks are missing the mark, the damage is multiplicative and often long lasting (see: key talent quitting). Time is of the essence. Reprogramming such individuals to meet your standards can be a full-time job on its own…one that doesn’t always pay off because they might still fail or quit from the sustained discomfort. If you need to reprogram multiple people, forget about it, it’s not happening. This is the management equivalent of a build vs. buy decision…but for people. Any time you decide to invest in someone (build) rather than hire a ready-to-go candidate (buy), it has to really be worth it.

Situational Leadership

MbM is not a silver bullet and does not apply in all circumstances.

• Building an entirely new org means starting with a null model. A more hands-on and demonstrative leadership style is needed to ensure the right patterns, behaviors, and systems are put into a place.

• Doomsday crises need a more active command-and-control leader. An existential competitive threat that could delete your business cannot be left to chance; these situations are often too dynamic for a large decentralized organization to handle appropriately…the body needs a brain!

• Once you have 3+ layers of management, your model will be woefully incomplete, your tripwires not sensitive enough, you won’t have enough visibility to know what to do about it, and almost everyone will be trying to manipulate you. At this scale, management turns into governance which requires a different playbook.

Ultimately, MbM assumes you have team that are largely stable and established in their structure, approach to work, shareholders, and goals…at least on the scale of the next 3-6 months.

Go forth and become a Model Manager

The proper response to increased scale isn’t just doing more of what you’re already doing, it’s recognizing you have a different job and your role in the system has shifted to governing how information flows and work gets done…all to maximize productivity (or maybe it’s “minimize wasted energy?”)

Doing this in 40 or so hours is no small feat, but it is doable:

1. Align your org’s incentives with your boss and the broader company’s success. Sift and winnow the existing problems/opportunities rather than creating new work. Prioritize the top #1 most impactful opportunity and swarm everything you have behind making that happen.

2. Create the environment necessary for that strategy to unfold successfully. Use careful process design, architecture principles, and other “work invariants” to shape org-wide behaviors. Carefully manage the high-interest and high-power shareholders to ensure your team has the support it needs.

3. Maintain an up-to-date model for how work actually gets done. Use tripwires like kanban/sprint ceremonies, project lifecycle gates, postmortem reviews, etc to detect deviations. Get curious, dig in, and (sometimes) intervene when you find a diff to keep work on track.

It’s so important I’ll say it again: leaders work on the system not in the system. It’s a bit black a white…but if you don’t then who else is going to do it…? No one. There’s huge opportunity cost to letting your org run through a series of implicit defaults. Get modeling!

Anyone who knows me has probably heard me talk about opening a startup. The thrill of standing on your own 2 feet, getting to wear many hats, the huge asymmetric upside if you’re successful (and, at a minimum, the rich/textured life story if not). Above all else, it’s been my primary aspiration for many years to create a workplace akin to those where I found my self-confidence and met my best friends (UW-Madison DoIT, Google Drive)—a real “second home” for the doers and strivers.

And yet, here I sit. It’s November and I’m filling out 17 annual reviews (kill me) for the 5th year in a row, comfortable and safe within the bulwarked walls of Google. I always said that I was just collecting the experience and skills needed to head out on my own, but the years stretch on….what the hell am I doing!?

Life is full of these idle dreams; ideas about what the future will hold, who we are, and where we are going. Things that are always just around the corner or paths that we will surely walk in the fullness of time. I have heard many such things from my friends and have my own fair share…

• “Next year I’ll move to Europe.”

• “Maybe I should go back to grad school, finish my PsyD, and start my own clinical practice.”

• “I will spend the rest of my life with you.”

• “Let’s make a video game.”

• “I will climb the corporate ladder and become a Director/VP.”

• “Nothing would make me happier than raising a family of my own.”

• “I want to experience living in NYC.”

In psychology, there’s a term for these imagined paths: life scripts. We unconsciously form/reform these throughout our lives, but especially during key developmental phases. In early childhood we’re taught how the world will regard us and how we ought to hold the world (trust vs. mistrust), in adolescence an image of our adult lives takes shape (often with heavy doses of parental influence), and throughout adulthood that life script is repeatedly challenged by the reality of our circumstances. Aside: it’s why dating can be so painful…you’re constantly writing, throwing away, and rewriting life scripts about what your future will hold as you try to find someone to love. It can be jarring to have your sense of self and eventual destination in life rewritten so radically and so frequently.

At the end of it all, very few of these things will actually come to pass. We talk a big game, but that’s all it is: talk. So how can we tell when something is real versus a daydream?

A dear friend of mine recently introduced me to the fluff test. The fluff test is simple: ask yourself what is a real, hard requirement for you and what is not? That is to say, what’s fluff? This is especially important if these un-lived dreams haunt you and take away from existing in and fully experiencing the present. You must give yourself permission to let go of the fluff.

The easiest way to diagnose fluff is to look hard at what you’re willing to make sacrifices for (or have already sacrificed for as that will surely reveal a pattern). When I look at my own life, there were many things for which I made real sacrifices:

• I spent almost all of my formative teenage and university years grinding to become an exceptional engineer, skipping canon moments and delaying key developmental experiences until much later. It’s rare when something hits you that hard and that true, but becoming someone capable of creation on a grand scale was non-negotiable.

• I left behind my very first adult friends, departed places I loved (Madison, Seattle) and delayed romantic relationships to ascend the corporate ladder.

• I have moved (multiple times) and spent a lot of money to experience novelty–new cities, new hobbies, new friends. I could have FIRE’d by now with a more restrained approach to life but I simply cannot tolerate boredom.

• I gave up much of my individuality to try and be more like my friends and potential partners so that we might grow closer.

Sometimes what turns out to be fluff will stun you. I never thought “starting a company” or “having a family” were fluff but my track record speaks for itself. These are things to date I’ve made no real sacrifices for; it’s time to shit or get off the pot.

This isn’t meant to be a sad thing or even all that terminal. Life is long. What might be fluff today can become a very real all-encompassing driver tomorrow. Acknowledging the seasonality and progressive nature of life is a key part of freeing oneself from the ghosts of an un-lived future. Only then can you let your present needs/goals/urges in and the answer to “what’s next” will become readily apparent.

I’ve written a lot recently about professional ennui: the notion that, for many working professionals, we accomplish major life goals only to now find ourselves adrift and unsure what to do with the years ahead. Through the lens of the fluff test, I’ve come to realize it’s really all about regret. At the end of my life, what will I regret having never done or never tried?

For me, attaining a senior leadership position at a respectable, large company was the animating force behind the first chapter of my life. It wasn’t about the power or the money or the status…rather, it was external validation that “no, I really am good at something.” To be trusted to lead a large group of competent people, direct lots of resources, and deliver a product that people actually care about would mean I had mastered the craft, and not just in my head either!

It would have been a great regret had I not pushed myself to achieve this…to hit the breaking point and just keep pushing and keep sacrificing until it finally, FINALLY, happened. Now in the end my reward is a job that is torturing me…but at least I have no regrets 😉 But I suppose that’s the point: it isn’t always about the destination or the pay off. It’s about being comfortable in your own skin and at peace with how you spent these few blessed years we have on Earth.

I would have deep regrets if I hadn’t….

• …seen how far I could go in my engineering career.

• …figured out how to be less damn awkward and relate to people.

• …gotten fit and experienced the joy of exerting oneself at the limit of your physical ability.

• …fallen deeply in love and through the pain grow past neediness and learn who I really am.

As you journey through life, ask yourself: “what is the next great regret I will forestall?”

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…

1. This isn’t the ranting of someone who burned out and couldn’t cut it.

2. 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.

• Your reports (and especially your skips) will put way too much weight behind every comment you make. One sternly worded doc comment could send an engineer into a self-doubting tailspin. A random throwaway technical hot take at lunch could unintentionally pivot your team’s entire technical roadmap.

• “Solving problems” at your level often translates to hiring/firing managers and TL’s or canceling/starting huge new initiatives. All of these things cause massive churn and panic and none of them are clean.

Very rarely do you get the chance to build an org from scratch; you will inherit someone else’s mess (sorry Matt, Yi, Cheryl, and Brian). Failing manager? Getting rid of that person is a full time job, and picking up the pieces afterwards is a full time job-and-a-half. Failing project? Good luck diving into the weeds with 2 layers of people obfuscating the details and actively trying to convince you how great a job they are doing.

If you immediately act upon the many inherited problems, you would instantly burn out. To deal with this you must limit yourself to lighting one fire at a time. Every team you “perturb” is just such a fire that will demand your active attention until it is fully resolved (unless you want to do the executive swoop-and-poop I guess). The corollary to this is being OK letting some teams suck for awhile…you have (a single) bigger fish to fry. At the rate one can realistically fix big weighty org problems, this also means you might be juggling the hot potato of a semi-dysfunctional org for multiple years. Get comfortable.

(I am trying very hard to mix as many metaphors as possible, how am I doing?)

8. Get really good at neutralizing conflicts.

Being in middle management is like defusing a bomb while wearing oven mitts.

You’ll hear about problems and usually have to work through others to solve them. You channel your best, most wisest feedback to the local lead only to find out it didn’t work 3 weeks later. “No, not like that,” you think, “if only I was in the room, I could show them how it’s done.”

Getting directly involved is no better, it sends a very strong signal that “I don’t trust you.” Now you have two problems. Moreover, your voice carries, and the team will have a tendency to snap to your opinion…prematurely ending debates before everyone is heard and all options explored. You’ll never know for sure what people really think because at least some percentage will mostly try to figure out ways to appease you…or to somehow say “you’re wrong” without saying it out loud. Now your nice simple technical disagreement is a hall of mirrors filled with all the smoke people are blowing up your ass. Good luck making sound decisions, weeeeee!

This is something I have always struggled with because it’s very easy to revert back to “being the TL” and directly solving the problem. Taking off the starchy, ill-fitting suit and putting on the comfy, well-worn hoody of yesteryear. All this director-ing is hard and scary and frustrating, but “being the TL” is something you’ve mastered!

Breaking this habit require feeling equally comfortable “managing at a distance” and steering groups towards the right outcome without them even realizing you’re doing it. As with all skills, I think the best way to start out is following a framework/recipe so you can get a feel for the maneuvers involved. Once it feels natural, you can start to freestyle.

Here’s my technique for refereeing conflict:

Midwife other’s ideas: make your role in debates the “translator-in-chief.” Listen deeply and carefully to the positions others are expressing. When you speak, it should be to clarify and strengthen others’ points, or to gently correct if something has been misinterpreted. Your primary goal is to ensure no one is talking past one another, that all ideas offered are treated with respect and due consideration, and that room is made for the quietest voice. When everyone leaves, the debate might not be over, but each person ought to be able to write down exactly what everyone else believes and wants accurately. Accurate and empathetic understanding is the firm foundation from which a pool of shared meaning can be constructed, and a way forward found.

Good questions: thought provoking questions can be used to illicit deeper thinking and consideration without showing your hand. For example, here are three questions I love to use when something goes wrong and you must decide what to do next–

1. What do we now know about what doesn’t work?

2. What assumptions led to these outcomes?

3. What risks are we exposed to now that need to be mitigated?

I find literature on coaching to be a great source for these sorts of questions.

Nudge interlocutors towards mutual understanding: in one-on-one settings I will test how much active listening is actually happening by posing the question directly, “John, tell me in your own words what you think Jane is pushing for here and why she thinks that.” Usually I’ll get a very facile, incomplete, uncharitable account of the opposite side of the debate. When that happens, I will give my report an assignment to go out on an “idea safari”–to observe non-judgmentally and without interference the thoughts of others and to report back what they found. I do not let up until they can represent and defend their opponent’s ideas as vigorously as their own. Sometimes this takes 2 or 3 one-to-ones and “safaris”…you can imagine the frustration that evokes, but it’s worth it. Being able to live in someone else’s head for a time is a skill that will pay off for the rest of one’s life.

Write a fork doc: once good mutual understanding is established, I bring structure to the remainder of the debate through what I call “fork docs.” Fork as in “fork in the road.” Fork docs are very simple–usually one page–they articulate the problem statement, the must-have traits of an acceptable solution, a purely factual summary of the alternatives under consideration, and decision-making rules (i.e. whose the decider). Fork docs let you put up some constraints without having to directly express an opinion. They defuse debates by naming the core disagreement and articulating the rules by which a final outcome will be decided.

9. Ten percent turnover is the norm; someone is always dying.

As the size of your team grows, you must get a lot more comfortable with higher baseline levels of chaos and tumult.

When leading a small team of IC’s, a single person quitting feels like disaster. A category 4 hurricane of dashed dreams, personal heartache, and self-doubt: “am I really any good at this people management thing?”

Once you manage 50+ people, that’s a Tuesday. You should expect approximately 10% of your org to turnover every single year. I don’t know why this is the magic number, but this was the case for all my orgs, my boss’ much larger orgs, peer orgs a few hops a way, etc. The math just keeps working out.

If you take this personally or over react, you will burn out. More so because you have very few levers to influence the situation. It’s a truism that most people leave “bad managers” not “bad jobs” but your ability to intercede is greatly limited by distance. You won’t know your skip reports’ hearts and minds as well as you know your directs. You won’t be in the room to understand the exact cocktail of micro and macro-behaviors that caused one of your employees to quit. Sure, you can fix “problem managers” that are driving away people in droves, but that’s usually not the issue. Get comfortable with turnover, and build an organization that can handle this disruption while rapidly training new talent.

A corollary to this “law of large numbers” is that someone’s grandma is always dying. Substitute death for chronic illness, birth, or family emergency and you get the picture. Some large fraction of your organization will always be on a leave of absence, especially at BigCo where there are many types of centrally supported and protected leave benefits.

You have to preserve enough slack to deal with the constant churn of terminations, resignations, leaves, and onboardings. It probably isn’t an epiphany that you cannot run your organization at 100% utilization, but the sheer scale of the required holdback probably is–in any given planning cycle, you should only intend to utilize 70% of your overall organization. Yikes. That doesn’t even factor in how many (acute or chronic) underperformers you are carrying. “I have 100 employees, we can do so much!” Bzzzt, wrong, try again. You have like…50?…actually useful humans at any given time.

10. Create a community of practice for managers.

Reading this far you are probably feeling vicarious exhaustion. Management can be like that. On one hand it feels amazing to create an environment that allows people to do the best work of their lives and to experience the self-worth and self-actualization of collective success. On the other hand: so. much. bologna.

• You pour all your energy into your reports–doing your best for them and the business–but who looks out for you?

• You spend most of your time at work, but forming real deep friendships is muddied by hierarchy.

• Managers tend to self-isolate and focus on their team. Often the only time spent with other managers is in a group setting with your boss (“the weekly staff meeting”). The boss’ presence dissuades managers from sharing their problems (the boss might be their problem!) and implicitly encourages competition.

You can shed all of these burdens with one simple trick: a community of practice (CoP). A CoP is a group of people who share a concern, passion, or problem, and deepen their knowledge and expertise in this area through ongoing interaction and shared activities. Key to a CoP is shared commitment to a domain, the development of community through mutual engagement and joint activities, and the creation of a shared repertoire of resources, experiences, and tools through practice.

I have found many managers resist forming such a group–they question the possibility and payoff of making a meetup like this work. This is a mistake. Well integrated managers working together have incredible potential to move work forward: sharing and assimilating information, consulting and strategizing on problems, and forming power blocs for ambitious org-wide schemes. All the better that it creates a safe, trusting environment…a “home base” you can always return to when the going gets rough.

I try to foster this by turning my “weekly staff meeting” into something of a “management repair garage” where we consult with each other on the conundrums of the day. This is a good starting point, but a true community of practice requires going further. Ideally, a regular meeting without “the boss” present to avoid competitive pressure and to encourage joint problem solving rather than deferring to power. To learn more about this concept and the problems it solves, read In the Middle by Barry Oshry (side note: try reading a book that talks constantly about “tops” and “bottoms” without laughing).

11. Managers scale by the number of problems, not the number of reports.

I have witnessed extremely skilled and experienced managers fail with only 5 reports. I have also seen managers succeed with as many as 25 directs (I did just that…twice…and it wasn’t as bad as you might think). What gives? What is the ideal “span of control” for a single manager?

Managers scale linearly i.e. O(n), but, hot take, I don’t think n is “number of reports.” Managers scale by the number of problems / goals / areas of concern they own.

Before I get completely dog piled, let’s be clear, there are limits. I don’t think a single manager can handle an unlimited number of people (just the effort of allocating work, giving feedback, and completing performance reviews for 30+ people is staggering). Even above ~12 people you need some adaptation techniques including fortnightly 1:1s and hiring exclusively staff+ tech leads…but the point is it is possible to do so and thrive.

The real limiter on managerial effectiveness is how many discrete, non-overlapping problem domains they own. Each area requires dedicated care and attention to (1) understand the goals, (2) formulate strategies, (3) implement said strategies, (4) build alliances, (5) operate the rhythms of business. These responsibilities are (usually) unique to the manager and, even when delegated to a strong TL, must only be partially delegated in a trust-but-verify sense.

Let me paint two not-so-hypothetical pictures to explain:

• The Mobile Team: every single feature and business objective involves this team because it’s the primary interface with the user. The manager(s) must be in tune with effectively ~all the goals of the organization, their respective dependencies/requirements/timelines, and ensure all of this goes off without a hitch. Given their broad exposure, they are in 10+ status meetings per week and, statistically speaking, something is always on fire. When resource contention occurs, they must somehow prioritize between irreconcilable objectives like “support DLP controls for enterprise customers” and “add new social features to incite product-led growth.”

• The Performance Team: they own a very specific objective (make it fast). Even though they must work across basically every system/app/component to achieve this goal, it is all in service of one particular outcome. They will divide and conquer to leverage expertise (workstream 1: “speed up database queries;” workstream 2: “progressively load the web app”). There’s still more work to go around than people to do it so prioritization is key, but the trade-offs are all tractable because you’re not comparing apples and oranges like the mobile team.

Both these teams might be quite large (10, 20, even 30 engineers) but the mobile team likely needs 2 or 3 dedicated managers while the performance team needs only 1.

A note of caution. While it’s possible for a single manager to lead a large group, that large group should not run as a single team. That is to say, “all the people who report to me” no longer makes sense as the definition of a team. Managers with large spans will end up running two or three teams. You’ve surely heard of “two pizza teams,” Dunbar’s Number, and the like. These rules-of-thumb still apply when forming high-functioning teams as they speak to the limits of human social psychology, but shouldn’t be used to determine how many managers you need….that is a different problem altogether.

12. Delegate and let things fail to sharpen your team.

Pretty much every manager under the sun has heard they need to delegate. Too often, however, what gets implemented is a sort of faux delegation where you’re still actively watching all of the proximate actions and even volunteering extra support for the really tough bits along the way. You tell yourself this is what it means to be a good manager–don’t throw your report to the wolves and all that–but the end result is the same time demands as if you were personally doing the task. Bonus: now you’re also subject to the stress and anxiety of working through someone else. In the end, you learn very little of what this person can handle solo.

Here’s the very raw deal we all get at BigCo. Everyone is doing 10 things at once, and success is determining which 2 absolutely cannot fail while letting the rest go. Spending any time at all beyond the occasional 1:1 on those other 8 things is not a good idea: you’re either going to deliver a weaker outcome on what really matters and/or sacrifice your personal life to make up for lost time.

This is especially hard once you enter middle management. The stuff you need to delegate isn’t straightforward tasks or even entire projects…they are things like:

• “The PM’s roadmap is a sham and their management isn’t going to do anything about it. Go make sure we have a real product strategy please.”

• “A dependency has refused a feature request that blocks our most important objective and their Director refuses to even meet with us–figure it out.”

• “We keep having back-to-back production incidents…make it stop but also don’t slow down feature velocity using either science or magic.”

These XXL, black diamond ambiguous problems are not just hard to solve but critical to the long-term success of your team. They are strategic, require extreme tact, and it’s possible to fail for reasons outside one’s control. The exact sort of thing you feel in your bones is your job because it’s your org and you cannot leave it to chance. Spoiler alert: you should absolutely leave it to chance.

First off, remember what it was like to be a line manager. You were smart/capable/accomplished. and hungry for an opportunity to do work that had real import and stretched you to your limits. You were ready to leave the kids table and it took waaaaay too long for your boss to trust you like that. Don’t repeat that mistake.

Part of this is recognizing just how far you’ve come, you’re no longer on the “ground floor” and there are people below you who are absolutely phenomenal leaders and operators. I know ego isn’t in vogue right now, but pretend humility doesn’t help and having a more realistic self-image lets you grok just how gnarly a challenge your managers can probably handle. The stuff you should be focusing on is the real nightmare fuel (e.g. “we are at risk of churning our largest public sector customer and nothing we do seems to appease them”). There is real opportunity cost to not tackling those issues yourself–far in excess of letting a few lower priority things potentially fail. The classic HBR essay “Who’s Got the Monkey” is a great starting point for learning to resist making everything your problem.

Second, delegating critical ambiguous problems helps precisely measure the limits of your leadership bench…how much you can trust them with and not have it come back to bite you in the ass. “What if they fail?” Yes and what if they do fail? They will either learn and grow, or a pattern will form and you’ll understand that person needs to be fired. I know that sounds very black-and-white, but if someone on your bench can’t be trusted with weighty important problems, it only holds you back because everything will just end up on your plate. Managers don’t usually fail for mundane reasons like failure-to-ship or misconduct…there’s always some amount of vaguely good progress and other positive-ish stuff happening. As a result, it’s easy to accidentally retain a management team that is more decorative than functional.

If you never trust your managers with the real, grown-up problems they are supposed to solve independently, you’ll wake up one day (after an all-nighter most likely) wondering why everything requires your personal attention and “wouldn’t it be nice if I could hire another me to help load balance?” You will have none to blame but yourself.

A team honed with real honest-to-god delegation is ridiculously sharp. With a deep bench, it will feel like you have nearly limitless capacity and your work-life balance will be…at least manageable 🙃. Big hairy problems become mundane and tractable. You’ll start to wonder “does the team even really need me any more?” As times change, people leave, orgs shift, there will be super stars primed and ready to enter the senior leadership team. All is right with the world.

Delegate things you think you shouldn’t; manage out the failures; focus on the one maybe two things that only you can solve. That is the recipe for a thriving Director/VP.

13. What the hell is “half” an FTE?

If you show me your quarterly OKRs and have “0.5 FTE” in the staffing column, I throw the entire plan in the bin.

“Half a person” is not a real thing, I’m sorry. When they come into work, what does this person understand their job responsibilities to be, exactly? “On Monday and Tuesday, I work on improving the mobile document scanner. On Wednesday and Thursday, I work on rebuilding the onboarding flow. On Friday, we make waffles!” Kill me.

Such plans usually fall victim to a number of common errors:

• Impossible Precision: planning over such large timescales (months/quarters/years) down to the level of fractions of a person is just not possible with the low quality, fuzzy data we feed into the planning process. Fixing those inputs to increase precision is usually impractical and not strictly necessary. Understand that for most senior leaders, they will abstract this all away as “John Doe = Project Foobar” or even higher up “Team X = Project Foobar.”

• Binpacking Assignments: thin slicing individuals this way encourages stuffing the team full of commitments. Even if you leave some slack built in and don’t fully allocate, your team still ends up on the hook for many different goals simultaneously…each of which may fail or need extra unplanned help. It’s a recipe for overpromising and underdelivering.

• So Many Silos: you end up with multiple projects that have only 1 person assigned. These projects will grind to a halt the minute said person takes a sick day or gets pulled into a production incident. If they leave, you have no backup plan. And they probably will leave because they’ll start complaining about feeling alone and isolated day in, day out.

Just don’t do it. Restrain yourself from faulty “manager math” and plan in whole FTEs only. In practice, you may be able to pack in more work than anticipated but that is far better than finding yourself up against a wall halfway through the quarter.

14. Managers are inherently insecure.

(that includes me, to be clear ¯\_(ツ)_/¯)

Adding more managers to your org carries a bunch of additional hazards. Each manager is a new mouth to feed: a bright-eyed, career-oriented, driven individual who gets bored easily. They expect important work, a fresh bushel of headcount every year, and meaningful opportunities to grow into senior leadership (despite there being, you know, only one next-level-up job and you’re currently busy doing it).

As org priorities change and headcount shifts (well, shrinks, it’s 2025 after all), it will be a three-alarm fire to ensure each manager feels special they have good scope. Any overlap at all between adjacent managers and you can expect confusion and anxious questions in 1:1s about “what do I really own? Where does my responsibility end and so-and-so’s begin?” No answer you offer will satisfy, trust me I’ve tried all of them including “just…work…together!?”

This also pops up for innocuous reasons day-to-day. If a peer suddenly pokes their nose into someone’s area, hackles are raised…even when there’s no nefarious intent (in fact, maybe you asked because something is too-important-to-fail and wanted to swarm extra people onto the project). You will spend way too much effort playing therapist and ensuring each manager knows they are the prettiest girl at the ball.

When packing your ranks with the maximum number of managers it can support, you give yourself more problems not fewer. There will come a day when there aren’t enough discrete swimlanes for everyone and there isn’t enough Advil on Earth to deal with the headache that will ensue.

I had enough slack in my latest org to add one extra manager. While it would have helped load balance some, it also would have been a long-term headache and limited career advancement for several of my directs. Now that I’ve left management, I’m extra glad I didn’t because ensuring everyone was well taken care of in the aftermath reorg was hard enough as-is.

Add managers to your org with caution. The pool can only fit so many swimlanes and no amount of doe-eyed optimism about “working together” can fix the inherent territorial insecurity endemic to the management caste.

15. Dig until you find what people really believe.

As you ascend the ranks people are less and less honest with you. This can happen when there is fear of reprisal or folks feel they are being judged for character and competence in your presence. There is a pretty obvious incentive for looking smart in front of the boss. This also happens indirectly because, the higher up you go, the more steeped in corporate culture your immediate directs become. You’ll never get a straight opinion out of anyone ever again because everything they say has been eviscerated by a corpspeak translation filter.

No one is going to walk into a one-on-one with you and say “this project is $*%&ed, we made the totally wrong architecture decision, and my manager is forcing us to ship it anyways. Oh by the way, the dog died yesterday.” You’ll get some polite drivel like, “the project is taking longer than expected because we made a challenging trade-off that had some unanticipated consequences. We’re working hard to get everything back on track.”

You cannot make good decisions if the only information you’re fed are these super anodyne, rose-colored, indirect nothings. Fixing this is hard; people are afraid of revealing their true beliefs. Unvarnished truths open them to judgment (“wow you really believe that?”) and it’s hard to treat everyone and everything fairly and with the right amount of nuance. I get it: you might exaggerate or misstate something or give me a half-formed thought that you’ll later be embarrassed by…just. spit. it. out.

I really value people’s intuitions. When one spends all day/week soaking in a given area and problem, your off-the-cuff thoughts are likely more accurate and revealing than any amount of armchair analysis the skip-level does from a distance. To get at these nuggets I often need to push hard…even to the point of discomfort: “what do you mean by that? what, concretely, has happened? what specifically would you do in this situation? no, you have to pick one thing, what is it? I don’t understand what you just said at all, try again.”

In doing so I have to perform radical acceptance….to make others feel safe offering raw truths and neither judged nor dismissed. This also means not reacting immediately to the information provided (I can’t just rattle off “ok here’s what we’re going to do”…that might need to come 1 or 2 meetings later). Some people buckle under this sort of pressure/attention; so be it. Most would agree its better to be a part of a team that gets shit done rather than getting hung up on polite performative doublespeak.

There’s this really amazing quote from Barry Diller (media mogul of ABC/Paramount/Fox fame) on the Prof G Pod that perfectly encapsulates this idea for me:

I like creative conflict, I like argument, I like the whole concept of arguing things out of passion because all I care about is instinct. In order to hear the truth of something you have to push through and get to “what does that person really believe.” […] I just think it’s the most productive way to manage.

Get really good at cutting straight through to the heart of things. From here on out, everyone is going to be talking around their real issues.

Leading from the Front

16. Power exists to be used.

I don’t believe in Servant Leadership. There. I said it. I view pure Servant Leadership as an abdication of many of the core responsibilities of a manager that is ultimately a disservice to my team.

• What someone wants and what’s best for the company (or even their own career) can sometimes be in direct conflict.

• Some situations need immediate action (think: emergencies) and there isn’t time for democracy.

• More generally, there are diminishing returns to unending deliberation. Teams can get stuck in planning paralysis when there is no clear right answer.

• The manager’s standing in the organization directly impacts the work and opportunities for everyone reporting to them. While it’s true your success comes from the team actually doing the work, so too does the team’s chance to receive such projects come from your personal victories. It’s symbiotic.

• No team is an island and you must actively align your group with the will and needs of the broader organization. Sometimes that means shutting down side quests, science experiments, and other larks when enough is enough.

• The org must believe you’re able to channel it’s resources wisely and to great effect, or your team will be starved to death with shrinking headcount and fewer/less important opportunities.

• Depending on the task-specific competence of a team member, you may need to do a lot of telling (or at least selling) to get the right level of performance.

I’m not evil, I don’t believe in command-and-control either. Management is definitely a type of service job, but you have multiple constituents (your customers, the company, the organization, your team, etc). Trust, autonomy, openness, and a focus on collective success (over individual success) are all traits of healthy teams and the best managers create that. Sure these are all components of “Servant Leadership,” but most managers get hung up on the touchy-feely and forget to, you know, actually lead! The formal theory usually needs so many qualifiers and addendums to be at all practical that it isn’t worth the attention it receives.

There is a reason we have hierarchies at all and don’t just run huge flat orgs. Effective use of a power can be a tremendous force for good in the workplace:

• Leaders are exposed to massive amounts of information. While we should strive to share and be transparent, a coder who once-in-awhile thinks about business strategy cannot hold a candle to someone who has 100+ people across functions feeding them info all day, every day. Leaders can quickly divine the ideal path through ambiguous, high-stakes situations.

• When irreconcilable differences create deadlock, leaders can resolve the conflict and set the team on a forward trajectory. Healthy escalations are not about “tattling to Mom and Dad” but recognizing that sometimes teams can hold mutually exclusive goals that need untangling.

• On that note, if someone really is behaving badly and causing problems, leaders can quickly end it, one way or another.

• There are many decisions that simply don’t matter or where there is only one situationally and politically viable path forward. Leaders can quickly remove unnecessary degrees of freedom and improve velocity with thoughtful proclamations.

• If you want to quickly influence the way hundreds of people work, give someone a very high title and make them extremely visible. This is often more effective than 1:1 performance coaching because employees see “if I do these things, there is extrinsic reward waiting for me.”

As always, with great power comes great responsibility. I strive to find the intersection between what individuals want and what the company needs– maximizing their opportunities for self-actualization while continuing to fulfill my obligation to the institution. Swinging the gavel of authority feels really good (it’s even somewhat addicting) but try to restrain yourself to moments where the alternative is significantly more painful for everyone involved.

17. The “E” in “EM” stands for Engineering…or did you forget?

Engineering Managers (EM’s) must be technical…and I don’t just mean “vaguely understand what’s going on and professionally wrote code 10 years ago.” The most successful EM’s I have seen:

• Are excellent software architects, understand the entire system, and know how to reason about complex design decisions.

• Have a finely tuned barometer for what’s hard and what’s easy, and can represent the team in early scoping and feasibility discussions. Their finger-to-the-wind estimates can be trusted.

• Can triage bugs and customer issues quickly with a reasonable degree of accuracy, ensuring the right person or team is activated.

• Get “how things are built” in their company and what aspects of the tools and processes are smooth vs. toilsome. They can articulate where the tech/org/process debt is and which debt is worth paying off.

• Know enough about the code, frameworks, and patterns used to adjudicate technical debates, identify and shutdown the really pointless discussions, and unstick their teams.

You cannot do any of this if your technical skills are weak/out of date, or you never touched a line of code in your present organization. For me personally, at an absolute minimum this requires:

1. Reviewing designs and participating in ~most design discussions.

2. Doing code reviews on a regular basis (but not all of them, to be clear).

3. Participating in incident response / chasing down production alerts…even holding the pager at times!

4. Make hands-on contributions off the critical path. I usually try to pay down toil and tech debt (fixing flakey tests, automating tasks, quiescing noisy alerts, root causing low priority issues that might otherwise get closed/backlogged forever).

5. Researching and keeping abreast on the latest practices and frameworks both within and without your company. Give tech talks and educational brown bags (the best way to learn is to teach, after all).

These contributions build up the technical intuition required to guide the team and represent your area in cross-functional discussions….but, spoiler alert, this is hard. Finding time to do all of the above, while not neglecting your people manager responsibilities, and also not lapsing into outright micromanagement, is something most people screw up. This is why you often hear low-brow advice like “manager’s shouldn’t code!” But that isn’t a good strategy, it’s a clunky/imprecise guardrail to help new managers avoid going back to their comfort zone (code) and ensure senior managers don’t turn into micromanaging despots.

That said, there is certainly a spectrum here:

Pure people managers have a number of predictable failure patterns: they become little more than information routers/delegators (what value are you adding exactly?) or the team will end up making a series of terrible technical decisions that they fail to detect or prevent. On the other hand, hardcore “Tech Lead Managers ” (TLM’s) are really doing two jobs at once, and probably doing a bad job at one aspect or another. They often burn out and leave their teams in a lurch, or fail to develop a bench of competent TL’s.

Here’s the kicker, I don’t think the right answer is “be the perfect goldilocks mix of TL and manager all the time.” You should:

1. Provide the leadership your team needs: I have (had?) a “pure people manager” for one of my team’s…and, despite what’s written here, I think they are perfection. They were exactly what that team needed: someone who could set up the environment and remove chaos, align the complex web of teams/partners, and provide the loving/caring attention and coaching needed to unlock everyone’s potential. There was no lack of technical chops in that group, but without proper structure they would fail. Likewise, there were teams where all their problems tracked back to an absence of technical vision and execution ability, they needed a visionary TL with autocratic powers to get out of the never-ending break/fix/break/fix loop. Figure out what your team’s biggest problems and gaps are, and then implement the appropriate leadership strategy.

2. Play to your strengths: too much effort is wasted trying to address one’s weaknesses (where all you can often do is grow from being “really terrible” to “kind of okay, I guess”). Understanding your unique, standout strengths as a leader and exploiting them to maximum effect is how you can have a really outsized impact and get ahead in your career. This is the whole philosophy behind Clifton StrengthsFinder. For myself, I recognize that being a “TLM” is doing two jobs at once but I wouldn’t have it any other way. I first orient myself by tending to the details, and then progressively zoom out to higher levels of abstraction until I understand the whole organization. I approach the job as incrementally evolving the whole socio-technical system into better, more optimal states. Technical details are the basis that enable me to identify avenues for improvement and impact that elude my peers.

Understand the type of leadership you excel at providing, and find opportunities/problems that are most likely to yield to that sort of leadership.

18. Just take the vacation, it’s always “bad” timing.

I am hoarding PTO like a dragon hoards gold. Seriously, if I quit now and got my vacation days paid out I would make more money than all of my stock picks in the last year (side note: do not take trading advice from me).

It just never seemed like the “right” time to take a week or two off work. Something would surely burn to a crisp. The emails would keep on coming. I would get back and just be “two weeks behind” which was strictly worse. This led to bargaining with myself: I’ll take that vacation after performance reviews are done / after promotion season / after annual planning. In 8 years I have taken…3 weeks of vacation? I think? Opps.

This one is simple: it’s always “bad” timing but never as bad as you think. It’s far worse for everyone if you’re burned out and not playing at your best. Just take the damn vacation. Even better, make sure it’s at least two weeks long so people don’t just wait for you to get back. This helps pressure test if you’re really building a team that can thrive on their own, and focus your bench building efforts when you return.

19. Maybe only 1 or 2 decisions per year really matter.

There were times when it felt like all I did all day long was “make decisions.” Be it what things to prioritize, who to assign to those projects, short-term technical decisions, long-term architectural roadmap items, with whom to form alliances, or where to host a team dinner. Any time the team was picking between two ambiguous and equally good sounding options, I was the vending machine they punched a few quarters into and got a decision.

This usually evokes one of two feelings on any given day:

1. Fatigue: it would be great if someone could send even a single chat message that didn’t require you to choose between two horrible options with long-term existential consequences. Every ping will trigger a fight or flight response: “oh boy, here we go again.” None of these decisions ever come quickly–it’ll always lead to some amount of homework to figure things out–and worse, there’s no way to make everyone happy. You’ll descend down the mountain, stone tablets in tow, to a room that is 50% elated and 50% grumpy with any given proclamation.

2. Euphoria: nothing can stop you! You’re a machine for organizational efficiency and engineering efficacy. You seem to reap but never sow. Knowledge is power and power is one hell of a drug. This is the runner’s high of being a manager and you couldn’t imagine going back to a world where you didn’t get to make all these decisions constantly.

Whether it’s negative or positive, if you’re like me, you may start to believe “my organization wouldn’t survive without me.” Well, bad news, I’m here on the other side of nigh on thousands of decisions big and small with the gift of hindsight: almost none of them mattered. They were the managerial and engineering equivalent of choosing where to grab lunch: “McDonald’s or Taco Bell” (the correct answer is Taco Bell, btw). While it was important to make some decision, any decision and not get stuck in planning paralysis, the actual outcomes were not significantly different or better.

On the flip side, I can distinctly pin point one or two decisions each year that had massive, long-term, existential ramifications…usually because I made those decisions incorrectly. From the time I gave in to lesser demons and appeased my boss–supporting the creation of an over-engineered framework that has created O(10) SWE-years of technical debt and slows everyone down–to the time I rejected a rewrite project claiming “we will release and weigh the ROI of a rewrite using production data”–wasting a year struggling to fix all the bugs and never actually releasing anything.

Horror of all horrors, these decisions at the time didn’t stand out as particularly remarkable or momentous. They felt the same as the usual parade of mundane bullshit that traipses through my inbox–there was no tell that we had a “big one” on our hands. Even then, I thought my decision making rationale at the time was sound/logical, and yet these are some the biggest mistakes I’ve ever made. When made correctly, a singular decision of this nature can pay for yourself and your entire team in one fell swoop. Maybe it’s avoiding a pointless project, some very shrewd hardening that prevented an epic production disaster, or making a key hire that permanently alters the trajectory of your team.

There is no silver lining in this story. I haven’t discovered a bullet-proof method for clocking which decisions truly matter. Bezos’ one-way door vs. two-way door thing is a cute analogy, but not at all definitive. First off, all the examples I can think of absolutely presented as two-way doors, but confirmation bias is a bitch and you’re likely to ignore the evidence you chose the wrong door. Second, every decision is a two-way door when you command 50+ SWEs and have hundreds-of-millions of dollars in operational budget. What couldn’t you “undo” if you really wanted to!?

My only advice is to postmortem every mess up to find the common traits and patterns of weighty decisions, and to build a library of heuristics you can apply going forward. For me, a few signs I might be dealing with a Big Decision are:

1. ~8+ people are involved or directly impacted by this decision. It determines what they work on and how they do it.

2. Multiple parties have displayed emotional attachment to the decision.

3. Back-channeling has broken out. No one is willing to say “I disagree” publicly.

4. I feel any urge to optimize for appearances (i.e. this decision seems important to how me or my team are perceived by people who matter).

20. The dopamine reward loop for managers totally blows.

No one wants to hear their leaders complain about how hard leading is (“my crown is too heavy”). But if you couldn’t tell from this post…IT IS. Researchers at Columbia University surveyed nearly 22,000 full-time workers and found that middle managers are more depressed and anxious than any other group. Longitudinal studies found ICs that became managers and later middle managers were more likely to become depressed and anxious. Cool cool. No big deal.

There are probably lots of reasons why that is, but I think it has much to do with our complete lack of a dopamine reward system. This is the built-in motivation circuit in your brain that releases the chemical dopamine when you do something pleasurable or achieve a goal, making you want to repeat that behavior. It evolved to reinforce survival activities like eating and socializing, but it also responds to things like accomplishments, unexpected rewards, and even anticipating something good is about to happen.

When you were a hands-on IC or even a line manager, every day you could do something that delivered a fresh hit of dopamine: checking in some code, squashing a bug, helping a peer or a customer.

As a manager, your dopamine reward loop is long (like, really looooong).

• You own entire major business objectives that might take 2/3/4 years to land.

• Coaching and training someone on your team might not show tangible progress for months…and sometimes it doesn’t stick making it all feel like a waste!

• Process changes can be implemented quickly, but you won’t know for sure if it generated the desired outcome (e.g. “faster launches”) for multiple quarters.

• Closing a new hire is great and all, but the real test is to see how well they onboard and if they can deliver valuable work. See you in 6-9 months!

Each day is spent nudging a complex socio-technical system into a more optimal (we hope) state. The individual activities that go into that do not return the same feeling of accomplishment:

• Coached Donald on conflict de-escalation techniques to use on Megan. They still hate each other.

• Reviewed Mike’s design doc and connected him with experts on the SRE team. This design isn’t going to work and the SRE’s are a hail mary.

• Argued with Scott about the frequency of status updates. No conclusion was reached.

• Presented our reliability strategy to exec leadership and got zero feedback.

• Traffic spiked and we ran out of resources, asked the team for postmortem. They were not happy with me and just wanted to ignore the issue.

• Politely refused a request from a peer team that was pathologically insane. They will escalate to my boss tomorrow.

In practice this translates to many dark weeks without the joyous spark of accomplishment. These long loops can easily get disrupted entirely (project delays/cancellations, someone quits, etc). I think this is why every manager I know is obsessed with fitness–it’s something entirely within our own control that can become a sort of daily dopamine supplement!

Some managers try to recreate the dopamine reward loop they had as an IC with fun games like inbox zero and manicured todo lists, but this is just delaying the inevitable or outright wasting your time. You have to ween yourself off this stuff–things will never be the same from here on out.

21. Truck routing is NP-hard and yet Fedex still manages to deliver your packages.

If you’re like 1 in 5 Americans, you probably had a package successfully delivered to your home today. This happened in spite of the fact that optimally routing trucks is a form of the traveling salesman problem, for which there is no polynomial time solution. We haven’t had computers (or humanity, or Earth) long enough to solve TSP so what gives? How is this possible?

Someone made a decision: a good-enough heuristic that happened to work well for the street grid in a given city. It might not be optimal, but you got your mail in reasonable amount of time didn’t you?

You too will be forced to make such decisions under ambiguity. Decisions where:

1. You have incomplete information.

2. There is no established norm or best-practice solution.

3. All available alternatives feature significant trade-offs.

4. There is insufficient time to identify the best possible option.

5. You may need to act first to get a sense of how cause/effect work (a complex or chaotic domain in the Cynefin sense).

There is simply not enough time to be empirical and deductive about absolutely everything. The usual engineering org is under so much pressure (either from within or without) that it is impractical to analyze everything until you’re absolutely certain what the right answer is.

Ultimately, a leader creates the clarity for the appropriate decisions and actions to emerge. In the event of outright paralysis, a leader personally takes action or makes the decision. This will put all of your intuition and experience to the test. I have always been a fan of Amazon’s leadership principle that states, “Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.” I have my own much more sarcastic version of this principle: “it’s not just good, it’s good enough.”

I am not advocating for making random, under-considered choices, but rather getting very fluent in techniques for reducing ambiguity, and thereafter comfortable not knowing whether you’re right or wrong and having to trust yourself (or your team).

One of the most eye-opening books in my journey to master ambiguity is How to Measure Anything: Finding the Value of Intangibles in Business by Douglas W. Hubbard. In the book, a definition of measurement is proposed:

Measurement is a quantitatively expressed reduction of uncertainty based on one or more observations.

This puts Big Tech’s data and metric obsession in a totally different light. Rather than thinking about “measuring something” as a way to observe a physical quantity in the world (think: the weight of some potatoes at the supermarket…there is only one right answer), it should be thought of as a way to reduce uncertainty around a decision you’re trying to make…at least until its no longer economically beneficial to do so.

Decisions like “should we build feature A or feature B?” and “how much effort is this project?” and “what in the world do my millions of users want from me?” can all have uncertainty reduced tremendously by some basic proxy measures and heuristic estimates. If you passed the algorithm and riddle festival that is the traditional Big Tech Interview, then you are at least serviceable at forming Fermi Estimates. Even just estimating ranges for unknowable quantities can be useful in navigating these ambiguous situations e.g. “this project will definitely take more than a month, but less than a whole year” or “we can surely capture 1% of the total addressable market with this feature, but there’s no chance we pass 5% any time soon.” Simple experiments, iterative launches, and existing metrics can be used to nibble away at unknowns and enable enough collective sense-making to unblock a decision.

It’s through this lens that I went from rolling my eyes at the weekly business review (and the many games my fellow managers played to make it look good) and learned to love metrics.

22. Hold a high bar, respect the opportunity

OK, I know corporate values seem super hollow to most people these days, but I really do think Google was on to something with “the three respects.” Specifically, “respect the opportunity.” As much as working at big tech can sometimes feel like one non-stop farcical Silicon Valley skit, it is truly an honor to work on products used by most of the human population and to create a positive impact at that scale.

Moreover, at an individual level, getting a job in big tech is fundamentally life changing. From the long-term career prospects, to finding a community of like-minded people (aka…nerds), to the staggering amount of personal wealth it generates and everything that unlocks. The American Corporation is an amazing engine for social mobility and in an age where big tech is the top of the corporate heap, nothing comes close to a FAANG job for its ability to lift individuals out of poverty and set them on a path to lifetime security and abundance.

I was literally homeless for part of my childhood, now I have more money than I know what to do with and short of, like, outright nuclear war, I will never experience precarity again.

For so many, jobs in big tech are a lifelong aspiration that they work for years and years to accomplish. Studying all night long to get CS degrees, foregoing relationships and friends for years at time, moving across the country, and grinding out LeetCode like their life depends on it.

This is why I have a reputation for being a bit of a hard-ass as a manager. I absolutely do not tolerate mediocrity or anyone coasting, and you shouldn’t either. Even the lowliest entry-level L3 SWE job is a role that someone, somewhere is dreaming of with every fibre of their being. With this comes the need to show people the door when they’re no longer holding up their end of the bargain. I have watched many managers waffle when someone is failing despite repeated coaching and feedback. It’s bad for the team, it’s bad for you, and it’s bad for them to let problems like this go unaddressed. Firing people is one of the most emotionally ruinous things a manager must endure, but it must be done. As a manager you have a duty to the company, and in my mind, society, to ensure these opportunities go to those who truly deserve them. Be uncompromising in the standards you uphold.

Career Growth

23. Figure out what your boss is trying to do and help them do it.

Maybe this seems pretty obvious, but I have seen far too many people screw this up.

Your manager has a mission: something they are trying to accomplish or deliver. Maybe it’s something handed to them by their boss or it’s a strategy/idea of their own making, it doesn’t really matter. The point is, just like your own staff, you are a cog in the machine that is grinding towards that mission. Understanding the role you and your team(s) play in that machine is critical to ensure you build an organization that is fit to purpose.

Where I see rookie managers go wrong is when they grow to a point where they believe their job is to create and implement business strategy. Usually this is after 2 or 3 years nailing the TLM and/or execution-oriented management gig. They get antsy, “what’s next!?” Someone gave them a copy of Rumelt’s Good Strategy Bad Strategy and now all the world’s a nail for the hammer that is Diagnosis/Guiding Policy/Coherent Actions. They never actually take stock of what role they and their team plays in the broader organization, and so start doing the “next-level up” job (or maybe more like next-next-next level up job, it’s BigCo after all). What happens next is a tale as old as time:

• Rookie manager proposes a grand ambitious strategy for their team (or maybe even several adjacent teams).

• Their leadership team shows little interest and continues to assign work like normal to rookie manager.

• Rookie manager tries to bend all assigned work to their strategy, constantly selling the team on their “amazing” vision.

• The strategy never fully materializes because it’s not actually driving action in the organization.

• The team becomes numb to all this “strategy” stuff because it just seems like a management bed time story and not reality.

• The rookie manager continuously advocates for their strategy in every meeting they can wedge it into.

• Their leadership team grows frustrated having to constantly placate and steer this person back onto the train tracks and starts giving them the cold shoulder.

• The rookie manager grows disillusioned and quietly gives up, bemoans reporting to a leadership team that “doesn’t have a strategy and just doesn’t get it.”

Look, I’ll be honest, I’ve walked this path. I’ve managed people who have walked this path. It always ends in tears (and quitting). This is what we mean when we say someone is “out of alignment with the org.” As usual, Camille Fournier can explain it better than I can.

I have continuously returned to this quote from Chad Fowler (of Wunderlist fame, RIP to the best todo app ever):

Doing a job with integrity means being focused on the business and its success in a way that shows you understand “success” from the perspective of the business…and you bring along others.

Your boss is fighting a multi-front war to bring their vision into reality (just think about your own struggle to get your team to do…anything). You cannot underestimate how powerful it is to “not be a problem” in that regard. This simple mindset has enabled me to quickly and repeatedly become my direct manager’s right-hand and confidant…it’s worked for something like 7 different managers. I take care of them so they take care of me, and shortly thereafter advancement up the ladder has followed.

Sometimes this means working on something you don’t believe in or aren’t particular proud of; I’ve shipped a lot of stinkers. You have to decide for yourself what’s important to you at the moment.

This emphasizes the importance of choosing who you follow carefully. The dissonance between “I think this mission is shite” and “to do my job with integrity I must throw my whole being behind making this happen” will drive you to strong drink. Ideally, you would one day report high enough that the “mission” is more like a high-level product strategy, a market to conquer, or an entirely new line of business to be built from scratch. These sorts of missions are broad enough that there is plenty of room for you to stretch your legs as a leader and use your hard-won expertise. Narrow missions like “deliver feature X” or “grow daily active users by 1%” leave little room to maneuver and you will focus primarily on execution, stunting growth (see the execution->impact->optics ladder discussed earlier).

24. You don’t need to outrun the bear, just the guy next to you.

A lot of people have this semi-naive belief that the key to getting promoted or ascend up the org chart is delivering some amazing smash home run…hitting a perfect score on all your OKRs, crushing the KPIs, clinching the deal, launching the huge feature, etc.

Sure, it won’t hurt, I guess.

The real secret? Professional endurance. The ability to report to work, every single day, and not burn out. To consistently and reliably do what you say and say what you mean. Being a dependable employee, with high bullshit tolerance, who takes feedback and listens well–all over a long period of time–makes you an extremely pleasant and desirable partner in crime. When your boss’s boss is picking their newest direct report, the first question they have to implicitly answer is “am I willing to talk to this person every single day or are they annoying as %&$*? When they say they are going to do something, do they do it? Do they think like me or do I have to convince them of everything? How hard is it to give them feedback? Can I leave them to their own devices for months at a time?”

My shot at running bigger and bigger orgs came from outlasting colleagues who crashed out from stress, and I was the next most dependable person on the leadership bench. It’s a little bit depressing, but at BigCo you’re playing a game that lasts decades so it actually makes sense to ensure the leadership bench is, above all else, durable.

25. Growth != the size of your org.

It is a common misconception that growth as a manager comes from a larger and larger organization. This type of thinking leads to toxic behaviors like empire building, inflating the size/complexity of projects, and building pointless things to justify yet more hiring. Runaway hiring motivated by ladder climbing managers is a direct contributor to the recent spat of tech layoffs.

Here’s the deal: the number of people reporting to you or even how many layers of managers you manage is more or less just a reflection of the number of humans required to do all the work. The number of humans could be quite vast (think: things that don’t scale like customer support) or quite slim (think: software engineering in the era of GenAI 👀). Sure it says something to be trusted with that many humans / that much wrapped up capital–there is certainly a rough correlation with “career growth”–but thinking this way is incredibly self-limiting and you are setting yourself up to hit a glass ceiling.

The key question to ask yourself is, “how has my job actually changed?” Consider–

• The sorts of problems you personally solve.

• The skills you bring to bear and are actively practicing.

• The scale and nature of the decisions you make.

• The outcomes you are trusted to deliver.

Therein you will find the real breakpoints in your career are not “10 -> 30 -> 100 reports” or even “L6 -> L7 -> L8.” Rather, growth occurs when you shift from managing execution to other planes of leadership Here’s an “alternative” career ladder for people leaders:

1. Projects: you are primarily concerned with execution. Success means delivering on time with the right level of quality.

2. Teams: you are primarily concerned with impact. Success means ensuring the projects delivered add up to something valuable to the enterprise.

3. Teams of Teams: you are primarily concerned with productivity. Success means optimizing the predictability, velocity, and efficiency with which your group delivers impact.

4. Functions: you are primarily concerned with strategy. Success means your function (e.g. “site reliability engineering”) delivers sustained competitive advantage to the overall business (e.g. “better reliability reputation enabling us to land large enterprise clients.”)

5. Businesses: you are primarily concerned with P&L. Success means your organization pays for itself or at least fulfills its role in the overall portfolio (see: loss leaders).

6. Portfolios: you are primarily concerned with entire markets. Success means capturing or generating substantially all of the available value in a given economic arena.

7. Enterprises: you are primarily concerned with governance. Success means creating the conditions and guardrails for your senior leaders to operate a suite of businesses/strategies/plays that create uncorrelated returns for shareholders.

Two books so perfectly capture this, I cannot recommend them enough: The Leadership Pipeline and it’s follow on The Performance Pipeline. I am also quite fond of Shreyas Doshi’s even simpler-to-understand framework: execution/impact/optics.

26. Track skill growth by level of effort and exertion.

Aspiring chefs are often asked to perfectly prepare eggs on demand of different styles. The simple yet unforgiving nature of many egg preparations tests the chef’s foundational cooking skills, recall and knowledge of methods, composure under pressure, and precision/discipline.

The “egg test” for managers is being subjected to 12 straight hours of meetings where every 30 minutes is about a totally different topic, with a totally different stakeholder, and every conversation is an active two-way exchange (no boring all-hands you can just tune out while you read emails). Here’s a random Thursday morning (not even a whole day) plucked off my calendar:

• 1:1 with a disgruntled skip report who wants to get promoted.

• H2 Roadmap session with Product.

• Design discussion about a new testing framework.

• HR consultation on a serious case of misconduct.

• Postmortem review from a huge incident we had last week.

• Status readout to VPs to decide if we shitcan an entire project.

• Coaching session on exec communication with one of my directs.

• Negotiating a stand off between the feature and platform teams.

• Emceeing a fun event for my distributed team members.

• Deciding on the final set of metrics we’ll use for next quarter’s OKRs.

It’s almost a misnomer to call this a “test” because it’s just an average day…but it really does push one to their limits. You no longer have the luxury of carefully preparing talking points for your status updates, good coaching questions for your 1:1, practicing the delivery of some hard feedback, or boning up on some technical details before a complex design review…you just have to walk in with <30s to change gears and nail it, first try, every time, completely cold.

What this means is that all this stuff that used to be hard/stressful and take a lot of time to prepare must absolutely be on autopilot. If a given skill or task requires non-trivial exertion on your part, you have room to grow.

I find it helpful to maintain an inventory of all the tasks and skills I need to call upon and rate them by the level of exertion / preparation I must put forth to do them well. My goal is to drive as many thing as possible to “autopilot.”

Part of putting skills on autopilot is having multiple ways to do them–there isn’t a one-size fits all method for delivering hard feedback or negotiating a cross-team technical decision–if you can only do things one way you will surely find yourself overmatched at some point. If you invite me over to breakfast, ask how I like my eggs, and then serve scrambled after I requested over-easy, I will doubt your culinary abilities. The same goes for management: beyond exertion, it pays to also track the different methods/techniques you’ve mastered in each category.

27. Professional ennui can kill you (literally).

There is a crisis of purposelessness forming in big tech; I’m no Marxist but the alienation of labor is alive and well. In the 6 months alone, I have had 10+ conversations with different people who no longer find their jobs fulfilling and are utterly unsure of what to do with their lives. They feel tired, bored, and estranged from the work that occupies nearly half their waking hours, and cannot see a way through the emotional storm cloud.

ennui (/änˈwē/): a feeling of listlessness and dissatisfaction arising from a lack of occupation or excitement.

There was a common pattern in all these conversations which startled me when I noticed it:

• Person born of little means works hard to secure a job in tech.

• Tech worker grinds with all their heart and attains success, either in the form of a particular career goal or job level.

• The successful tech worker suddenly has enough wealth to feel truly secure for the first time and is no longer compelled to grind.

  • (alternatively: has some sort of health scare that shocks them out of continuously climbing the ladder).

• They look around and realize they feel no inspiration from shipping someone else’s garbage ideas, in a codebase so full of toxic sludge it’s a superfund site, with a process that makes the U.S. Congress seem high functioning.

• At this point, they experience stuckness from one of two angles:

  • So much of their life/identity is tied up in the job that they can’t imagine a change. They’ve come to depend on the stable source of income because now they have a family of their own or elderly parents to take care of.

  • They’ve never experienced having “real” choice in their lives before. They were on rails from the time they entered high school to today so now have no clue how to navigate life with resources and options.

Oh yeah, and add in the complete collapse of tech hiring, a topsy-turvy economy, and a massive over-supply of CS graduates so there’s little hope for job hopping as a distraction. So here many of us find ourselves, in the midst of late-in-life personal crises, stuck in jobs that no longer offer the sense of purpose and direction needed to feel fulfilled.

All it takes at that point is a bad break-up, a fight with a family member, the death of a pet, or even just a failing project to send you into a massive depressive spiral. One hopes to have a close friend or a partner to call upon in their darkest hour…or maybe not having done nothing but work your entire adult life. I know this is all very dark to consider, but I write it so that if you recognize yourself herein, you know you’re not alone and what you’re going through is normal.

Viktor Frankl’s Man’s Search for Meaning was immensely impactful in navigating my own crisis of purpose. Therein, Frankl introduces man’s “will to meaning” (the premise that the primary motivational force of an individual is to find meaning in life) and “noogenic neuroses” (mental disorders which follow from existential frustration). He offers a set of truths uncovered from enduring the holocaust:

1. Life has meaning under all circumstances, even the most miserable ones.

2. Our main motivation for living is our will to find meaning in life.

3. We have freedom to find meaning in what we do, and what we experience, or at least in the stance we take when faced with a situation of unchangeable suffering.

As I wrap up this novella-sized blog post, you’ve surely gotten the sense that, at many times in my career, management has felt utterly pointless: herding cats through organizational games of chutes-and-ladders to deliver on goals I didn’t always believe in. Yet management–or at least people leadership in general–is the most meaningful thing I have done and maybe will ever do with my life.

For me, work is sacred. A tumultuous childhood left me with a deep insecurity over my own uselessness. I learned what it meant to feel powerless watching a parent succumb to addiction, seeing the life we’d built disappear, and being unable to stop any of it. Work was my redemption: an outlet where I could build something solid and lasting with my own two hands, of my own will and volition, and accumulate the wealth and power to protect the ones I love. The self-worth, self-confidence, and self-actualization that accompanied achievement at work saved me many times over. Now, I set out to offer that same redemption to anyone who will have it. Creating an environment for people to thrive and do things they will look back on with pride is my “why” and no amount of organizational dysfunction will distract from this purpose. Most importantly, I’ve realized I can do this from nearly any role I occupy, I don’t need to be in management to lead in this way.

Defining your own “why” is something only you can do for yourself, but as Nietzsche says:

He who has a why to live for can bear almost any how.

Looking Ahead

It’s an interesting time to be leaving management: the industry is cutting back on “fat” in the middle management tier, is asking more of managers than ever before (the average span of control in my neck of the woods has gone from 4-7 ICs to 10-16 ICs with “tech lead” expectations sprinkled on top), and it’s an open question if this sabbatical turns permanent. This has happened before, and it only took a few years for us to “rediscover” that good managers that aren’t overloaded do, in fact, increase effectiveness and improve business outcomes.

For anyone that expects to make the leap to leading the post-AI generation of tech worker/team/company, I think you’ll need to do more than dabble on nights and weekend while juggling way-too-many-reports. The current management climate, personal health issues, and the “AI revolution” was the perfect excuse for me to make diving head first into the new world my full-time job…at least for a time. I expect to pendulum back into management very soon, especially given my views on the inseparability of “tech lead” and “manager”…whatever leadership is needed to get the job done, right? I’m a bit of a leap-then-look person at it always seems to work out in the end. For my committed readers, I’ll keep you posted how this turns out.

The only “death” I fear is standing still.

Does this sound like you? You’re an achievement-oriented leader. To build momentum, you personally set the standard for performance and for exemplifying the values of the organization. You take the lead, set the pace, and expect the people around you will notice, follow along, and (eventually) catch up to and match your performance. What do you think actually happens? Not what you expect. Let me save you many months of pain. This pacesetter-type leadership has been a huge part of how I have managed the last 2 years, and while reflecting on 2024, I’ve finally come to understand some of the ways it works but can also fall short.

In 2022, I inherited a team operating a piece of critical platform infrastructure for Google. The team was full of bright, experienced engineers but was ostensibly failing. An infrastructure migration effort was entering its 3rd year with little to show in the way of results. Still getting my bearings in the new org, I spent time observing the team and came to the conclusion we were dying a death by a thousand cuts. Everyone was super talented and in each area (architecture, project management, operations, code health, testing, product, etc) we were easily scoring a solid “B+.” But, it turns out, that “final missing 10%” compounded in a way that made the aggregate result underwhelming.

Consequently, the situation called for small, surgical changes across the board to optimize the performance of the team. The required changes would encompass both cultural attributes (habits/incentives/values) as well as fundamental technical skills and problem solving intuition. As part of my overall approach to turning the ship around, I resolved to role model the desired behaviors. For example, when we had a near-miss incident (caught during the release/rollout process) I personally authored the postmortem and led the review. Whenever production did something unexpected/strange (even if non-breaking), I would doggedly pursue an explanation even if it took hours/days. My intention was to exemplify a value of curiosity and an unwillingness to accept “I don’t know” as the final answer. I would show-not-tell the team how to exploit debugging tools to maximum advantage and buff up our observability approach whenever an answer was not forthcoming. Surely, then, they would all become masterful solvers of distributed systems murder mysteries….right? Surely they would all become naturally curious and investigate these blips without being asked…right? Right!?

Not quite. My superstars and favorites continued to excel and even improved. Meanwhile, the strugglers and the “chronically stuck” continued in their old ways. These were the very people I most wanted to help! It wasn’t that “leading by example” made no difference (in fact, it was quite important to my eventual success coaching this team), but rather the role it played is more akin to setting the table…someone still has to cook dinner if you’re going to have an excellent meal. Through this experience and talking to other managers, I found many incorrect assumptions about the mechanism by which leading-by-example works.

In this post, I will–

• Chronicle the 6 errant assumptions that prevent learning-by-example from working consistently.

• Dive into the scientific underpinnings of observational learning, using neuroscience, psychology, and sociologally to describe the preconditions for vicarious learning.

• Describe a technique for successfully leveraging leading-by-example as a key component of an overall performance coaching regiment.

Assumption 1: your intentions are pure.

It is quite a coincidence that one of your primary instincts when the team is struggling is exactly the thing you’re told not to do as a manager and that most new managers struggle to resist: doing the work yourself. Dressing it up as “leading by example” is a great way to deceive yourself into believing that you’re doing the right thing when in reality you’re falling back on old habits built up when you were a tech lead.

In football, the offensive coordinator cannot grab the ball and run down the field. It’s against the rules and regardless they probably aren’t physically capable of a 4.5s forty-yard dash. There’s no such limitation in software engineering, you’re perfectly capable of reprising your role as star quarterback. Instead, you need to take a step back and ask yourself “what would I do if it was physically impossible for me to step onto the field?”

You need to be skeptical when your intuitions seemingly justify a personal vice. “Uggh, I know McDonalds isn’t part of my new diet, but I’m just so busy today I don’t have time to cook and need to eat so….” Engaging your critical thinking is hard (addiction is a bitch). Verbalizing your thought process either in writing or by talking to a trusted peer can pressure test the decision. You’ll know you’re on firm ground when you can articulate…

• A complete set of observed symptoms of team dysfunction.

• An unexaggerated diagnosis of the causes of this dysfunction.

• Next steps and interventions flowing logically from these conditions.

Leading-by-example isn’t a meaningful intervention, it’s a tactic implemented towards a specific intervention strategy. For example, if the problems your team is facing require “culture change” then role modeling might help…but it should appear alongside several other tactics (such as: adjusting performance incentives, declaring values, screening for culture fit in the hiring process, team recomposition, etc).

Assumption 2: people want to be you.

I’ll never forget the moment I realized I was a different species. A colleague had come to me for advice: they were having a heated disagreement with the tech lead of a sister team. I was offering perspective from my past experience when they interrupted me asking, “oh wait a minute, you’re on the management ladder right?” and promptly short-circuited the conversation. It was as if my role in management meant I had no valid advice to offer an individual contributor. Prior to this point, I still very much thought of myself as an engineer, one that just happened to be working on problems at such scale that it was necessary to program people in addition to computers. This was a senior staff engineer so ostensibly their role wasn’t too far removed from my own. And yet, I had 3 or 4 similar such experiences in short order which further confirmed I was an “other.” In Google’s culture, managers are a different specifies. The same is probably true at your company. This creates an apparent category error wherein many of your reports won’t even have a fundamental recognition that how you manage your skillset, spend your time, and direct your attention has any bearing on how they ought to do the same.

Even your beliefs and preferences will be regarded with a grain of salt–seen as descended from a different set of priors towards a totally different ends. Borrowing the language of Max Weber–

• Engineers experience managers as purveyors of functional rationality: a type of bureaucrat whose primary concern is a means-end calculation of how a result be quickly and efficiently achieved (“I want this task done, done quickly, and with just enough effort”)

• Engineers see themselves as purveyors of substantive rationality: more holistic, reticular, and value-driven (“I navigate the interdependency of a wide range of objectives and perspectives, balancing elegance/functionality/cost/extensibility/…”)

In most cases, there will be no recognition that what appears as the former is really a much more advanced practice of the latter. For example, consider the entrenched resistance you’ve probably encountered over task management/agile practices. While you see organized backlogs, task breakdowns and small single-purpose PRs as tools that personally help you do “better” engineering, others see these as tone-deaf bureaucratic demands.

Assuming that people “look up to you” and are therefore motivated to learn your skills and imitate your proclivities is wishful thinking. As such, leading-by-example can actually move your team in the opposite direction. Your actions will be seen as establishing “this is the sort of thing the boss deals with.” The end result is less engagement with the desired behaviors rather than more. This is why tech leads (TLs) are so critically important. TLs inspire mimesis with ease because many envision a direct progression from where they are to the TL’s role–they want to be the TL and so watch their behavior carefully. No one wants to be a manager…especially if you’re like me and spend far too much time talking about how miserable the job can be.

Assumption 3: people care what you think.

Have you ever downplayed your own authority/power/importance? Probably! Servant leadership dominates present-day work culture. Regardless of style, most leaders try to actively encourage thinking for oneself and having a strong sense of ownership . This is a good thing! Low-ego cultures are amazing! People feel compelled to offer their best work, are unafraid of admitting mistakes, and readily adopt a beginner’s mindset ensuring continuous growth. However, this also means eroding your own capacity to influence through deeds alone. You have, in effect, been continuously declaring “what I care about, believe, and do might not matter…think for yourself.” It would be hypocritical then to express dismay when someone fails to emulate your behavior.

This flies in the face of a pervasive belief in leadership circles that where leaders focus their energies team interest follows. I most often hear this expressed by high-ranking VPs. First off, these folks exist on a totally different plane of existence from run-of-the-mill managers like me. Most people probably don’t care where you or I direct our gaze. Moreover, I think this confuses actual and proximate cause. For example, you show up to an operational review and grill the engineers with deep, probing questions that catch them off guard. At next month’s review, suddenly the engineers are much more prepared and they successfully answer your questions. Have you taught them the importance of rigor and engineering excellence? Probably not. What you’ve actually done is served up a hearty dose of negative reinforcement via public embarrassment. People are extremely sensitive to social rejection and will be certain to avoid repeating such mistakes. Any deeper learning rests on the assumption that the team is mature enough to realize that their boss’s attention is a valuable signal about what matters. This lesson unfortunately tends to occur somewhere in the mid-to-late stage of one’s career.

Speaking of hard-won career lessons: when is the last time you were memed into doing something because it was “VP so-and-so’s #1 thing” only to find out later that said VP actually has five or six “#1 things?” Probably, like, yesterday given how often this happens to me. In effect, all of us–no matter our level in the organization–have been taught that a very-powerful-person’s interests are mercurial (hey, it’s almost like they are humans like the rest of us). One will not last long over-indexing on the opinion du jour.

As leaders under conditions of egalitarianism and fickleness, we’ve effectively forfeit the ability to influence behavior through the dispensation of attention/favor alone. I believe power exists to be used (otherwise, just have one giant flat org) and you probably shouldn’t just give it all away, but that’s a topic for a different blog post. At this point the cat is probably already out of the bag. You could fall back on the one “hard power” we posses: the distribution of opportunities and career advancement (and $$$). But then that brings us to…

Assumption 4: you can always reward the right behavior.

You need to be realistic about much authority you really have. You might think, “I define what success looks like in this team/org/company.” However, the average reader of this blog is a manager at BigCo where promotions and annual ratings are the result of committee consensus. Are you certain you can sway the committee to support Jane Doe’s promotion just because she followed your lead? This rests on an even more tenuous assumption that you personally are well-aligned with what the organization values. Or that factors outside of your control won’t pop up at the wrong time (like an economic recession decimating the merit increase budget). Even startup leaders will run into the limitations of social capital and how much they are willing to shorten runway or strain relationships with cofounders in the name of perfect fairness.

Every time you fail to reward or at least praise someone who followed your lead, you run the risk of breaking the operant conditioning loop. There is a sort of game theoretic calculus happening where each of your reports is operating under imperfect information. For example, say you only offer formal feedback during annual review cycles. Your reports will be hypersensitive to any positive/negative signal whatsoever–even accidental signals. They are likely to see mirages of feedback where there is none and end up optimizing for the wrong behaviors.

Even the best managers fall victim to this in small ways due to inconsistency. It’s impossible to have perfect visibility into how all of your reports spend their time. They might not think to broadcast that they did something or realize what they did is praiseworthy. You might have too many reports to pay close attention. You’ll be stressed and overwhelmed one day and just forget to respond to that launch email with a hearty congratulations. Either way, at some point you’ll miss something. Doubly so if you’re trying to incentivize “micro-behaviors” that aren’t readily apparent to distant observers.

Assumption 5: everyone’s definition of success is the same.

On the subject of incentives, not everyone is incentivized by extrinsic motivators like promotions and wealth. Engineers ultimately choose which incentives they respond to, and some of those incentives are not under your direct control. Consider intrinsic motivators like mastery, novelty, relatedness, acceptance, and honor, freedom. If someone is motivated by mastery (e.g. constructing elegant, maintainable, well-architected systems) then they aren’t likely to pay much attention to the techniques you employ for achieving business impact (e.g. balancing velocity/quality for long-term commercial success).

Imparting new skills via role modeling depends on the motivation of the learner to make an effort to understand and replicate your actions. Role models often operate on the faulty syllogism:

1. My team has the same goals as me (i.e. business impact).

2. My team is motivated to grow their role at the company.

3. My team is not acting optimally towards that objective.

4. Therefore this must be because of missing knowledge.

5. Therefore they will be attentive and driven to replicate behaviors that demonstrably achieve business impact and garner recognition.

The problems begin as early as step #1, where you assume everyone is aligned around the definition of success. Consider the divide between “launch” and “landing.” When someone sees “launching” as the end-goal, they will throw a party and go home the second their code hits production. Meanwhile, if you see “landing” as the end-goal, you’ll continue diligently measuring and assessing whether the launched feature is resonating with users. What you might view as excellent role modeling, your team sees as “oh that’s just Jim, he’s obsessed with metrics 🙄.”

Misalignment occurs in somewhat obvious ways, like in the example above, but also in more pernicious forms. For example, someone may be very transparent that they are seeking career advancement and therefore define success around helping the organization achieve its goals. But what happens when you disagree about the specific ways they need to show up given their role/level? Your team members have some conception of what their “craft” is and the skills required to be a masterful practitioner. When their conception of “being an excellent engineer” is in conflict with “the behaviors the organization will reward” cognitive dissonance follows. In the worst case, engineers become embittered and lose confidence in the organization. No amount of role modeling will get through to someone who sees those behaviors as emblematic of an inferior value system.

Assumption 6: your work is visible.

Goal formation occurs at the macro level (as in the prior assumption, where we talked about overarching objectives like business impact) as well as micro level (goals employed in the problem solving procedure). For example, responding to a production incident involves goals like “figure out when the incident started” which itself can entail further goals like “find the right graph in Prometheus.” Unless you go out of your way to broadcast every step taken, your team will have no visibility. It will be impossible for someone to replicate your problem solving strategies or the subordinate skills you drew upon in the process.

Observational learning depends on the learner’s capacity to recognize, encode, and structure the critical concepts. If the learner cannot perceive and understanding the nuance behind your actions, they aren’t likely to successfully replicate those behaviors or employ them at the appropriate times.

That said, perception also depends on sensation which is all too often missing in our brave new world and remote and hybrid work. The bulk of your brightest moments and breakthrough problem solving likely occur in private or a closed conference room. Your team can’t learn anything if all they can observe is the final end result.

I’ve tried to solve this by sharing stream-of-consciousness documents and chat threads which capture my entire process, tools utilized, and evidence collected every step of the way. I call this “live-tweeting the problem.” One such document was over 20 pages and took several days to write. This just isn’t practical. It’s even less practical to chronicle the nearly infinite number of things you didn’t do and actively avoided because you knew they were fruitless blind allies. This is what’s known as negative knowledge and assists with effectively avoiding obstacles (like spending hours debugging a WARNING in the logs that you know is just a spammy log line that gets printed even during normal operation).

Despite your best efforts, most of the time your team will be reading smoke signals limiting the effectiveness of any role modeling.

The Science of Observational Learning

I’ve painted a pretty negative picture, so I want to reiterate that leading-by-example is a foundational part of how I approach my work. Doing this effectively means replacing errant assumptions with empirical facts. When you “lead by example” you are deploying what psychologists call observational learning. Understanding the underlying mechanisms will help you be a more effective role model. Let’s build this up starting from neuroscience.

Learning Abstract Concepts and Mirror Neurons

A mirror neuron is a neuron that fires both when an animal acts and when the animal observes the same action performed by another. It has been postulated that mirror neurons play a critical role in the acquisition of motor skills and even speech/language. Mirror neurons have been frequently referenced in self-help literature and pop-science media, over-hyping the role they play. There is limited scientific consensus on the full extent of their function in human cognition beyond motor skills. In fact, mirror neurons were first discovered in the motor cortex (specifically area F5 of the premotor cortex) of macaque monkeys. When we talk about “mirror neurons” in the context of knowledge work or abstract skill acquisition, we’re often incorrectly extending the concept beyond its neurological basis.

What actually happens during knowledge work and abstract learning is more complex. Rather than mirror neuron activation, we’re typically engaging multiple cognitive networks, including:

• The executive function network in the prefrontal cortex, which handles planning, decision-making, and abstract thinking.

• The default mode network, which is involved in understanding others’ mental states and perspective-taking.

• The working memory system, centered in the dorsolateral prefrontal cortex, which maintains and manipulates information.

When we observe someone performing knowledge work, like programming or problem-solving, we’re not actually mirroring their actions in our motor cortex. Instead, we’re engaging in what cognitive scientists call “cognitive modeling” or “mental simulation.” This process involves:

1. Understanding the goals and subgoals of the observed behavior.

2. Recognizing patterns and strategies.

3. Building mental models of the problem-solving approach.

4. Integrating new information with existing knowledge structures.

When we watch someone debug code, we’re not actually engaging mirror neurons in the same way we would when watching physical movements. The learning process is more cognitive than motor-based.

“[Learners] need to make sense of the situation or instruction, identify and construe relevant goals, develop appropriate responses, and realize the goals to which their efforts are directed. Hence, individuals’ thinking, acting, and learning are mediated by the degree of conscious engagement when undertaking work tasks.”

– Stephen Billett, Christian Harteis, & Hans Gruber, Developing Occupational Expertise through Everyday Work Activities and Interactions, The Cambridge Handbook of Expertise and Expert Performance.

This distinction is important because it helps us understand why learning abstract skills through observation can be more challenging than learning physical skills. Without the direct motor-mapping that mirror neurons provide, we need to rely more heavily on explicit instruction, understanding of principles, and active engagement with the material. When one “leads by example,” that usually precludes any of the above:

• There is by definition no explicit instruction happening and any communication of principles rests on prior understanding.

• The low visibility of technical work in general further constrains the bandwidth of any information transmitted to the learner.

• Engagement with the material rests on motivation which, as covered earlier, can be impeded by self-identity mismatch, goal/motivation mismatch, and inconsistent reinforcement.

This partially explains why leading-by-example is middling-at-best for teaching new software engineering skills.

Social Cognitive Learning Theory

There are 4 cognitive conditions that mediate vicarious behavior acquisition according to Albert Bandura–

1. Attention: learners must actively focus on the model and behavior being demonstrated. This process is influenced by characteristics of the model, such as how much one likes or identifies with the model, and by characteristics of the learner, such as the learners’s expectations.

2. Retention: the observed behavior must be remembered and mentally represented. This process depends on the learner’s ability to code or structure the information in an easily remembered form or to mentally/physically rehearse the model’s actions.

3. Reproduction: learners must be capable of physically and intellectually performing the observed actions. Reproducing the model’s actions may involve skills the learner has not yet acquired. It is one thing to carefully watch a circus juggler, but it is quite another to go home and repeat those acts.

4. Motivation: there must be a reason or desire to perform the learned behavior. This process can be impaired by the learner’s beliefs about their ability to succeed i.e. self-efficacy. Someone may observe a behavior and believe it will help them acquire their goal states but with low self-efficacy they simply give up.

This framework gives us a new lens to understand our faulty assumptions. Your team is not attentive to you as a potential model because they do not identify with you or see you as an “elder engineer” to learn from. The inherently low-visibility nature of technical work makes it difficult to observe/encode/retain the critical concepts. Inconsistent or incompatible rewards/recognition schemes impinge motivation. Your over-involvement reduces opportunities to rehearse and reinforce reproduction. Goal states, values, and beliefs misaligned with the demands of the role and needs of the organization cause all 4 conditions to misfire.

Bandura’s theory is the accepted contemporary account. That said, psychologists have studied observational learning for more than a century. There are multiple outmoded theories and misconceptions that are relevant to dispel:

• Affective (emotional) response is not necessary for vicarious acquisition and reinforcement, in fact vicarious learning can occur even when affective responses have been chemically or surgically blocked.

• A response (skill) does not need to be taught before observation can affect it. Observation can successfully convey entirely novel, never-before-seen behaviors and abstract rules.

• Observation of an action alone cannot elicit a drive to emulate that action. That is to say, behavior will not be imitated unless reinforcement follows. Reinforcement does not always take the form of an explicit reward/punishment, it can also occur via normative social pressure or internal beliefs/goal states.

When conditions are right, observational learning is extremely powerful. It’s the basis for much of early childhood development. Considering that language and formal instruction are relatively modern inventions (anthropologically speaking), it really was the basis for all learning for thousands of years.

“The time, effort, and grief saved can be vast. Learning by observation also minimizes the need for overt trial and error practice. Even elaborate concepts and cognitive strategies are vicariously acquired. Also, most of our cultural heritage is socially transmitted. If it were not, each generation would need to reinvent algebra and the means to harness electricity. Witnessing others’ actions at solving problems, and the environmental effects so produced, together foster observational learning.”

– Ted Rosenthal & Barry Zimmerman, Social Learning and Cognition.

Now let’s put all of this theory into practice.

Effective Leading by Example Builds Credibility

The conditions for observational learning must be right. As we’ve seen, those conditions aren’t naturally found in the workplace. Moreover, there are many models that may be observed in the workplace. Imitation is first and foremost a sociocultural mechanism of transmitting in-group identities. Humans feel compelled to acquire the habits/traits/behavior of their identity groups in order to become accepted by those groups. We have an evolutionary need for the protection of the herd. You are not a herd, you are one manager. Statistically, your team is observing others more than they are observing you. There are more bad examples than good in the herd at large.

Cutting through the noise requires attention. As established above, attention is mediated by how much the learner likes or identifies with you as a model. When you step onto the field and do some hands-on technical work, you build credibility as an engineer rather than as a people manager. When you pick up some important but painful toil (holding a pager, fixing a broken integration test), you show that you’re not above hard work. When you become recognizable to your team as “one of them,” a fellow engineer, they will be more likely to take note of the behaviors you role model.

Sociology defines three paradigms of authority/influence:

1. Traditional authority is based on established customs, traditions, and history. It’s a long-standing form of authority, often inherited or passed down through lineage or religious practices. Think of a monarchy.

2. Charismatic authority stems from the personal qualities, charisma, and magnetism of a leader. It’s associated with individuals who inspire loyalty and devotion through their exceptional personality, heroism, or conviction.

3. Rational authority is based on means-ends logic where authority comes from overall effectiveness in achieving a stated purpose and the role one plays towards that end. It’s associated with bureaucratic structures (think governments and corporations) exactly because those structures codify a dominant way of achieving goals replete with elevated roles (managers, police officers).

We’ve established earlier that modern-day egalitarian work cultures and the politics of large companies means we cannot rely upon traditional or rational authority. So instead, leading-by-example cultivates a type of charismatic authority that lends your beliefs and actions weight they would otherwise lack…lubricating the influencing process.

Transitioning from “Doing” to “Coaching”

The credibility you earn can be used as the basis for the all-important “here’s what success and growth looks like in your role” conversation. This isn’t just some perfunctory reading of the job responsibilities. This is a deep, visceral, almost brutal heart-to-heart. Your goal is to probe deeply and elicit vulnerability to learn what your coachee really deeply desires out of their job/career without all the defensive architecture and corporate sterilization. You can see how this sort of thing can only happen if there is an established basis of credibility, intimacy, and rapport. This comes from working elbow-to-elbow.

With an understanding of what they really want, you can begin discussing the ways that is or isn’t in alignment with what the organization needs or is willing to reward/recognize. Coachees can dialectically explore whether they want to be “reprogrammed” with a new set of goals better aligned with the organization. This will ensure their attention is directed at the right behaviors to emulate, and that the necessary reinforcement will be forthcoming so as to sustain motivation, and thereby, continuous learning.

Skipping this conversation altogether, or doing it poorly, is not an option. Leaving your reports out of alignment will leave their growth effectively up to chance. In truth, this was me and my new team. Initially, I skipped these conversations with my staff engineers. Due to extreme seniority and long tenure, I errantly believed they would already be well-aligned with the organization. In one particularly bad case, an aspiring staff engineer put forth tremendous effort to complete key projects in record time, only to find out they wouldn’t be promoted due to focusing too much on “tactical work” over “strategic influence.” I had dropped (what were to me) obvious hints and opportunities for strategic influence all year, and went out of my way to role model the necessary behaviors. But they never took the bait and just kept focusing on more immediate tasks. Ther resulting perfectly-acceptable-yet-average results failed to substantiate a promo. The shock of a no-promo was sufficient negative reinforcement to jumpstart the learning process but the pain was completely avoidable. All it takes is one conversation. (In fact, another important takeaway is to keep re-attempting this conversation if the first time doesn’t connect). Observational learning depends on the learner’s capacity to recognize concepts as critical and germane to their goals…in this case, getting promoted.

Even if you go no further than this hard 1:1 where you get honest and deep about what people want and what it will take to get there, you will be advancing steadily towards improving the team’s performance. From this foundation, further role modeling should emphasize highly visible actions that put the abstract reasoning, intermediate goal states, and subordinate skills on display (e.g. pair programming, stream-of-consciousness how-I-solved-it docs, etc) to support encoding/retention.

Back to the story of my struggling infrastructure team. I had to walk before I could run. By getting hands-on and leading by example, I built a better understanding of the constraints and demands placed on my engineers…the tools and options at their disposable and what was truly achievable and what I could realistically expect from them. With that in hand, I set out to do the real job of coaching. I was eventually able to turn around those “chronically stuck” folks mentioned earlier by having exploratory coaching conversations wherein I came to fully understand their worldview. I then used my hard-won credibility to influence them towards more productive orientations aligned with what the team needs and the organization would reward. Where possible, you should try to identify their own unique genius and how that can be leveraged rather than always just “reprogramming” them. Either way, this is a delicate operation filled with crucial conversations where the entire working relationship is on the line. Done well, you can transform someone, unlock the next stage of career growth, and build a life-long follower. I leverage a cocktail of techniques from many sources including Coaching for Performance, Humble Inquiry, Nonviolent Communication, and Multipliers.

In summary, leading by example is a laudable ethic, will go a long way towards establishing an “everybody cleans” culture, and might earn you some credibility to do the real job of coaching. But as a standalone coaching technique it’s extremely weak and limiting. It depends on observant/aware reports, alignment on what the role demands, a culture where you are an unequivocal elder, time to actually do the job well and role model the right behaviors, the authority to actually recognize/reward adherents, and a way to actually directly observe the work at hand.

Much has been written about hiring for passion: seeking out engineers who…

• spend as much of their time programming and interacting with computers as possible.

• identify with your company’s mission and believe it lends their life a sense of purpose (John Doerr’s whole missionaries-not-mercenaries thing).

• put work before everything else and regularly find themselves burning the midnight oil.

That is to say, only hiring people who substantially derive their self-identity from work and working with computers in particular, and have a tendency to view their employer’s mission/purpose as their life’s work.

Before rushing to enrich your GitHub with side projects and open source contributions (alongside a stellar resume), there has been just as much said about explicitly not hiring for passion, that passion-centric hiring…

• leads to massive burnout and/or hostile workplaces where everyone takes everything personally.

• excludes skillful talent that trained hard and would do good things for your company, but ultimately entered engineering for sustainable pay that would allow them to build a good life free of precarity.

• is disconnected from the reality that your silly little app startup is probably not, in fact, changing the world or solving society’s greatest problems.

Reflecting on the sort of workplace I want to have—both as an employee and as a manager responsible for shaping the environment—neither of these two positions sounded particularly like what I was looking for.

Community, Belonging, Purpose

I want to work with people who still have a verve for life, who share that which makes them feel uniquely alive and human, and who have an authentic interest in other people for their own sake. People who realize that the act of coming to work means joining a community and with it adopting community values: sincerity, reciprocity, commitment, care, respect, mutual accountability, codependence, etc. These are not the sort of people you would characterize as “lacking passion.” In fact, such individuals can make nearly any job, from the mundane to the magical, fulfilling. Note how I haven’t really said anything about the actual work itself…that’s because, frankly, it’s a secondary concern; Ray Dalio captured this sentiment best:

Success is not a matter of achieving one’s goals. The things we strive for are just bait…the struggle to get them with people that we care about gives us the personal evolution and the meaningful relationships that are the real rewards. […] I instead wanted to stay in the jungle, struggling to be successful with people I cared about.

– Ray Dalio, Principles

Picking a job, then, is about so much more than picking who signs your paycheck. It’s really about finding a group of people where you feel welcomed, safe, and respected…thereby able to give back to that very same community. Some may immediately take umbrage with this as sometimes you’ll do whatever it takes to survive—trust me, I’ve been there—but ultimately you choose what attitude you bring to work and how you relate to other people. Part of the issue is one of terminology: what people describe as “passion” I think of more as “mission-driven” (an almost obsessive fixation with purpose/achievement in spite of all other factors), and its opposite is “professional” (characterized by working with integrity to realize goals and achieve mutual benefit in a more ecologically balanced sense). Professional environments can be indifferent or enthusiastic depending on how people show up.

More Than a Vocation

No matter how hard you try, work ultimately takes on a bigger role in our lives than just being a source of income. I met my best friends through work; that said, our relationship is about so much more than a mutual interest in technology (in fact, we’re increasingly curmudgeonly in our views towards tech). I want to befriend even more people, and I expect many of you feel the same way given the difficulty of forming adult friendships. But how do you expect to make connections in a workplace populated by zombies: people whose soul is dead, although their body is alive; people whose thoughts and conversation are trivial; who chatter instead of talk and assert cliché opinions instead of thinking; people who are shut off from the outside world and tolerate the requirement to interact with one another only because of the need to earn money for food and medicine? I don’t care if the thing you’re passionate for is tech, but be passionate about something—your family, your hobbies, your friends, anything—and share that spark with those around you. We have been fed a false dichotomy, you can be enthusiastic and professional at the same time.

You spend one-third of your life at work. What’s the difference between mission-driven work that becomes all-consuming and filling every waking hour, versus passionless and disconnected work just to get by? Nothing. You’re still wasting one-third of your life either way (either in the absence of a personal life, or the absence of a work life that contributes anything to your well-being and wholeness as a human). No matter what you do or who you do it with, take pride in your work: recognize it’s innate value because you are the one doing it, spending the precious few hours you have on this Earth. You don’t have to be passionate about something to do it with integrity and to make an active effort to build community wherever you are.

Scene: you wake up out of a day-dream and find yourself in the middle of a business meeting. Everyone is staring, waiting for you to say something. What do you do?

Say any of these things below and 9 times out of 10 it will not seem like a non sequitur, and nearly everyone will think you are Very Smart™:

1. We need to define success metrics.

2. We need more ambitious goals.

3. We need to go faster.

4. We need to stop thinking tactically, and start thinking strategically.

5. We need to think long-term–what does this look like N years from now?

6. We need more headcount/resources before we can do that.

7. We need more data to make a decision.

8. We don’t need more data, let’s make a decision.

9. We don’t need policy or process; we need a culture change!

10. We need fewer meetings.

11. We need to sync more often.

12. We need to do a postmortem/retrospective.

13. We need more documentation.

14. We need someone to own this.

15. We need a working group/task force/tiger team.

16. We need to standardize/deduplicate.

17. We need to talk to the customer.

18. We need to break this down so it fits into a sprint.

19. We need to [cut some corner], but we’ll fix it right after.

20. We need a plan/proposal/design doc.

21. We need a single source of truth.

Apple Pie Opinions unraveled

I call positions like these apple pie opinions (as in motherhood-and-apple-pie) because they verge on being truisms, if not popularly held misconceptions, while also employing a clever rhetorical structure that makes them downright insidious:

Problem #1: apple pie opinions are infinitely defensible

These sorts of “non-positions” cannot be productively discussed in a group setting as their opposite sounds almost farcical: “no we shouldn’t talk to the customer.” People innately rely on these short hand emotional judgments during spur-of-the-moment debates because deeper thought takes time. As a result, any opposition will be working at a disadvantage from the very beginning.

How do you argue against “more data” or “being in sync?” If you try, the discussion usually turns mind-bendingly meta: “culture change would be great, but that is difficult to achieve without small incremental steps to get the ball rolling.” Now you’re no longer discussing the issue at hand, but business/management theory and organizational dynamics…domains that are mistreated by laymen and thrive off personal preferences masquerading as wisdom.

The only way to defeat bad opinions, it seems, is more bad opinions.

Problem #2: apple pie opinions thrive off power dynamics

Who says something is almost as important as why they are saying it. These perfectly fortified opinions take on a life of their own when power differentials enter the equations because the personal cost of speaking out far outweighs the benefits of nodding along. What’s a few days writing a useless design doc when you can make your boss feel good and like you more?

We are often unware of (or unwilling to acknowledge) power differentials so you may be running afoul of this without realizing it. Power can come from many places:

• Explicit: managers (at all levels) are responsible for people’s livelihoods which is the closest thing to “life or death” on this list.

• Role-based: technical leads and mentors hold less authority than managers but are granted a lot of deference.

• Expertise: holding an outsized share of knowledge, or having a particular job level (senior/staff/principal), implicitly puts pressure on everyone around you.

• Relational: “early hires” hold a lot of sway regardless of official role because of the proximity to leadership stemming from being employee #15 or whatever.

• Structural: members of the majority have privileges that their underrepresented peers do not: chiefly the ability to speak out with impunity.

…and many more. Power literacy is just as important for those with power as it is for those seeking it.

Problem #3: apple pie opinions waste time

If these opinions effectively have no content, what’s the harm? Wasted time, frustration, disillusionment. Each such position motivates a lot of extra work. The extra overhead makes everyone feel unproductive. It puts the brakes on new (but fragile) ideas because they often cannot stand up to the scrutiny of a cost/benefit analysis or a detailed project plan early on. Your team will start feeling like this isn’t a place where they can be productive or innovative.

“We need more data.” Someone has to collect, clean, and analyze it…not to mention all of the subsequent discussions. “We need to define success metric.” It takes time to identify measures worth committing in such an official fashion, and that doesn’t even account for the added overhead of everyone involved continuously bending their work in service of these success metrics.

None of these things are innately bad mind you…but if they were entirely motivated by no more than a powerful person trying to sound smart in a meeting, then it’s all in service to nothing.

Contributing constructively

Before you fly into rage, know that I have sincerely said all of these things before…and still do on a regular basis. The issue is not the sentiments themselves, but rather why and how they are being said at all. Hence it is better to think of these opinions not as innately “anodyne” but rather “dangerous.” Dangerous in the sense that if wielded irresponsibly it will do harm to you, your projects, and your team.

Check your motivation

Speaking up for the sake of speaking up (appearing smart, scoring points, etc) is not a sound reason to share an apple pie opinion. Good leaders know when their input is critical and when it is superfluous. If asked directly for your opinion when you have none, be honest: “I have nothing to add at this time, it sounds like you’re on the right track, I’ll let you know if I think of anything else offline.”

Speak candidly

I see a lot of apple pie opinions come out because someone disagrees, but is not willing/able to be honest.

Consider this scenario: someone is discussing their chosen approach to a project in a team meeting. You disagree with some of the technical decisions, but don’t want to so “publicly” call out the individual and put them on the spot; you’re not even sure you’re right and don’t want to seem like a micromanager. Instead you reach for an apple pie opinion that will steer them towards rethinking these decisions: “some of this seems pretty complicated, we really need to get an MVP out the door and iterate based on customer feedback.”

You’ve fallen into what Kim Scott calls either “Ruinous Empathy” or “Manipulative Insincerity.” Failing to speak honestly and challenge directly can lead to a lot of wasted time and frustration as both sides keep “taking past each other.” Overcorrecting the other direction (into “obnoxious aggression”) will surely avoid anodyne opinions, but come at a much greater cost in the long run.

If, after considering what’s right for both the people and project before you, it still seems like one of these positions is the right choice, then you can proceed.

Include context

Once you’ve resolved that one of these dangerous opinions is the necessary and right position to espouse, pay attention to your delivery.

Don’t just say “we need more data.” Explain why you believe that to be true, including any assumptions you are making (either about the problem or the beliefs of others in the room). While it is almost impossible to argue against “more data,” it is much more plausible to refute the reasoning behind your statement and thus have a productive discussion.

Putting it all together: delivering a constructive opinion

Here is an example combining all of the above advice:

Earl, you mentioned that it will take a couple months to get this product rolled out to the early adopters. Since a lot of the benefits of Project X require customers to also change their habits, I assume that it will take a long time (1+ year) before we know if this idea is going to work. Therefore, I recommend we come up with some success metrics that can be used to gauge our progress and course correct as needed, else I worry we will spend a lot of time for not very much gain. Do you think that will help or just be a tax?

• All assumptions are stated up front so no one is second guessing why you might suggest this.

• Your understanding of the concept at hand is restated in your own words, inviting corrections.

• Ending on a leading question suggests that you’re open to hearing contrary opinions.

I can confidently state that no one I work with is an “empty suit.” Nevertheless, I’ve been in plenty of discussions that devolved into a circular exchange of apple pie opinions. This is a natural side effect of working in a professional environment, and thus a phenomenon that needs to be explicitly kept in check….lest we all lose the ability to communicate except through increasingly inscrutable managerese.

Starting your first job is tough: you have to juggle learning the ropes of professional life alongside skilling up as a new engineer. You’re probably doing this concurrently to a whole host of other life changes: leaving home/college, moving across the country, etc. As such, you might believe the going gets easier each subsequent job switch. Sorry to disappoint: it doesn’t–taking a new job mid-career comes with increased expectations.

You’re no longer “entry level” and will be expected to arrive as a mostly competent and productive member of the team. The pressure is further increased by the fact that job changes often result in a title bump: how does one live up to the expectations of Senior Software Engineer when virtually all of your new colleagues will be outperforming you for the foreseeable future–even the ones without the shiny new title?

Worry not: you’ve got this. You do have something valuable to contribute. The fact you’re here means something; software hiring and interview practices have not become Machiavellian torture tests for nothing. That doesn’t mean you can just show up and start acting like you always know best; what matters most is that you stay humble. Getting the most out of this experience requires keeping an open mind to different ways of working. Over my own career, I’ve developed a basic 3-step process to ramp up quickly, learn a lot, and start making a big impact fast.

Phase 1: naturalize and observe

In the beginning, your strategy should be to listen and learn. Joining an established organization, your biggest hurdle will be navigating the existing structures and norms, and none of the short-hands and relationships that carried you in your old job will exist. The goal is to understand the unique culture of the team and what is (implicitly) expected of you as a newly minted member of that culture.

The company and your manager likely have some sort of onboarding planned for you; put all your energy into that and be present. During your onboarding you should take notes; write everything down…especially 1:1 advice, as well as anything you have to figure out and research on your own. Collect useful links and documentation you come across. This serves three purposes:

1. You can enhance the existing onboarding documentation, and guide future new hires as someone who has recently been through the experience.

2. Peers and managers will offer a lot of advice during this period, and much of it will never be repeated once you’re considered a fully vested employee.

3. Much of the information you encounter will parse differently rereading it 3 months/6 months/12 months into the job.

Do your best to follow instructions and perform responsibilities as directed. When in doubt (or for lack of guidance), identify a role model and copy them. Formalizing your relationship with this role model as a mentor will further increase your access to tips and tricks for navigating the new environment, and bolster your work social network early, when it is sorely needed.

As an experienced hire, you may be inclined to show up and start agitating right away: you should already know how to do the job, and were hired for your knowledge and experiences right? If you keep it to yourself then what’s the point!? Don’t, stop, cease, wait…no! This way lies madness (and much animosity).

I’m not saying you should be meek and complicit. Rather, you would be well advised to prioritize listening so you can actually understand what others expect of you and avoid operating off prior assumptions. Moreover, in an ideal world, you would be joining a company you respect and want to learn as much as you can about their unique culture/secret sauce/system of work as you can. Some of the key cultural aspects and behavioral norms I look out for include:

• Communication norms: when does the team use chat, email, or a meeting? How polished are meeting presentations and agendas? When do discussions and decisions get recorded in writing? How long and formal are these documents? Does the group do any form of collective brainstorming, pair programming, etc?

• Decision making rules: how does the team make decisions? Who is involved? What approvals are sought and when? What decisions can you make solo and which should be formed via consensus? How are decisions recorded and shared?

• Jargon: what terms of art, nonce phrases, and aphorisms get used? What are the preferred phrases for key concepts (e.g. I have worked at places where saying “CI” would get blank stares, but “postpush testing” is crystal clear)? What terms are verboten or conjure up violent negative reactions?

• Transparency and socialization: how much or how little do people share about their personal lives and preferences? How tolerant is the group of “chit-chat” or “small talk?” When does socialization occur and between whom?

• Polish and failure: how complete and refined are solutions and ideas before they are shared or publicized? How and when are problems/blockers declared? How tolerant is the group of failure and taking bets…how often do others fail?

Fully engaging in your onboarding, and attempting to learn the traits of a model team member gives you a strong foundation for future success. As you start to influence the culture, make changes, and even come into conflict, you have a “safe haven” to return to when things aren’t working out: a set of behaviors that you know will be accepted (and rewarded). Most importantly, this demonstrates a great deal of humility and respect, and will make you a more effective change agent: others will be more receptive to your ideas and criticisms believing they come from a place of understanding, rather than a blind attempt to be more like <previous employer X>.

Phase 2: compare and contrast

As you start to get more comfortable in your new job, you’ll want to expand your impact and scope of practice to be more than just task completion–focusing on how to multiply the overall efficacy of your new team. This is hard…like, really hard, like the-whole-point-of-your-career hard.

The overarching goal at this point is to bring to bear all of your hard-won experience. The best way I have found to do this is to draw comparisons, identifying aspects that are similar and forming 1:1 maps from your new role, team, and company to previous encounters. Through this process interesting “diffs” will emerge that explain unique challenges (or advantages) for you to exploit. You will sometimes find the silver bullet lies in one of your past experiences, it just wasn’t obvious how it applied until you constructed the metaphor. This applies just as much to interpersonal and leadership problems as it does to technical issues. Some examples from my life include:

• The Verve Asset Manager (VAM) I inherited at Verve stores data in a user-configurable schema that allows customers to specify arbitrary fields and relationships for all the items they want to track. This turned out to be very similar to the feature set and problem domain of the custom CMDB in use at <redacted employer>. The CMDB had run much longer, served a larger customer footprint, and had already surmounted many of the same technical hurdles (sharding, replication, asynchronous streaming, etc)…meaning VAM was able to avoid several pitfalls before they occurred.

• Working in IT at UW-Madison gave me a lot of experience serving an internal customer base. Both the Architecture group at Two Sigma, and the Engineering Productivity group at Google function very similarly: providing services (consulting, tools, support, etc) to a captive customer base. Besides the experience itself, there is a wealth of literature, talks, and best practices to call upon when doing IT service design, and I was able to apply all of it—principally shifting the nature of our customer engagements from one of governance and control, to one of education and enablement that let us exert greater influence over technical direction and team dynamics.

You never know when inspiration will strike and you see the hidden connection to something from your past. My last example raises an important source of inspiration: inter-disciplinary metaphors. If you have exposure to ideas outside of tech (or in parts of tech that are less frequently traveled by software engineers like IT, product, support, etc), you will find many “hard problems” are already partially solved. Turns out software engineering isn’t the first field to attempt collective problem solving in a professional environment /s.

One of my favorite ah-ha! moments of late was coming across Vargo and Lusch’s “Evolving to a New Dominant Logic for Marketing.” In this paper, the author’s claim that the fundamental economic shift from exchanging value in the form of tangible goods and products, to exchanging value via intangible resources like knowledge, relationships, and services, leads to a similarly fundamental rewiring in the theory and execution of marketing. One aspect of this shift is how “goods are transmitters of operant resources (embedded knowledge); they are intermediate ‘products’ that are used by [customers] as appliances in the value-creation process.” How does any of this apply to my day job?

I work in Engineering Productivity at Google, wherein I aim to create the best place to be a developer: where folks can come and focus on building great products and experiences, and the tools and processes to do so fade into the background. The problem? There is no silver bullet; I can’t just build the most-magical-CI-system-you’ve-ever-seen and have that make everything better. Some improvements can only come when the way the software is designed and implemented changes. What do you do when it’s not your product or team that needs influencing? The key mindset shift that is required is to stop thinking in terms of delivering a tangible product (a piece of software like a CI/CD platform), and more in terms of delivering a service (software engineering and methodology consulting). Through that lens, the tools I build become the “transmitters” of the actual “operant resources:” my particular philosophy and approach to software. I’m not selling a tool, I’m selling a lifestyle…ready-made tools propagate that lifestyle in a very attractive package.

“Evolving to a New Dominant Logic for Marketing” describes this shift in detail, and if you continue to extend the metaphor, there are even more novel and applicable takeaways for anyone in roles such as mine. Exposing your new team to foreign ideas and concepts that they might not encounter otherwise is one simple way to start providing extra “value add” even before you’ve fully mastered the new gig and have your “sea legs” underneath you.

Phase 3: invent and expand

Thinking in metaphors can take you very far, and as you get further soaked in context, you will start to make novel leaps and new ideas that are all your own. Bear in mind there are no bonus points for originality, but it definitely feels good when you’re able to solve a problem with your own creativity.

I have no secret wisdom to share: you will know when you’re here because your brain will form new connections and pick up on provocative ideas almost entirely unbidden…the subconscious mind at work.

At this phase you should take care to avoid fixating on “innovation for innovation’s sake.” The urge to change things and pursue new projects will intensify as the volume of your insights increases, but you should remain anchored in solving real problems.

• Continually assess alignment with the team, product, and business. Solving imagined problems or working towards a divergent end goal delivers no value.

• Use leverage as your yardstick for measuring effectiveness, rather than just output. Time is your most limited resources as unlike other resources, time cannot be stored, extended, or replaced.

• Think of (almost) everything as an experiment and ask yourself what you should do to maximize the amount of new information you can gain, even if that experiment should “fail.”

Enduring beyond the first year

I have used this mental model while starting 4 new jobs over the last 6 years, and it has served me well. While job hopping has become quite typical for software engineers–increasing the need for guidance such as this–it is still the case that you need to find a job and stick with it for some number of years to build real mastery. 5 years of “1 year of experience” is very different from “5 years of experience.” I have done 3 such extended stays in my career (6 years, 4 years, and 2 years in duration).

In year 1, much of your work and priorities are predetermined. The manager that hired you had to justify your headcount somehow, and that typically requires 1+ year worth of high-value projects on the backlog that are ready to go. You spend your first year nailing those projects, and relying on your team/boss’s social networks to get things done…then year 2 rolls around the real challenge begins.

In year 2+, you will be expected to continue delivering value, but there may not be a shovel-ready project in the wings. How you source, identify, and select the next big thing you work on is critical…it doesn’t matter if you do this as an individual or as a team. That is why the tips I have shared here are singularly focused on bringing your innate creativity to bear.

It’s can be nerve-wracking to start over mid-career…the challenge of getting back to your former level of productivity and effectiveness will be different every time (maybe that’s partly why more and more of us are drawn to job hopping?). Good luck, and enjoy your new job 😊

You can’t make it more than 1 paragraph/slide/minute into a piece of media discussing microservices without encountering admonitions to “carefully consider the trade-offs.” This is promptly followed by not mentioning or explaining any trade-offs, and resuming to filibuster around whatever point they were trying to make, as if being direct and complete would make their position technically indefensible.

Software Architecture does not mean what you think it means

I don’t think these authors are being disingenuous; the trade-offs involved are context-specific, so how could they ever offer something here that would be above reproach? Here’s the problem: without some treatment of the trade-offs you navigated, from the perspective of your particular project, it’s impossible to gather any useful takeaways.

The recommendation or pattern you are trying to share is not “architecture.” It is the output of architecture (which is more a process than a tangible artifact). How we collect, analyze, and reconcile competing requirements to craft a system that meets our needs within a set of constraints is architecture, and it’s what elevates rote programming to software engineering.

By leaving out how you arrived at the result and all the surrounding context, you strip your message of the most instructive parts and stuff them into the hand-wave “consider the trade-offs.” It’s like reading a math textbook only to have a profound theorem’s proof excluded as an “exercise to the reader.” I won’t go so far as to call this gate-keeping, but it suffices to say that those in-the-know (and likely do not require your guidance) will “get it” and those who could benefit from your experience will leave with the wrong takeaways.

It’s the sort of education that breeds charlatanism; where real technical decision making and architecture get completely elided by resume-driven development, or stalled out by someone sagely uttering “consider the trade-offs” and thinking it profound. Of course we will consider the trade-offs…that’s what we’re doing, that’s engineering! Anodyne opinions like this can only be refuted at great personal cost, and so entire organizations entertain these arguments in costly ways (analysis paralysis anyone?) even though the person who proffered this statement sometimes has no deeper meaning or insight.

If the intent is to spread good ideas and sound architecture, then we need to also accompany our ideas with examples of how real-world constraints and trade-offs manifested, and how our approach balanced those concerns to open a new way forward.

This does not mean belaboring every talk and blog post with a universal framework for decision-making. It would suffice to share the context and experience that led you to speak out, and allow the reader to judge how that does (or does not) apply to them. Being able to [describe CQRS] is trivia; knowing that [when faced with problem X, constraint Y, and requirement Z that CQRS led to the following virtues and vices] is wisdom.

You need non-functional requirements in your life

“Requirements gathering” smacks of archaic software engineering practices that predate the post-Agile era…but that’s exactly what you’re doing when you design systems. Requirements are more than just bewildering TODO lists of conflicting features, authored by despotic business leaders. Nor do you need to do requirements gathering all-at-once, waterfall-style. Once you break the association of “requirements” with this unhealthy modality you can recoup the most useful tool in our arsenal.

The first step in resuscitating “requirements” is to recognize they fall into three categories:

• Functional Requirements: what you classically think of when you hear “requirements.” Things the software must be able to do, and how it should behave and react to runtime stimuli. For example, “users should receive an alert when their order ships.”

• Non-functional Requirements: also known as “software quality attributes,” these are qualifications of the functional requirements and describe the operation of the system. Things like timing requirements (“performance”) and other “ilities” like maintainability, availability, scalability, operability, etc. See a more complete list here. For example, “users should receive password reset emails within 30 seconds of requesting a reset.”

• Constraints: a design decision with zero degrees of freedom. These can come in the form of implicit standards in your organization—e.g. “all services are written in Java”—in the form of edicts—e.g. “everyone must publish an OpenAPI spec”—or in the form of previous decisions that are being ruled as out-of-scope for the current project—e.g. “we are using flatbuffers instead of protobuffers.”

Constraints and functional requirements are not very transformative, but non-functional requirements give you a way to discuss trade-offs…especially because some non-functional requirements appear to be foils of each other. A classic trade-off is security vs. usability: requiring a user to 2Fa significant configuration changes is less usable, but more secure. Non-functional requirements offer firm definitions for these concepts, patterns for achieving them, and allows you to be complete in your accounting of what you’re giving up for the sake of the other.

Security is the system’s ability to protect data from unauthorized access.

Usability is a measure of how easy it is for a user to accomplish a desired task and learn system features. This includes learning system features, minimizing the impact of errors, adapting the system to user needs, and increasing confidence and satisfaction.

It is not necessary to detail all functional and non-functional requirements up front to approach architecture this way. You may only know a few requirements, or have a notion of what you want absent the challenges that may make it untenable (“I want consistency, availability, AND partition tolerance…oh wait…). It is natural to have requirements emerge during the implementation process, and to have their relative importance shift as the boundaries of what’s possible (and what’s necessary) become clear.

Non-functional requirements do not present a solution to changing requirements (and the need to be “agile”), they provide:

1. A framework to conduct systematic searches through the space of possible requirements and complications.

2. A language that codifies the essential abstractions and common ground needed to productively discuss software design, without getting waylaid by details of a particular instantiation, talking past one another, and excessive reliance on nonce terms.

…in other words, exactly what’s needed to help your audience “consider the trade-offs.”

Making sense of microservices

Returning to the example that motivated this article, let’s talk about microservice trade-offs.

It’s easy to accidentally attribute a lot of virtues to microservices related to modularity (single responsibility principle, interface segregation principle) but that does not capture the essence of microservices. It is perfectly reasonable to organize your code using strong namespacing and interfaces, granting you much the same modularity in a single process. Microservices take this a step further by achieving (enforcing?) through process isolation of subcomponents. With this in mind, we can now summarize essential strengths and weaknesses of microservices, as viewed through non-functional requirements.

Strengths

• Scalability: each process can be scaled (horizontally or vertically) independent of the others. That is not to say a “monolithic” process cannot be scaled horizontally, but that typically requires sharding where microservices may be able to avoid that altogether.

• Conceptual Integrity: the single responsibility principle ensures that the process has a small surface area, and theoretically can implement a single coherent concept better than multiple competing features. This eases maintainability, but also makes the system easier to reason about in production.

• Reusability: processes that publish a well-defined API can be reused in almost any context: different teams, different companies, different programming languages, different use-cases.

• Reliability: separate processes build in “bulk heads” into your application that isolate failures. With sufficiently defensive IPC (retries, back-offs, deadlines, etc), even faulting systems may still be able to deliver partial-to-full functionality.

• Organizational Autonomy: each process can be built in some modicum of isolation from the others, coordinating via the shared API and contracts. This isn’t exactly perfect (in my experience, a lot of growing pains experienced by MSFT/AMZN/GOOG are a direct result of this), but it does enable a product team to sustain productivity even as it scales into the hundreds of engineers.

Weaknesses

• Operability: each process is another mouth to feed. It needs deployment orchestration, testing, monitoring, an oncall rotation, and more. As the number of processes grows, it becomes almost impossible to hold a complete mental model of the system in your head.

• Observability: user-facing features and user journeys take place across a constellation of services, communicating using generic API’s. It is more challenging to observe the flow of a single request, and it’s more difficult for the system to make reasonable service-level decisions (request prioritization, load shedding).

• Supportability: when something goes wrong, it will be more challenging to reconstruct the context and end-to-end flow that precipitated the failure. Troubleshooting and reproducing issues is made more complicated by the number of moving pieces that must be started and manipulated to construct a hermetic repro.

All of the above can be improved with additional architectural patterns…each with their own quality attributes. By using the language of non-functional requirements, you can methodically navigate these “trade-offs” and make better, contextual decisions…as opposed to always chasing the latest tech trend.

S.O.S. (save our systems)

I’m lampooning microservices quite a bit in this article, when in reality that was just the topic of the most recent tech talk that made me want to drive my car into the ocean. There are also plenty of authors who understand this problem and treat it appropriately. However, I have seen too much puffery and too many projects doomed by quixotic, resume-driven architectures to believe there isn’t a gap in how we train and educate software engineers at large.

Using the language of requirements and constraints, you can ground your thinkpieces in the realities of bringing software into the world, you can hold more productive design discussions, and you can accelerate the training of the next generation of software engineer.

Architecture is the confluence of people, processes, and structures used to design systems; do not forget to talk about the people and processes as they determine more about the structures than you think.

Literature on the importance of empathetic leadership is everywhere, especially in software engineering. You would be hard pressed to find anyone that doesn’t use the language of empathy when describing their approach to management. Someone who eschews personal connection and empathy in the workplace entirely sounds like a caricature…a cartoon villain that couldn’t possibly exist.

However, just because we now talk about things like relationships, emotions, trust, and authenticity at work does not mean that we have all magically become more empathetic. In fact, the situation is more complicated than ever. Sociopaths walk among us and now have a beautifully crafted Trojan horse to conceal their machinations within. Even well-meaning managers have to walk a fine line between outright manipulation and influence.

Empathetically Dishonest

We believe ourselves to be empathetic people, either as a natural facet of our personality or through practice and explicit effort. We read books like Radical Candor and Nonviolent Communication (both terrific, btw). In one-on-one’s, we listen attentively and express deep, almost personal, concern for the other’s feelings and experiences.

…and then we go right on ahead and manipulate them anyways. It was just a performance. What happened?

Intent is everything. An empathetic point of view enables you to feel someone else’s pain, but that does not require you to act on those feelings of reciprocity. In practice, that means your personal goals and needs are still the driving motivator for all your actions. Without realizing it, you stop seeing people as people, and instead see them as tools to get what you want.

Consider the following incident, which (partially) prompted this entire article:

I was a rising manager at a growing company; we had recently hired engineer #14 and a formal org structure was emerging. I had not yet assumed management of all the teams, and for this team in particular I was just the project manager. Bob, my boss and CTO, was officially manager and technical lead of the product this team produced. Ryan was an individual contributor hired to replace Bob as the technical lead, due to his many years of experience with the underlying technology.

Bob and Ryan were not getting along. Ryan would submit code that was much more defensive than the norm for that product, and often structured his work in a way divergent from Bob’s. It wasn’t necessarily wrong, just different. Like anyone else, his code had gaps and flaws that Bob would point out in code review. Mixed in with the valid criticism were comments that boiled down to “this isn’t how I would do it, therefore it is wrong, please do it my way instead.”

After months of this, the relationship had degenerated into outright micromanagement. Ryan could not submit a line of code that was not close to, if not exactly, what Bob would write…even in cases where Ryan’s code would have been more resilient. One severe occurrence of Bob overriding Ryan occurred over our team chat, and as the conversation unfolded I saw Ryan (who sat across from me) become physically agitated…he had clearly had enough. I asked him to take a walk with me.

(the conversation proceeds back and forth, with me listening and reciprocating Ryan’s feelings)

(at this point I’m looking for a way forward, I know I can’t fix Bob but I need to give Ryan hope for the future and get him solution-oriented rather than wallowing in the present situation)

(the apologetics are in full swing, I talk about different behaviors Bob respects and how Ryan can shape his personal workflow to include checkpoints with Bob to avoid late-stage blow ups and, hopefully, build trust)

In that story, did I help Ryan with his problem or manipulate him? All I wanted for him was a sense of autonomy, mastery and purpose—classic sources of motivation and self-actualization—and I knew the most plausible route to that would require gaining Bob’s trust. I listened closely and came to understand (in my mind) what Ryan needed and gave him advice on how to get that. Seems fine, but let’s talk about my intent.

As project manager, I had massive incentives to see work getting done on schedule (career growth, money). Whether or not I was explicitly, consciously thinking about that motivation, it still decided most of my actions. I knew Bob’s micromanaging proclivities and had previously made attempts to fix the issue. Knowing the root cause was beyond my influence, I was “playing with the hand I was dealt.” This blow up was just another hurdle between me and my ultimate goal of a happy team that finished projects on time…so how could I get Ryan to put this behind him (like I myself did previously) and get back to work?

1. Before the incident, accrue an empathetic persona. Speak frequently on the importance of building relationships and the “human” side of making software.

2. After the incident, make the offended party feel heard and respected. Ask questions, give them space to say their piece, and display active listening with the likes of “agree, build, compare.“

3. Use the subtle cues and view points you hear from the other person to steer the conversation. Plant the idea in their head that what they desire (and why this incident was so inflammatory for them) is autonomy, and that the environment is as much to blame for the lack of it as the person.

4. Leverage the trust you’ve accrued and the existing power dynamic to offer “sage” advice on how to get autonomy: prove you can be trusted to execute tasks superlatively and can handle direct feedback when needed.

That was quite the song and dance to basically say “suck it up and get back to work…it’ll (hopefully) work out eventually.” Viewed through the lens of my own personal goals and intent, I didn’t just commiserate and advise…I actively manipulated; it was just cloaked in the language of empathy and understanding.

Self Deception is a Defense Mechanism

Was this just a case of what Radical Candor calls “manipulative insincerity?” At no point during the exchange above was I plotting to get what I wanted (work getting done, no drama). I thought I was focused on Ryan and how to help him make the best out of the situation.

Therein lies the self-deception: I knew even in the heat of the moment that what was really needed was fixing Bob’s micromanagement issues—one way or another—or else issues like this would multiply. Saying I was just helping Ryan understand his situation and find a way forward is how I justified to myself the original betrayal of leaving the hard problem untouched (Bob) and focusing on the more pliable person (Ryan).

My ego needed that excuse, otherwise I would have to confront either the limits of my efficacy (I knew I couldn’t fix Bob) or my self-preservation instinct (I need this work done, which means I need this problem to go away).

True empathy requires the ability to consistently remove the self from consideration…but how?

Insights from Esther Perel

Esther Perel is a therapist whose podcast “Where Should We Begin?” features recordings of couples undergoing therapy; clips were featured on This American Life 617: Fermi’s Paradox, Act Two. What was just some idle background noise while I was at the gym turned out to be the key insight in answering this question.

In the episode, Esther is counseling a couple where the wife discovered her husband had been cheating on her “widely, and compulsively” for decades. She wanted to stay together if at all possible, and keep all the good things in their life: kids, grandkids, etc. Turns out that being lied to for decades makes it hard to move forward.

From that point forward the whole session is about getting the husband to actually acknowledge the pain his wife is feeling, without talking about himself. There are flashes where he seems to understand this, but then lapses into talking about himself and what he did.

It was in that I realized one of the ways to solve my problem was to check my language. When speaking in a supposedly empathetic situation, can I say what I need to say without invoking myself: the way I feel, my actions, or my experiences? For example, if I am trying to communicate “I understand” by sharing my own past experiences (as a sort of conversational compare-and-contrast), then I may be slipping into the empathy-as-influencing-tool trap.

Keeping Yourself Honest

When empathy is used as a tool, it becomes the vehicle by which you create an emotional context ripe for manipulation and abuse. This is a feature, not a bug. In a normal relationship between equals, the closer you become the more vulnerable you are…the more each can inflict great pain or great joy upon the other. It can be a wonderful experience with the right intentions.

As much as I am agonizing over this issue, and trying to get you to do the same, there is truth in the quip “a spoonful of sugar makes the medicine go down.” As a manager you will need to influence your team to do things that may not be their first instinct or their most preferred path forward. Your job is to find the intersection of what each individual needs and what the company needs.

The intimacy you breed will ultimately conceal the power dynamics underlying your influence…from your reports as well as yourself. It is a slippery slope from a well-meaning and emotionally aware leader to manipulative sociopath. If you fear this down slide as much as I do, consider adding some self-checks to your personal event loop:

1. The Esther Perel Check: after one-on-ones, take a moment to reflect on the conversation and whether the focus was primarily on you and your experiences or the other person in the room…was that focus reflected in the language?

2. The Crucial Conversations Check: before an important meeting or conversation, ask yourself “what do I want? How would I act if that was truly what I am after?”

3. The Peer Check: find someone removed from your workplace (a mentor or even a therapist) to talk through tricky situations or replay important conversations. It takes a really honest friend to say “lol, are you a sociopath?” but a dispassionate professional can easily gut-check these things.

The proliferation of self-help and people management literature aimed at improving EQ has democratized access to very effective tools for influencing others. Intent makes all the difference; make sure you use your super powers for good.

If this article spoke to you, consider reading Leadership and Self-Deception. Ultimately what I described here is the act of “getting out of the box” from that book, and it wasn’t until after I started writing this post and doing background research that I found this gem…it could have saved me quite a lot of pain.

I spend a majority of my time in meetings as a manager (and even in the past as a senior IC). Like Jack Donaghy, I aspire to be featured in Meeting Magazine. Running effective meetings is not just a point of personal pride—I deliver most of my impact by pushing the whole group forward. Ensuring everyone is aligned around a single direction is my top priority; building support for that direction must be conducted in the open to establish procedural justice. Despite their necessity and prevalence, I attend a huge number of meetings that are duds.

Hosting meetings with 3 or more people is a little bit of a dark art. Unlike a 1-on-1, larger group settings don’t benefit from spontaneity. The group gets side tracked, talks in circles, and by the end of the meeting no one is sure what was accomplished. The fix is structure. As the host, you establish structure by deciding in advance the topics of the meeting, the desired outcomes for each of those topics, and the techniques you will use to achieve those outcomes. I’m avoiding calling this an agenda because just having an ordered list of discussion topics is not enough; you need all three elements to get the most out of a large meeting.

This involves a certain amount of regimentation. Structured meetings won’t feel very natural, and you’ll lose a good dose of socialization. You may feel reluctant to take charge with a group of your peers, or as is often the case with larger meetings: members of your management chain. If your team has a more egalitarian culture, the whole idea of structure will seem out of place…like trying to use parliamentary procedure to pick a dinner spot with friends. I promise it’s not that awkward, and your meeting participants will thank you for taking the lead. To understand why, try to get in the head of someone invited to your meeting:

• They’re trying to be helpful. They know you invited them for a reason and want to live up to your expectations…how do you make it obvious what you want from them?

• They’re trying to perform. With a large group present, meeting participants will feel pressure to put their best foot forward…how can you help them avoid embarrassment?

Structure is the way you can help participants perform, while hopefully getting something done yourself at the same time!

Topics

Start by figuring out what you want to address in the meeting e.g. “annual employee survey results.” While it is possible to cover multiple topics in a single sitting, you will get better participation if you stick to one item. Assume your participants will need to spend some time preparing for the meeting—with fewer topics to prepare, they will come ready to make higher-quality contributions.

Consider whether or not the topic requires a significant amount of context, or requires participants to wade into a lot of technical details. If so, provide pre-work in the form of references. You may end up spending half of the meeting just getting everyone up to speed anyways.

Standing staff meetings usually have multiple topics that need immediate action, so you won’t be able to uphold the single-topic recommendation in all situations. That’s just fine, it simply makes the outcomes and techniques even more important.

Outcomes

With your topic(s) selected, the next step is to determine your desired outcome. In my experience most meeting topics will fit into 1 of 6 categories:

1. Sharing information e.g. presenting annual employee survey results and bringing new-joiners up to speed on results from previous years.

2. Collective brainstorming e.g. coming up with different options for addressing the problems identified in survey responses.

3. Providing input e.g. obtaining opinions and rationale on a proposed program for increasing employee engagement.

4. Making decisions e.g. finalizing the actions each member of the management team will take as part of the new engagement program.

5. Building capacity e.g. training everyone on the basics of analyzing survey results with Jupyter so they can form their own conclusions and contribute to a later collective brainstorming meeting.

6. Building community e.g. celebrate improvements from last year’s results with a team social.

It is also possible to move through multiple outcomes in a single meeting i.e. sharing a new problem, brainstorming how to solve it, and deciding on a course of action. The key thing is to call out the distinct phases to the conversation; preventing attendees from getting ahead of themselves, making room for everyone to contribute, and ensuring you leave the meeting with

Techniques

Now that you have a list of topics, and each topic mapped to the desired outcomes, you have 80% of the recipe for a successful meeting. If you stop here then you’re already going to have a significantly more effective and enjoyable meeting for everyone involved. To get the final 20%, you must map the desired outcomes to techniques suited for achieving those results.

• Sharing information: presentations and reports (do you really need a meeting for this?), “ask the expert” Q&A

• Collective brainstorming, split into pairs, lean coffee, drawing flowcharts i.e. process/value stream/workflow mapping,

• Providing input: dot voting, silent meetings, fishbowl meetings

• Making decisions: gradients of agreement, straw-man proposals, setting decision-making rules

• Building capacity: ADEPT model, hands-on self-directed learning i.e. codelabs

• Building community: kudos, lightning talks

Picking a technique avoids opening a topic, just to have the only directive be “now… discuss!” Lacking any guidance, participants aren’t sure how to contribute, and you’re basically handing control of the meeting to the dominant personalities in the room—squelching the

Putting it all together: The Structured Meeting

Share the topics, outcomes, and techniques in advance; either via a formal agenda or just jotting a note in the meeting invite. Once you’re in the room, open each topic by explaining the desired outcome and the basic approach the group will take to get there. As the meeting progresses, use the structure to keep participants on topic and from getting lost in the weeds. You’ll be empowered to call people out directly as the facilitator of a structured meeting because everyone knows what is expected at a given moment.