What are you optimizing for?

I left Squarespace in July after an eight year run. To reiterate what I said in that post, Squarespace changed my life. I grew up as an IC at Etsy, and I grew up as a manager/leader at Squarespace. And both on paper and in practice, it was a great role - a wide managerial scope (3 orgs / 12 teams / 85 reports), the carried reputation of successfully building International from the ground up, and the opportunity to work with a diverse set of smart and kind coworkers who operated in good faith. I had no major complaints about my compensation or work-life balance. I genuinely enjoyed those whom I worked most closely with as people.

Which naturally begs the question: why did I leave?

During The Great Resignation of 2021-2022, I didn’t take any interviews. While fully remote opportunities with bigger titles and sky-rocketing compensation were available, it wasn’t the right time. International wasn’t what it could be, yet. I was determined to get a few deserving teammates promoted. My family was navigating a personal tragedy. And in the midst of Covid lockdown, my wife, young son and I were slowly losing our minds at home. In the scope of what I was optimizing for most - personal stability, achieving International’s vision, my reports - an elevated title and more money weren’t my priorities.

And you know what? It was the right call. We needed the stability at home, International changed the face of the Squarespace business, and nothing gave me more pleasure as a manager than facilitating career growth for many excellent teammates. It was truly one of the best parts of my job.

Fast forward to 2025 and the opportunity at Imprint came up in May. For the first time in many years, the things I was optimizing for (both personal and professional) had meaningfully changed:

• My family life felt more stable. My kids are a bit older now, and while I become a chauffeur starting at 5pm every day, their days (and most importantly nights) are increasingly predictable.
• Purchasing a house we loved gave us a sense of location permanence and a community to invest in.
• I wanted to feel more shared urgency at work, and I wanted the shared organizational incentive of an exit / financial outcome to override any cross-functional complacency. I was ready to trade off a less predictable startup work schedule for this urgency.
• I’ve learned a lot from Will and his writing over the years, and I wanted to work with him directly.
• Imprint was an order of magnitude smaller - 150 people, ~40 engineers - with booming financials and a nascent engineering culture. I’ve built enduring engineering teams and cultures. I wanted to know if I could do it again.
• I stopped caring about management vanity metrics like reporting number and org size. I know I can do that job. I wanted to get back to feeling like I was actively pushing the business forward, and was happy to frontline manage teams again in order to do so.

What people value at a given time varies: current liquid compensation, future stock compensation, title, work-life balance, job stability, the challenge of building something significant, the convenience of building something insignificant, a leadership chain you believe in, etc. The mistake I see most often is assuming those values must be static or universal. None of these are more or less right or wrong than others, and they’re fully contingent upon context and timing.

Thinking about this question has grown me in a few specific ways:

• When you sell candidates on joining your company/team, how does your framing of the opportunity match what the best fit candidate is optimizing for?
• As a leader/manager, how much does your culture and practices match what your coworkers were optimizing for when they chose to accept their jobs?
• I have grace (for others, for myself) when highly valued coworkers move onto new companies. Sometimes the reasons are work related, sometimes they’re not. Often it’s a messy mixture of both. Despite any feelings of disappointment, be happy that they’re making the best decision for them. In the grand scheme of things, jobs come and go, but strong relationships with amazing coworkers who you’d be happy to work with again are few and far between.

My enduring advice to job seekers is to know what you are optimizing for, and navigate your search and interviews through that lens. Knowing what you’re optimizing for doesn’t guarantee the right outcome, but not knowing almost guarantees confusion.

When I joined Squarespace in 2017 I was excited for something new. After witnessing the first major round of Etsy layoffs as a manager, it was the cap to a sense of frustration and burnout that was growing for months. I resigned without a job lined up and decided to take a break.¹

I took a 4.5 month break between jobs (not having kids was truly a different planet of optionality), and while I have zero recollection of how I spent that time other than exploring food courts in Flushing, it was the reset I needed. Eventually it was time to find another job. Our pregnancy was half over and given what I already knew to be true about the unpredictable time intensity of the management track, I started explicitly looking for jobs on the IC track. I was also excited to code again. After interviewing for a bit, and a very fair and pleasant interview experience, I accepted an offer from Squarespace.

I was part of a massive engineering growth push; the mandate was to increase engineering headcount from 100+ to 300+, and I was somewhere in that range. Commensurate with that growth were growing pains: they had just split up long-standing core teams into smaller teams (with tenured ICs becoming the new Team Leads of those teams), engineering levels were recently introduced, and the IC to manager ratio was in the ballpark of ~30 -> 1. But the chaos (and most growth-related chaos) was a lagging indicator of a fundamentally successful business, so while the specifics were messy, the future was bright, and times were exciting.²

I was lucky to land on a team led by Jake, who will always be one of my favorite coworkers ever. From the start we had an intuitive alignment in technical smell, management smell, and “wtf.” I landed on a team called “Interface Architecture,” which was the team that owned all horizontal frontend concerns. Libraries, build tools, interfaces, DevEx - it all directly aligned to the work I cut my teeth on at Etsy.

Before I arrived the team had been tasked to build the first version of internationalization libraries to translate the product. I didn’t have any previous International experience, but I did have significant “roll out a technical pattern that everyone has to use and anticipate why it’ll be loved or hated” experience. And in the first couple months I remember reading the code of our translation workflow and following up with Jake in a 1:1 - “Hey man; I don’t think this will work.” I foresaw various pitfalls around determinism and DevEx that I knew would become really problematic. I had some ideas as to how the workflow could be improved, and with the team’s buy-in I started to prototype a different solution. This proved serendipitous as my parental leave was rapidly approaching and I was eager to demonstrate impact on a meaty, important problem.

In a lot of ways the translation workflow was the ideal IC project: business critical, engineering critical, far reaching in technical scope, and complicated enough that I’d think about it in the shower but bounded enough that I could make meaningful progress everyday. By the time our son was born I was very close to completion - maybe 85% - but not quite there. Thankfully during my leave a teammate of mine - Karim - took it to dev complete.

When I returned from parental leave several months later, Karim and I pushed the workflow across the finish line. Not only deploying it to prod, but creating all of the ancillary parts (docs, presentations, linting, etc) to operationalize it fully. The end result was the Unified Translation Workflow (UTW) which remains how translations are extracted and consumed across codebases today.

Shortly afterwards I was approached by someone in Engineering leadership - “UTW is a great step in the direction we’ve always wanted to go with International. Are you interested in starting and leading an International Engineering team?”

To which I replied, “can I work with Karim?”

And we were off to the races.

In a vacuum International feels like an easy and obvious growth lever – “we have a product that works very well in America, all we have to do is translate it and everyone in [countries] will love it as much as they do here!” – until companies learn the hard way that localization is not nearly that straightforward for both technical and operational reasons³:

• International customers have their own cultural norms and expectations around UX and product experience. Your core brand identity may not resonate at all in a different market. And Marketing matters - a lot!
• The same language (and numbers, dates and currencies), can be rendered and formatted differently in different locales (e.g. Spanish in Spain vs Spanish in Mexico).
• Those APIs/UIs coded 10+ years ago, that nobody on the current payroll has touched (and has no tests), that consume en-US only dates / numbers / text? They need to be carefully updated to work across all locales.
• Let’s assume most of your customers are US-based, but the company wants to strategically prioritize building for non-US. How do you incentivize product teams to deprioritize their current largest customer segment - US customers - for a promising but undeniably smaller customer segment (international markets)? How do you align that choice to their incentives?
• Are you shipping different the same product to all locales or different products to different locales? Your choice here will ultimately impact building and deploying code, monitoring, alerting, and team topology.

Ten years ago conventional wisdom in tech was to change jobs every 18 months. There are pros and cons to long tenures at tech companies, but one pro I realized at Squarespace is that a long, focused, undisrupted tenure is what it takes to realize a multi-year vision and do something really big.

When we started International the cross functional team was hilariously small - me representing Engineering, no one from Product or Design, and two coworkers from Marketing. I stumbled my way through my first reps of setting cross-functional alignment with non-PED stakeholders. I have a distinct memory of one of our first meetings where they started with their top ask: “We’d like to build multilingual websites.” To which I (too) honestly replied, “Multilingual websites?! We can’t even properly format a date!”⁴

Fast forward seven years later, and we did ship multilingual websites, in addition to a huge number of other product, engineering, and workflow improvements across our entire product suite. There was no silver bullet to making International a platform that other teams could build on - only the lead bullets of diligence and persistence over time. To get to multilingual websites, we had to build proper formatting libraries. To build formatting libraries, we had to build locale abstractions. To build locale abstractions, we had to determine how we wanted to build and deploy code for N new languages. All milestones built upon the incremental milestones before them, and powering through changes within unowned and untested codebases became less of a reluctant chore and more of a hallmark of our team identity. A shared vision and a trail of well delivered outcomes is a hell of an incentive to continue to push.

It was a massive team effort. What started as Karim and me sitting next to each other and grinding through tickets eventually grew into multiple PED triads, a cross functional effort of 100+, and 300M in revenue. We hired, transferred and promoted a talented, resilient, kind, and diverse distributed team across the US and Dublin. I worked with excellent engineering managers, engineers, product managers, designers, and localization specialists. These teams set my bar for what I now know is possible for teams at the nexus of technical rigor and psychological safety.

When International first started I would often reiterate my belief that it’d change the face of the Squarespace business, as the data around international customer growth made that seem obvious. But seeing the potential in something and realizing its potential are different. It was exciting, stressful, joyous, and frustrating, and we rode those waves together. And it’s been the privilege of my career to date to play a role in that story.

It’s impossible to catalog all of the lessons I learned at Squarespace, but some that stick out:

• Narratives run the world, and make or break teams (and companies). There is always a narrative, whether you as a leader choose to own it or not. If you do not own a narrative, teams will create one for you, and it will often bias towards being uncharitable. Your responsibility as a leader is to own, and drive, a narrative.
• Nobody is more accountable to your career growth than yourself, and there is more growth outside of a career ladder than within it.
• It’s a better investment of time and energy to focus on what you can control.
• The key lesson from Covid is that work cannot happen when human needs are not met.
• The biggest cost of a leader’s unwillingness to address underperformers is the disillusionment of their highest performers.
• The greatest work life hack is to genuinely enjoy the company of the people you interact with most.

Footnotes

Ownership

