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 respon…

Read more

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.

Read more

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).

Read more

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.

Read more

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.

Read more

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.

What’s the most dreaded interview in the standard software engineering hiring funnel? No no, not as an applicant…but an interviewer! Is it the technical? Coming up with questions that are neither brain teasers nor walks in the park? The team-fit? What do you even ask to get the right signals without injecting bias?

None of the above! I think it’s the phone screen. In a phone screen you have limited time to make a judgment about a candidate…someone you have just met and know practically nothing about. Worse, for many of us, phone screens are our first foray into interviewing. Junior and mid-level engineers are given phone screens as a practice ground before being allowed into on-site technicals. This folly aside, the phone screen touches every candidate in your pipeline and thus determines who even gets a chance to show what they’re capable of in the later rounds. Getting the phone screen wrong can have dire consequences for your hiring pipeline.

Is this candidate worth your time?

Each stage of an hiring funnel is designed to gather a specific type of data about the candidate, and that guides how those conversations are structured. Unlike later stages, like the technical interview or the team-fit interview, the phone screen does not have an obvious main topic. The consequence is that many interviewers have a natural inclination to treat the phone interview as a little bit of everything, capturing a very incomplete picture of the candidate. Without enough information to make a firm decision, our natural curiosity takes over and the candidate is let through to the next stage.

Such false positives can be a tremendous risk:

1. It wastes the time/resources of both parties, as the next stage is usually a technical. For the candidate this requires preparation, taking time-off, and usually some travel. For the company, this can be 8+ hours of lost productivity building and executing the interview.

2. The candidate is one step closer to a job offer, but you haven’t actually made any progress confirming they are the right person for the job! The cost of a bad hire is astronomical, so making sure each stage of the hiring funnel is actually contributing to making better decisions is more than just sound economics.

Every stage of the hiring funnel has a different goal that can be used to frame the conversation. The technical and team-fit conversations are about getting to “yes.” You should leave such interviews convinced the candidate is the one for the job, that you would unequivocally answer “yes” when asked “should we hire this person?” If you leave those meetings a “maybe,” “I don’t know,” or “more information required,” most companies will ere on the side of caution and pass on the candidate.

The phone screen is different. The conclusion of a phone screen is not “yes” or “no”… it is “no” or “not no.”

Bad phone screens happen when interviewers ask questions that are about getting to “yes,” rather than getting to “not no.” There isn’t enough time to build an adequate picture of the candidate, and the medium is poorly suited for the nuanced conversations that build up the confidence required to say “yes.” That means the data you extract from the phone screen is unlikely to be useful in making the final hiring decision as later interviews will do a much better job of revealing the pertinent facts about a person.

Therefore the phone screen serves to gate access to the more intensive technical and team-fit interviews, that’s it. It answers the question, “Is this candidate worth our time?”

A more altruistic way to frame this is, “Would this candidate have a positive experience with our interview process?” If someone is just going to get steamrolled by the technical prompts in the on-site, or feel utterly out of their depth in the behavioral questions from the hiring manager, then save them some humiliation and pass now.

Getting to “Not No”

I won’t suggest a generic template for all phone screens, the most effective interview loops are designed and consider not only the requisite job skills for the position, but also company values and culture. What I outline here are the behaviors you can use as an interviewer to execute the design in a way that ensures the phone screen pulls its weight.

Keep it short and sweet

Phone screens should take 30-45 minutes at most, and feature a single interviewer—no panels. By virtue of coming early in the hiring funnel, you will be doing a lot of them. This also applies to the candidates who will be having similar calls with many other companies simultaneously. Long, panel-based phone screens run counter to their proposed value of cheaply disqualifying candidates that would struggle in later stages of the interview.

Phone screens can be kept on time by limiting them to a single purpose: assessing the candidate. They are not about explaining the role, bootstrapping the relationship, or preparing the candidate for the interview process…that should happen before the phone screen.

