2025-06-02 14:59:22
As people become managers, it’s quite common for their team members to want to commiserate with them. This is especially true for friendly, competent, reasonable-seeming managers – people want to commiserate with winners. This makes commiseration extra dangerous, as it comes with a hint of flattery (“I respect your opinion and trust your discretion”).
But commiseration, especially with your direct reports, is organizational poison. It erodes the fabric of an organization and builds factions. It leads to feelings of superiority and creates a low-trust environment – even if what you’re complaining about is made up! Worst of all, it doesn’t give other teams an opportunity to improve. If I think that HR sucks, and I commiserate with my directs about it, my team is going to treat them poorly. HR will never know why, will never fix the problem, and will just think that my team are jerks (and they’ll arguably be right). Commiseration is self-fulfilling because it’s a form of victimhood: The world is conspiring against us, the only truly virtuous team.
Commiseration comes naturally to most people, because it happens all the time in real life. As your best friend, if you come to me saying that you were just dumped by your girlfriend, you will get unconditional sympathy beyond words. You’re the best, she didn’t deserve you, you can do so much better, everyone knows you’re the man, I have no idea why you ever spent time with her. There will be no questions, there will be no need for you to explain anything about the situation, even if all you did for the last 2 years was sit on your couch smoking weed and playing Warzone, Greg. Unless you did something totally crazy or illegal, my loyalty will be immediate and unconditional, because – let’s be real – none of it matters. You’re going your way, she’s going hers, and it’s over.
As a manager, your empathy needs to be highly conditional. Your job is to get to the truth of a matter in a respectful way, not make your team feel good. You are largely stuck with your coworkers, and you need to get stuff done together or everyone suffers. If you break up with your girlfriend you get unconditional sympathy. But if you break up with your girlfriend, and the 3 of us were trying to climb Mt. Everest together, I’m going to be a lot more measured in how I communicate and balance your relationship so that we can all survive the next few days.
Commiseration is generally a sensitive topic, so I’ve tried to boil down how to handle situations when a direct comes to you with grievances via some heuristics:
Of course sometimes people really are AAA grade idiots. When this happens, your communication should typically address the issue, not the other team. For most situations, it’s best to say “let me follow up,” rather than “I agree that they’re dumb.” In particularly egregious cases, you can go with “I know this is a problem and I’ll get on it” or “I hear you, I’m working on it, but I can’t give you every detail on how and don’t expect ongoing updates” – this avoids gaslighting them that everything is fine, but it also stops the vent session. When the door opens to commiseration with your team, you must slam it shut.
Either way, following up is the ideal next step because it commits you to respond but separates the emotion from the action. Accumulated strong emotions leave a strong impression, especially when they’re negative emotions like bitterness, so it’s best to suck the emotion out of the conversation as fast as possible. For evidence of this, light autists often make very effective managers.
Finally – we’re all human here, and sometimes you need to commiserate with someone before your head explodes. If you must commiserate, it’s almost always best if they’re a peer / near peer, and they’re not on your direct team (you don’t share a boss). This at least dodges the situation where a manager complains alongside their team, and thereby implicitly blesses their most negative views.
2025-05-26 14:59:22
It’s performance-review season and I’m watching managers kneecap their careers. Gleefully they share the best prompts to have ChatGPT write their performance assessments - exactly the sort of shortcut that guarantees they’ll never get better at the job.
Below, we’ll break down why AI’s leaky interface is a crutch, not an abstraction layer, and how leaning on it is already stunting growth.
Performance write-ups feel brutal because you’re not great at management. Great managers improvise on feedback the way a jazz soloist riffs on a theme - always on, always smooth. That fluency only comes from thousands of hours of uncomfortable reps: hard conversations, careful wordsmithing, and the stress of getting it right.
A performance assessment is management boiled down to a page. It demands precision, empathy, and strategic thinking. Offloading that to AI means skipping the workout; your team might hear something that sounds okay, but you’ve gained zero coaching muscle.
Experienced managers know that the performance assessment is just as much about growing management skills as it is growing the skills of your reports.
“But wait—aren’t tools supposed to make us better?” Sometimes. The key difference is reliability. True abstractions (think memory-safe languages, spell-check, or a calculator) behave the same way every time, so you can build skill on top of them.
Management AI isn’t that. If every managerial moment were forever mediated through an AI - 1:1s, presentations, promotions - then perhaps it could serve as a real abstraction. That world is nowhere close. As a result, using AI for critical deliverables is fundamentally restricting your ability to gain managerial skills.
Some work is meant to hurt - that strain is the rewiring session your brain needs to level up. Letting AI sand off the edges is test-day cheating: great for today’s quiz, fatal for tomorrow’s mastery.
How to use AI for management:
Rule of thumb: use AI on repetitive tasks or where the answer is absolute. If you’re thinking hard in the realm of ambiguity and human behavior, that’s learning how to manage, and you can’t afford to offload it.
2025-05-05 14:59:22
One of your most important activities as an executive, especially at a startup, is to set policies: Sets of guardrails or rules for how company systems work, such as vacation policies, expense policies, WFH policies, or rules for how to get promoted.
Companies are just groups of people with money on the line, and they need rules to avoid descending into chaos. Startups are born without any rules, so as you scale someone ultimately needs to set up everything from scratch. As a result, setting policies is one of the most important roles that one plays as an executive.
But as common as policy setting is, there are few guides that actually describe how to do it effectively. So here are some rules and heuristics to keep in mind. We’ll use something really simple as an example – how to set a travel expense policy for your growing startup.
This may seem trite, but policies that will impact many people simply must be high-quality. Even the simplest policy can get surprisingly complex, and you want to catch second-order and third-order consequences to make sure that they make sense in all circumstances.
For an example of how this can get complicated, let’s take the case of your startup’s travel expense policy:
The best way to ensure that your policies make sense from top to bottom is to treat them like products. When you release a new product, you:
Does this take time? Yes. Do you know what else takes a lot of time? Negotiating with angry people who are rightfully pointing out that your policy sucks, and then revising it with your tail between your legs.
As a completely unrelated side-benefit, reviewing policies is a really good way to identify talent on your team. People who have good feedback on policies that they didn’t generate are often good at creating new ones themselves. Using your team as a sounding board is a free and easy way to identify strong managers.
The worst way that policies generate distrust is via secret exceptions. Secret exceptions occur when there’s some loophole that is allowed to remain for a long period of time – typically in a fashion where enough people know about it that it gets utilized regularly.
For example, let’s say that:
This sort of exception can dramatically erode trust. Not just because of the secrecy of the exception, but because knowledge of the secret trick will inevitably get distributed unevenly. Worse yet, loopholes are typically exploited most by the teams that are most aware of them: i.e., the policy setting team themselves. Suddenly, you realize that Finance is constantly booking offsites during the last two weeks of the quarter and flying business class, and nobody else is, and it feels like the system was an inside job.
Consider whether your policy passes the all hands test: If you were asked to explain this policy – the whole policy, including loopholes and past examples – would you be nonchalant or nervous? If the latter, you need to rethink how you’re operating.
The absolute worst form of policy exception occurs when you have a policy that breaks down in ways that punish you for being a good team player.
For example, perhaps every team is given a hiring budget at the start of the year. However, if the hiring budget needs to be shrunk (maybe sales are slow, or there’s a global pandemic), then the company goes into an immediate hiring freeze. As a result, maintaining a high hiring bar is punished, and you’ve rewarded burning through your budget as fast as possible to “win” the game of Budget Musical Chairs.
Or imagine that you follow a use-it-or-lose-it budget process. In these situations, you can be actively punished for responsible policy adherence if you cut costs and subsequently have your budget shrunk. This is very common at large organizations.
If you want your policies to work, it needs to be as easy as possible to conform to them. You never want to be in a situation where process adherence is punished, because this causes cascading distrust and erosion of every policy going forward.
One of the worst situations is a policy that benefits one group but harms another, which the first group refuses to re-evaluate. For example:
It’s crucial that the people who are the most impacted by a given policy have the ability to push back and drive change; without this, inertia can cause significant damage over time. This is largely a cultural issue, and your culture needs to celebrate people revisiting their assumptions, rather than misconstruing an unwillingness to compromise as confidence or strength.
A heuristic – for every concrete dimension of your policy that people grumble about, you need to be able to articulate at least one very strong reason that your policy must be the way that it is. Extra sacrifice requires extra benefit.
The final rule of setting policies is that the more rules you set up, the less any one rule will be followed. If you’re at a successful company, people are extremely busy and won’t have much time to follow your processes. If you’re at a less successful company, people are frankly probably not as sharp, and likely don’t have the capacity to handle a lot of policies. Either way, it behooves you to dictate less.
Many teams confuse creating policies with adding value – one of the most toxic mistakes that an organization can allow. Creating a new rule is something concrete that you can put on your performance review. It feels like building, but in reality it tends to add friction and slow down all of your real builders. As a leader you must constrain the urge to indulge the false productivity of setting non-essential new policies. A new policy itself should never be a win unless it comes with metrics on what it’s helped you to solve, and consideration of whether it’s wasting time.
Our industry encourages this sense of false productivity. People go on podcasts and get asked what they do for, say, OKRs at a high-growth company (I have fielded this exact line of questioning). Everyone wants to have an answer showing that they have a thorough framework for world domination; nobody wants to respond “well we just kinda set a bookings target and a few check-ins for big projects, and make sure everyone is working real hard.”
Healthy organizations should seek to prune or automate policies that are no longer needed. We had a laborious check-in on every release after a number of incidents, but our testing expectations and launch process has reduced the risk of release-related issues. We used to have strict central budgeting rules for team events, but now every team just gets a budget and we trust that you’ll spend it like an adult. These are signs of a healthy organizational dynamic, and will allow you to stay nimble even after you’ve left your startup days behind.
2025-04-20 14:59:22
Leading from the front means leading where the action is happening.
Here we’ll talk about three critical aspects of leading from the front:
Leading from the front is important for two main reasons:
First, leading from the front makes you a more effective leader because you learn from the front.
Being on the front lines - in the incidents, in the customer calls, in the meltdowns - gets you critical information with first-hand knowledge. There’s a major difference between “an engineer made a Jira ticket that I saw that said this was an important incident followup” and “I saw this happen and if we don’t do this followup we deserve to fail. It’s not a question - we’re doing it.”
But it not only gives you the information, it also gives you the motivation. Being woken up at 3am, or having a $1M customer scream at you, catalyzes action like few other things can. Leading from the front gives you the literal incentive and neurological shock to overcome the forces of inertia, politeness, and busy-ness that normally hinder action.
Second, effort is contagious.
Most people will try really hard as long as they know there’s at least one person who will storm the hill, who will go into oncoming fire and spit bullets back at the enemy.
The problem with large organizations is that those people often get promoted and then stuck in meetings all day. They’re no longer on the frontlines. They might swoop in to help, but that’s not the same as being in the foxhole.
This is why leading from the front is so important. You literally just need one single leader with general stripes who is in the foxhole with the team saying I ain’t going nowhere. I have nothing more important than fighting with you.
That’s the difference between a motivated org and a disengaged org. Somebody who has authority and power is in the stuff with you.
You might say - but everyone is incentivized to try hard, why do we need this? Incentives are necessary but only go so far. In fact, they don’t cover two critical cases.
The first case is collective action. I might be incentivized to try hard, but if my whole team is phoning it in, I don’t believe my efforts are worth it. But if a leader comes in and gets these bozos to rise to the occasion, I’m ready to charge the hill. Nobody wants to be the hardest worker on the last place team.
The second is that you can only unlock the higher order gears like professional pride, duty, and honor with the moral authority of putting yourself on the line. Yeah, I’ll try hard enough if I’m incentivized. But if there’s a leader out here who looks just as intense at 5 hours into this incident as they were 5 minutes in, with no inkling of quit in them, if there’s someone who is just hardwired to never give up, I can sprint.
This is why coaches matter.
To be that contagion, to lead from the front, the most important thing is that your leadership is predictable and consistent, and that you know where the front is.
Most leaders think that the most important thing is that they are reachable if things get bad enough. While this is a worthy goal, it regularly and quickly falls apart.
A leader says “if things get bad enough, call me, page me, I’ll come running”. And when the leader says that, they mean it. But then that leader:
Quickly you find that even though that leader genuinely wants to help when things get bad, they’re simply too busy.
The right away to lead from the front is to be predictable and consistent. There’s a lot of ways to do this, but this can look like:
This is what committing to leading from the front looks like. It means a commitment to being present.
Note that not every role can be on the front with these time requirements. That’s ok. It’s important to be clear if you can actually commit to leading from the front. It doesn’t make you less good at your job to admit this.
Some leaders might also say - hey traveling and being out of pocket is the front lines, isn’t it? Well yes, it is, but it’s often just a different front line than the one your team is on. Some generals need to go to Washington to secure funding. They’re just as important - if not more - than the frontline generals. The problem arises if the general in Washington believes they’re both (and doesn’t find someone to man the front).
Beyond just being available, you must also know where the front is. In some leadership positions, without intentionality you can be boxed out of any of the real action (which happens in teams you’re not part of). To solve for this, you must ensure you have checkpoints to coordinate with your teams’ goings-on.
Ok, you’ve decided to lead from the front, you’ve actually set yourself up to be able to do it and be there. Here’s how to lead when you’re there.
First, you have to know what you’re doing. Most leaders avoid leading from the front by never investing enough to actually know what to do when they’re there. To lead from the front you must be ready when the battle starts with skills that matter. These include:
This is why it’s so important for engineering managers to go on-call - to learn the basics of how to debug in a system. It’s why it’s important for, for example, design leaders to use and test the products under their remit.
To learn to coordinate resources you must simply do it. Shirking away from hard product decisions, or arbitrating disagreements, or late night incidents will only entrench your lack of ability. Confidence in how to wrangle people, how to organize thought and action, and how to drive next steps is only learned from experience.
Second, your demeanor must be poised and determined and urgent. If you enter an incident hysterical or say “how the hell did this happen”, you are a distraction. Go fly a kite. Instead, your presence must imbue the team with a sense of “it does not matter how we got here. We will fix this and I will be here until we do.”
You must also, critically, have the energy. One of the most common things to fail at in frontline leadership is giving up too early. We’ve already been at this for 8 hours, do we really need to dot this i and cross this t. In incidents small and large, if you leave an ember burning you will be woken up by another fire. As a leader, you likely won’t be in the deep deep weeds. Your job is to make sure that people don’t give up before the fire is out. Your job is to be measured and calm, while being urgent and intense. You will not quit and you will not yell. Inhabiting this duality is one of the most powerful skills of leadership.
Finally, you must follow through. You must make sure the things that caused this fire drill will never happen again. Lots of people can help out when things fail, but to have the grit to follow up on the root causes and drive the change to prevent recurrence in a super-power.
If you can put all of these together, you will be a great leader.
Most people will not lead from the front. They won’t learn what’s needed to be useful when they get there. They won’t block the time to be able to show up. Or when they get there they’ll be a distraction. Or after being woken up twice at 3am in a month they’ll say “this really just isn’t for me.”
But those that do will earn the respect of their team. They’ll motivate their team to be better than the sum of their parts. And they’ll deliver outcomes that are outsized to their resourcing.
In summary:
For those who learn better from anti-patterns, reminder that great ways to not lead from the front are:
2025-04-06 14:59:22
As a manager, your words are your bond
In the squishy realm of managing humans, the specific things you say have specific outcomes.
Unfortunately, most managers are very bad at speaking precisely. Speaking precisely, especially about long-term, uncertain things, is not something many people do by nature.
To compound issues, there are a variety of factors that drive managers to speak non-specifically and say the wrong thing. These include things like:
Let’s explore some common examples of imprecise language and how to fix them.
The most common example of imprecise language is when someone asks you in a 1:1 “how am I doing?” Very few managers are ready to answer this question well on the spot. But managers answer the question anyway and often say things like:
“Oh you’re doing well, communication could improve a bit but overall you’re doing well.”
Well, what often happens is that the performance round happens and the person gets below expectations.
“I thought I was doing well?”
Yes, you did say that. You didn’t say that the communication piece is actually a major factor in their performance that is causing regular friction in the team.
The right answer in this situation is almost always to say that you need some time to gather your thoughts and will come to the next 1:1 with a more considered answer. By default this should be your answer any time anyone asks you how they’re doing, because unless you hold a ton of information in your head at all times and have regularly reviewed it for an accurate synthesis of their performance, there’s no way you can answer that question specifically, or well.
I mentioned this topic in our article on writing performance reviews. It’s extremely common for managers to use vague and overly flowery language in performance reviews.
Imagine you’re a junior engineer and you get a review that says:
“Angela is a great engineer and always up for a challenge.”
Problems:
So, be very specific in what you’re calling out, and give feedback around actions, not attributes. Good examples:
Another common example of unspecific language happens when your boss asks you if your team can do something. There’s two common, bad answers that people habitually use:
The problem is that neither of these answers are specific or true. The right answer here is to gather more information and circle back. But if there are meaningful tradeoffs, the right answer is always:
“We probably can but let me draw out the implications of taking on this work so we can align on priorities.”
The point here is that specific language really matters. “Good” is not the same as “persistent”. “Soon” is not the same thing as “6 months.”
One of the reasons why writing things down all the time is so useful is that it forces people into more measured, specific language. If you’re a manager, using measured and specific language needs to be a skill you learn ASAP.
Here’s a bunch of examples where people often use vague language when they shouldn’t:
2025-04-02 14:59:22
If you spend a lot of time in tech, you’ll inevitably hear people extolling the virtues of being a First Principles Thinker – that is, someone who analyzes situations in terms of foundational axioms and then uses their impeccable reasoning to determine a bold and original course of action.
But if you’ve spent significant time operating a business, it’s obvious that the solutions to your problems are rarely unique. In business the optimal move is often just to reason by analogy quickly and decisively.
So I’m going to propose a somewhat different way to break down the debate on whether reasoning from first principles or reasoning by analogy is better. In most situations that I’ve seen, you’ll get better results if you:
Let’s take a conceptually simple problem – why is retention low? This seemingly straightforward problem could have many possible root causes:
With this many possibilities, you can’t just draw from your past experiences to identify the core problem. Unfortunately, it’s all too common for experienced leaders to jump to the conclusion that whatever was most broken at their last team or company is broken again. Poor retention? Seen it before, fire the Head of Support. Seen it before, the product is broken – fire the Head of Product. Seen it before, you need to replatform to remove tech debt. Seen it before, you need to hire more customer success.
This incurious approach consistently leads to poor outcomes. In about 75% of cases that I’ve seen, identifying root cause problems by analogy ends with blaming the nearest leader who’s a weak communicator, somewhat abrasive, overly passive, or all 3. This bystander is usually a problem, but he’s often not the problem.
Using first principles to identify problems is like solving a math proof: Start from your ground truths, use them to generate hypotheses, and check whether those hypotheses would logically lead to the visible symptoms. A good litmus test is whether you can articulate your root problem using the word “therefore.” For example, retention is low because:
Closely observing the problem also helps. In the retention example, if you actually talk to 5 customers who are churning your learnings should align with your first principles analysis.
But once you correctly identify your problems, there’s a relatively short list of common solution archetypes in startups and business writ large. Your problem might be unique but the optimal solution is probably not.
As a result, you should pull solutions from a library of similar scenarios wherever possible – this not only improves the odds that you’ll get to a good outcome, but also critically lets you move much faster. The faster you implement fixes the less accurate you need to be, because you can take more shots on goal.
A list of some of the most common solutions to have in your repertoire:
Using first principles to determine solutions can have equally bad outcomes.
The first pattern is a tendency to over-complicate simple situations. A classic example is a startup that crafts an entirely unique pricing structure, because they have some logical first principles argument that their custom pricing scheme makes more sense than all known industry standards. Enterprise buyers show up, get confused, and run in horror until the startup picks a standard, boring pricing scheme.
Another common failure mode is moving too slowly because teams don’t realize that they’re in a known scenario. For example, maybe our startup is losing competitiveness because we’re building too slowly. The answer is not to get advisors or run a huge analysis on your unique velocity challenges; the answer is almost certainly that you need more senior engineers, better PMs and designers, a culture that pushes everyone to ship with urgency, and basic processes to improve quality of products produced.
It’s worth mentioning that in many circles first principles thinking is viewed as some sort of inherently superior activity – first principles thinking is treated like some kind of lightsaber that only the most worthy can wield to invent new secrets of the universe.
Maybe that’s true in theoretical physics, but in 99.5% of situations it’s just a tool. Few B2B SaaS startups that I’ve seen are busy discovering new laws of the universe. To be effective you need to have the skillset and willingness to both think from first principles and reason by analogy as the situation demands.
This is a really powerful combination, and some of the very strongest leaders that I’ve worked with are older, more experienced people who have a strong ability to reason from first principles about their problems and then draw from a huge array of potential solutions. Because really, the key is to have a bit of humility: To admit that maybe your experience doesn’t mean that you know best, or that maybe the sheer force of your intellect isn’t the only solution.