For the last 40+ years, my mom has owned and operated a beauty supply store. She is my hero in so many ways. Born into an extremely impoverished family in war-torn South Korea, she was the youngest of six siblings during a period of widespread instability and economic devastation. As the youngest child and a woman in a patriarchal society, there was limited time or money for schooling beyond a secondary education. Eventually she married, moved to the States, had children and tried various small businesses until she opened a small beauty supply store over 40 years ago. She is self made and self taught in every sense of the term: language, culture, and business. And her devotion to her store – 10 hours a day x 6-7 days a week x 40 years – made our lives possible.

I grew up as latchkey kid, coming home to an empty house after school, mostly microwaving myself Bagel Bites / cans of Chef Boyardee, playing SEGA and not answering the phone or the door. My mom was almost never at my little league baseball or basketball games, unless they were serendipitously scheduled on the one day off she sometimes had per week. I didn’t bemoan this - she made sure I felt her love everyday. It was simply a fact of life: the sky is blue, grass is green, and umma (“mom” in Korean) is at work.

Roughly ten years ago there was a family first birthday scheduled on a Saturday at 11am. In Korean culture a baby’s first birthday is a significant cultural milestone, its importance falling somewhere between the American customs of a Sweet Sixteen and a wedding (closer to the latter than the former).

My mom’s reaction was immediate:

I can’t make it. 11am Saturday? I have to work.

There were some temporarily hurt feelings and attempts at rationalization, but she remained resolute in her stance, almost surprised at the backlash of what she deemed obvious. I had heard “I have to work” so many times in my own childhood, unable to formulate a rebuttal due to insufficient age and life experience. But I was an adult now - gainfully employed and married - so I asked her:

I don’t get it - why do you always have to work? What’s the big deal if you miss a few hours of work on a Saturday for this birthday party? Don’t you have an employee or two that can cover for you? Why do you care so much about being at the store all the time?¹”

And her response, said as a passing comment, has stuck with me to this day:

I am the owner of this store. Employees come and go, but they are not the owner. I am the only one responsible for what happens here, and it’s important I am around to take that responsibility. When the owner is not around, things are not the same.

My context/privilege² is very different than my mom’s. I’m not really here to debate my mom’s idea of work-life balance, nor would I necessarily make the same decision. But in the thousands of conversations I’ve had with her over my lifetime, this is one conversation that I find myself revisiting. Both because it helps me better understand her lived experience, and because I find it increasingly relevant to my own life as a son, husband, father, and manager.

Ownership at work

It’s common to see “we act like owners” on a company’s careers page or list of values, but it’s a lofty aphorism without concrete direction. Nor does ownership necessarily prescribe a set of values or behaviors; there are many terrible dog owners and homeowners. When I think of true “ownership,” I prefer my mom’s definition: “within the scope of what I can control, and in the good and bad, I am ultimately accountable.”

There are a lot of mechanisms by which a sense of ownership can dissolve in organizations:

• “Stakeholder management”: a “polite,” formal-sounding, likely templated email/slack message that communicates how an urgent request has been heard and will be triaged during a sprint planning meeting two weeks from now;
• “We don’t own this”: common during incident triage, the practice of hot potato-ing accountability until someone realizes the team that owns the broken system was re-org’d out of existence six months ago;
• “It’s the vendors fault”: the sibling to “we don’t own this.”

To be fair, these reasons can be real, and sometimes there are limited options to pursue when a vendor in the critical path is on fire. But I’ve experienced many more situations where reality is much less black and white, and with some thought and effort there is in fact an alternative or workaround to pursue. But teams or individuals absolve themselves of responsibility by blaming various unaccountable parties: circumstances, topology, priorities, “the org.”

But I’ve also noticed that some people - ICs and managers alike - don’t do that. They face the same blockers but approach them as obstacles, not outcomes. These people are often the most effective operators at their level, and uniquely seem to get more done and are more widely respected as teammates. The difference is they operate as owners.

Owners don’t have the luxury of wiping their hands of responsibility due to circumstances. Owners push forward with the additional step of identifying solutions, which in the absence of clear steps forward (i.e. formal lines of ownership aside, just fixing the damn thing themselves), means communicating pragmatic, potentially unpalatable alternatives:

• Here’s what we need to know or do to address this;
• Here are the inevitable tradeoffs we’ll need to make to prioritize this over other things;
• Here’s why I think this is, or is not, worth it.

The more I progress in my career, and the more I interface with executives, the more I’m convinced this is ultimately what senior leaders want. No matter what track you’re on, in response to an ask don’t simply tell them “no” or that something isn’t possible - read the room of how important an ask is, triage it against any existing priorities and processes, and bring them alternatives by which that ask can get done and the tradeoffs involved. And in the circumstances when you are truly blocked - you’ve racked your brain for alternatives, and there are none available at your scope - ask for help. Walk them through what you’ve tried and why. These are the foundations of building trust and delegated authority.

I once read that “the best way to learn to be an owner is to act like an owner.” I think that’s good advice. For the job you ultimately want, I think it’s hard to suddenly “turn on” behaviors you’ve never demonstrated before. The less obvious instincts and behaviors that make ICs and leaders great - the smells, the triangulation of incentives and personalities, the ability to drive conversations to resolutions, the courage to push through friction - can only be learned by doing. The learning is in the reps. The fastest way to get better at being the owner you aspire to become - Cofounder, C-suite executive, Head of Department, Distinguished Engineer - is to act like an owner today.

I’ll often ask a guiding question to explore this idea in 1:1s: “Forget your title, the org, and your boss. Tomorrow you’re appointed as the CEO/CTO - what would you do here?” I like this question because it takes people through the mental exercise of breaking out of perceived organizational constraints.

Urgency

The corollary to ownership is urgency. “Urgency” in this context is not the need to meet an external time-based standard³, but rather the need to meet an internal quality standard. In practice they’re often correlated - high urgency people often execute tasks quickly - but it’s not because speed is the goal. It’s because knowing a suboptimal thing exists annoys them into fixing it as soon as possible.

One of my favorite parts of Hamilton is during Non-Stop, when Aaron Burr delivers a commentary on Alexander Hamilton’s contribution to The Federalist Papers:

Alexander joins forces with James Madison and John Jay to write a series of essays defending the new United States Constitution, entitled The Federalist Papers. The plan was to write a total of twenty-five essays, the work divided evenly among the three men. In the end, they wrote eighty-five essays, in the span of six months.

John Jay got sick after writing five.

James Madison wrote twenty-nine.

Hamilton wrote the other FIFTY-ONE!

How do you write like you’re running out of time?…

Alexander Hamilton didn’t write 51 Federalist papers because he needed everyone to celebrate his pace of work relative to his peers. He wrote 51 Federalist Papers because that’s what it took to accomplish his actual goal, which was to ratify the US Constitution. And if his peers wrote 34 and the end state required 85, well… that means he had to write 51. The volume of work was incidental to the outcome.

How often in the course of work is this true? You set out with nominal acceptance criteria - “25 essays” - and in practice the delivery of the ultimate outcome balloons to significantly more work. Urgency is the impulse that carries the most effective operators through to the end of a road, regardless of how long that road is.

In practice I find that high urgency individuals often share a similar trait: they’re optimistically dissatisfied. “This could be better, and I have the skills to see how, and I’m going to drive it forward to my own high standards of what ‘good’ looks like.” And it’s not because that better state is solely contingent upon the next rung on the career ladder, or their bosses’ opinion, or acceptance criteria in a Jira ticket. The drive is internal: if something could be better, why shouldn’t it be better? If something could be faster, why shouldn’t it be faster? If you’re going to put your name on something, why wouldn’t it be the best version of what you can do? What’s the point in doing this if we’re not going to do it as well as we can?

Caring, enough

While these traits are powerful drivers of impact, urgency and ownership are a double-edged sword. On the positive side there’s the impetus to aspire, try new processes, and push towards better outcomes. On the negative side, when outcomes aren’t what you expect or want, frustration can boil over into complacency, cynicism, disengagement, and ultimately burnout. How do you care enough to drive a system to a better state, but not care so much that your mental state is solely contingent on the results?

For me, it’s taking a hard look at recognizing what I can control and what I can’t. And the scope of what I can control includes (1) my inputs, or the work I put in, and (2) my sphere of influence (teams/managers under my remit). If I’m happy with my inputs within my sphere of influence, I’ve operated well as an owner.

Footnotes

Caution: 8 Mile plot spoilers ahead. In my defense, 8 Mile was released in 2002 so if you haven’t watched it by now, I doubt it’s in your Netflix queue.

The premise of 8 Mile is that Eminem (Jimmy, aka B-Rabbit) is a poor, white, blue collar, motor factory worker trying to make a name for himself in Detroit’s underground battle rap scene. His closest friends recognize his immense talent, but his recurring stage fright makes him unable to perform in front of a raucous and increasingly skeptical audience. The antagonist of the movie is played by Anthony Mackie (Papa Doc), a strong battle rapper and leader of an opposing crew. One significant difference between the two groups is obvious economic disparity, as Anthony Mackie’s crew drives around in a Cadillac Escalade and Eminem’s crew drives around in a beaten down Oldsmobile. Living in a trailer park with his mom and daughter, Eminem’s economic situation is a source of shame that he does his best to keep hidden. He knows music is one means to greater financial mobility but he’s perpetually “working on his demo.”

The ending of the movie pits Eminem against each member of Papa Doc’s crew in a series of rap battles. Eminem finally overcomes his stage fright to take down each member of the crew one by one. In the final scene, having finally reached defending champion Papa Doc himself, they flip a coin to determine that Eminem goes first. I’ll let Wikipedia explain the rest:

Going first, Jimmy preempts Papa Doc’s potential insults, acknowledging his own “white trash” roots and difficult life. He ends his battle repudiating Papa Doc’s image as a thug by exposing his privileged background; having attended a private school in a wealthy suburb and living in a stable, two-parent household, and the fact that his name is Clarence. Embarrassed and with nothing to say in rebuttal, Papa Doc hands the microphone back to Future, conceding the battle.

Here’s the scene on YouTube. All expected content warnings apply: this is an R rated movie from 2002, centered around battle rap, starring Eminem.

Even in high school I found Eminem’s approach in that final battle both unexpected and brilliant. B-Rabbit’s strategic insight? The best way to quell a potential rebuttal is to preemptively address its main points.

A reasonable question: “why on Earth would I ever mention this movie in a professional setting?” The answer is because this insight applies in an unexpectedly large number of real-world work situations:

• I’m writing a long-term strategy for our team, and it requires trade-offs that people might be upset about.
• We need to work within the codebases of another team, and they hate it when other teams touch their code.
• We need to collaborate with another team to accomplish our highest priority work stream, but they won’t do it because they’re too busy with their priorities.

Enduring compromises are win-win

