2025-08-21 14:59:22
One of the most consistent observations I’ve had in my time in startups, scale-ups, and public companies is that smart people with context on a tricky situation almost always know exactly what they need to do.
Teams obsess about company strategy, about data, and about frameworks for decision-making. But I’ve found that for most operational decisions the right course of action is actually pretty obvious to people with a lot of business context.
The simple fact is that people hate confronting difficult decisions. And instead, most come up with increasingly painful coping mechanisms to avoid conflict. Eventually they wind up incurring much more aggregate pain than if they had simply bitten the bullet as soon as they recognized the realities of their situation.
Some of the more notable instances where this plays out:
The fact that the right business decision is so often obvious leads to a few actionable operational steps.
If you’re torn between multiple choices, the path that makes you most uncomfortable is unfortunately almost always the right one. There’s a very strong human tendency to avoid hard decisions, so the errors you make will only go in one direction. Pay attention when you hear any of the tells below – in particular watch out for the word “just” which is a calling card for an argument that’s really an excuse:
Since people close to a problem almost always know what to do, teams must be open to difficult feedback from inconvenient sources. Especially as organizations grow, the difference in comprehension between an expert who is close to a situation vs. someone who’s further away or not an expert can be night and day. Favor proximity (and expertise) over title.
A common type of error that one sees is a friendly, charismatic, highly-visible executive who is very popular with more junior members of other teams but seen as incompetent by his peers and senior staff. The senior veterans who are closest to the situation know what to do, but they avoid providing the harsh feedback because it’s awkward and seen as not worth the effort.
The cult of being data-driven, particularly at huge consumer companies with non-intuitive user behavior patterns, has led many people to believe that there are non-obvious nuances to every situation. In reality, most business and management situations do not have a lot of nuance.
Being data-driven has many merits, but its most debilitating flaws are that it favors certainty over speed and trains teams to look for subtle nuances that don’t exist 99% of the time. If you know what to do, you should just do it as soon as possible rather than waiting for more information. If you’re a smart and experienced executive, don’t let the siren call of more data gaslight you into re-running the analysis on a situation where you have certainty.
Having worked with teams as an advisor/investor in the past, I’ve also found that external advisors can be very helpful to simply confirm what teams already know. Importantly, these external forces can also help informed teams to assess severity. In a pinch, one of the easier ways to get a gut check is to ask a trusted friend to rubber duck a difficult management decision with you. Just explain the challenging call to them, and have them ask occasional questions until it’s clear what to do. Some of the most useful discussions that I’ve had with companies begin with someone simply asking “is this normal?”
Finally, you actually owe it to your team to make the hard calls that you know to be correct. Many leaders fall into a state of paralysis because they don’t want their team to blame them for making the wrong decision. They would do better to respect their team’s macro analysis more: everyone who joins your team is ultimately doing so because they trust your judgment on some level. Well run companies are benevolent dictatorships not democracies, and your team will respect you more for decisive action than they will for a theoretically higher hit-rate on your decisions.
2025-08-02 14:59:22
Metrics can be incredibly powerful. But you have too many of them.
Let’s talk about how and when to use metrics.
The golden rule of metrics is this: any metric you maintain should directly drive action if outside expected bounds.
The reason this is an important rule is:
The longer I'm an exec the more confident I become that 80% of metrics dashboards are adult pacifiers for managers with poor strategic sense and anxiety disorders
— staysaasy (@staysaasy) March 24, 2025
A direct corollary - because the cost of setting up, maintaining, and actioning on metrics is high, you shouldn’t have that many metrics.
Let’s talk about setting up metrics and how to use them, as well as how to not use them.
Setting up a metric takes time. You have to:
Depending on your company and the metric, this could be a couple hours of work or a couple months of work via multiple tickets. Some tools give certain metrics by default, but that’s also not free (you’re paying for it).
The takeaway is that setting up metrics cost time and money.
Good metrics:
Regular review of metrics is critical, because any metric you don’t regularly review will eventually become inaccurate.
Many people come back to a metric a year after setting it up and realize it doesn’t look quite right. Upon investigation they realize a week ago someone changed the definition in middleware and it started double counting. This kind of thing happens all the time. The most pernicious version of this happens when the metric looks like things are working well, while actually it’s overreporting and things are having issues.
Regular review scrutinizes the metric value as well as matches it against other information to ensure it seems right. As a general milepost, expect to find something broken in a metric about once a year, needing repair.
Metrics without expectations are just gossip prompts.
Some metrics only matter if they move > 10%. Some matter if they’re .1% off target.
State explicitly what your expectation is for a metric and the conditions of action in either direction. Otherwise, metric review will become an exercise in taking a really long time to realize people don’t know what matters.
If a metric is outside the bounds of certain expectations, you must take action. This is the biggest cost to maintaining metrics - you actually have to do something if the metrics indicate something you’ve said you don’t want to happen.
Too many people have 25 metrics in their dashboard and don’t do a damn thing about anything. They just go back to the same backlog they were working on and put away the shiny metrics for powerpoints when they need to convince someone of something.
Metrics should have expectations. If those expectations are not being met, action must be taken.
Let’s talk through a couple examples.
An ambitious PM has a bunch of metrics in a dashboard. The PM uses them for things like: showing how well their team is doing, and asking for a raise, and asking for more resources.
The problem is that they only review those metrics in preparation for those activities. They actually have no regular review, and no owner, and no clear expectation of what it should or shouldn’t be.
Then one day the PM’s boss wakes up and says wait, this isn’t quite right. And that’s when you find out not only is the usage data wrong, but even if it was right, the whole concept of appropriate growth was not aligned upon. So in fact, all of these metrics were, for their entire lifetime, worse than useless.
Instead of showing the micro-cohort CSAT for 7 different customer profiles across 3 products, their manager should have asked to see one or two metrics, and should have scrutinized them regularly, with clear expectations on growth (not just that up and to the right is good).
It’s common practice to regularly review infrastructure cost at companies with the finance team. Oftentimes these processes have two things correct: they review metrics and each piece of infrastructure has an owner. The common failure, however, is to not discuss what good and bad actually looks like.
When do we actually have to do something about a cost changing in a certain way?
This question is often never asked, and so people debate minor cost fluctuations and lack clarity on if any changes are needed. The simple answer is to set up a working agreement: we’ll review the cost to make sure it all makes sense, but we’re only actioning if it’s more than 2% above the quarterly forecast or 5% over the yearly forecast. And, if it’s above that, you must take effort to reduce it.
With this agreement, you gain efficiency when things don’t require action, and direct clarity when things do.
Having a few great metrics is much better than having a bunch of trash metrics. Metrics require intense focus to keep accurate and to have high integrity. Metrics require expectations and action to be worth spending all of the time it takes to make them accurate and have high integrity.
If someone says “I got metrics” ask them the last time they did something because of a metric. If they don’t immediately know, they don’t have metrics, they have a dashboard of graphs that they use to persuade people and sooth themself.
2025-07-06 14:59:22
Forming a new software team is easy to get wrong in many ways, including:
Here, however, we’ll focus on one of the most important and often bungled aspects of team formation - the team name.
Let’s review how to avoid the common trap of naming teams poorly.
Let’s assume that you have a team with a good mission (this talk is good inspiration for crafting high-quality team missions).
Now you’re ready to name the new team, which is when things commonly go awry. Even if you have a great team mission, you can shoot yourself in the foot with the name.A strong name:
Names are sticky. Missions live in docs nobody reads; names live in brains.
It is incredibly easy for a broad team name to lead to mission expansion down the line. When asked if it is appropriate to upscope a team’s mission, people always say “well we are the _____ team after all!”
People often mildly upscope their name to be more ambitious than their mission. Then, over time two teams who have upscoped their mission end up believing they both own some hot new area of technology.
Then people fight viciously.
A good team name doesn’t overlap with any other team and doesn’t allow for major upscoping of ownership.
People in large organizations burn thousands of hours just finding the right Slack channel to get answers they need. Asking questions to the proper team, finding the right people for projects and incidents, and all other routing activities are a massively expensive set of endeavors when compounded over hundreds or thousands of people. If a team is named properly, you can create major efficiency every time someone needs to figure out who owns what.
There are a couple big failures in team naming as it pertains to routing:
Let’s make these ideas real with an example. Let’s create a fake team that has the following properties:
Here are good and bad team names.
Bad
Good
Teams often want to avoid tightly scoped team names so they can expand in the future. They’ll also claim that it allows them to think more broadly about a problem space. However, in general:
Team names are contracts that define who does what. Getting them right up front is an incredibly important piece of scaling software organizations.
2025-06-26 14:59:22
A common logical fallacy is claiming something won’t work because a previous attempt failed.
People often look to previous failures to set their future course for several reasons, including:
Let’s talk about why trying again often works.
Especially if there has been a long time between attempts, people often underestimate how much has changed.
Maybe five years ago the company tried a product rebrand, but the number of things to update in the UI ended up causing them to abandon it for other priorities. You might nix the idea of a rebrand if it came up again today, but you’d fail to realize that a whole design system was implemented in the interim, and the level of effort is an order of magnitude less.
New leaders, people, processes, teams, and architecture all contribute to a changing environment that can make very similar attempts yield wildly better results.
People often undercount their personal contribution to previous failures. Oftentimes they say something can’t be done because they tried it, but the main problem was their leadership, skills, or often their own personal interest level.
New ownership over a project can make all the difference. Just because I missed a three pointer doesn’t mean it can’t be done. If you hire Steph Curry, you should start shooting.
Sometimes people claim to have tried a related initiative and failed and then say the new initiative can’t work.
Maybe your team tried to sell an AI product and customers didn’t like it. So someone proposes a new one and a leader says “our customer base isn’t ready for AI products.”
Upon discovery, you find that the original product was a high complexity, high integration product, and the new proposal is a simple LLM tool to check customers’ work. These are absolutely not the same product. If you’re claiming a previous failure is prior art, you need to be sure the past failure and new attempt are almost exactly the same.
Often it actually requires all of the above things to change for the opportunity to now be available.
Think of a key opening a lock - many people say “we tried pushing several pins up and it didn’t work”. Well, to open a lock you need to push all the pins up in the exact right way at the same time.
People often seriously struggle to see interconnected problems in this way. Take the example of revamping a component of your compensation philosophy. To change your whole equity program, you might need:
If you tried before and half of those ingredients weren’t there, it doesn’t mean it’s impossible.
When you are going to not do something new because of previous results, you should try to distill down your learnings to the most concise and granular statements possible.
“We tried to sell a product like this before” is not a concise statement. There’s about 10,000 variables from pricing and packaging to feature set and more that could impact a product selling or not.
Examples of precise learnings:
People bias towards avoiding the scene of prior failures. But you must analyze where the failure was and think specifically about its implications.
A good heuristic for if you’re over-biasing on previous failures is is that if you’re deciding a high volume of new initiatives based on old failures, you’re being too general and don’t really understand why it didn’t work.
It’s also always good to remember what must be done as a business. Sometimes you find people with failure-bias saying things like “we’ll never reduce support” or “we’ll never make this cost effective.” But those are things that you absolutely must do as a business, and realizing that highlights the inadequacy of their failure bias.
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.