Therefore you should always precede phone screens with a “warm up” call. The warm up call is your first high-fidelity moment of contact with the candidate—giving you an opportunity to start selling the position, answer questions about the company, and explain the interview procedure. This post isn’t about hosting warm-up calls or techniques for closing however: try this or this or this if you’re interested.

Once you have 30-45 minutes of time dedicated to assessing the candidate, the next step is being realistic with what you can accomplish in that time window. In my experience you can fit 4-5 simple technical questions (e.g. “Explain the difference between a process and a thread.”), OR 1-2 behavioral questions (e.g. “Tell me about a time you ____” and follow-ups).

Without role-specific guidance, my general approach is to blend the two as follows:

• Open with a behavioral question based on something on their resume. People like talking about themselves, it will make them comfortable and it shows you’re interested. As a secondary benefit, you get a quick read on how much of their resume is bluster and how much is legit.

• Move on with 3-4 technical questions. Never make them up on the spot, and ideally practice them on a peer before trying them “in production.”

• If there is any time left over, ask if they have any questions.

The hardest part about this format is it will feel awkward. Transitioning cleanly and conversationally between different prompts is hard, and the result is it will feel a bit like recitation. If the warm-up call has set the context correctly, then the candidate will come in expecting this and no harm, no foul. Keep practicing, as masters of the craft will be able to keep the entire thing conversational, and thereby directly contribute towards closing the candidate.

Remove yourself from the conversation

The phone screen is supposed to be about them, not you. It’s very easy to slip into a call where the real thing being tested is how well someone can hold an engaging conversation. Signs you may be taking over the conversation include:

• Faux active listening: you repeat back what you heard the candidate say, but you “clean it up” by applying your own knowledge to remove rough edges.

• Long speeches: you find yourself giving long explanations, usually in response to an implied question, as a way of sharing your ideology towards removing some of the mystery about yourself and the company.

The result of either is the same: it pulls the center of attention away from the person being interviewed, and onto you. It’s an unconscious assertion of dominance, and the candidates that pick up on this shift and play along with the appropriate rejoinders and conversational norms are likely to receive high marks from you in interview feedback. You probably won’t even realize the real person you’re evaluating in the feedback is yourself. This is a recipe for unconscious bias.

The root of the problem is that the power-dynamic in any interview strongly favors the interviewer. Humans are biologically wired to key off power signals, even adopting similar manners of speech. Beyond that, it’s just sound strategy to figure out what an interviewer likes/wants and to provide that in the conversation. By over-participating, you effectively give the candidate the answers by showing them something to imitate that they know you’ll respond positively towards.

The solution? Shut up. Stop talking and listen. Get the urge to correct them or “subtly” nudge them towards a better answer? Don’t. Let them show you what they know and drive the conversation. If you’re actually interested in these candidates as people and not just resources, you’ll give them the courtesy of being themselves. Then, all you need to do is determine if their unique skills and personality will be a boon to the team.

Be selective

50% of all candidates should fail the phone screen.

If that number sounds high, consider that even at Verve—a tiny, no-name industrial software company where I led engineering—about 50 people made it through to the phone screen per open requisition. With a 50% pass rate, that was still 25 people x 8 hours x 3 interviewers = 600 hours of interviewing in the subsequent stages.

More than that, if >50% of people are passing it’s probably because you aren’t collecting the right information about the candidate. You probably tried to figure out if they are a fit for the job, rather than if they would thrive in your interview process. There’s just no way to do that in a single sitting over the phone, and your natural curiosity likely leads you to “giving them the benefit of the doubt” and forwarding them through to the next round. You don’t want to miss out on a good candidate right!?

Instrument your hiring funnel, and keep an eye on the number of candidates that are passing. When that number crests above 50%, it’s time to conduct an investigation and figure out what’s going on in your interviews. Sometimes the cause will be benign—an uptick in recruiter-sourced candidates is likely to correspond to an uptick in phone screen success—other times it’s more serious. I call process health indicators like this “trip wires,” and they strike a balance between negligence and hyper-vigilance.

Don’t talk about experience