Years ago I read Getting To Yes, which explains the principles of successful negotiation. One of the key principles of the book is “successful negotiations are mutually beneficial” - it’s never prudent to win a short-term negotiation at the cost of a long-term relationship. “Putting something over on someone” is extremely short sighted and ultimately self-defeating. In service of long term mutual benefit, there are four key components to successful negotiation:

1. Separate the People from the Problem
2. Focus on Interests, Not Positions
3. Invent Options for Mutual Gain
4. Insist on Using Objective Criteria

While 2+3 are not necessarily great advice for a rap battle, I find thematic similarities between these points and Eminem’s winning tactics. At their core they both ask, “forget what I want in the vacuum of my own interests - what does this other party really want? And if I anticipate those desires, how does that contextualize the plan for my behavior?”

A similar concept is to explore the Steel Man Argument. In contrast to Straw Man arguments, which center on bad faith and superficial interpretations of a viewpoint, a Steel Man Argument focuses on addressing the strongest rebuttals against a stated position. In a work context sometimes the outcomes are conveniently binary (i.e. a “go”/”no go”), but more often than not you must find a pragmatic solution that grapples with competing incentives and tradeoffs. In this case, a successful “8 Mile Method” is to seek the Steel Man compromise. In light of the other party’s incentives, what are the pain points you can anticipate to make a “yes” as likely as possible?

Going back to the real-work examples:

I’m writing a long-term strategy for our team, and it requires trade-offs that people will be upset about.

Does your strategy explicitly address its most likely critiques? If you’re proposing a significant deviation from the status quo, are you substantiating that deviation with compelling quantitative and qualitative outcomes? “If we do [x] we end up at [compelling future state], and if we keep doing what we’re doing we end up at [worse/status quo future state].” How does the narrative of your proposed future state better appeal to the long-term incentives of your stakeholders, even if it’s more painful to pursue in the short term?

We need to work within the codebases of another team, and they hate it when other teams touch their code.

Think about it: why do they hate it when other teams touch their code? Is it because they’ve been burned in the past before with haphazard changes to their codebases that they’ve been left to maintain? (Side note: this is literally always the reason.)

Can you propose workflows to preempt those concerns? For example: can you ensure that all of your incoming PRs are well documented and tested? Can you ensure that your code is sufficiently silo’d so that when it breaks, the rest of the codebase degrades gracefully and your team is paged instead of theirs?

We need to collaborate with another team to accomplish our highest priority work stream, but they’re too busy with their priorities.

The other team is so time constrained that they can’t dedicate the coordination / IC hours to your work stream. Can you minimize the their time commitment while still benefiting from their experience and context? Can your team assume nearly all of the IC work, and limit their involvement to planning / periodic consultation / PR approvals? Alternatively, is there a way for you to position your work in alignment with one of the other team’s higher level goals, thereby increasing the priority of your request?

No team wants to be a blocker, especially to good outcomes. They become a blocker because they don’t have viable alternatives. Your job as a leader is to give them alternatives.

From 🤷🏻‍♂️ to action

There is a concept in psychology called the Locus of Control. In short, the locus of control is the existential question of how much an individual attributes outcomes to external factors vs internal factors (i.e. their own behaviors). I’m not qualified to opine on where people should sit on this spectrum (and personally I think “luck” has an oversized impact on so many of life’s outcomes), but I do often encounter situations at work where I see people give up too soon. They encounter the friction of bureaucratic process, pre-defined planning cycles and roadmaps, or even checked out coworkers, and throw their hands up in frustration and stop trying.¹ To be frustrated in these situations is often just and reasonable, but frustration alone doesn’t change outcomes.

People often have more agency to change work outcomes than they think. Your team appears to be blocked by opinions, emotions, or priorities. How can you turn progress away from what you can’t control (other people’s behavior) to something you can (your behavior)? Are you truly looking at all of the possible angles to get to a solution, or is your frustration cutting that analysis short? The 8 Mile Method will force you to enumerate realistic alternatives.

Footnotes

When I talk through challenges with these managers, a common blocker in these conversations is navigating points of conflict: underperforming teammates, delivering disappointing career news, acknowledging misalignment with close coworkers, etc. And the answer to the most obvious question - “have you told [this person] about how you feel?” - is often “no.”

There are variety of context-dependent rationales here, but if I had to generalize, the most common reason boils down to “I don’t want to be mean.” And to be fair, there’s a lot of positive signal in that response. Management is a moral exercise, and a moral compass is critical to navigating the web of surprisingly emotional judgment calls that a manager is tasked with everyday. “Try not to be mean” is a good overall aspiration.

But the more times I encounter this situation (and reflect on my own past instances of “I don’t want to be mean”), the less I think the problem is a matter of “mean” or “nice” at all. Instead I think a more accurate framing of conflict avoidance for managers is “I don’t want to be vulnerable.” And I find vulnerability avoidance in a leadership role to be very limiting, in both obvious and non-obvious ways.

Vulnerability isn’t nice or mean, it’s honest

When I use the word “vulnerable,” I don’t mean “meek” or “emotionally demonstrative.” You don’t have to have tears in your eyes to be vulnerable. In this context vulnerability means being willing to do the leg work to be emotionally and intellectually honest when evaluating a situation, and confront the truth when that evaluation diverges from easy outcomes. Confronting the truth takes courage, and it’s easier to make conclusions upstream of details because it spares you the emotional cost of grappling with confounding or unpalatable nuance.

When things go wrong, sometimes it’s your fault, sometimes it’s somebody else’s fault, and sometimes it’s nobody’s fault. Sometimes it’s a combination of all three. Either way, to be vulnerable as a leader is to be open to any of those conclusions, and owning the responsibility to follow through with fair, corrective action - even against yourself. Sometimes the right outcome might be admitting to a team, “I really screwed this up, the fault lies with me.”

The Tyrant and The Pushover

In the worst case, there are two opposing archetypes created by vulnerability avoidance: The Tyrant and The Pushover.

The Tyrant is a manager that leads by context-less accountability and fiat: “I make demands and they are followed.” When those demands are not met, yelling or finger-pointing becomes a proxy for accountability, and in the worst case people unfairly lose their jobs. Were the demands realistic? Was the team set up for success with appropriate staffing and strategic direction? Were there real, competing incentives that the team was not set up to trade off? None of these details matter to The Tyrant.

It doesn’t matter that blindly mandating outcomes isn’t strategic. The Tyrant will make generic proclamations like “I need to put a fire under this team” and “this team lacks urgency,” which are common scapegoats levied by managers who are unwilling or incapable of digging into details. Being upset about poor outcomes is frankly easier for The Tyrant than acknowledging their role in creating the inputs that undermined the outcomes in the first place.

The Pushover, by contrast, holds nobody accountable. The Pushover’s team operates blissfully agnostic to delivery timelines or role expectations, and individual underperformance is repeatedly swept under the rug. As a result the team doesn’t ship enough, or they don’t ship the right things. The Pushover believes their core job is to keep engineers happy and “protect the team,” but the net result of this protection is that the leadership team above them has no idea what they’re working on and why deadlines are slipping. Kim Scott refers to this management style as Ruinous Empathy.

I’ve found The Pushover to be much more prevalent than The Tyrant. But The Pushover is easier to overlook because at face value their team is happy and kind to each other, which feels like culture. But underneath this facade of team culture lies a much more pernicious reality:

• The team is invisible. Because the organization doesn’t understand what the team actually does (and it doesn’t ship!), the organization will never give this team priority. Nobody gets promoted, the team never grows in size, and in times of cost sensitivity the team’s headcount is heavily scrutinized.
• The strongest ICs are burning out. I am 100% convinced the best way to burn out the highest performers on a team is to fail to engage in any corrective action of any low performers, especially as titles increase. “If performance doesn’t matter, why am I trying so hard?” It’s a team and morale killer at the price of one leader’s unwillingness to engage in an honest conversation.¹

This leads to perhaps one of my most controversial management hot-takes:

It is impossible to foster a psychologically safe culture if persistent underperformance goes unaddressed.

Psychologically safe culture is not centered around being nice, it is centered around being fair. In the famous words of the Netflix culture deck, work is a sports team, not a family. Fortunately, kindness is often a side effect of just cultures.

Positive feedback is vulnerable, too

Here’s a real question: when’s the last time you received detailed, deeply encouraging and non-generic positive feedback from a manager acknowledging the effort and impact of an initiative you spent a lot of effort on? Not simply “you did great on this,” but feedback so specific and personal that it could not have been written by ChatGPT? And when was that feedback delivered face-to-face in a timely manner rather than limited to a written annual review?

My guess is that for the majority of people the answer is “never.” Because it turns out that delivering extremely positive, specific, personal feedback can feel just as uncomfortable to many managers as delivering negative feedback. This is further reason why I think feedback is less a “mean” problem than a vulnerability problem. Praise is as far from “mean” as you can get, and yet managers who are averse to conflict tend to avoid positive feedback just as much.

Earlier in my career this was me, too. I can’t rationalize why, but it simply felt more comfortable to be reserved rather than effusive in my encouragement at work. But a few years ago I made the conscious decision to change my behavior - I would lean into praise when I saw great work happening. This meant showing appreciation in 1:1s, Slack, email chains, and meetings where the recipient wasn’t even attending. And now the opportunity to meet with someone face to face and thank them for their work on something really important is one of the best parts of my job.

The Peter Principle

An idea I will always remember from High Output Management is when Andy Grove discusses the Peter Principle, or leaders “rising to the level of their incompetence.” A common excuse for managers when promoting someone to a title they underperform in is “oh, it’s fine if they struggle, they’re learning.” Andy’s response: “It’s great that they’re learning, but remember - who’s paying their tuition? The team underneath the person who is flailing.”

I think the Peter Principle is often misread as a flippant or cynical observation rather than an objective observation, but it’s absolutely the latter. It’s only natural when promoting someone into a role or scope they’ve never had before that they’ll struggle to adapt, at least for some time. But that begs the question - with sufficient time, what if it’s not working out? What if the scope is simply too big or the skills just aren’t there? Will you do the hard thing of moving them back to the level they’re comfortable in or keep them flailing at a level they can’t operate in? That’s not an easy conversation, nor is it “nice.” But is it the best thing for the team and this person? You made a judgment call and it didn’t work out. Do you have the courage to do something about it?

To confront these questions is an exercise in vulnerability.

Footnotes

The good-faith approaches to these problems frequently center around education or inspiration:

• “Let’s send an email to the Engineering mailing list saying this is important.”
• “We’ll give a talk at Engineering All Hands.”
• “Let’s run monthly training.”
• “If we communicate the pitfalls that these behaviors create, others will see why we’re pushing this change and how it benefits everyone.”

