MoreRSS

site iconStay SaaSyModify

We started this blog to share what we’ve learned on how to scale product and engineering through all stages of startup hypergrowth.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Stay SaaSy

First Principles Problems, Secondhand Solutions

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:

  • Reason from first principles to establish what your problems actually are.
  • Reason from analogy to figure out what solutions you should actually deploy.

A First Principles Example: Retention

Let’s take a conceptually simple problem – why is retention low? This seemingly straightforward problem could have many possible root causes:

  • Is the product weak? This could be due to poor product management, design, or engineering. Weakness in any of the three, or a combination, could lead to similarly bad metrics.
  • Is something about our support process failing? Is the support team’s leadership bad? (A weak product and a weak support team can manifest in similar symptoms, such as poor response times and broken integrations)
  • Is the customer success team failing? Are they under-resourced, incorrectly incentivized, or just not operating well?
  • Have we oversold customers because we were forced to stretch out of our Ideal Customer Profile (ICP)? Did sales oversell, or sell to bad-fit customers?
  • If sales oversold some customers, was it an execution issue on their side, or were they effectively forced to oversell because they didn’t have enough pipeline? (And keep in mind that a marketing problem might go all the way back to the top – it’s often a product issue!)

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:

  • We can see that adoption of our features is low, especially in customers who churn. We also know that our engineering team has high velocity and support response times / CSAT have been improving – they’re likely not the problem. Therefore, we’re probably building the wrong things which is leading to failing product-market fit.
  • We can see that our Security team buyers are churning at disproportionately high rates, but our Engineering buyers seem pretty happy. Our growth rate is only barely acceptable as-is. Therefore, we’re likely overselling a Security offering that is not actually competitive in the market, causing customers to churn.

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.

There Are Many Solutions, But Not Infinite Solutions

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:

  • You have a bad leader at some level of the organization – change them out.
  • You are not following best practices in an important function and must re-establish high-quality execution, typically via a time-consuming but conceptually simple back-to-basics approach. This is most common on teams like sales, engineering, and support that have a large number of people doing the same fundamental job.
  • You are in the wrong market, and should be shifting the markets where you focus in a dramatic way, e.g. by going up-market or refocusing your geographic footprint.
  • You are misallocating financial resources and need to rebaseline. For example, marketing is underfunded vs. sales. Engineering is underfunded vs. customer support.
  • You are doing too much and must re-establish focus by cutting projects.
  • Your pricing and packaging are unworkable in some regard and need to be changed.
  • You must fix broken incentives – for example, compensating sales based upon their deals renewing, not just deals closed.
  • (In startups) You do not have product-market fit and need to reset the company.

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.

You Need Both

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.

Managing People You Can’t Fire

2025-03-26 14:59:22

One of the worst situations in management is needing to fire someone and getting blocked. This happens somewhat regularly and is one of the most trust-breaking experiences between a manager and their boss. Let’s talk about why it happens and how to right-size the situation

The Ingredients

Managers end up needing to fire someone for many reasons, the most common being:

  • Behavioral issues
  • Significant underperformance

Almost all managers loathe the idea of firing someone, so when they advocate for it, it’s almost certainly needed. Think about that again - the point is important. Much, much more often managers are late to fire someone. Because firing is such a traumatic experience on both sides, managers do not come to the conclusion lightly.

So if you’re a manager’s manager and they come to you asking for a termination, the chances that it’s the right thing to do are very high.

Despite this reality, many managers of managers often block the termination, or say not now. The reasons they do this vary, but include:

  • They have a personal relationship with the person being fired and intervene.
  • They think the manager is being too harsh. Note - this happens, but again, it’s really not common.
  • They don’t trust their hire to get it done without that person.
  • They’re being risk averse.

From the perspective of the manager in this situation, this was the formative moment where your boss could show that they trust you. You regularly take on work for them, make them look good, accept their critical feedback. All of that is worth it for their respect and trust (and the money). And at this moment, the time where they could really prove they trust you - they do the opposite. They do something that shows that you are in fact just on training wheels.

Then it’s not like HR can write down “manager was probably right, overridden by their boss.” So in cases of behavioral issues, including with the manager, there is often some documented feedback that the manager was wrong, and themselves needs to improve.