At first glance, it’s not obvious what sorts of questions work well over the phone. Technical questions are limited by the lack of access to a whiteboard, IDE, or other tools. If you take the advice of “removing yourself from the conversation,” than you may be inclined to ask about the candidate’s prior work. That should reveal a lot about them right?

Maybe, but it is more likely to lead to the same outcome: a feeling of uncertainty and an inclination to give them the benefit of the doubt.

The problem with asking people about their experience is that they almost certainly know more about it than you. Unless they have worked in an identical area, you don’t have enough expertise to assess the caliber of their answers. There can be no “wrong” answers when talking about experience, so you’re liable to apply your own personal judgments to their background and whether or not it is relevant to the position at hand. Instead, you need to let the candidate show you that their experience has prepared them for the role. This allows you to open the door to people from non-traditional and under-represented backgrounds that might be at a disadvantage under experienced-based regimes.

The sorts of questions that allow a candidate’s to apply their experiences rather than recite them, while upholding an objective standard, are also the same sorts of question that make it easy for you to shut up and listen rather than dominate the conversation.

Good technical questions for a phone screen…

• …permit a range of responses that will reflect a candidate’s knowledge. Think like a grading rubric from primary school: needs improvement, developing, proficient, accomplished, and distinguished. You-know-it-or-you-don’t questions like, “What is the signature of the copy-constructor in C++?” are a bad choice because the range of responses is binary.

• …are specific and do not allow a candidate to hand-wave an answer without revealing something about their knowledge level. “Describe how decorators are defined and used in Python,” is better than, “Tell me about your level of proficiency with Python?”

• …tie back to a specific job requirement. The phone screen shouldn’t feel like a CS quiz. Not going to have this person write sorting algorithms once they get hired? Then you probably shouldn’t ask about quicksort.

• …challenge the candidate and solicit a complex response. Questions that can receive 1-sentence answers, or seem excessively trivial, will make the candidate feel like they are completing a verbal version of fizz buzz. I have actually watched someone ask a candidate, “What is an IP address?” only 30 seconds after they got done answering a 20-minute long design question.

A question I frequently use, despite it’s surface appearance as CS trivia, is “Explain to me how a hashtable works in as much detail as possible.” The number of possible answers and levels of detail is endless, it’s just about the only data structure 100% of developers use no matter the job, and I can sit back and let the candidate drive instead of having to “pull” them through a multi-part scenario-driven question.

Technical questions aren’t the only safe haven for avoiding experiential questions. Start by picking a functional skill that is important to the job. For example building consensus is critical for senior-level developers that are expected to be change agents. Then probe the candidate to explain how that functional skill is done e.g. “What does it mean to be good at building consensus?” and “What do you do when you are trying to build consensus?” Candidates will have a tendency to talk in abstract, so push them to talk about what they would do (or have done) specifically.

Candidates who can do the job will be able to answer any of the above questions without making appeals to their experience to make their points. It shows they can apply analytical reasoning to determine the best course of action, and would be able to share that reasoning to build support and cohesion once they are in the role.

Prioritizing the Litmus Test

The software engineering interview is an evolving art, and as screening procedures have been found to be ineffective or prejudice, we have discarded them. It’s been a long time since I’ve seen companies use brain teasers, and whiteboard-centric algorithms tests seem like they might be next on the chopping block.

Phone screens, however, are unlikely to leave us anytime soon because many of the interview processes that are emerging to replace teasers, whiteboards, and algorithms are even more time-intensive. That means we need increasingly effective early-stage screening to make such time investments tenable for both the organization and the candidate.

If this is your first foray into interviewing, don’t assume it’s just a training ground before you move on to the “big leagues” of on-site technicals. The phone screen is an equally critical node in the hiring funnel; you do yourself, your employer, and your candidates a service by taking the time to master the art.

I have started referring to these types of phone screens as litmus tests (a metaphor for a practice by the same name in politics). It’s a nifty short-hand to combine the mindsets of “getting to not no,” “are they worth my time?” and “will they have a positive experience?” For those that are mathematically inclined, you may prefer the expression “necessary but not sufficient.” With these first principles, you will be able to go out in the world and host effective phone screens—phone screens that are short, emphasize the candidate’s skills over their background/conversation abilities, and selective.