Here’s a hard-learned truth: this doesn’t work. That isn’t to say that education / inspiration / teaching isn’t a core component of lasting change (it is), but changing sentiment alone doesn’t guarantee outcomes.

These alternatives suffer from a few critical flaws:

1. They’re timely. You have to read the email. You have to see the Slack message. You have to attend the All Hands. What if you were on PTO? What if you get 100 emails a day and don’t read them all? What if you joined the company the day after All Hands? If a critical message is contingent upon the circumstances of “you had to be there,” it is brittle.
2. Continued manual intervention doesn’t scale. For example: monthly training. If your team size is limited, are you really going to dedicate the time towards training for and proctoring a recurring meeting? Assuming everyone’s calendars fill with meetings across an organization, what stops your recurring training from becoming calendar noise? If nobody attends your recurring meeting for months, is your team going to stick with it? In my experience, the answer is overwhelmingly no.¹

While these publicity campaigns are accompanied by short-term optimism, I often see well-meaning teams burn out in frustration in the long term with a bad-faith conclusion: “nobody cares.” And I don’t think that’s the real story. I have yet to find a good engineer who doesn’t care about well-written, performant, accessible code. In a vacuum they do care, but in practice they probably don’t care as much as you do, because their incentives don’t align to yours. In a universe of fixed time and attention, they’re going to pursue their own localized incentives over those of horizontal incentives, because those localized incentives are what get them promoted. For product teams, that usually means getting a product out to customers as soon as possible, and manual interventions and trainings slow them down towards these goals. This doesn’t make these engineers bad, it makes them rational.

Consequently I’ve developed a mantra in response to these circumstances:

“If you want to change engineer behavior, don’t change hearts, change workflows.”

In technical terms: codify your desired behaviors into system behavior as much as possible. What are the high leverage points where work must pass through? Two that come to mind are a Design System and CI. A Design System is a great place to implement product behaviors: performance, accessibility, localization, etc. CI is a great place to enforce code-level behaviors: formatting, test coverage, bespoke checks to ensure characteristics on incoming commits, etc. Using both is aligned to an engineer’s incentives - you can’t get code to production otherwise! And instead of requiring engineers to keep all of these higher level concerns in mind at the same time, they get them for “free.” All engineers have to do is use the tools available to them.

Another reason I like this is because it scales to new hires very well. Sometimes incumbent coworkers will push back on workflow changes (see: new CI checks), especially if they’re perceived to slow down existing processes. And there’s a delicate balance here to keep in mind. But if you’re absolutely confident that the short-term trade-off in workflow speed is worth the long-term benefit of technical correctness, any current pushback discounts the reality that when new engineers join the company, this new workflow is normal. New hires assume the norms present on day one are the norms, and that’s a real mechanism by which technical and cultural change propagates over time.

Caveats

• CI, which is a singular bottleneck to getting code to production, is an extremely high leverage point. The pace of CI is the pace of engineering, and when it’s fast and reliable versus slow and flaky, engineering pace goes in lockstep. This means that if you’re going to add steps to a CI process, you must ensure those steps are high value and reliable. Adding faulty or flaky checks will quickly undermine the purpose of those checks and the velocity of engineering. Approach workflow changes with serious scrutiny.
• If you enforce behavior in CI, you must make it easy for an engineer who runs into an error state to resolve their own error quickly. Error states should be actionable and come with self-service documentation.
• You still need to invest in education / publicity. What is the strategic or cultural goal that motivates these workflows? Make sure that’s well communicated and easily accessible, and ideally report on the progress of the long-term goal on a regular cadence.

What if you can’t codify?

One common piece of pushback I hear to this advice is: “well, that might work for some teams, but our problems require manual intervention.” And I agree that this is sometimes true - for example, determining the accessibility of a UI can’t be fully automated. But I also think teams can often save significant time by codifying low hanging fruit into tooling rather than relying solely on manual intervention, even if the tooling isn’t exhaustive.

For a real-world example, as part of the growth of the International engineering effort we had to develop a new architectural pattern for bootstrapping our language tooling into frontend applications. While this pattern ultimately led to successful product outcomes, it was extremely hard to debug when things went wrong, and required manual intervention on behalf of an engineer on our team to dive deep into the resulting stack trace. This was fine for a while, but it began to show up more frequently as teams begun to build new greenfield applications. The manual triage required from our team became frustrating and time consuming.

One day I had a conversation with one of my teammates:

Me: “When you debug these things, are you mentally going through a series of checks?”

Them: “Yeah. I have a series of things I look for, roughly in order of prevalence.”

Me: “Can code do this check for us?”

Them: “Hmm… I think so. Some of them, yeah. Not all of the things, but maybe the top 2-3 failure modes.”

Me: “What if we created a script we could ask engineers to run on their machine to check through those failure modes first before they ask us for help?”

Them: “I’ll try it out.”

That script - i18n-diagnose - linked to internal documentation to resolve common error states. After putting the script into use, our inbound interrupt volume went down, and we had a place to add more debugging utilities as we encountered new problems. And in response to some error states accidentally leaking into production, we integrated i18n-diagnose into our CI runs.

Is it perfect? No. In the gnarliest cases there’s still some manual intervention required. But did it empower other teams to solve their own errors and free our ICs up to work on our most important priorities rather than be overburdened with manual triage? Absolutely.

Footnotes

In July of last year, Pat Kua emailed me to ask if I wanted to be a guest on a new podcast he was creating: The Managing Managers Podcast. While I’ve never met Pat in real life, I was familiar with Pat’s work across the engineering management internet/Twittersphere, and he had previously included some of my blog posts in his LevelUp newsletter. After talking through the logistics, we scheduled a recording in September, and in the first week of March the episode went live.

Working with Pat was great. It quickly became obvious that he was experienced in this type of thing, he was extremely kind and responsive throughout the process, and the software he used to record the podcast worked without a hitch.

I admit that I had some initial trepidation when considering his request — generally around accidentally saying something stupid or regrettable — but several years ago I made the conscious decision to adopt a philosophy around saying yes to “free” career opportunities. “Free” in this context means opportunities without dramatic tradeoffs, including new opportunities that scare me a little but don’t cost much other than time and effort. This has turned out to be generally good advice, and it’s paid off over time.

Overall the interview went well, and it was definitely instructive. There are things I’d do differently next time - look at the camera more, be more conscious of filler words, etc. - but those takeaways are only borne of reps. My main hope before recording was that what I said during the interview would correctly encapsulate my thoughts on the topics at hand, and I think I accomplished that.

For a ~45 minute interview we covered a wide breadth of topics, including my career journey to date, why I think management is “a different planet” than IC work, and how I evaluate my own performance as my role, scope and title both increase and get less defined.

A couple topics I particularly enjoyed talking about(via Pat’s transcripts, lightly edited for clarity/brevity):

Management as a career calling

Patrick Kua: Great. I’d like to maybe backtrack a little bit and go back to one of the things I heard you say. Which was, I heard you say, the management track as your true calling. What does that mean to you?

Yeah. That’s a really good question. This is actually a thing that I’ve talked about with a number of people. I’ve had people email me, being like, ‘hey I’ve thought about going to the management track…’ I have tactical reasons why I think the management track is better suited for me personally. I think it aligns a little bit better to some of my skills. Some of my differentiating skills. So, for example, I really don’t struggle to put my thoughts to paper. Which sounds really weird, right?… But there’s this trope, “Oh I tried management and it was horrible. I was in meetings all day and I had to write docs all day.” That’s kind of true. I think it’s a very uncharitable take on it, but inevitably a lot of your artifacts are communication, either written, in person, or presenting. And if you hate that, maybe this isn’t the job for you. But I don’t mind that. I actually have never struggled with any of those parts. So that part is not even a thing that I consider a blocker.

The other thing about calling, though, that I can’t really explain really well… the analogy I actually give people is:

So growing up I owned a bunch of guitars. I owned maybe five. And I knew a lot about guitars. I can see a guitar from my desk right now. But the reality is I suck at guitar. And the reason is when I pick up a guitar, I just don’t care that much. As much as I appreciate a good guitarist, I understand a lot about it and I can probably identify what guitar they’re playing. And I like music. But when I sit down to put in the reps of building the callouses and doing the scales and learning the music theory, I just don’t. I never did. It’s just not resonant.

Whereas when I’m in the work of day-to-day management, I really find this intrinsic value in understanding incentives, living out the cultural beliefs that I want to be true in a team. I don’t really mind the long feedback loop. A lot of the pitfalls that I think people don’t like and the main differences between an IC track and a management track are things that I don’t really find that problematic. Ever since I stepped into the function… I like planning. I like making a strategic decision. I like taking a diverse set of inputs. I don’t mind the meetings required to do it. I like understanding the incentives of non-engineering people to help dictate our roadmap. I really like the mentorship aspect. So in that way, it’s really hard to explain resonance, but it just feels better. That isn’t to say I don’t like to code. I was a staff engineer and I did write a lot of code. It’s just if I had to choose, it’s the management track.

My three expectations for my performance

Patrick Kua: Great, Yeah, no, you’re absolutely right. Which is, as you talk about, it gets more generic perhaps. Or more vague. But there’s that sense of more responsibility or accountability associated with that title. And that’s an interesting dynamic because at some point, there’s expectations. So if you’re thinking about your manager, how do you think about, are you meeting their expectations around your job as a director in your role?

… I’m driven by three goals when I think about what I want my managers to get from me. The first goal is: I want to demonstrate excellence in my function. I want to be unquestionably good at what I do. I don’t want them to ever question my competence as someone who is accountable to the business outcomes and the strategic outcomes. Managing up. Managing across.

So there’s the technical stuff. Am I accurately representing our wins and our challenges and our context to the company leadership? Am I taking the appropriate inputs? Am I approaching them with the appropriate strategic context and the data that’s coming in from marketing and strategy and the business side to help drive our roadmaps? When I have the opportunity to speak or to create a written artifact, is that artifact good? So I think that’s a big thing. Do I demonstrate competence and, thus, serve as an exemplar for them, in terms of what does a strong manager look like.

The two sides to the management coin are not only are you good at the technical stuff but are you good at the human stuff, which is critical. Do I manifest the values that I say I care about? Do we have the culture? Does our management sync and the wider syncs demonstrate the psychological safety that I think that I proclaim is critical for the success of a team? So I think that’s a big thing. Am I good at my job?