Finally, the manager then has to keep on living with that underperformer and dealing with all of the chaos they cause.

The result of this triple whammy is often a deep-seated frustration on the part of the manager and often leads to them quitting. And it’s an issue that doesn’t go away because if that person needs to be fired in the future, the manager’s boss is now invested in that not happening to not be proven wrong.

A Better Way

There should only two versions of firing decisions.

The first is learning mode. The boss is clear to their new manager that for the first 6 months they’ll be the final decision on any performance or firing decisions, because the new manager needs to understand the culture and calibrate to organizational standards. Set the expectation clearly, and it’s fine.

The only other mode is trust. Again, extremely few managers are not going to offer up a termination proposal without cause. If you’re sure it’s a mistake - intervene. If you’re unsure - the tie goes to the manager. They’re living the reality, they deserve that trust.

Summary

In summary:

  • If a manager is proposing a termination, it’s almost always needed
  • That moment in time is an opportunity for their boss to show if they trust them or not
  • So, they deserve to be trusted

Note: there are grizzled VP/C-level psychopaths who fire people like eating Tic Tacs, but this post is not about them. The managers in question are managing ICs, probably have been managing for under 7 years…etc.

Tips For Better Interactions

2025-03-17 14:59:22

The following are an assortment of tips for having better interactions and better meetings.

Don’t Be Frustrated

Don’t ever agree to the premise that you’re “frustrated” or “upset” at work.

People will often consciously or subconsciously say things like “I know you’re frustrated, but…”

If you’re in a meeting and this happens, cut them off. Say “to be clear I’m not frustrated I’m…”

  • Just escalating an issue
  • Just getting more information,
  • Just making sure that X is accounted for

… or whatever

Once you allow the premise that you’re frustrated, everything that happens after is someone dealing with a frustrated person, which is never to your benefit.

Another benefit of this technique is that if you are frustrated, it acts as a mantra to remind yourself to stop acting that way ASAP.

Taking Notes

One of the simplest ways to be a better leader is to be the note taker in meetings.

Taking notes:

  • Is important. You codify the discussion.
  • Is humble. It shows everyone an act of service.
  • Helps you shape the conversation. If you can’t write the logic, the logic isn’t happening.
  • Gives people something to look at (present the notes).
  • Gives you a chance to slow the meeting if things get emotional, and lets you create natural pauses to get things back on track.
  • Shows people that their opinion is both heard but also is being recorded, by way of visibly creating a record. This acknowledges contributions and dissuades people from saying wildly stupid stuff (e.g. not wanting to be codified as the person that won’t let the new company-wide process happen because their it’ll harsh their vibe when they work from their Tahoe house).

Of all the ways I’ve tried to get people to run meetings better, having them take notes while facilitating is the only one that works reliably and well. I’ve seen people go from rambling rabbit hole-ing messes to focused meeting facilitators with just this one change.

Avoid Boundary Objections

So much of bad meeting feedback is “if you take this idea too far we’ll have problems.” This is one of the most useless pieces of feedback.

If someone says “we should let people choose lunch once a week,” and you respond with “if we let people choose everything around here the inmates will run the asylum!” - you’re being actively counter-productive.

Boundary objections are almost never realistic and are often disrespectful - they imply that the presenter is dumb, foolish, or would act with low integrity. No Alan, I’m not proposing we let employees choose executive comp just because I said once a week they should be able to choose pizza or burgers.

Boundary thinking has a place, namely in thinking about the behavior of engineered systems. Beyond that, it’s almost always a negative distraction.

Let People Be Wrong

Another way people often waste time in meetings is chasing the accuracy of details that don’t matter. The meeting is about whether we should code freeze on the 10th or the 11th, and your department head is debating a detail on slide 5 about how many customers we have in Italy. It doesn’t matter.

People do this all the time, because:

  • Some people see it as their job to correct every mistake they see. ATTN: it’s not.
  • Some people get itchy if they think something is wrong. Instead of living with the tension of an unimportant thing they don’t agree with, they need to resolve it.
  • Some people are well intentioned but don’t realize they’re wasting time.
  • Some people believe that not calling out something they think is false is implicit agreement with it.