Junction is a Python package that allows developers to publish markdown files tracked in a Git repository to Confluence. With Junction, you can use existing Git workflows for managing code (pull requests, code review, release branches, etc) to also manage how documentation gets released to your wiki.

It’s available on PyPI as a pure-python dependency:

pip install confluence-junction

Keep your documentation by your code

The idea for Junction came about in 2017 when I worked at Two Sigma. As one the firm’s lead architects, I advocated for the adoption of lightweight architecture decision records.

Lightweight architecture decision records capture the reasoning and context behind changes to your software’s design. They work best when kept near the code they pertain to because developers will find them in the course of working, and they can be created as part of the PR introducing a change—all ensuring the pertinent context is available with minimal searching. You can see an example of this in use by the UK government.

The problem was that over the course of years, Confluence had become the center of gravity for internal documentation and was the first place people went to find designs, best practices, and reference material. Moreover, not all documentation fits naturally into the codebase as markdown files, so many teams wished to have a single view that combined in-repo docs with richer wiki pages.

Since then I’ve seen this same problem play out again and again, everywhere I see development teams using Confluence. With some free time on my hands, and an itch to work on a side project, Junction was born.

As a side project, I wanted to not only solve a problem (how do I make in-repo docs available on a wiki?) but to also broaden my horizons and try something new. I didn’t have unlimited time, and wanted to reach a reasonable level of completion in only a few weeks…hence using an entirely new language or toolkit was out of bounds.

Therefore I chose to use my current-strongest language, Python, but to try and make use of newer features and emerging standards:

• Python 3.8

• Typed Python (with static type checking)

• Poetry and pyproject.toml

• GitHub Actions

• Managing the entire project form GitHub (issues, projects, etc)

It turned out to be quite informative! Here are my top 5 takeaways that may help you evaluate and get started with any of the above:

1. Don’t go overboard with Python typing

The Junction codebase uses statically typed Python everywhere, no exceptions. In fact, the requirement to type-annotate every single function signature is enforced by mypy as part of a pre-commit hook and build rule. Here is an example:

def markdown_to_storage(text: Optional[Union[str, bytes]]) -> str:
	pass

This function converts markdown text to a string containing Confluence storage representation. The markdown text can come in as None, a string, or bytes. The function will handle the different argument types without complaint. Besides self-documenting how to safely use this function, it allows for static type checking.

I have lusted for static typing in Python for a long time. Witnessing brutally simple bugs slip into production because of developer-error is painful. Don’t get me wrong: Python is my primary language these days for a reason. I don’t necessarily believe statically-typed languages are inherently safer than dynamically-typed: in fact, compilers often lend developers a false sense of confidence.

That doesn’t mean type-checking is a waste of time! After I went back and added in all of the type annotations, mypy managed to find ~4 different bugs in my code! Nice!

In the end, though, I do not recommend typed Python for every project under the sun.

• Typing support didn’t really reach maturity until Python 3.8 which is still inconsistently supported by other community projects and is less likely to be available in your runtime environment than say Python 3.7.

• mypy will happily report 0 errors when your code is not fully typed, leading to overconfidence. You need to explicitly configure mypy to disallow this. Moreover, it’s very easy to accidentally let an Any or two into your typing, and inadvertently cause an entire critical path to essentially go unchecked, with none the wiser. This isn’t a mypy flaw, more like mixing duck-typing and static-typing is an inherently tricky task.

• Trying to actually make use of Python’s fast-and-fluid duck-typing and “trust the developer” mentality is almost impossible. In fact, those aspects of the language actively fight you when statically typing and can make you very unproductive as a result.

In effect, using Python with totally enforced static typing makes the dynamic aspect of the language a burden, while loading you up with the overconfidence of static type checking to boot.

