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