Let unimportant things go even if you think they might be wrong. If you really need to do something about them, you can:

  • Say “I don’t agree with all the details here, but it doesn’t matter, I think __
  • Send a follow up to a meeting or discussion with a note on the thing you think is false

Time Your Interactions

Important meetings shouldn’t be on Monday or Friday, and should never be the last meeting of the day, and shouldn’t be during lunch hour, and shouldn’t be changed by calendaring software, and nobody should be off camera (if remote).

Narrowly, avoid all of these in particular for 1:1s. Dynamic calendaring software that often moves 1:1s around to “optimize” your calendar does more harm than good. There’s value in having meetings at the same time every week. It allows for a rhythm of preparation and a consistency in environment (e.g. morning vs afternoon).

Prioritize Your Meeting Agenda and Don’t Force Yourself to Get To Everything

“We have to move on to get to the rest of the agenda” is a sign of a bad meeting.

Your meeting should have an agenda with topics in priority order. You move on from things when you’re done with them.

Bad meetings focus on moving on to the next item even when the current item is unresolved.

This is dumb.

Stop having meetings with 5 topics that get cut off and produce no value. Discuss 2 points well and find time for the rest or punt them.

Companies that can’t run good meetings almost always can’t prioritize well. An overbooked, under-prioritized meeting is a symptom of an overbooked and under-prioritized company.

Relatedly, don’t try to rush the end of a meeting to finish something. It’s always better to find a separate time. One of the most common unforced errors is rushing things. A great way to be wrong is to be right in a rush.

Blameful Post-Mortems

2025-03-12 14:59:22

Over the last decade, the concept of a “blameless” post-mortem has become a software industry standard. According to ChatGPT, blameless was introduced to the software world by a 2012 blog post:

Having a “blameless” Post-Mortem process means that engineers whose actions have contributed to an accident can give a detailed account of [what happened[...and that they can give this detailed account without fear of punishment or retribution.

Why shouldn’t they be punished or reprimanded? Because an engineer who thinks they’re going to be reprimanded are disincentivized to give the details necessary to get an understanding of the mechanism, pathology, and operation of the failure. This lack of understanding of how the accident occurred all but guarantees that it will repeat. If not with the original engineer, another one in the future.

The intent of this philosophy is good - let’s avoid fear of unfair punishment so we can learn from incidents.

The problem is that there is a metric ton of nuance in these statements. Instead of finding a middle ground of accountability and empathy, many companies ran with these principles into a no-man’s land of non-accountability.

Let’s talk about why. But first, some background.

The History Of Blameless

The idea of blameless post-mortems came from aviation and healthcare. I’m not an expert, but I think that the situations that prompted these industries to conduct blameless post-mortems had the following qualities:

  • Severity: Something really really bad happened. A plane crashed. A person died in the operating room.
  • Frequency: Incidents are generally infrequent. Most people are rarely involved in a post-mortem.
  • Punishment: The punishment for negligence can be extraordinarily high, e.g. murder charges. You need to assuage people that they aren’t at risk of criminal punishment for well-intentioned mistakes.
  • Recurrence: Given the severity of these incidents, you need to be absolutely sure you are doing every possible thing to prevent recurrence.
  • Follow-through: Following an incident, official governing bodies change official rules or laws.

This all makes sense. A plane crashes once in the Toledo airport in 50 years, we gotta make sure the person who screwed in the lug nuts isn’t afraid to tell us that their wrench did seem a little loose that day.

Blameless in Software

Post-mortems in many software companies happen regularly. Many companies do weekly incident reviews. The properties of software post-mortems look like:

  • Severity: Comparatively, most software incidents aren’t that bad. Your average incident might be something like an API going down for 5 minutes. You gotta fix it, but they’re not hauling bodies out of the bay.
  • Frequency: Frequent. Often weekly.
  • Punishment: Listen, if you cause a 5 minute API outage and we’re holding you accountable, you’re probably not even getting rated Below Expectations at most companies. Do it twice and you probably are. Do it three times and you have to go find another job that might pay you 10% more. You’re not going to jail.
  • Recurrence: We do want to avoid recurrences of software incidents. It’s very important.
  • Follow-through: Follow-ups are typically owned by teams, often with medium-level priority, sometimes forgotten.

Software vs Aviation/Health

In summary, software post-mortems are much lower severity and much more frequent than aviation or healthcare post-mortems. In fact, they’re so common that they’re a critical part of regular accountability and learning in software organizations.

As a result, software culture becoming too blameless is just as bad as being too blameful:

  • Individuals and teams miss the opportunity to learn. Without actually saying whose fault something is, people can end up living in a world where they never hear the thing that they need to hear most - this one was on you and you must change what you’re doing.
  • Because follow-ups are not as fanatically and centrally implemented, the key driver of quality is accountability, not new rules. When you obscure accountability in software incidents, you create sustained mediocrity.

Said another way, the severity of an average software incident is not so bad that it’s worth the non-accountability of a blameless approach. As a result, it’s critical that software post-mortems tweak these practices to more effectively serve their needs.

Blameful Postmortems - A Goldilocks Solution

There must be a middle ground where we can achieve all of our goals. Blameful Postmortems should have the following properties:

It’s Somebody’s Fault

An absolutely critical part of every post-mortem is that it’s somebody’s fault. Every issue is either:

  • Someone’s job and thus their fault when it fails
  • Nobody’s job and the fault of the leader who has an ambiguous organizational design

Note: it must be primarily one person or one team’s fault. If it’s multiple teams that are allegedly at fault, it’s the same as no teams at fault. Driving to the core of who should have prevented an incident is often one of the most fruitful exercises in refining and clarifying responsibilities.

There are no exceptions. Common examples are:

  • It’s a third party provider, how can that be my fault? You picked the third party provider, you need to own their outcomes.
  • I inherited this thing and never worked on it, how can that be my fault? You might not be in a ton of trouble for this failure, but it’s still your responsibility.

Note: the word fault here is knowingly a bit harsh sounding, but it’s used intentionally. Other words start you on the slippery slope to blameless avoidance. Every incident should have had someone whose job it was to own the prevention or risk mitigation.

Accountability Is Fair

A key failure with most blameless cultures is that people believe it means you don’t have consequences when things break. That’s a non-accountable culture. That’s nonsense. A good post-mortem and engineering culture promises that people will be held accountable in a fair and balanced way.

For example, if there was really no way that you could have been expected to prevent an incident, it might still be your fault, but you might have 0 repercussions. We might walk away agreeing that next time is the one you’re expected to prevent.

On the flip side, if you really messed up, you might get fired. If we said we’re in a code freeze and you YOLOed a release to try to push out a project to game the performance assessment round and you took out prod for 2 days, you will be blamed and you will be fired.

Most repercussions are a middle ground. Good culture doesn’t mean people face all-or-nothing repercussions - it means they face the appropriate accountability.

The Right Incentives

As a quick aside - I absolutely hate how most people treat incentives. So many leaders act like incentives are the only thing you can expect people to follow.

Hey, my top sales guy sold a $1M deal but did it at -90% margin, but there was no rule against it, so what do you expect?

Hey, you created this process of always holding people accountable to incidents, don’t be surprised when people hide stuff, right?

Horse apples. Nonsense.

There is one main incentive that all employees have - act with high integrity or get fired. Stop excusing people for bad behavior because your little point systems don’t cover every case of common sense.

So, as it applies to post-mortems - be clear with your team:

  • Everything is someone’s fault
  • Something being your fault doesn’t mean it’s a huge deal. Most things are not.
  • If you game the system, hide information, or otherwise prioritize your own rewards over the health of our company, you will be subject to disciplinary action up to and including termination

Blameful Postmortems - Final Thoughts

Software isn’t aviation or healthcare, so let’s stop acting like it. Post-mortems are good. Focus on non-recurrence of incidents is good. Let’s keep doing those.

But not having accountability for failures is bad. Let’s stop doing that.

Finally, leaders make or break processes like this. The worst leaders are overly blameful and punish people unfairly, often this is to cover their own tracks. As we make it back to a more healthy culture of appropriate blame, let’s make sure that leaders are held accountable as well.

Delegating Complex Tasks

2025-03-10 08:59:22

Many leaders struggle with complex delegation.

Failure to delegate often makes you a bottleneck. There are few things more demoralizing for a team than spending days trying to get a leader to do something that takes them minutes,

Failure to delegate also creates key person risk, leaving you as the only person with critical knowledge, and, as a result, the only person to call when that knowledge is needed. Getting repeatedly paged at 3am because you didn’t delegate is a literal wakeup call.

Most leaders can delegate simple things - e.g. teams, metrics - pretty well. Most leaders struggle with delegating complex skills or responsibilities.

Herein we’ll discuss two proven methods for delegating complex tasks that you can use right away.

Exponential training

The types of problems that are especially prone to growing key person risk tend to have the following traits:

  • The problem requires deep knowledge
  • That deep knowledge can only be gained through lots of at-bats
  • There aren’t a lot of at-bats available

A great example here is the plight of The Database Guy. The Database Guy at your company is often someone who was there early and had to wrangle all the database issues. Then they realize that to scale they need to get other people to understand the databases too. Often this realization comes when the failure to delegate means they’re getting paged constantly.

So The Database Guy does a training on indexes and sharding and networking and query optimization and throttling operations and restarting tiers of hardware and how to get ahold of someone at your third party provider who can fix your problem. They then nod contentedly and figure they’ll get some much earned sleep. That night the Database Guy gets paged again.

The problem is that you don’t learn deep skills by watching a PowerPoint. You learn them by doing. But complex, high-risk problems (like database failures) don’t happen often enough for passive learning to work.

The way to solve this is via Exponential Training. Exponential Training works like this:

  • Train one person deeply. Instead of running a big seminar, work one-on-one with a single person for a quarter.
  • Give them real at-bats. Have them handle database issues for all teams, not just their own. Make them the primary responder.
  • Use historical incidents as practice. E.g. set up real-world drills in a dev environment.
  • Repeat. Each trained person teaches someone new the next quarter. After a year, you have a whole bench of experts.

When done right, it only takes 12-24 months to get a sizable set of people really knowledgeable on a deep skill.

Most people do not do this because:

  • It’s perceived as slow. This is a classic rabbit and hare issue.
  • Leaders don’t know how to get people the at-bats. Often a leader has access to much more data or opportunities than other people and this encumbers other’s ability to get experience. The answer is to give people more access.

Especially if you have deep key person risk at your company, consider exponential training as a slow-to-start, fast-to-finish process for actually solving your problem.

Suboptimal Standardization

Suboptimal Standardization is the idea that you should be quick to delegate complex problems as long as they have checkpoints for quality control.

The problems that require Suboptimal Standardization have similar conditions as ones that require Exponential Training - low opportunities for hands-on training and deep knowledge required. The difference is that Suboptimal Standardization problems can have quality control checkpoints.

Two good examples here are making offers to candidates and budgeting processes. Leaders often own these processes beyond the point at which they have become a bottleneck. Leaders delay delegating them because:

  • They think it’s too complex to delegate. One of the biggest hurdles to delegating a responsibility is that some leaders don’t know or want to admit that their decisions actually aren’t that complicated. Decisions are almost never that complicated and failure to articulate how decisions are made should speak more to the weakness of a leader than further the mystique of their ability.
  • They claim it’s important to be able to optimize. In reality, the benefits of delegating almost always far outweigh any optimization you’ll ever do. This is especially true once you’ve become a bottleneck - when you don’t have the time to do any real optimization anymore.

Let’s explore the example of making offers to candidates.

When you decide how to make an offer to a candidate, you have to consider interview performance, market changes, equity, bonuses, competing offers and more. There are many things to consider, but there aren’t that many things. The complexity is enough though that many leaders decide to treat it more like an art than a process.

When I was at a company at the size where department heads created all offers, I personally held onto making offers for a long time because it seemed impossible to get others to consider all of the factors involved. I needed to get it right, so I held onto it.

Eventually I became a bottleneck and it caused problems. Once that pressure forced me to reconsider, I realized two things:

  • What I was doing was actually not that complicated.
  • I was prioritizing little micro-optimizations vs speed of execution and federated ownership

So I challenged myself to really write out what it was I was doing, and I made a system that looked like:

  • Step 1: If interview performance is X for role Y, the offer is Z.
  • Step 2: If they negotiate, here are the standard counter-offers.
  • Step 3: If there’s an exception, escalate to me.

Everything got better once I delegated making offers. This is because:

  • Giving my team the ability to run this process gave them the ability to think about the rules and optimize them.
  • Candidates got fairer, more predictable outcomes.
  • Recruiters could avoid mis-representing compensation ranges due to clearer expectations.

When you find yourself as a bottleneck on a complex decision, create a Suboptimal Standardization. To do this:

  • Force yourself to write down a decision tree of how you actually make decisions
  • If the factors you consider include information your team doesn’t have access to, give them that information. Similar to Exponential Training, this is often a major blocker to delegation and you need to rip the bandaid.
  • Set up an approval process. When you make approvals, tweak the process as you notice things you hadn’t coached people on.

If you do it right, Suboptimal Standardization quickly becomes more optimal standardization.

An Afterthought

It was only through writing this post that I realized how often access to information is a throughline in delegation failure. Per the examples above and more, this often happens because:

  • Giving people access to messy information can be stressful or risky. For example, giving people access to all recruiting offers being made across all teams (beyond their own), creates risk. In many cases it’s a form of showing your work that leaders prefer not to be judged by, or exposing harsh realities you’re afraid of making people aware of (like some teams getting paid more than others).
  • Leaders can have egos around information access.

If you’re bottleneck at anything as a leader, challenge yourself to consider if information asymmetry is a problem you’re creating. Amongst the other benefits, I’ve found that trusting my team with sensitive information has often deepened trust (in both directions), grown leader maturity, and increased fairness faster than almost any other thing I’ve done.

Judge Your Coworkers

2025-02-17 20:59:22

One of the most counterproductive things that companies do is coach people to not judge their coworkers. Having an understanding of your coworkers’ performance means that you understand what they do, and understanding what they do is critical to making sure you collaborate with them effectively. This is especially important if you’re in a leadership role or a cross-functional team. Also, raising the alarm on peer underperformance can be both necessary and highly impactful.

A Sad Story

In the early days of a startup, teams are in survival mode - if you’re not pulling your weight, we’re not sharing food with you. Startups that became successful rarely stifled peer feedback in the early days.

Then you hire more vocations. As you add PM and Design and Product Marketing, you eventually hit your first conflict between these groups. It’s usually an engineer alleging that another vocation is not doing their job because, amongst other reasons, engineers are usually hired first (more tenured). And then the big lie begins - you don’t understand what we do, stay in your lane.

Your company dies a bit on that day.

Eventually someone again alleges someone is not doing their job, and the leader of the target employee agrees with the assessment, but they’re not gonna let someone who’s never been in their shoes tell them how to run their team. So they drag their feet and nobody does anything about it.

Your company dies a bit more on that day.

Meanwhile, the leaders you’ve hired are trying not to get into fights while ramping up, and your CEO is trying to avoid criticism that they don’t know how to hire executives or manage different kinds of employees. Everyone is trying to avoid being accused of being a fraud; they don’t cast judgement on others to avoid getting judged themselves.

Finally, you get to a place where there’s enough mediocrity that the few truth tellers left start to get punished because they’re the only ones who won’t pretend that standards have fallen.

As then your company is officially dead.

You’ll make it until the last of the good tenured leaders stick around to keep the boats afloat. Eventually the whole company will be mediocre and a company that throws underperformers off the island will invade and take your land.

A Different Way

It doesn’t have to be this way. In fact, with the right guidance you can encourage your team to judge their coworkers’ abilities, learn from it, and have it be part of a healthy ecosystem of accountability and growth.

Here’s how to do it.

Ground Rules

First, things fail when people start attacking others directly and publicly. People can disagree in meetings, but people should not be making judgements on their teammates in public. Performance is public, performance management is private. Make it clear to your team that any and all feedback shared on a coworker’s ability is shared either in a private conversation between a person and their own manager, or in the peer feedback section of a performance review.

Second, follow-ups are done privately. There is never the expectation that people are privy to the details of some else’s performance management. That said, if a peer’s performance is causing significant issues for an individual, team, or the business, it may be appropriate to talk about how to work around those issues while performance management is happening.

Finally, you must make clear that nobody is promised a perfect coworker. All teammates are imperfect, and the average action is not termination but coaching. One of the teachable moments in a discussion about peer performance is making clear that people are expected to succeed despite imperfect coworkers; imperfect coworker performance is a reality, not an excuse.

How To Do It

OK, here’s how to productively encourage your team to think about evaluating their coworkers’ performance.

First of all, you should set an expectation that your reports actually have an opinion on their peers’ performance. Sometime in the first few months you should say out loud something like: We strongly value peer feedback and the ability to understand and evaluate peer performance. As we work together, I’ll periodically ask you how your peers are doing and I’d like you to be able to have thoughtful conversations about it.

Furthermore, if they’re in a leadership position, you might add something like: It’s quite important that you have a mature opinion on how your cross-functional partners are doing. Please make sure that you’re thinking about the different roles and responsibilities you share, how they are performing, and where you see opportunities for improvement.

Next, you should periodically ask your report (e.g. once every 6-12 months) how they think their peers are doing. This is now when the productive conversation starts.

If they think someone is doing well, why? This is a teachable moment - what do you think good performance looks like? Through this exercise you can help people understand:

  • The difference between superhuman performance and expectations (people often glamourize or mythify people just doing a really good job)
  • The ingredients of certain people’s success. Sometimes it’s as simple as highlighting that a strong performer works really hard.
  • The differences in leveling and experience. That person is doing a solid job, but they’re three levels above you and a lot of what they do is quite expected in role.

If they think someone is doing poorly, why? Again, this is a very teachable moment. It’s a critical opportunity for you to be aware of underperformance, the perception of underperformance, or a misunderstanding. This is often a great opportunity to help people understand:

  • What the role of a person actually is. Many times critical perceptions are driven by a misunderstanding of what someone is actually supposed to do. No, actually, your PM is not your project manager.
  • The differences in leveling and experience. Sometimes people think someone isn’t good at their job, but they forget that they are 4 levels beneath them in the ladder.

These conversations are also a very important way to get real time updates on the performance of teammates. Getting significant critical feedback from many people about a specific person is almost always a signal of underperformance. Getting this feedback in a continuous fashion is quite valuable, as many companies leave it to very infrequent performance review cycles to solicit that signal.

Finally, an awareness of the strengths and weaknesses of a peer lets people supplement their work more effectively. OK, Bob isn’t great at meeting follow-ups. His manager can work on that for him, but can you, as someone who is great at it, help the team not fail when something is missed?

Closing Thoughts

All of this boils down to not letting tension relief run your company.

When people work together and things fail, it’s somebody’s fault. One of the most evil things a company can do to people is not hold people accountable. I’ve felt bad for people who have had mean bosses, but I feel terrible for people with overly protective bosses. I’ve seen people literally ruin their career because they spent years under a manager who didn’t have the guts to give them feedback, even when other teams were complaining.

Especially for leaders, not knowing how to evaluate the performance of your peer leaders is a major miss. If you don’t know what they’re supposed to do, how can you make sure you’re working together to create a business outcome? How can you improve processes across your vocational boundaries if you don’t even know what their job is? This is why it’s important that all leaders have some sense of how the business fundamentally works. This is why telling people to stay in their lane is so messed up - the minute you tell someone they couldn’t possibly know what they’re talking about when it comes to other vocations, they can never be held accountable to end to end business value again.

And for junior hires, how can they learn without knowing what good looks like? How can you learn what good looks like without ever having the ability to point to someone and talk about their performance?

Judge your coworkers, lest you not be judged, because to not be judged is to never learn.

Assorted Notes

  • Holding people accountable doesn’t always mean severe punishment. In fact it almost never means severe punishment. At a small scale, it simply means having clarity on who actually owned a thing that didn’t go well. At a large enough scale, it should mean some action is taken, and that action should be referenced in performance reviews. A lot of the industry moved too far into blameless culture in the last decade. A lot of stuff is someone’s fault, and it’s ok to say it.
  • It really is inexcusable for a senior leader to not have a point of view on a peer’s performance. Senior leaders should be knowledgeable enough to evaluate and heavily incentivized to care how their peers are doing. Apathy from a leader about peer performance is smoke that one or both of those is not true of the leader you’re evaluating.
  • One of the biggest opportunities of letting people judge their peers is coaching them when they’re wrong in that assessment because they don’t understand the person’s role. Very few people have intuition about other roles and responsibilities, and almost no companies are going to make explicit time to teach you about them. These conversations can be one of the only places to learn what other people are supposed to be doing.