The second goal is: am I in the work with them? Am I actively coaching them through problems? I recently listened to this podcast by Scott Galloway, who’s this famous person. He was a CEO and he’s a podcast host. He’s an NYU Stern professor… And he talked about how he thinks the two frameworks to think about leaders are the inspirational leader and the player coach. The inspirational leader gets up in front of people and is like, “Here are the reasons why you should work here and why this is a good use of your time.” And thus when the inspirational leader gets on stage, everyone is very excited to work for this company.

The player coach, conversely, is not really about that. The player coach is more, “Hey, you’re making a presentation. I’m really good at presentations. Let’s work together and let me walk you through how to make a really effective presentation.” So for me, I think the inspirational part is kind of embedded in the first component. I want to be good at my job. But the second component, player coach is really important too. I have a lot of experience. I’ve gotten a lot of reps. I want to make sure that when my managers are trying things, I’m able to lend my experience in reps to them to make them better and grow their capability to create a roadmap, or to define a strategy, or even make a presentation.

Then the third component to this is I really want to make sure that I’m sponsoring their career growth. I heard the saying once, “Work for someone who will mention your name in a room of opportunity that you’re not in.” So I think that’s really important. I think the notion of understanding the career goals of my reports and then when I hear an opportunity where someone in engineering leadership is like, “We need someone to streamline onboarding” or “We need someone to streamline incident command,” I can put their name in the hat, if that’s something that’s consistent with their goals.

I can count on one hand the number of times I’ve presented in this meeting over the last three years (maybe… four). 90% of these meetings center around topics outside of Engineering, covering things like product oppportunities, market sizing, revenue/growth, and marketing and operational spend. Occasionally I have an opportunity to inform a decision re: Engineering feasibility, but I spend the majority of my time in these meetings listening rather than speaking. And I don’t mind at all. It has been a fantastic opportunity to gain more perspective about the holistic inputs that drive company direction, and how to best frame topics for an executive audience. These inputs directly inform how I craft the narratives of the initiatives within my scope.

The responsibility of planning the agenda/content of the meeting falls to the VP/Director level. That planning starts weeks before the next meeting, when my cross-functional peers and I begin vetting topics and speakers in response to executive concerns. Closer to meeting day we prepare/critique slides and presentation content. Doing this for several years has solidified my thoughts on how to present to an executive audience.

Packed days of 51/49 decisions

I think about this a lot: executives spend their days jumping between 30/60-minute meetings where they’re repeatedly presented with 51/49 decisions. ¹ Presenters, who have been eagerly anticipating and preparing for these meetings for weeks, perceive these meetings as their most important opportunity to change the company’s direction. To the executive - well, it’s their 8th back-to-back meeting of the day. It sounds exhausting. And while I’ve experienced personally how you can grow your capacity for meeting volume, the reality is as my meeting time expands my tolerance for low-value meetings decreases. I can only imagine how much worse this problem is for someone in the C-suite.

ISC is 60 minutes long. Given what I’ve observed in a multi-executive meeting like this, there are some fun dichotomies to navigate:

• 60 minutes of an executive’s time is very expensive, and even more so if multiple executives are involved. But 60 minutes is also not enough time to solicit in depth discussion from multiple executives on multiple complex topics.
• 51/49 problems are hard to navigate due to their nuance; teams, incentives and outcomes cascade in complex ways. To understand nuance, you must explain details. Explaining details takes time - which you don’t have!
• Your meeting is really important, and the organization’s path forward is contingent upon their consensus on a critical decision. Guess what? The same was true of their previous meeting, which is why they were 5 minutes late. And the same is true of their next meeting, which is why they have a hard stop. In practice your scheduled 60 minute meeting is closer to 55 minutes of functional time.

60 minutes is both a lot of time to ask for and not that much time to operate within. The cost of leaving the meeting without a resolution is extremely high. And due to calendars it is often impossible to schedule ad-hoc follow-ups.

You have one shot. Be intentional about structure, pacing and content to ensure the outcomes you need.

Time the meeting intentionally

Through a lot of observation of what works and what doesn’t, I’ve developed a personal guideline for these 60 minute meetings:

15 minute presentation time and two big topics, maximum.

These constraints prioritize discussion time over presentation time. Because International spans so many departments, our overarching goal is almost always alignment on critical decision points. Alignment across departments requires discussion.

I approach all important meetings (interviews, presentations, ISC) in time blocks. So in theory, if ISC starts at 12:00pm:

• Pre-meeting: Slides/materials are shared ahead of time, critical decision points communicated to set context
• 12:00: People start to join, banter, wait for people who are late
• 12:05: Everyone who is likely to show on time is there; start
• 12:05 - 12:20: Slides - Intro (1min) topic 1 (7min), topic 2 (7min)
• 12:20 - 12:35: Topic 1 discussion
• 12:35 - 12:50: Topic 2 discussion
• 12:50 - 1:00: Recap decisions and action items
• Post-meeting: Email recap email of decisions and action items

In practice I don’t expect to follow this agenda precisely, but it is a sensible basis for planning. Regardless of plans it’s important to be flexible. Sometimes you can nudge a discussion along to fit a timebox and sometimes you can’t; agendas often change in the moment for good reasons. Assume executives will ask clarifying questions. Assume they are very quick at thinking on their feet. Assume they will interject if they disagree. Assume they will poke holes in prevailing theories. And most importantly, assume they have context you don’t. All of these are great outcomes! This is what you want! And if you have 45 minutes of slides, this is what you don’t leave time for.

Make crisp asks

A “crisp ask” to me, in this context, is a request that narrows a problem to a single decision point that only an executive can solve/remedy. It fully clarifies the inputs and tradeoffs of the problem, and contextualizes outcomes in the areas that participating executives care most about - which is often revenue.

Here’s a poor ask:

We can’t get buy-in from teams to buy into our roadmap items. They tend to say no to helping us achieve our goals, despite their presence on the company-wide roadmap. Can you help?

Here’s a crisp ask:

Some teams are caught between these two competing priorities in the product strategy: International and [foo]. As a result, [these teams] are deprioritizing initiatives [A, B] that roll into our International goal in favor of initiatives [C, D] that roll into [foo]. The expected impact of their current priorities is [numbers], but if they were to focus on the International goals their impact would be [numbers]. While both courses of action are justifiable in isolation, we think a focus on International is more aligned to our long-term revenue targets because it will unlock [$X, $Y, $Z] in the medium/long-term. Can you clarify if this tradeoff is acceptable, and if not, clarify expectations with [these teams] around their focus on International vs. other priorities?

The first ask is poor because there are too many unknowns, and no signs of the due diligence necessary to identify the core problem. And this is not the arena for coaching. Frankly if you’re presenting to executives, you should have already pursued the usual workflows of “did you try speaking with their manager?” You should already be solving the 80/20, 70/30, 60/40 decisions that come across your plate. Bring the 51/49 problems you can’t solve without executive authority.

The second ask is crisp because it provides critical context. It’s not an overly simplistic take implying that people are being stupid or lazy. Instead it communicates how and why various teams, acting in good faith, cannot proceed without clarity or decisiveness, and why navigating the tradeoffs are not obvious. It speaks to the unintentional creation of competing incentives. And it states the outcomes in terms of quantifiable future revenue.

The Ask is more important than the Narrative

As my reporting chain can attest, my first question when coaching someone through delivering a presentation is always, “What is the narrative of this work?” Because the secret to nearly all effective presentations is telling a compelling story. The most common arc: the pain points that created a need for this work, lessons learned through implementation, and the opportunities unlocked after delivery.

I say “nearly all presentations” because my advice for delivering a presentation to a room of executives is the opposite: don’t deliver a narrative. Deliver the crisp ask first, and focus on data versus a story.

This is for a few reasons:

1. You don’t have the time for a story.
2. Reiterating a previous point: executives have context you don’t. They often already know your story, or know why it’s not the real story.

So in terms of slide construction:

1. Present the crisp ask first.
2. Triage the remainder of your presentation to the most important, data-driven points that fit into your time constraints.
3. Create slides in an appendix for all other supporting data and context. Assume you won’t present these slides, but have them available if you need to clarify anything during the meeting.

When I think about it, I don’t find this point that unintuitive. If you’re very senior, have you ever listened to a presentation where you could quickly guess the crux of the problem and solution in the first five minutes? But the presentation is actually 25 minutes long?

Narratives are great at educating and inspiring, which are major goals for larger audiences. But for a very experienced, targeted audience where time is expensive? Get straight to the point. If the problem doesn’t fit into one of their existing mental models, they’ll tell you.

Grab bag of reasonable questions

What if you have three really important topics?

Sorry - it doesn’t work. Prioritize your two most important outcomes/decision points and triage the third for a subsequent meeting / email.

What if there’s one topic that requires an explanation of deep/nuanced context?

Great - you have one meeting topic that day. You can stretch the presentation content to 20min and extend the discussion time.

I’ve personally used this format to explain engineering/feasibility rationale wrt headcount, which involved walking a predominantly non-technical audience through technical constraints and outcomes. This was one of the rare executive presentations where a narrative was valuable because the content was so far out of most of the audience’s domain expertise.

What if you only have 30 minutes?

Your presentation time is reduced to 5 minutes, 1 topic. Remember: you’ll still start the meeting 5 minutes late.

Footnotes

51/49 Decisions

I’m a little surprised I can’t find a better link representing “51/49” decisions, which is a thing Chad Dickerson would speak about at All Hands while he was the CEO at Etsy. This article, despite being covered in ads for things I will never buy, is surprisingly substantive re: Obama’s decision making framework for choosing between alternatives with poor tradeoffs:

1. Listen to the people who will be most affected by the change.
2. Realize there’s no right answer – it’s about weighing the odds.
3. Seek out the naysayers.
4. Get outside the ‘bubble’ of people who are ‘supposed’ to advise you.
5. Test your B.S. detector.
6. Insist that people deliver bad news quickly and are not punished for honest mistakes.

“People used to ask me, Why was I calm during the presidency? In addition to being from Hawaii, which really helped (we’re just chill),” he joked, “part of the reason is I set up processes. So by the time I made a decision, I might not get the outcome I wanted, but it might be a 51-49 decision, or a 60-40 decision, but I can say I heard all the voices involved – gotten all the info, seen all the perspectives – so when I made decision, I was making it as well as anybody could make it.”

Let’s take the idea of balance.

So no surprise, we all have a natural and intuitive understanding that negative information carries a lot more impact and weight than positive information. So even when I think you’ve done a lousy job, I’ll normally start it with some throwaway like, “Oh that went pretty well, you really worked hard at that, you know the audience seemed to really like like that one piece… “

You’ll start out with some softening of the blow, because number one you you want people to hear you, but number two you naturally know that if you go negative to start people withdraw: they shut down, they don’t they react, they do all kinds of things.