My advice? The choice is not between dynamically typed or statically typed Python. You should view static typing as a safety tool: it makes code safer to change by pointing out unexpected side-effects early, and documents your code in a way that is very accessible to other contributors. Does your project actually have a requirement for that level of safety? If yes, then typing is for you…and even then, maybe only the parts of your project that are relatively stable and mature.

2. New Python features have a long bake time

I normally use a fairly standard Python project layout which makes use of setup.py, requirements.txt, src/, test/, pip, and virtualenv. Before jumping in with my usual boilerplate, I decided to take a look around because I knew some exciting things were on the horizon back in 2017 when I last assessed the environment management and packaging landscape.

Pipenv and Pipfile‘s were high on my list for solving the pains of using a mosaic of different tools and configs across dev, test, and release. However that project has two gaps: (1) you still need to maintain setup.py if you intend to release, and (2) you can’t use pre-release packages without permitting pre-release packages for everything.

No matter, what other options exist for leaving behind setup.py and friends? PEP518 and pyproject.toml. Nothing makes this new standard more appealing and user friendly than Poetry. From getting setup with the right version of Python, to activating my environment and resolving dependencies…it was painless. With Poetry in place, I could lean into the use of pyproject.toml and avoid littering the root of my project with one-off ini files!

Despite years of maturation and community adoption, not all projects have picked up support for this new configuration option: Flake8 still uses .flake8, mypy requires mypy.ini, and even Tox only has partial support.

These little compatibility land mines pop up in other arenas as well. Python 3.8 adds support for assignment expressions (:= AKA PEP572), but both pyflakes and pycodestyle lack support and will report false-negatives..unless you’re using the latest pre-release builds.

All annoyances and no major road blockers, but the experience has left me doubtful. When you choose to develop in Python, you must acknowledge how critical these community-supported tools are to providing a fully-fleshed out SDLC. Python 3.8 is 6 months old at this point, and pyproject.toml has been around for ~3 years.

This paints a pretty bleak picture about how long advancements in Python take before they can be adopted and embraced by developers at large. So what’s to be done? Well, if you can, start contributing to these tools yourself! PyCQA and PyPA may sound super-official, but they aren’t paid endeavors. It’s still just people like you and me largely donating their time to creating amazing tools that make our favorite programming language more usable. You can make a difference by lending a hand. In fact, the next release of pyflakes and pycodestyle with full 3.8 support appears to be orchestrated by a very helpful community member.

3. OpenAPI is still painful

Confluence Cloud publishes an OpenAPI (formerly known as Swagger) specification for their API. Just finding that specification was an exercise in frustration, because it’s hidden behind a link in a “…” menu in the corner of their website.

Once I found the actual spec I thought my troubles were over and I could get a fully working API client with the help of OpenAPI Generator. I mean, that’s the entire value proposition of OpenAPI isn’t it? And surely things have gotten better since when I last tried to this with Swagger (OpenAPI 2.0)?

lol, no.

1. The Confluence Cloud API spec has bugs in it. It’s massive, clocking in at 13,000 lines of JSON. It’s clearly generated from the actual API stubs in their server code, and whatever is generating this is broken.

2. After you manually fix the bugs, OpenAPI Generator doesn’t produce valid Python code. It doesn’t put down the proper imports for handling the object hierarchy found inside Confluence’s API.

3. Apparently not everyone agrees with the direction of OpenAPI Generator, so the original Swagger Codegen is still maintained and under active development, however the code it generates is even more broken. Open source fragmentation is cool.

In the end I made my own lightweight API client. It took forever and was mostly mechanical…sounds like a job for codegen ?. OpenAPI still has a ton of potential, but the codegen feels like the same toy/tech demo it was back in 2016 when I tried it last. Without reliable codegen, I honestly see very little value in publishing OpenAPI specs for my own API’s…it’s just setting my users up for frustration.

4. GitHub Actions are great; YAML is not

Actions are the new(ish) CI/CD offering from GitHub built in to your repository. The reception of Actions has been universally positive and enthusiastic in my extended social circle, so I was excited to try it out. It definitely lives up to the hype, here are my favorite parts