Most feedback and criticism — most of it other than praise and flattery and so forth — has a negative tinge to it. When you’re trying to improve people’s performance you’re giving them at least constructive criticism around, “try this differently,” “do this,” and so forth. We know that the negative and the positive are very different and because we know the negative is overweighted — it’s called the negativity effect — so we naturally buffer almost everything we say. We start with a little bit of positive and then we offer a little negative and then we get to our negative.

Now if I do that consistently - if I give you one little positive and then I give you my four criticisms — the balance is not there. It’s actually out of balance.

Let’s take an example of a presentation. I’m just gonna make it up off the top of my head, but let me give you two pieces of feedback on a presentation.

My first feedback goes:

”Hey, the presentation went pretty well, I think. The audience was engaged. But listen:

You know your slide in the deck - slide 10 - it was not really understandable. And slide 15 confused everybody. I didn’t think you tied the introduction to your conclusions so you lost people at the end. When you got to Q&A you started out okay but boy you were really flat footed on the second question - your answer was really weak - and I thought the audience was not as responsive at the end as they should have been across the presentation.”

And you’re thinking, “Wow - okay, I mean, you really thought the thing went okay and that the audience was engaged? I don’t remember that but I remember you just crapped a lot on everything I just did.”

Let me give you the same feedback but in balance. So instead the leader says to you:

”Listen, I think the the audience was engaged across your presentation. I think it went pretty well. I want to tell you that I never saw slide 8 before and I thought it was masterful - I thought you took something really complex and made it simple. I thought before you got to Q&A, when you reached your main point, I thought that you hit it hard several times to the point where it resonated with the group. I think they were excited to get to Q&A to ask you questions.

I thought you started out Q&A really well, and I believe that your answer to the fourth question, which was the hardest question of all around why we do what we do, you just hit it out of the park.

Now let me be critical on the other side. Your slide five was indecipherable - we’ve got to do something about that. Your slide 10 really took something that was complex and made it even more complex. I didn’t think you tied the introduction and conclusion nearly strongly enough. I thought when you got to the Q&A your second answer to the second question was really flat-footed and really left people wanting. And I think overall people could have been a lot more engaged if so some of those things were fixed.”

That’s an example of the difference between feedback in balance versus feedback being totally out of balance. Because I don’t know anybody that wants the first one (there are a lot of people that don’t want the second one either, by the way), but if you really want to get better, you want the second one, and you can deal with the balance of it.

So what did we learn? The behavior is not just about being in balance; it’s about how you’re in balance.

And when we study the best leaders on the planet, they all do the same thing. They all start positive, just like we all do intuitively when we’re going to be critical, but their positive is as vivid, elaborate and as detailed as the negatives, and they generally match in terms of number. So if I’m going to give you five criticisms, I probably need to have three, four or five really positive things. But they can’t just be at a level of vividness or detail that is not equal. So I’m going to start positive and I’m going to go as deep into that positive as I can.

I tell this to leaders all the time, and they’ll say, “well I have five criticisms but I only have one really good positive that I can focus on.” I tell them: stretch yourself. See if you come up with two. But more importantly, they’re only ready to hear two criticisms from you right now.

I often find that when I’m asked to review something - e.g. before a key presentation or sharing a document with a wider group - I engage the most critical and nit-picky parts of my brain. While it’s an exercise in good faith towards the author’s good showing, it does mean I’m in the headspace of looking for what what’s wrong instead of appreciating what’s done well. And that’s not great - to Stutman’s point, habitually glossing over positive feedback in service of delivering critique has the particularly bad outcome of making both positive and negative feedback less meaningful. Given the currency of trust, approaching feedback in the appropriate balance feels like a better strategy towards maintaining positive work relationships.

Delivering feedback is one of those “soft” skills that makes the transition to management difficult. Personally I’ve found a lot of guidance in Lara Hogan’s Feedback Equation, and I used the content of that post in the creation of a talk at LeadDev Together 2020: “Growing Teams and Culture with Actionable Feedback”. The key takeaway from that talk speaks to the same conclusion from Randall Stutman: the mark of successful feedback is in its reception, not its delivery.

“Hey, you’re a programmer right?”

Yeah.

“I have a great idea for a social network - I just need someone to build it. Are you available? Split it 50/50?”

The ensuing eyeroll and punchline, of course, was that the act of building an app / social network is significantly more than 50% of the job than having an idea for one. In the immortal words of Jesse Eisenberg, “If you guys were the inventors of Facebook, you’d have invented Facebook.” Ideas are cheap, execution is everything. Obvious, right?

But Richard Rumelt, author of Good Strategy / Bad Strategy, wrote an entire book about the fact that companies often operate this way:

Executives who complain about “execution” problems have usually confused strategy with goal setting. When the “strategy” process is basically a game of setting performance goals — so much market share and so much profit, so many students graduating high school, so many visitors to the museum — then there remains a yawning gap between these ambitions and action. Strategy is about how an organization will move forward. Doing strategy is figuring out how to advance the organization’s interests. Of course, a leader can set goals and delegate to others the job of figuring out what to do. But that is not strategy. If that is how the organization runs, let’s skip the spin and be honest — call it goal setting.

To illustrate this further, I’ll include my favorite excerpt from the book: the story of Rumelt’s consultation with Chad Logan, the CEO of a graphic arts company: GSBS: Chad Logan. ²

Rumelt speaks to my core takeaway from the book in the following quote:

Many people assume that a strategy is a big-picture overall direction, divorced from any specific action. But defining strategy as broad concepts, thereby leaving out action, creates a wide chasm between “strategy” and “implementation.” If you accept this chasm, most strategy work becomes wheel spinning…

A good strategy includes a set of coherent actions. They are not “implementation” details; they are the punch in the strategy. A strategy that fails to define a variety of plausible and feasible immediate actions is missing a critical component.

Plausible and feasible actions

My two favorite words in this quote are “plausible” and “feasible.” These two conditions give the entire premise of Good Strategy its punch.

When a company wants to build a thing, there are two arenas of feasibility to consider: technical and organizational. The easier arena is technical feasibility: do we have the people, skillsets, and software/hardware to build it? I’m not saying this is easy, but it’s easier, because it can be scoped and bounded with objective facts: headcount, tooling, metrics, project breakdowns, etc.

The harder arena is organizational feasibility: do incentives align across all relevant stakeholders to prioritize this thing being built? Do the accountability structures exist to prevent teams from deviating from that alignment? Is someone able to break the ties between competing priorities? Organizational feasibility is more difficult because the barriers are less visible - blockers are due to people and political realities that are often left unspoken but nonetheless inhibit work.

Good strategy addresses both. Most strategy starts with a breakdown of work into workstreams, but that’s only the tip of the iceberg. Good strategy identifies technical and organizational blockers, acknowledges which can and cannot be resolved, and evaluates realistic alternatives in the midst of those challenges. An alternatively good ending is to conclude that workarounds are not possible and thus work should not be started in the first place.

The writers of good strategy - both ICs and managers - must be in the work enough to know the difference between implausible and plausible actions. Being in the work is absolutely critical. When you craft outcomes disconnected to lived realities you might as well be writing a wish list. And when leaders are in the work, it prevents pushing the work of overcoming these blockers down the organizational hierarchy to people and teams that increasingly lack the authority to do so. ³

The Kernel, and PTO Handoff documents

The most famous takeaway from GS/BS is “The Kernel,” or how Rumelt defines the three components of good strategy:

1. Diagnosis
2. Guiding Policy/Policies
3. Coherent Actions

I’ll define The Kernel via an example of using it to create a process in real life: PTO Handoff documents.

During the earliest parts of the Covid lockdown in 2020 it was clear many of us were struggling mentally and emotionally, and I wanted to make sure my team felt like they could take necessary mental health breaks from work without the cost of dropping important work in flight. I’m happy to report that my teams still use PTO Handoff documents today.

Diagnosis

Defines the challenge. What’s holding you back from reaching your goals? A good diagnosis simplifies the often overwhelming complexity of reality down to a simpler story by identifying certain aspects of the situation as critical.

As a manager I want to ensure teammates manage their own mental health appropriately, and given work’s flexible PTO policy, take whatever PTO they need in order to do so. However, when people went on PTO the team’s output was impacted negatively, as commitments and coordinated efforts were unintentionally dropped.

Guiding Policies

An overall approach chosen to cope with or overcome the obstacles identified in the diagnosis. Like the guardrails on a highway, the guiding policy directs and constrains action in certain directions without defining exactly what shall be done.

1. I’d like to ensure that teammates explicitly consider and communicate work in flight / work to be handed off before going on PTO.
2. I’d like to ensure on-call rotations are handed off by those going on PTO.
3. I don’t want creating a PTO doc to feel so overbearing that it disincentivizes their use. I don’t want the writing the document itself to feel like too much work, and I want the criteria to qualify for the doc to feel reasonable.
4. I want discoverability of PTO documents to be easy for any remaining team members who may need to reference them.

Coherent Actions

Dictate how the guiding policy will be carried out. The actions should be coherent, meaning the use of resources, policies, and maneuvers that are undertaken should be coordinated and support each other (not fight each other, or be independent from one another).

1. Create a PTO handoff document by duplicating and editing an existing template in a specified Google Docs folder.
2. All PTO handoff documents follow the same naming format, meaning there’s semantic meaning to the contents of the folder and it’s easy to scan for PTO docs based on date.
3. PTO handoff documents are required to be shared before going on PTO >= three days.

PTO Handoff Template

For the curious, the final PTO Handoff Template.

Footnotes

Sometimes I struggle to fill the time of 1:1s with my direct reports. With some of my reports the conversation flows naturally, or they drive the conversation by talking about what they’re working on or the problems they’re facing, but for other reports the conversations are often full of silence. I’m often waiting for them to say something but they don’t.

Should I be expected to drive the content of these 1:1s? And if they regularly don’t have anything to say, what do you think if I instead made them elective/ad-hoc?

Short answer: Keep regular 1:1s. A weekly 1:1 ¹ is critical to building trust and context, and elective 1:1s are unlikely to be used until there’s a fire. A regular 1:1 allows you to smell those fires ahead of time, which is a critical part of the job. And yes, you are expected to drive the content in the absence of the other person doing so.

The importance of regularly scheduled 1:1s are rooted in a few lessons:

1. Regular availability is critical for a healthy management relationship. ² The best way to understand someone - their context, their motives, their preferences - is to spend consistent time together. The times I’ve felt most frustrated by a manager is when I felt unacknowledged due to a persistent lack of responsiveness. Regularly rescheduling or cancelling 1:1s, regardless of the reason, unavoidably communicates that someone is not a priority. ³ The currency of challenging management conversations is trust, and the backbone of that trust is being available and responsive.
2. Management calamity often snowballs quickly. A pattern I’ve seen often is that when people are upset about something, they stay quiet until it reaches a breaking point, after which their frustration spirals. It is much harder to bring someone back to a good place post-spiral than pre-spiral.

The currency of trust

While I don’t love characterizing management relationship as transactional, what I mean by “the currency of trust” is that management behaviors either “bank” or “spend” trust. You bank trust when you demonstrate behaviors that show a report you’re in their corner: sponsoring them for an opportunity, helping them navigate a case for promotion, or supporting them through challenging circumstances. You spend trust when you deliver bad news: the constraints of a difficult economic environment during comp time, the need to delegate some unglamorous glue work, or sharing some critical feedback. The good reception of bad news is often predicated on how much the receiver of that news trusts the intentions and character of the deliverer of that news. Regular, good faith 1:1s are an exercise in banking trust.

Don’t offer to cancel

Something I’ve learned not to say to a report: “Hey I don’t have anything to talk about today, are you good to cancel?”

While it’s dependent upon personality, I find that in most cases the power dynamics implicit in reporting structures means that it’s likely a report will say yes to this request, even if they do have something to talk about. Consequently I’ve developed a personal rule to never preemptively offer to cancel a 1:1.

I think the same question in the other direction is fine. And if in the course of conversation we run out of things to talk about and mutually agree to end early, that’s also fine. But I want to leave either situation confident that I’ve given the opportunity for the other person to voice what’s on their mind.

Driving content

While many reports will drive the content of 1:1s without prompting, some don’t. It just happens. And in these cases the responsibility of driving content falls on the manager. Assuming you’re going to manage a variety of personalities across a career, this is a skill worth cultivating.

When conversations go stale in 1:1s, a common reason is that the topics at hand are too limited in scope or time horizon: “the work is chugging along and nothing is wrong right now.” To break from that my strategy is similar to my strategy for conducting interviews: ask a lot of questions. I zoom in: how they feel projects are going, what skills they’re developing, what the pain points are, what could go better, etc. I zoom out: how their work aligns to career goals, feelings about changes in team/company strategy, what their growth areas are, etc. I share my own opinions of things I’m excited about or disappointed by and ask for their takes. And I do my best to actively listen so I can follow up to any responses with new questions.

It can also be helpful to set expectations around 1:1s via a framework of topics. Jean-Michel Lemieux, the ex-CTO of Shopify, shared his framework on Twitter where he splits topics for meeting with his reports into three general categories:

1. 25% Boss: Keep accountable for goals, quality, and growth
2. 50% Peer: Bring decisions and get my feedback, let’s brainstorm. I’ll share what I’m up to as well.
3. 25% Work for you: Given your goals, how can I help you?

I’ve literally pasted the tweeted graphic at the top of 1:1 docs. Not because I expect to follow it to a tee, but because it serves as a reminder to both me and my report about the type of topics we should be bringing to our recurring meeting.

Footnotes

There are two types of effective leaders or managers.

The first is the “inspiring leader.” They can stand up in front of a group of people and distill down the North Star: this what we’re here to do, this is why you are here to do it, and this is why this is the right place and right time for you to be here right now. And it gives people a sense of connective tissue that they’re here for something bigger, and it says to them, “when you show up here, you are appreciated, and it was a smart decision to be here.” And they can paint a really exciting future.

Then there’s the “player-coach.” That person is so good at what they do, and takes a vested interest in other people’s success. My partner at my business, Katherine Dillon, is a player-coach. If someone is editing a document, she takes her chair and sits next to this person and says, “I’m going to show you how to edit a document. This is good, but this is where you got it wrong.” And she’s kind but very direct, and she teaches people to be much better players.

I’m the inspiring leader - I like getting up in front of a group of my employees and painting the vision. The inspiring leader is effective over the short term but not usually the long term.

The player-coach point reminds me of this excerpt from a blog post by Will Larson (”Grab bag of random thoughts”):

There are a number of executives out there who are very good at some things, but lack the flexibility to operate in varied environments. Sometimes this is because they are stubborn, and have a specific working style that they insist on following independently of the company. Another major contributor, in my experience, is executives who lack experience working in middle management.

Middle management is, of course, something that people often view as fake work, but it’s the critical work of translating an executive’s stated plan into a series of real plans that the company can actually implement. Executives who don’t understand this are doomed to create systems and processes that impede organizational execution, often screwing things up while claiming to improve organizational execution. Based on my experience, I don’t think you can be an excellent executive at a scaled (or scaling) company without middle management experience. ¹

I’ve seen many people become frustrated in the middle manager role (full disclosure: I am a middle manager) but I agree with Will that the reps are valuable. The challenges of the middle manager role are real: managing up and managing down, being further away from implementation details, needing to bridge the gap between an executive’s desires and pragmatic realities, etc. But assuming you have goals to continue to climb the career ladder, how else do you expect to coach and grow middle managers in future roles without this experience? The reps breed a deep empathy for what works and what doesn’t, which allows you to step into a role as a player-coach when it’s appropriate.

The notion of player-coach also speaks to the crux of what I mean when I say engineering managers must be technical enough to intervene. Honestly, my coding skills are stale - I haven’t meaningfully contributed production code in years, and the JavaScript zeitgeist changes every 10 minutes. But because I’ve spent years shipping complicated changes to production I have a lot of smells around things like rollout plans and the difference between real technical due diligence and lip service. Because I’ve spent years authoring technical roadmaps and documents like RFCs I can guide my teams through authoring their own. It’d be impossible to coach my reports through this work if my opinions weren’t rooted in meaningful reps.

One nuance in improving as a manager is minding the gap between being a player coach and a micromanager. The goal is to distinguish between showing someone how to do something versus doing the work for them. One strategy I use: I think it’s most productive to coach someone through improving an artifact they’ve made the first version of alone. For example, if I know someone is an inexperienced public speaker and wants feedback before presentation delivery, I’ll ask them to present at a dry-run the week before. Then I’ll duplicate the slide deck and coach them through any potential improvements using their slides as a baseline. ² The same goes for RFCs, engineering-all emails, etc. And then I give less oversight the next time, with the caveat that I’ll intervene if I need to.

I’m less sure about training the “inspiring leader.” I think you can absolutely become a better public speaker, which, like many things, gets better with practice. And I think it’s important for leaders to cultivate that skill. But inspirational public speaking is 90% message and 10% delivery. One question I ask often: “what’s the core narrative behind this work? Why should this matter to someone who is not you? How does this become a story of problems and outcomes and less about technical detail?”

An inflection point for me was when I realized that all of the best talks / podcast interviews / etc I’ve ever heard were stories. Inspiring leaders are storytellers, and even your frontend JavaScript build library upgrade has a compelling story. And that story is not a retelling of the Jira tickets, but rather the story of the before and after. What were the unexpected learnings? What were the hardest parts? That’s what stays with people.

I like the Galloway quote because it succinctly identifies the two aspirational qualities I often find myself admiring in others: the ability to stand up in front of a group of people and rally their enthusiasm behind shared goals/values, and the ability to scale execution across people and teams with a carrot and not a stick. Thinking about these two qualities helps me frame my own work by thinking about how I conduct myself, what I say yes to, and how I find opportunities for those who report to me.

Footnotes

“What do you do every day that’s the equivalent of a musician practicing their scales?”

The list of his podcast guests spans a wide variety of industries and domains, from business leaders to authors to tech workers to philosophers. The premise of his question is rooted in the idea that like athletes, knowledge workers should train. A quote from that blog post (via David Perell):

Athletes train. Musicians train. Performers train. But knowledge workers don’t.

Knowledge workers should train like LeBron, and implement strict “learning plans.” To be sure, intellectual life is different from basketball. Success is harder to measure and the metrics for improvement aren’t quite as clear. Even then, there’s a lot to learn from the way top athletes train. They are clear in their objectives and deliberate in their pursuit of improvement.

Knowledge workers should imitate them.

This begs the question: can you “train” to become a better engineering leader?

What is there to train?

As an Engineering Director I view my primary responsibilities to include:

1. Sponsor career growth for my managers and their ICs
2. Establish the incentives and behaviors of a just and equitable culture
3. Help create and evangelize the narratives of our work
4. Align and communicate the work of my teams Up, Down, and Across
   1. Up through the senior/executive levels of the organization
   2. Down through the teams in my organization
   3. Across through the PED (Product/Engineering/Design) triad and other sub-organizations within Engineering

None of these skills are imminently “trainable” like an athlete running on a treadmill. When I zoom out from that list of responsibilities, I see a few themes: coaching, building culture, and understanding the mechanics of how companies execute. My “training” goals are less for repetition or practice and more seeking inspiration: stories I can learn from and share, strategies that have proven successful in other contexts, and lessons I can internalize to make performance in my job more sustainable.

General James Mattis ¹ has a famous quote that I like:

“If you haven’t read hundreds of books, you are functionally illiterate, and you will be incompetent, because your personal experiences alone aren’t broad enough to sustain you. Any commander who claims he is ‘too busy to read’ is going to fill body bags with his troops as he learns the hard way.”

A pretty hot take. I’m happy to work a job at lower stakes than General Mattis.

But the message he’s making here is that even his challenges on the battlefield, while infinitely contextual, are by no means “new.” Humans have been learning the lessons of leadership for thousands of years. It feels ludicrous to him to rely on “learning lessons the hard way” rather than investing time to learn from the similar experiences of others.

In this season of my life I have some constraints (see: two young kids) that eliminate time-intensive alternatives like academic coursework or outside-of-work professional development programs. But in the scope of my bandwidth I’ve found a few sustainable means of investing in my own growth.

A recent list:

• I loved Good Strategy / Bad Strategy so much that I’m reading through it again with my reporting managers. It’s a surprisingly approachable and easy read given its subject matter, and I find Richard Rumelt’s transparent critiques of bad strategies hilarious. I’d like to write a blog post about my takeaways from this book, but if I had to summarize it in a single sentence: “true strategy is not a statement of your ambitions, but an outflow of how you’re actually going to get there given the reality of what’s holding you back.”
• Because they allow me to multitask during chores (note: my non-work life is chores), I like to fill the empty headspace of rote work with podcasts. One of my podcast life hacks is to search Spotify for interviews from authors / leaders that I admire. The best thing about author interviews is that they inevitably summarize and expand on the critical takeaways from their books. Some interviews I recently enjoyed:
  • Radical Candor: Kim Scott, via Wisdom from the Top with Guy Raz. I loved the anecdote about when Kim Scott received feedback from Sheryl Sandberg around her public speaking. Kim Scott is also just a fantastic interview.
  • 253: Richard Rumelt, How to solve the crux via The Strategy Skills Podcast. A nice followup listen shortly after reading the book.
  • Spend Time on What Matters with Will Larson CTO @ Calm #30 via The Engineering Leadership Podcast. The thing I admire most about Will is how obvious it is that he spent meaningful time in the work as a frontline manager, deeply understands organizational and managerial dysfunctions, and now uses his elevated titles to find ways to systematically address these problems. The guy just gets it.
  • How much to invest in platform work - Jean-Michel Lemieux (Shopify, Atlassian) via the Engineering Enablement Podcast. I’ve always enjoyed and learned from Jean-Michel’s tweet threads around engineering culture and leadership, and platform engineering (specifically related to DevEx and build tooling) is a topic near and dear to my heart given my experience working on frontend build tooling. The focus on DevEx at Shopify is really inspirational, and it’s clear it started from the top.
  • #96 Randall Stutman: The Essence of Leadership via The Knowledge Project Podcast. There is an incredible point in this episode about the importance of balancing negative and positive feedback (the presentation example) that will stick with me forever.
• I subscribe to a select set of email newsletters that I actually read:
  • Lara Hogan’s Newsletter at Wherewithall
  • Irrational Exuberance - Will Larson’s Blog
  • Software Lead Weekly by Oren Ellenbogen
• Earlier this year I was fortunate to participate in an orbital.nyc Director Studio, which was a small (in my case, five person) manager den of Director-level leaders across tech companies. We met once a week for five weeks to discuss challenges, strategies, wins and losses. My group was lovely, and we’ve even met after our program’s conclusion to check back in on each other.

I’m surprised how often I speak to managers that don’t look for external sources to improve their performance on the job. I suppose the alternative is to rely on personal experience or coaching from their manager. But in the spirit of one of my favorite pieces of management writing, it feels like a loss to constrict your growth to circumstance. What if your role is limited? What if your managing relationship is poor? Neither are good reasons to limit your personal development.

Footnotes

In his book “The Hard Thing About Hard Things,” ¹ Ben Horowitz (of Andreessen Horowitz) articulates the dichotomy in a startup CEO’s behavior in favorable vs. unfavorable business conditions as “peacetime” vs “wartime”: Peacetime CEO/Wartime CEO. I think it’s reasonable to say that as a result of economic conditions that were extremely favorable to the tech industry ² over the last decade+, most of our collective memory lives in peacetime. But as a result of rising interest rates, declining post-COVID growth numbers, the rise of LLMs and increasingly expensive lock-in to publicly-traded SaaS vendors, peacetime is becoming less peaceful. Every new layoff announcement mentions renewed investments in efficiency and execution, and the market demands both growth and revenue.

As an IC, each time I heard this request I didn’t understand what the expectations were in terms of changing my behavior. Create more tickets? Have fewer meetings? Work more hours? It didn’t feel like any of these activities would actually contribute to stronger outcomes, and engaging in productivity theater is extremely demoralizing. It also doesn’t take many long nights or weekend hours to breed irreparable burnout. Consequently the prevailing sentiment myself and many of my peers felt was panic. And panic is a terrible state of mind for timely, strategic execution.

The plea to “act with urgency” would have probably been more precisely phrased as “ship more code,” and it felt like it carried a veiled permission to eschew typical process and bureaucracy to unlock everyone’s inner Herculean effort to turn the ship around. And to be fair this advice probably makes sense at startups or small companies that are often built by individual Herculean efforts. But at mid-to-large sized companies operating within complex and intertwined systems, engineers frantically committing code without coordination or planning ultimately generates more problems than it solves. There is a tremendous amount of required context to keep these systems running beyond the obvious, happy path.

Requests for things like “urgency” often fall flat because they don’t speak to the actual barriers of what makes outcomes fast or slow. These include poorly defined or changing product requirements, too much cross-team collaboration, a developer experience with slow feedback loops, etc. It’s rarely raw effort, but it’s an easy scapegoat.

In my experience the ability of teams to execute in wartime is a function of their diligence in peacetime. Some thoughts about teams, their construction, and the potential to increase pace:

To ship faster, you must ship in the first place.

A common scenario: a team in a critical but stable path doesn’t have a track record of shipping regularly. Due to nascent/favorable business conditions it never mattered much - the business grew regardless of what was (and was not) shipped. Suddenly business conditions change and the team faces pressure to execute work quickly. But because they don’t already have the process or norms to define and execute work, they struggle to fulfill their new mandate and chaos ensues.

The most important indicator of team health is shipping regularly. And getting a team to the point where they ship regularly is the long game of clear product direction, process buy-in, and discipline. An urgency mandate reduces these mechanics to a switch, and I’ve yet to witness a team suddenly “turn on” performance when they didn’t already have a track record of it.

My suggestion for managers is to always take team culture and performance seriously, and promptly address issues as they arise during peacetime.

One way I’ve seen this blow up is the case of the toxic or underperforming teammate. Negative performance conversations are one of the most confrontational and uncomfortable parts about a manager’s job, and when you add on legal considerations (documentation, performance improvement plans, etc) they can be a tremendous investment of time. It’s often tempting for managers to work around or even ignore these problems rather than address them.

In peacetime they might be able to put this person on a secondary project, limit their involvement in certain meetings, or cover for their failures with additional staffing (these are all smells!). But a situation of urgency and rapidly changing headcount will throw oils on these fires, and issues that were once an inconvenient but tolerable disturbance will suddenly become a threat to the rest of the team’s continued employment. The last place any employee wants to be is on a team with a reputation of poor output or toxicity when the business is critically analyzing its costs.

The Mythical Man Month is much less painful for teams who have a defined onboarding process.

Declarations of urgency often precede a re-org where coworkers are moved from lower to higher priority workstreams. Teams in critical paths can suddenly find themselves with new headcount in an effort to increase development speed, which is in stark contrast to the Mythical Man Month (MMM).

This is a tough scenario for a few reasons. In terms of output, the MMM is very real - building shared context takes time and is inevitably a cost to short term productivity. In terms of people, the worst side effect of re-orgs is the loss of managerial career context. Peacetime investment in onboarding process helps mitigate both. Some guiding questions:

• Is there an up-to-date onboarding document that is as self-service as possible?
• Does your team write documentation around its ownership and ceremony?
• Is there a defined backlog of work with new-hire tasks already allocated?
• Are you performing 1:1:1 manager handoffs between the new manager, old manager, and the transferee to ensure they can advocate for themselves and maintain career context in their new role?

Going faster forces intentional tradeoffs about risk. Ensure those are well understood!

A team’s output speed is bottlenecked by getting defined, prioritized work into the hands of ICs as fast as possible. This process is often slow because understanding priority requires a lot of inputs.

The stages of a software planning process exist to ensure your team is building the most important thing despite a universe of competing priorities and constraints. User Research validates customer assumptions, A/B testing validates product and technical assumptions, test plans validate resiliency assumptions… these are all valuable guardrails that take time to mature.

One of the main levers for increasing output speed to remove some of these guardrails. Maybe you engage in fewer customer interviews when performing product discovery. Maybe you ship something to production with a weaker QA pass. You likely need to cut some product and technical scope.

In an environment where you are suddenly prioritizing delivery speed over confidence, make sure these tradeoffs are well understood by all. I recommend writing the decisions and impacts into a document, and aligning on them upward and with product / engineering / design leadership. Situations demanding urgency are often emotionally heightened, but there is a very real opportunity cost to eliminating guardrails. You want to take steps to avoid a situation where you cut scope in service of pace, consequently delivered the wrong thing, and can’t explain how and why you got there.

In summary I’ll borrow another phrase from The Hard Thing About Hard Things: “there are no silver bullets, only lead bullets.” Appealing to effort feels like grasping for a silver bullet when only the lead bullets of well-oiled process are relevant. Going faster is an optimization over existing performance. As a manager/manager of managers, if you’re only concerned with team pace and execution during wartime, you’re probably too late.

Footnotes

tl;dr: Use https://slack-copy-paste.danielna.com to copy/paste Slack messages as plain text. It’s not perfect, but it’s a better starting point than copy/pasting text from the application directly.

Background

One recurring annoyance is that it’s difficult to copy/paste conversations from Slack, which is most useful when trying to keep a record of key discussions in Jira or Google Docs. The app does not provide an affordance on its own to export a chunk of text as plain text, and if you’ve ever attempted the highlight -> copy -> paste workflow from Slack before you know what I’m referring to - a lot of line breaks, objects mashed together, the capturing of emoji reactions and counts, etc. It’s no different than attempting to copy/paste complex UI elements within an HTML page, which makes sense because Slack is an Electron app. The text isn’t meant to stand alone outside of the UI treatments.

Here’s a screenshot of a conversation and its raw copy/pasted text:

The raw pasted text:

Dan Na
  9:08 PM
Hello this is a test!
:tada:
1



Dan Na
  9:08 PM
:broom: Clean these messages
:+1:
1


2 replies
Last reply 9 days agoView thread


Dan Na
  11:22 AM
I wish I could cleanly copy/paste the text from this conversation into another document! (edited) 

Lots of line breaks and items on new lines. Here’s what this text looks like after running it through my script:

Dan Na 9:08PM
  Hello this is a test!
  [Reactions] :tada: +1

Dan Na 9:08PM
  :broom: Clean these messages
  [Reactions] :+1: +1
  [Thread] 2 replies, Last reply 9 days ago

Dan Na 11:22AM
  I wish I could cleanly copy/paste the text from this conversation into another document! (edited) 

If you select all of the current cleaning options (removing emoji reactions, threads, and joined room notifications), the script removes some more items:

Dan Na 9:08PM
  Hello this is a test!

Dan Na 9:08PM
  :broom: Clean these messages

Dan Na 11:22AM
  I wish I could cleanly copy/paste the text from this conversation into another document! (edited) 

Not perfect, but decidedly cleaner! It also generally works with threads, although the intersection between room/threads needs to be composed manually.

I wrote a disclaimer on the page about the state of the script (in short: it is brittle for many reasons and there is a surprising amount of state in Slack that I inevitably am not accounting for) but you can still edit the output in the second text box before copy/pasting for your own needs. I also cannot guarantee it will work with future Slack UI changes, as a previous iteration of this tool I wrote two years ago became obselete.

A small, utilitarian side project that scratches the occasional itch of wanting to code a solution to a problem. Hopefully it helps someone!