• There is a large (and growing) library of community-contributed actions which make building out your workflow almost effortless.

• It’s free for public repositories, and you get up to 2000 minutes/month for private repositories…which is way more than enough for hobby projects.

• Sooo fast; with only ~10s per job spent on setup/teardown.

• Beautiful documentation, seriously a gold standard that leaves nothing to the imagination. No need to spin up an experiment just to see how something works.

In spite of my new-found love for Actions, it’s hampered by writing workflows in YAML, software engineering’s most ubiquitous accomplishment mistake. GitHub provides a competent web UI for editing workflows, but there is an upper-bound on how usable any YAML-driven tool can be in my opinion. For any sufficiently expressive configuration system (i.e. CI pipelines), the YAML devolves into a domain-specific language. This sort of “meta programming” is a poor replacement for a full-fledged imperative programming language that has mature IDE support and the possibility of running locally. Even when keeping your workflows lightweight and deferring the heavy lifting to in-repo scripts, you’ll still be keeping the workflow YAML specification close at hand to muddle through ever so slowly.

None of this is really the fault of GitHub Action’s, and maybe just an expression of some pent-up frustration with Kubernetes, but the nail in the coffin is that there is no way to run the workflows locally (or directly form the web editor) without pushing a commit. Having a way to test the workflows quickly tightens the feedback loop and eases the pain associated with idiosyncratic YAML DSL’s.

Matters of taste aside, I still recommend Actions to everyone, even if that means migrating your project from another source control platform.

5. Click is my new goto tool for CLI’s

I make a lot of CLI’s. They are a quick way to provide functionality to a developer, as well as a cheap “API” when something more serious is overkill (see: CI/CD workflows). The usability of a CLI is largely a function of its presdictable (and forgiving) parsing of arguments/flags, and towards that end pretty much every language has a goto library for argument parsing:

• Java has Apache Commons CLI, which I despise.

• C# has PowerShell cmdlets, which I enjoy.

• Python has argparse, which I find toilsome.

• Bash has getopt(1), which I use for simple cases.

The CLI for Junction is fairly tricky to use so I wanted strict parsing and detailed help text, and to do so with argparse alone would have been a large effort. After a short search, I stumbled upon Click.

I will never look back.

Click made producing Junction’s CLI take less than 2 hours…and that includes figuring out how to use the library. My CLI has gloriously detailed help text, as well as clean output with ANSI coloring on supported terminals! The whole thing fits in less than 200 SLOC. Seriously, I have never felt “good” about any CLI I have ever released because I know they are full of bugs and edge cases, but are juuust good enough to pass. With Click I am confident this CLI is going to work, and if I want to unit test the hell out of it, I can with ease.

High-quality side projects are hard

The hardest part about this entire experience wasn’t grappling with these unfamiliar elements… it was the basics of maintaining good developer hygiene: writing good issue descriptions, leaving useful commit messages, documenting architecture, and unit testing. In fact I probably failed at 3/4 of the above because the only thing I really did was document the architecture (and it felt like pulling teeth despite being one of my favorite activities at my day job).

What was missing? Well obviously not everyone finds the above intrinsically enjoyable. More than that though, what I felt missing was a feeling of community. What motivates me to do any of these hygiene tasks well and to do them regularly is the obligation I feel to my peers and the sense of pride I receive as a craftsman.

I am able to draw a few fundamental takeaways from this whole experience then:

1. Don’t sweat the small stuff, just do what you can. If not writing enough unit tests stopped me from starting (or finishing) this project I would have missed out on a wealth of experience.

2. When starting a new project, prioritize building a sense of team. Shared commitments and interpersonal morality are strong motivators for all the things that keep development projects healthy i.e. documentation, testing, and communication.

3. As a hiring manager, don’t hold a lack of side projects against someone. If I had a child, a spouse, or other commitments there is no way in hell this project would have happened…it was a slog. GitHub and Stack Overflow profiles can be useful, but at most they can be used to abridge the interview process..never to filter someone out.