But if you’re going to make the most of startup people you need to know how to work with them. And if you want to work with startup people, you need to know how to manage their tendencies – including one of their most distinctive traits, which I call high amplitude disagreeableness.

High Amplitude Disagreeableness

Disagreeableness is kind of like a sound wave. Waves have properties of:

• Frequency: In this case, how often someone is disagreeable

• Amplitude: When they actually disagree with something, how intense is the dispute? Do they let things go, or are they righteously upset, insistent, and willing to go all out to make sure that their opinion is followed (or at least fully considered)?

Amplitude vs. Frequency

Some people are basically argumentative and combative all the time: high frequency. Others are actually very genial and (usually) conflict-avoidant: low frequency. That’s just human nature.

But all startup people share an ability to reach an extremely high amplitude of disagreeableness – if you’re really wrong, they will fucking nuke you from orbit, and they are willing to get in front of the entire company and call you an idiot because it doesn’t bother them one bit if there’s an audience when they push the big red button. One of the defining traits of a startup person is their willingness to disagree publicly, even with senior people, and to remain insistent over a long period of time – for example, fighting to change a bad process or build the right product even if it takes years. When you see a mid-level person politely but firmly disagree with some member of the C-suite in front of a hundred people, you’re seeing the startup spirit at work.

Subscribe now

What To Do

This pattern of high amplitude disagreeableness among startup people is essentially universal in my experience. As a result, if you want to tap the intensity of an entrepreneurial team, you will need to contend with (or harness) this pattern of behavior. There are a few management implications if you want to attract, retain, or deploy entrepreneurial talent.

First off – what creates this trait? Startup people tend to view their jobs in terms of creation instead of the more typical approach of viewing your job as extraction. If you’re just trying to extract value from a company, it’s really important that people don’t dislike you – and disagreeing vehemently is a pretty quick way to be disliked.

What this means is that if you never seriously disagree with people, even when it’s warranted, startup people won’t respect you. Your inability to reach a high amplitude of disagreeableness is actually an indicator that you aren’t a part of the tribe: You’re an extractor not a creator. They are people who are willing to fight for what they believe in with righteous anger; if you aren’t the same, they’ll think that you’re weak at best or lack integrity at worst. Startup people will quit working for these sorts of managers.

Additionally, you can disagree very strongly with startup people, even in public, and they’re surprisingly likely to just brush it off. Big-company corporate types hate getting pushback – it challenges their authority, and the perception of authority is how you climb the corporate ladder. High amplitude disagreement destabilizes existing power structures because it levels the playing field – it lets people step out of their lane to make change as long as they have enough conviction. Startup types don’t exactly like being challenged, but they recognize it as necessary at times, and a sign that someone actually cares. You can often recognize a healthy entrepreneurial culture because it accepts people being highly disagreeable (within reason) without permanently branding them as a troublemaker.

You also need to have a culture where strong disagreement doesn’t lead to punishment or ostracism. This can be surprisingly challenging. If you manage entrepreneurial startup types, you will find yourself explaining, defending, or occasionally apologizing for the fact that they very intensely disagreed with someone else surprisingly often. It’s essential that you create a culture that can accommodate the fact that there are going to be some intense arguments, while also making sure that your workplace stays professional and pleasant.

Finally, startup people really tend to hold grudges if you’re confidently wrong. At the root of high amplitude disagreeableness is a belief that the truth is knowable and that it matters, deeply. Startup people are running software where their conviction meter maxes out at a much higher level. This means that if you’re wrong in big ways, and you don’t correct it, startup people are guaranteed to remember and hold it against you since they believe that the difference between right and wrong really matters. Corporate types might hold their noses and put up with outright incorrectness, but startup people won’t. If you want to lose the startup people on your team, the most reliable way is to be confidently wrong.

Share to Twitter , Hacker News, LinkedIn

Subscribe now

Here’s how to think about management in 2026.

Managers Must Be Builders

Managers must be builders in 2026 for two reasons.

First, you have to learn AI tools. Without a deep understanding of how people build and execute with AI, you will be completely clueless about what to expect from your team and how to guide them.

This cannot be overstated.

A manager’s job is to do things like help people get better at their job and set expectations. Without hands-on fluency with AI tooling, you will be fundamentally unable to do these things well. It would be like trying to manage a software team in 2015 without knowing how to use the internet.

Second, building is often the most efficient path for the team. In the old world, a manager might spend five hours in meetings defending the team’s time against a drive-by request from another team. In 2026, the manager should just spend an hour and build the damn thing.

Managers must build because not building is now the bigger waste of time.

Managers Must Expect More

People have incredibly powerful tools at their disposal and companies are spending real money on them. Managers have to raise expectations of output. This will require willful effort, but that effort must be taken.

If you need a cheat sheet for raising expectations:

• The trickle test. There is no longer any excuse for people not to have a steady stream of small things getting done alongside their main work. Bug fixes, small improvements, documentation — these should be flowing constantly.

• Partial work is no longer partially acceptable. Whether it’s competitive intelligence, scanning the ticket backlog for signals, or writing tests — the “I ran out of time” excuse doesn’t hold when your tools can do the grunt work.

• Outcomes over output. People need to add value to the business in ways that are obvious. More than ever, individuals must be end-to-end owners of business outcomes, not just contributors to tasks.

AI tooling is also putting immense pressure on underperformers. Engineers who can’t review code effectively. PMs and Designers who are bottlenecks. Leaders who can’t adapt to change. 2026 is going to put everyone below the bar underwater, and you need to be ready to step in.

Managers Must Manage Budgets

AI tools are moving to consumption-based pricing, which means managers are going to have to think about how much money to invest in each individual. This is a massive paradigm shift. It’s like if you had to decide every month how good of a laptop each person on your team gets, and sometimes people run out of laptop halfway through the month.

Start thinking through these challenges now:

• Should a more senior person get more AI spend than a more junior one?

• What’s the maximum you’d spend per person if you could clearly see results?

• What do you do when a high performer runs out of tokens halfway through the month?

• What do you do when a high performer is upset they don’t get more tokens?

None of this has established best practice yet. The managers who figure it out first will have a meaningful edge.

Goal Clarity Is Non-Negotiable

With more tooling and raw power than ever, your teams need precise goals. The fuzziness that used to get figured out later during slow build cycles will now kill you in the short run.

When your team can build fast, building the wrong thing is the primary risk.

Make sure your teams and individuals have precise goals, or you’ll spend $10k per person per month on AI tools and find out it all added up to a pile of features that didn’t move the business.

Collaboration Needs A Forcing Function

Documents are getting longer. Code is getting more verbose. Toolchains are exploding in complexity. Everyone is heads-down with their personal fleet of agents, cranking out work in parallel.

This is great for raw throughput. It is terrible for coherence.

Collaboration in 2026 requires intense, deliberate focus from managers. Week by week, you will need to pull people out of their individual sprints long enough to make sure they’re all running in the same direction. If you don’t force this, your team will ship fast and end up with a product that feels like it was built by five different companies.

Hire Like It Matters More Than Ever

A mis-hire in 2026 is catastrophic. The delta between a great engineer with AI tools and a mediocre one with the same tools is not 2x — it’s 100x. One ships compounding value. The other ships compounding slop.

Raise your hiring bar now or spend the rest of the year cleaning up after it.

Summary

Management is not dead. In fact, 2026 is the year where management becomes a key differentiator between teams that win and teams that drown in their own output.

This is the year you need to adapt faster, expect more, and start building again.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

Some teams have emergencies regularly. We need a new report; someone has to put together a presentation; we need to change plans to incorporate new feedback. Other teams essentially only have emergencies due to exogenous or hard-to-predict factors: us-east-1 went down; we’re getting sued; our CEO got in a car crash. This variability is universal across industries and company sizes; I’ve even heard of non-profits with a culture of constant emergencies. Madness.

As you would expect, better managers have fewer emergencies, and worse managers have more. And at the extremes, it’s common to find that the best managers basically never have preventable emergencies, and the worst managers have teams which are constantly in a state of emergency, to the point that they’re 100% reactive.

There are a few factors that contribute to a very significantly lower rate of emergencies on well-managed teams, and happily they’re easy to copy:

Good Managers Know How Hard Things Are

One of the dumbest form of emergencies is simple underestimation of the amount of effort required to get a team’s projects done. Good management can prevent this in a few ways.

First and most importantly, managers need to be deep experts in what their teams actually do, and put in real effort to stay informed. If they’re an engineering manager, they need to be a solid engineer themselves and also stay up-to-date on the state of the technology that their team owns, their biggest challenges, and their capabilities. Bad managers love to black box their teams in the name of delegation: “I shouldn’t need to inspect what’s going on with my team, they should just handle it.” Good managers trust but verify by staying informed before delegating. They know if that report they’re suddenly asking for is easy or hard to produce.

Next, good managers just ask questions. Contrast two identical situations where an ask came from your CEO:

• “Hey, I really need a report on how project X is going – what would it take to get that this afternoon?”

• “Give me a report on project X TODAY”

Simply asking the question resolves a surprising amount of emergencies before they get started. If it’s truly impractical to get the report this afternoon, it’s better to just find out upfront rather than pulling all of the fire alarms immediately.

Finally, good managers set expectations and communicate reasoning. “I need you to get me a report on project X but if it’s going to take more than 30min let me know before you do anything. I want to get a readout to a new sales prospect but it’s not essential.” Especially when seniority gaps are large, a little expectation-setting goes a long way.

Subscribe now

Good Managers Know What’s Important

A huge amount of artificial emergencies stem from managers who don’t understand what is actually important for their teams.

If you don’t know what matters for your team, the latest thing that just popped into your brain often feels critical. If you didn’t have strong conviction about whatever project was in-flight, any new good idea always seems like it could be worthwhile. Bad managers can’t stay on target, and because they can’t stay on target they never say no to new work, creating constant emergencies for their teams.

A simple technique that works here is to always make sure that you have very strong conviction that what your team is working on matters, and actively force yourself to make sure you always know why their roadmap is important. This is critical to give you the courage to push back on the worst sorts of emergencies: executive requests like “[CEO] needs a full proposal on how we’d tackle this idea today.” If your team is really working on business critical needs, responses like “we can get you that after [critical work] is finished” or “how about we get you 5 bullets and a summary, because we’re finishing [work we all agreed matters]” actually become available arrows in your quiver.

Good Managers Have a Mental Model of Their Team and Company

This is a more subtle concept, but one of the most important.

Good managers have a strong mental model for how their team operates and the role it plays within the company, and have a strong understanding of the state of the business and industry. This empowers them to more accurately forecast what will be needed of their teams in the future.

For example, let’s say that I’m running a Product Design team. I know that my team currently outputs pictures of what we’re going to build. But I also know that AI is shaking an already dynamic landscape: for example, there’s more AI prototyping including from non-designers, a rise in vibe coding, and all of this amid rising UX standards for enterprise software.

With this simple mental model, I can make a number of moves that will prevent emergencies down the line:

• Invest in AI prototyping tools so that we’re staying at the forefront of the industry; when your CEO comes in and says “I just tried Lovable and it’s awesome, are we using it,” the team will already have a well-formed opinion and momentum

• Invest in a framework that all teams can use for vibe coding

• Hire fewer, more senior designers and preferentially allocate them to more complex parts of the product where AI prototyping tools are least likely to suggest workable solutions

This concept always reminds me of college-level math. If you take college-level electromagnetism, differential equations, or probability and statistics, you’ll often find that there are two ways to pass your tests:

• You can memorize a bunch of heuristics for how to solve certain problems, and skate by via pattern-matching

• You can actually internalize all of the material, so that you can solve any problem covered by the source material that you’ve learned

To really prevent emergencies, you need to be in the second state when it comes to your team.

Good Managers Care

And finally… good managers simply care more about their teams’ well-being. And if you care about your team, you’re much less likely to throw a hand grenade into the room and walk out the door while your team is still inside.

Despite the many bitter comments that you hear on internet forums and bars at 5pm, in my experience many managers really do care deeply about their teams. I’ve had so many conversations with managers who are working their butts off to prevent emergencies from impacting their teams.

The simple fact is that in many cases emergencies are a choice – specifically, they come from making the choice to satiate some desire by sacrificing your own team’s time. You can prevent this: you just need to care more about your team’s long-term productivity than a short-term boost to your career or mental health.

Takeaways

One of the best parts of following this advice to prevent emergencies is that it really will make your team happier and more productive, and it will do so almost immediately. Nobody wants to live in a world of constant emergencies, but it’s all too common across every industry. Great people want to do great work, and a culture of emergencies is anathema to the focus that great work requires. If you can find a way to keep your team operating from a level-headed playing field, you’ll have unlocked one of the best talent retention mechanisms that exists.

Share to X, Hacker News, LinkedIn

Subscribe now

The intuition is simple:

• Great engineering (fast, reliable) is irreplaceable. Very-good to great design can be rented or borrowed; great product-market fit can ultimately be accomplished via luck or trial and error.

• Great engineering accelerates PM / design much faster than great PM / design accelerates engineering.

• At an even deeper level – the very best engineers are often great at product or design. The very best sales leaders often have great marketing instincts. But your best PM is worthless without an engineering team (unless they start coding themselves). Your best marketer is useless without a sales team (unless they start selling).

• Great sales is necessary to solidify product-market fit (PMF) by building a brand – sell to better customers, make them happy, build your brand – and brand is one of the most powerful compounding forces in business.

• Sales execution is the engine that makes SaaS scale. In some cases, product-led growth (PLG) can succeed without a real sales motion, but those cases are a rare and distinct minority.

• All other functions, while important, don’t move the needle on your company’s core axis of value delivery.

This truth is so clear that it can be used as a litmus test for whether you have any idea about what the hell you’re doing in SaaS. If you find someone who doesn’t intuitively understand why these two teams make the world go ‘round, then you clearly haven’t been in the business for real.

The prominence of engineering and sales may seem like a trivial observation, but it actually comes with a number of very important operational takeaways.

Subscribe now

Know Your Place

A lot of people struggle with this, so I’ll just say it plainly – if you’re not in sales or engineering, you need to know your place. As a product manager myself, I’ll describe this in terms of how I want my teams to (ideally) work with our engineering counterparts:

• We ultimately only deliver value via engineering. Without customer insight, good designs, or PRDs, engineering could eventually muddle through. Without working code we deliver no value.

• As specialized partners to engineering (and to a lesser extent sales), it’s essential that we stay focused on areas that will maximize what those teams deliver – whether that means identifying the most efficient path to customer value for engineering, figuring out how to make sales cycles go faster, or identifying exactly how we can make a big marketing splash with our product. We need to propel those teams to do more.

• We need to move especially fast when working with engineering and there is value in saving their time. For example, if we can test a hypothesis with a week of manual PM time that would take a week to verify with engineering effort, we would probably accept that trade.

• If our team isn’t adding value on a project (for example, a PM simply isn’t working out and we verify that), and engineering doesn’t want them involved, we should find someone else to work with them or just pull PM off of that project. Engineering is the customer.

• Our job is to get the highest value code to our customers, and monetize it. We share a bucket of resources with engineering (the company R\&D budget). We need to carefully scrutinize whether we’re using the right amount, rather than taking whatever we can get away with politically, since there’s a direct tradeoff between our team and engineering.

This doesn’t mean that you should just do whatever engineering (or sales) wants. If sales or engineering are incompetent you need to deal with it.

But you need to assume that all else being equal, their immediate priorities – writing and launching code; closing deals; renewing customers – are at or among the very highest priorities for the business as a whole. For example:

• If the sales team is focused on closing the quarter, it’s not the time to run performance reviews

• If the engineering team is working on a production incident, review of your next Figma mock is delayed until the incident is resolved

• If we’re down to our last $200k, our default is to spend it on the next engineer unless we desperately need a PM

Sales & Engineering Execution

If you’re actually leading a sales or engineering function, there’s a lot of pressure on you to perform.

As a company matures and grows your job will evolve, becoming more complex, with higher standards. You need to constantly improve at your job as well. This might be an academic exercise if you are, say, an HR team. But if you’re one of the two most important teams at a company you can literally be solely responsible for killing an otherwise thriving business if you don’t evolve fast enough.

The criticality of sales and engineering leads to a paradoxical situation:

• In the short run, these teams often have very high job security. Nobody wants to rock the boat even if it has a few holes in it.

• In the long run, these teams have very poor job security if you aren’t excelling. The CEO, board, and investors are constantly assessing the strength of sales and engineering and overhauling these teams can be the answer if things really get off track.

Since sales and engineering are the pace-setters of an organization, there is no such thing as “good enough.” You will always be compared to the best team that the company believes it could theoretically build. Nobody wakes up in a cold sweat wondering how they could have a 1.5x better HR team; every CEO in the world would move heaven and earth for a 1.5x better sales or engineering organization.

As a result, it’s on you to constantly self-improve, because nobody is generally going to mess with their money-making teams… at least until they decide that you’re not cutting it, at which point you’ll be replaced.

Building Sales & Engineering Expertise

If you are in an adjacent field to sales or engineering, you should strongly consider how you can build more experience in these critical fields.

In many situations, the priorities of your sales and engineering teams are going to take precedence over your own. The biggest deal of the quarter is more important than your marketing deck review; launching the rebuild of the product is more important than your PRD. This is fine and actually often the sign of a healthy business. As a result, learning about what makes both sales and engineering tick and why will help you do your job better. You cannot swim against this tide, so you need to learn how to swim with it.

The main way that I see leaders getting into bad situations is by assuming that sales and engineering are simpler than they really are. It’s fine for me to be a non-technical PM, I know the customers. It’s fine for me to do marketing without being a sales expert, I know how to build an audience. No. You need to understand sales and engineering as well as you possibly can – otherwise, you’re going to be like a quarterback who’s watched hours of Sportscenter but has never thrown a football.

Sales & Engineering Risks

The fact that sales and engineering are the most important teams means that sales and engineering failures are the largest risks to your business. If you’re at a company where these teams are weak, you should strongly consider leaving. You are highly unlikely to save the ship.

Once you see this truth, many other fact patterns start to make more sense.

• Tech CEOs are disproportionately drawn from the ranks of sales leaders and PMs who used to be engineers. There is enormous value in literally knowing how to build a product.

• PLG companies targeting smaller customers often do well despite poor economics relative to enterprise customers, because they take one of the biggest risks (incompetent sales team) off the table. Additionally, not needing to field a large sales team allows companies to overinvest in engineering, which often brings massive advantages – many of the most successful SaaS companies have a PLG motion. Unfortunately, PLG business models only work for certain industries.

• Y Combinator, probably the greatest early stage investors of all time, have an extremely strong preference for funding companies that have engineering expertise on their founding team. De-risking engineering is that important.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

AI was the story this year and it often left little air in the room for other topics. At different parts of this year: management was declared dead, SaaS was declared dead, blogging was declared dead.

And yet here we are. All of these things are not dead, just changing.

We look forward to another exciting year of writing, tweeting, and engaging with the great Stay SaaSy community. We’re confident that blogging, management, and SaaS will still be here this time next year. But we believe they’ll likely be meaningfully different, and that things are only speeding up from here.

We’re excited to go on the next part of this ride with you.

Top Posts

• Advice For Individual Contributors

• Own A Graph

• Leveling Up Teams Fast And Slow

• No Pain, No Gain

• Your Manager Is Not Your Best Friend

• Tips For Better Interactions

• Delegating Complex Tasks

• This Is How You’re Eroding Your Accountability

Top Tweets

Podcast

We did several episodes of a podcast this year!

Podcasting was a new format for us and certainly something we haven’t learned to be consistent at. We also used voice modulators to stay anonymous and we got feedback that for some people it was a bit too much.

If you enjoyed the podcast or have feedback - let us know! We’re going to try it a bit more this year, ideally with some software that gives us cooler voices.

Subscribe now

Share to Twitter , Hacker News , LinkedIn

Make Breakthroughs

Individual contributors have the special property that they can get real work done. Managers are often constrained because their leverage is through people, which often means slower and steadier change.

ICs can bypass this. You can work a weekend to deliver a working prototype. You can spend nights finding an insane performance optimization. You can Proof-of-Concept a feature scheduled for next year.

So much of a company is bound by risk assessment, expected timing, and prioritization minutiae. Finding a genuine breakthrough cuts through the bureaucracy and fundamentally shifts the timeline.

If this work is so important, why isn’t it prioritized? It’s not prioritized because if you make it part of the day-to-day, it gets bogged down and dragged out like everything else, often resulting in sunk time with nothing to show for it.

By taking a calculated risk on yourself—the risk that you might fail—you can deliver a breakthrough that dramatically increases your value and the company’s. Occasionally, ICs should go all-in, work intensely, and find a breakthrough.

Act Like A Leader

If you want to be a leader, you have to act like one.

That begins with being optimistic, not starting or encouraging big commiseration sessions with more junior people, not trying to set up an us-vs-them dynamic against “management” or treat other company structures like the bad guy.

Many senior ICs think it’s their job to be the union rep for ICs. The only thing that actually accomplishes is undermining your own credibility. It doesn’t deliver the value that would make people’s bonuses go up, and it doesn’t change hearts and minds.

But you also shouldn’t be a shill for management.

Like it or not, your job is to be an unaffiliated, unbiased leader, and doing what’s right in individual situations.

Take Specific Ownership

Another critical part of being an IC leader is owning things.

One of the specific virtues of the manager position is that it provides radical clarity on ownership - you own the team. With that ownership comes risk, reward, and accountability. The team wins, you win. The team fails, you fail.

Too often ICs get slotted into being 1 of n engineers on a team, becoming a non-unique, non-owner of outcomes. In fact, agile development processes often specifically encourage interchangeable resourcing.

But ICs should avoid taking this too far. Ownership and accountability are critical forcing functions for growth. You should ask yourself - what specifically could fail that would cause me to get less rewards? What specifically could do well that I should uniquely get credit for?

If you don’t have a good answer, you don’t have enough specific, named ownership. While ownership can come in many forms (services, features..etc), the core unit of ownership is a goal. If you don’t uniquely own any specific goal you are shortchanging yourself.

Send Regular Updates

Send regular updates.

Bi-weekly is usually a good cadence.

Send your boss a doc that says what you’re doing, what you need help with, and cc their boss.

This serves multiple functions

• Builds awareness of your work

• Builds awareness (and record) of your needs

• Forces you to reflect on the above

• Forces you to make sure you’re making meaningful progress on things every two weeks

• Forces you to write regularly

• Gives you more time in 1:1s to do important discussions (context already set on status)

• If your update is thoughtful, it also makes your own boss look good, which is strictly positive for your career

The benefits of this ritual are truly massive.

You’ll be shocked at how much better you get at self-management when forced to do it.

You’ll be shocked at how often your boss/boss’s boss can solve your problems faster when presented this way, and how grateful they will be for the clear updates.

PS if you use AI to write these updates you’ve destroyed their purpose entirely and are subtracting value.

Talk To Senior Leaders

Talk to people more senior than you in the org chart.

Seriously - book time with senior people, or ask them for 30 minutes to discuss what they think is valuable and worth doing. Senior leaders absolutely love this, because it lets them get more important work done through their team, and it often doubles as a therapy session.

Talk to five people from different parts of the business.

Then go solve one of those problems.

This is an extremely underrated activity because:

• It helps you get both perspective and ideas on ways to help the business

• People don’t do this nearly enough. Too many people do recurring skip levels that are boring and useless; too few do meetings with senior leaders they haven’t talked to.

• It’s good for your brand

• If you solve a leader’s problem, they’ll be in your corner for a very long time. If you can solve a leader’s big problem five different times, in my experience they’ll literally be an ally or direct sponsor of your career for life

Share to Twitter , Hacker News , LinkedIn

Subscribe now

The Goal of Compensation is to Create the Most Talented, Enthusiastic Team That Your Budget Allows

It might seem obvious… but your foremost goal when running a compensation cycle is to maximize the talent and enthusiasm of your team. Full stop.

• Your goal is not to make people happy

• Your goal is not to retain your team at any cost (although retention is part of the equation)

• Your goal is not to get a “deal” on what you’re paying employees

• Your goal is not to match the market

• Your goal is not to match what <other company> is paying

• Your goal is not to match employee expectations

• Your goal is not to pay equally (although part of your goal is to establish fairness)

Creating a talented team means that you can get great people to accept your hiring offers. Creating an enthusiastic team means that these great people are motivated to work for you, engaged in their work, and (in the upside case), will work much harder than otherwise due to their compensation structure. And you need to fit this into a budget that allows your business to function.

You Can’t Buy Happiness

If you spend enough time as a manager, you start to realize that:

• You can never make someone happy with compensation alone. People who dislike working on your team will quit even if they’re paid well above market

• There is no amount you can pay that will permanently increase job satisfaction; eventually everyone’s expectations will adjust

• But there is an amount you can pay where compensation alone will cause 0 marginal unhappiness on your team

To hit that final metric, you roughly want to target paying at least the amount where team members can’t easily find another job that will pay them more. (And on top of that, of course you need to try to make your work environment as otherwise appealing as possible)

The intuition here is that many jobs basically kind of suck, so if you don’t mind your current job, switching jobs is risky – and most people know that. What you want in your team’s head is some version of “perhaps I could theoretically get paid more elsewhere, but it would probably take a lot of effort and maybe the new job would suck in other ways.” This will retain most otherwise happy employees, which is ultimately what you deserve and the best you can hope for in any case.

Of course, this is easier said than done! You need to track the market, both via surveys and seeing what new candidate offers are accepted / heavily negotiated / rejected. You need to watch for attrition on your team, observing where departing folks go and why. And when you get new signal you need to react – don’t allow your compensation to get out of line with your target market percentile. But all of that is tractable as long as you put in the work.

Subscribe now

Unfairness Creates Unhappiness

But while you can’t make an unhappy team member happy with compensation alone, the converse is not true: how you compensate can absolutely make an otherwise happy team member unhappy.

What makes people absolutely furious about compensation is finding out that they’re paid the same, or less, than someone they think is less deserving. There are some people who will literally quit a company on the same day if this happens.

The best way to prevent a sense of injustice is simply to have clear compensation bands, and essentially never allow employees’ compensation to drift outside of them. Compensation bands are excellent at preventing some of the most common sources of unfairness – managers using their discretion to play favorites, and new hires making more than existing team members at the same or higher seniority (salary compression). The latter occurs regularly when market compensation shifts, hiring managers are captivated by a shiny new hire, and they allow their team to fall behind the market. Rigorous compensation bands prevent this from occurring (if you move your bands to accommodate a new hire, you need to move your existing team’s comp as well).

The most common cause of unjust compensation is simply laziness. Keeping track of everyone’s compensation to prevent unfairness or setting up a system that enforces standards takes effort, and many teams fail to do it. This is a huge mistake, as perceptions of unjust compensation are one of the ugliest and most acute sources of employee dissatisfaction. Additionally…

People Talk

Many people talk about their compensation with others. As a result, you should be willing to explain exactly why any team member’s compensation is set where it is, in front of the whole company. You won’t have to do this often, but it’s the standard to hold yourself to. The reasons that comp is uneven between employees can actually even be random or somewhat weak, but there needs to be some justification. Some common, defensible examples:

• “Alex makes more than you because they’re a distributed systems engineer and you’re a marketing associate”

• “Alex makes more than you because they’re higher in the compensation band; you were just promoted and they already have industry experience at this level”

• “Alex makes more than you because you were just hired and they have built trust over many years on the team”

• “We granted Alex their stock when our company valuation was low, so they’re making 2x market because they’re lucky”

• “Alex makes more than you because they’re better at their job”

Some of these reasons aren’t necessarily emotionally satisfying, but they’re all completely intelligible without any whiff of injustice. And injustice is the critical factor that drives people crazy.

Maximizing Upside

Since the goal of compensation is creating an enthusiastic team, there are additional ways that you need to think about pay in order to maximize return on your dollars.

The most immediate levers are performance-based compensation such as bonuses and sales commissions. The main heuristic to keep in mind for any performance-based comp is that:

• The further an action is from concrete compensation, the less it will motivate any change in behavior. Contrast the motivational impact of “Here’s a big bonus because you did a great job over the entirety of the last year” vs. “Here’s $25,000 because you closed that large enterprise contract.”

• Any action that is directly compensated will lead people to heavily optimize their behavior towards it. For example, the salesperson telling white lies to a customer in order to close a deal.

But equity is a much better lever.

If someone has 10% of their annual compensation in company equity, they will act like an “owner” the way that you act like an owner of your rental car. They’ll take care of things, generally be responsible, and won’t badmouth your company (much).

But if someone feels like their equity will change their life, most will act like a completely different kind of owner. They’ll start to treat your company like their child – they’ll stay up all night caring for it if there are issues, they’ll think about its well-being all the time. For your top performers it’s really worth getting them to that point via equity compensation if you can. If you want a quick heuristic, the most common amount of money that most people consider to be life-changing is roughly the price of a good-condition 3 bedroom home in their nearest metro area.

Takeaways

In summary:

• The goal of compensation is to create the most talented, enthusiastic team that your budget allows

• Minimally, aim to pay your most valuable team members at a level that it would be difficult for them to match in the market

• Don’t allow there to be injustice in your compensation system, and use compensation bands to enforce fairness

• You should be willing to explain any compensation decision on your team

• Maximize the value that you get from compensation via equity and well-crafted performance-based compensation

One of the quickest ways to get better at your job is to own a graph.

There are many ways to do work that don’t matter and there are many ways to do work that matters but fail to articulate that value well. Owning a graph solves both of these problems.

Solving Problems That Matter

At a senior level, you must own big problems. Basically every problem worth owning can be shown on a graph. On a multi-quarter timeframe, the things you’re doing should be visible in graph format. Things like:

• Reducing pages

• Improving performance

• Saving money

• Driving revenue

• Reducing churn

Not every bit of work you do has to be part of a graph, but if you don’t have at least one graph you’re owning, you’re not operating at a senior level.

Concise Communication

One of the most common frustrations of senior people is that their impact isn’t understood. One of the hardest truths for people to learn is that that’s a them problem - they’re not communicating well enough.

Graphs are the most powerful tool you have to communicate your impact.

People often try to explain their impact in words. They might say something like “I reduced pages by 15%.” If you send that to your leadership, good leaders will immediately have 20 followup questions. 15% from what to what? Over what time period? Did it happen all at once or steadily? Was it already declining or did your actions clearly impact it?

Graphs show all of this information right away. You see scale, history, volatility. One graph can replace paragraphs of language. You also often get a free link to the data, so the recipient can spot-check the graph to gain confidence in it’s integrity.

Further, this ability to concisely communicate impact and effort is a critical tool for getting feedback. Sometimes you’re not working on the right thing. Sometimes the scale of your impact isn’t worth the time you’re putting in. If you represent your work in ambiguous prose, you’re not going to get direct feedback on it.

Representing your work as a graph gives you an ultra-concise way to both get credit but also get feedback.

Tying It All Together

In On Achieving Goals we talked about the radical simplicity of getting things done - set a goal and check in on it.

This is an addendum to that concept - you should do that process, with a graph.

This combination is so effective that it can be the difference between high performance and unemployment.

Summary

Graphs are a critical unit of ownership for senior people to track their progress, communicate outcomes, and get feedback. If you don’t own one, fix that ASAP.

Appendix: Tips & Tricks

Assorted tips and ticks:

• You’ll know that you’re on the right track when other people reference your graph. People are lazy and if your graph is helpful and accurate you will boost your career with it.

• Your graph doesn’t have to be perfect on day 1. You’ll get feedback on it and iterate over time, and that’s fine (that’s actual ownership).

• There is an anti-pattern to avoid which is “owning too many graphs.” Some people have a thousand graphs that they “own” by showing in a meeting when it fits their narrative. You should own a few really important graphs. You have too many metrics, so the graphs you own should be few and extremely valuable.

• If you’re an engineer trying to find a graph to own, quality issues are a great place to start. Pages, incidents, bugs, performance all have graphs that are begging to be owned. If you’re a PM/designer: support tickets, revenue, competitive win rates, attach rates for retention are all great things to own.

• You don’t always need to have the ability to move the metric solo (although it’s great if you can). Just monitoring something important and following up tenaciously to move it in the right direction is enough to get your career going.

  Share to Twitter , Hacker News , LinkedIn

  Subscribe now

The first is setting up a strong product culture, establishing strong design/roadmapping practices, mapping out product processes, managing cross-functional partners, etc. Basically, being an executive that runs a strategic cross-functional team. I’m aware that “cross-functional” is one of those buzzwords that might seem to mean nothing, but I think it’s important to emphasize that PM teams tend to touch almost every project that an organization takes on, in at least some form. As a result they need to run efficient, high-quality organizations.

The second job of a CPO is aligning tightly with your CEO to set the right product strategy. Every CEO-CPO pairing falls in a different place on the continuous spectrum from “CEO sets all product vision” to “CPO sets effectively the entire product vision.” Regardless of where you fall, it’s essential that you and your CEO are on the same page. This is basically an Individual Contributor job, and is only barely delegate-able. It’s like raising your kids – you can delegate a few aspects of it but you are solely accountable and the spirit of the job must be done completely by you.

Job #1, setting the right product culture, is essential for your team to work well. Without this you won’t have enough impact. But if you don’t do job #2 well and align with company strategy immediately and forever, you will not remain head of product for long. And the two jobs are surprisingly different.

Balancing Culture and Strategy

There’s no perfect way to balance setting up the systems that build the product and setting the direction of the product itself. But you can dramatically increase the odds of success by looking for efficient ways to balance both jobs.

First off – realize that the job of setting direction is the more important of the two roles. If you aren’t perfect at setting product culture, but you’re pointing your imperfect ship in the right direction, then you’ll have time to iterate and continuously improve. But if you are great at setting product culture and point your well-oiled product building machine in the wrong direction, you’re going to get replaced. CEOs and boards of directors are rightfully uncompromising about alignment between your product strategy and the company’s direction. You can sometimes be a bit early or a bit late to pivot towards a strategy that aligns to your CEO, but going in a different direction is unacceptable.

Worth defining: Strategic alignment doesn’t mean that you just do whatever your CEO says, and that all of their ideas are your ideas. It just means that you 1. Incorporate their ideas into your product strategy appropriately, and 2. That you elevate and support your team’s best ideas. Unwillingness to admit that others have good ideas and inability to inspire others are non-starters for a head of product.

Second, it’s valuable to efficiently set up a strong, stage-appropriate operational muscle on your product team. Get the right templates in place; set up the right rituals; set the right expectations; establish the right interview plans. Because of how product teams operate (typically 1 PM per team), a team of PMs has a huge amount of room for drift; much more than other vocations. 10 engineers might all be on the same team. 10 designers will work on different products, but they’ll need to establish shared design systems and protocols for customers’ sanity (and their own). But 10 PMs can legitimately end up running 10 different products, some of which have different pricing, technology stacks, business models, and even customer profiles.

Subscribe now

Scaling Product Culture

One of the best ways to find balance is by delegating or establishing key product operational tasks once it’s clear that your team will be scaling up significantly. Be warned, however, that it can be very counterproductive to delegate product culture or process-setting to someone who hasn’t spent a lot of time building products themselves. Shipping product is really nuanced and you can’t just slap some generic template on a lot of it – the systems you set up need to be configured for your business and for a high-quality culture of builders.

For a tiny example, on my product team we spend a lot of effort curating and managing early access periods for new products due to types of workloads that we run (medium-high business criticality, very high scale). We’ve also had to devote meaningful effort alongside engineering to making sure that there are firm limits on the product due to cost/scale concerns. This is something that a prosumer note-taking app simply wouldn’t care as much about; but I bet that they care more about interaction design than we need to. You need product experts to make these sorts of calls, and can’t just hire a generic ops person.

Scaling Strategic Alignment

Scaling strategy is much harder, especially for a complex product. But luckily it can be steered individually much more easily - think about how one person can turn a cruise ship but it takes dozens to operate the engines.

One of the most important ways to run strategy is to just be a dictator. How to run your team can be a debate and active discussion; the direction that you’re going should not be.

Hiring or training people who get “the plan” of how your product is going to win is one of the best ways to get strategic alignment. Businesses are complicated; having someone who can support the company’s strategic direction without being hand-held is invaluable. The litmus test – they should jump on new key opportunities in their area of responsibility before you realized that they exist. Training enough of these people will allow your department to maintain strategic alignment without the CPO having to audit every single decision.

Takeaways

The two jobs of a head of product are hard but tractable.

It’s not that the two different jobs are inherently incompatible. It’s simply that they are each distinct jobs, requiring large amounts of effort and expertise, and it’s hard to accomplish two hard tasks at the same time. The danger comes from the fact that many people don’t realize that their job is to set both product culture and strategy, and that one of them can be worked on iteratively (product culture), while strategy is a do-or-die requirement from day 1. Keep in mind that your manager will feel an asymmetry in these jobs as well; they are the god-emperor of your company’s strategy, but you are likely more of an expert at the tactical details of building a great product team.

I suspect that the dichotomy between these two roles is also why Chief Product Officers are one of the harder positions to fill once a company gets to scale. The skills that get you hired as a CPO are all about product culture and process setting. But the skills that keep you from getting fired are all about strategic alignment, and finding that alignment with a high-octane, highly confident CEO is an entirely different skill. A lot of companies hire product culture builders because the skillset is portable, and these hires then fail to lock-in on where the company should go.

If you’re a head of product, it’s critical to realize that you have two major directives that won’t directly reinforce one another. Communication with your CEO / manager is key – help them understand what you need to do, and how far along you are at accomplishing it. That way you can keep everyone on the same page and actually do the job you were hired for.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

• Money is no substitute for money. People might like the mission, but they need to get paid right. Never think your mission can cover a pay gap.

• The All Hands Test - you will never have to defend an individual comp decision at an All Hands, but you should be able to

• Comp can make people furious, but it usually won’t make people ecstatic - the downside is much higher than the upside

• Never think a young employee is lucky for how much they’re getting paid. The market is the market.

• It’s critical that you uphold the mechanics you agreed to and not change them (e.g. if company growth means people are getting paid a ton).

There are many ingredients that go into an effective team – hiring, performance management, incentive structures, clear goal setting, streamlined processes, and more. But in the broadest sense I believe that there are two fundamental activities, one fast and one slow, that are essential to a well-functioning team and that anyone can put into place immediately.

Leveling up slowly: Teams never go backwards

The best way to ensure that your team gets better over time is to ensure that you’re constantly leveling them up, and that teams never degrade in effectiveness and performance culture.

Organizations have a natural gravity that will pull them towards the lowest common denominator that they observe around them. Let’s say that you have 5 teams, and one of them works at a slower pace, has worse outputs, or takes on a less strategic role. All of these weaknesses will provide air cover for lower performers on the other 4 teams, and ultimately bring down the quality of your organization.

The key, replicable activity to keep in mind: You should always spend some amount of time debugging your weakest team, and bringing them back up to at least the median of the rest of your teams. Over time, this will gradually improve your organization – and more importantly, it will do it in a way that is highly stable, as this evolution doesn’t require massive changes or sudden changes to multiple teams at once. At any given point in time as a manager, you have a weakest team: Some percentage of your efforts should simply go towards fixing them.

The simple fact is that it’s pretty hard to debug multiple teams at once. It is very rare to have a team that sucks for reasons that are purely their own fault. 95% of the time, once you begin debugging, you’ll find that the situation is due to some combination of poor incentives, weak partners, or misunderstandings – in addition to any raw competence gaps. And if you want to be fair (which you should!), that will require investigation and follow-up with some degree of nuance.

The solution is to focus on one team at a time, and make sure that you are always working on the most challenged team. That way, even when things seem fine in general, you’re building up a buffer of higher performance that you can bank on when times are rough.

Subscribe now

Leveling up fast: Put the best in charge

But this inexorable shift towards higher performance moves slowly. If you can debug one team per quarter (which is not a bad rate at a scaled up business), that’s a positive trajectory but a gradual slope across an organization of dozens, hundreds, or thousands. So you need a faster lever.

My favorite quick lever for performance upleveling is simply to put the most competent people in charge, regardless of their vocation or title or the shape of the org chart:

• If there’s a complicated project, put a star performer on it.

• Tell everybody else that they’re in charge (implied – until they screw it up). Let one person hold the steering wheel so the car doesn’t crash.

• If they do well, their leadership will feel natural, as if you couldn’t have imagined any other way.

Companies that are >50 people hate doing this – it disrupts the chain of command, can create the perception of playing favorites, and doesn’t follow the MBA playbook. More significantly, it requires a degree of leadership resolve that is rare among career executives – it’s politically destabilizing to your organization, and the way that you tend to get ahead as a career exec is by making your team extremely politically stable.

But it works – because one thing that you find if you operate in fast-moving businesses for long enough is that the best members of your organization are often far more competent than the baseline team member (even on really strong teams!). You can ignore this, causing top performers to become more frustrated – or you can empower them and use them like battering rams that smash your worst problems into little splinters. The latter obviously works much better, and it works shockingly fast. Like, the project was screwed up this morning, but it’s 4pm and now the entire team has a skip in their step and confidence that they never had before.

The other reason that this works is that most organizations default to having a lot of hands on the steering wheel. This is a strictly worse situation – while some cars can be driven with 3 people holding the wheel simultaneously, it tends to require extreme competence, trust, and experience working together from every single person involved. I’ve seen this rapport get established between startup founders, siblings, or a combination of startup founders and extremely early employees (first 50), but never with any other group of human beings. For your situation you’re almost certainly better off just putting Jennie the Genius or Bob the Badass in charge and telling everybody else to shut up and fall in line.

People want to know that there’s a plan and that it’s going to be okay – and very competent singular leaders provide that drive and direction.

And I’ve also found that once you’ve established that leadership, the politics disappear. By constantly leveling up your teams (see part 1), you’ve hired good people. Good people love winning, and they love following a single great leader because that helps you win. And that’s all that anyone was looking for anyway.

Share to Twitter , Hacker News , LinkedIn

A young startup might ask an engineer to play roles ranging from engineer to PM to interim manager to solution consultant and more. A young startup might ask a PM to be a PM and pricing expert and a product marketing expert and a documentation writer and an ersatz designer and an interim engineering manager.

In bigger companies, all of these roles are done by specialists.

The upside of this transition is that, most of the time, you get higher quality output for each of these vocational tasks as you specialize. A dedicated pricing specialist is way better than a pinch-hitting PM. A PM is way better than the average engineer doing PM stuff.

There are major downsides though.

The number one downside is that all of these specialists must coordinate to get anything done. Coordination effort skyrockets. This can lead to dramatically increased times to deliver projects. And, sometimes, the coordination effort is so significant that the project slows to a crawl and lacks time for iteration, leading to lower quality.

In a world where slowness kills companies, this can be existential.

Another major issue is that as the number of required specialists goes up, the probability of an underperforming member of a project team goes to 100%. Most companies have 0 ability to react in realtime to an underperforming member of a project (perf management is too slow; embedded roles lack visibility). This can lead to serious deficiencies, slow delivery, and morale issues.

Finally, an amazing engineer is actually better than an average PM at product management. An amazing PM is actually better than an average pricing expert on pricing. As a result, deference to specialists can be deadly. If a great PM says that the design sucks, I don’t care if a middling designer has more experience, the design probably sucks.

Headcount growth is part of any successful company trajectory. But, to avoid these pitfalls, ensure that:

• You stay as lean as possible as long as possible (with great people in seat). Don’t let yourself go beyond 2 org chart layers until you’re absolutely forced to do it.

• You have strong oversight over projects as specialists increase in number. You should be able to make sure that projects don’t go slow, and you should also have a process to detect and correct performance issues.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

At least in SaaS, I believe that this is wrong. If you ignore your competition, you’ll get to experience capitalism in its rawest form: competitors who are more aggressive, more vicious, or more desperate than you will pillage your customers and put you out of business. This is bad for your startup and your wallet.

Don’t let this happen to you. Having seen many, many rounds of direct SaaS competition, here are a few of the main lessons to keep in mind.

Play To Win

Competition is everywhere. If you don’t see competitors for your product it’s often a sign that you’ve picked a fundamentally unviable or impractical market to attack. All good markets are warzones.

Most markets settle into a long-term stable system where 1-3 players gain effectively all of the market share. The ultimate goal of competing is to be one of the top players in your space who are going to get all of the value.

In order to be one of the top players in your space, you typically need to either be the #1 player in a reliable subset of the market, or you must be the overall category leader. Examples of a defensible niche include: The low-cost player. The very premium player. A player in a very specific industry (“We’re Salesforce, but for life sciences”). The only local player in a market (“We’re Shopify for Asia”). But regardless, you must be considered the best in some discrete market at a minimum.

Look For Knockdown Blows

The way that you become the best in a discrete market is by dealing knockdown blows to your competitors, causing them to eventually retreat.

You do this by incentivizing them to change their product-market fit such that it doesn’t overlap with yours: typically by beating them in deals (or winning over their customers), thereby forcing them to change product, marketing, or sales strategy to avoid you. This is how you carve out your niche; eventually if the niche gets big enough, you become the leader of the category – the Microsoft, Salesforce, Intuit, or Palantir of your industry.

Note that the goal of competition is not to put your competitors out of business. Generally speaking, you should assume that any competitor with >$25m ARR is essentially unkillable – expect to compete against them effectively forever. SaaS margins are too high and SaaS products are too sticky (which is why it’s such a great business).

Knockdown blows come in a few forms, such as:

• Layoffs

• Founder exits or transitions to less critical roles, especially founding CEOs

• Business model pivots

• Forced sales, or acceptance of weaker M\&A options

Essentially, you’re looking to force competitors to take painful steps that make them open to resetting their strategy, with the new strategy being something that is further from your areas of overlap. Knockdown blows can take many forms but they are all downstream of the same cause: a competitor losing the will to fight you for market share.

Subscribe now

To Deliver a Knockdown Blow, Target Their Revenue Operations

Knockdown blows are solidified by a very concrete first step: a company’s revenue operations team (who handles sales quotas, territory mapping, and general Go-To-Market (GTM) investment) raises the flag that they view a particular business area as unviable. When this happens, their next step is to either invest more to win, or divest to cut their losses – reallocate resources, spin down investment, stop the bleeding. Your role is to make them reach the conclusion that divesting is necessary as quickly and confidently as possible.

Your only point of leverage against a SaaS competitor is your ability to negatively impact their top sales representatives’ quota attainment. This is the point where your business directly contacts theirs; it is your only point of leverage. Everything else – the LinkedIn influencer posts, the Magic Quadrants, the billboards on 101 – are all just noise compared to the direct grappling of head-to-head sales.

You want all of the best sales reps who compete against you to be nervous and force internal change: this is how you need to break their will. The general way that this works is:

• Reps who compete against you can’t hit their quota. Many of the strong sales reps quit for greener pastures while the weaker reps stay and are managed out due to underperformance.

• The strong reps who remain complain about how they need more support from marketing and product

• Some combination of the marketing, product, and finance teams eventually trigger the discussion of asking why the company keeps throwing good money after bad. You have achieved a milestone – competing against you has become a career liability. This means that you will no longer compete against the best & brightest armed with the lion’s share of their organization’s resources, and your winning streak can continue.

• Shortly after this point, most companies will capitulate and stop sending more resources against you.

Every company’s timetable varies, but generally speaking you should expect that startups will only allow you to pummel them for 2-3 months, scaleups for 2-3 quarters, and enterprise companies (say, >1000 employees) for 2-3 years before they’re forced to react. Mega-cap companies (Salesforce, Intuit, Adobe, ServiceNow) will hold out the longest – you may need to compete for a decade.

Morale and momentum matters tremendously in enterprise sales. At the end of the day, SaaS is a luxury good – nobody starves tonight if they don’t buy Workday. Sales teams thrive on the confidence to make sales in the absence of urgency and shaking their confidence can break a team.

As a result, knockdown blows will be visible on Glassdoor and Blind 2-6 months before their effects are public. A key metric that you can iterate your competitive strategy towards is Glassdoor reviews that are well-written, well-reasoned, typically quite long (5+ paragraphs), and highly negative. These reviews should call out competitive pressures or flagging product-market fit as the cause of dissatisfaction, as well as strategic gaps (“we don’t have a plan” or “we’re completely reactive”). In some cases they will literally call your company out by name.

Be Persistent

The key trait for competing effectively is not cleverness, but persistence. You need to apply competitive pressure with very little positive feedback for many quarters (or years) to get any sort of return. This is why founder-led companies, or companies with founder DNA, are the best at competition in the long run.

But many leaders do not have the stomach for real competition. Competing means admitting that your competitors are strong; it means admitting that you aren’t infallible. You must be willing to show vulnerability, if only internally, in order to take the required competitive steps with the required intensity.

Most steps that are necessary to compete are obvious. Some startups psyche themselves out, looking for that one “differentiated product” (read: magic trick) that will flip the market in their favor. You should just assume that this trick does not exist, and not overthink things. If you just lost 3 deals because you didn’t have feature X, you should just build X rather than wondering whether you’d be better off digging in your magician’s cap for a rabbit one more time.

Beware of Strong Builders

There’s an order to how you compete:

• If you’re much stronger, you compete with marketing: we have the best brand, we are the default choice. This is by far the easiest, and only requires that your product and post-sales motion are strong enough to keep customers happy.

• If you’re moderately stronger, you compete with sales: we can outsell you because we have a better reputation and more resources (= stronger sales reps). This is harder, as it requires an excellent GTM motion. Note that most top SaaS companies have excellent GTM even if they tout their product teams.

• If you’re close to equal in strength, or weaker, you compete with product: we’ll build a better product than you, and fight tooth & nail in every sales cycle to gain any product edge. This is very hard, and requires a full wartime mobilization of your company from product and engineering all the way to sales and marketing.

The scariest competitors will always be companies that can build quickly, because even if your GTM is stronger, they can threaten your product-market fit by leapfrogging your technology. Companies that build fast are disproportionately startups, and the best competitive strategists are very alert to startup competitors.

In some cases, a knockdown blow isn’t enough to make a competitor leave you alone. In some cases the only path to success for a competitor is to beat you in the markets where you compete – they can’t be discouraged from going right after you, because it’s existential for them. These companies will fight you to the bitter end. These desperate competitors can be the most dangerous, because they’ll often use sketchy tactics (negative gross margin deals; unlimited liability; lying about you) to try to win. If they’re product-oriented and founder-led, this is also when they will build the fastest and potentially leapfrog you.

Share to Twitter , Hacker News , LinkedIn

• Understanding the business so you can improve the business. You’ll go far if you understand NDR.

• Getting good at reacting to asks from your boss. Stop making everything a tradeoff.

• Knowing how to get your boss promoted. Their success means your success.

• Having your own version of the vision. Vision isn’t a something handed to you, it’s a conversation you’re part of.

• Being positive. Be aware of the picture you’re painting for your manager.

Firing People

I first became a manager when I was 26. I first had to fire someone when I was 26.

I spent the whole week anxious. The night before I couldn’t sleep. On the day of the firing I was all nerves. On the way to the conference room I felt sick to my stomach. While telling him that he no longer had a job, my hands were shaking under the table. When he reacted to the news, I felt emotional.

I walked him to the elevator and said goodbye. Then I went back to my desk where my team was. I asked everyone to gather and let them know that he was no longer with the team. Everyone sat down and I looked at my screen for an hour without doing anything, mindlessly clicking around, pretending to work. I took off early and got several drinks. I kept thinking for days what he was doing and how he was doing.

It was traumatic.

But, it was supposed to be. When I saw how terrible it was to fire someone, I deeply understood how important it was to hire great people and performance manage well. Every subsequent firing had the same effect - I will hire better, I will performance manage better.

These convictions were not held lighty. In rooms of 10 people all pushing to hire someone because they were “good enough,” I would say absolutely not. Good enough isn’t good enough. Underneath that conviction was a deep knowledge of the experience of firing. I will not be lazy here if it risks that happening again.

The agony of firing was part of what made me much better at management. The problem with may big company environments is that managers are shielded from pain:

• A seasoned HR person is with you the whole way, and will answer anything that that needs a response

• They often do 90% of the talking, or even all of it

• What you say is very limited and constrained

And the kicker? The real crazy thing - it’s often remote. Talking into a screen is a joke. It removes the humanity from an interaction like nothing else can. You’re essentially playing a video game.

So what happens? You remove the suffering and people don’t learn. They don’t learn to hire better. They don’t learn to performance manage better. The worst case isn’t a real life horror show of an experience - it’s a 15 minute make believe session and then you’re back to sitting in your home office eating bon bons.

Shipping Bugs

Shipping bugs is another place that you are supposed to learn from pain. As companies get big and cultures get blameless, engineers are often very, very isolated from the impact of their bugs. You write a bug, it causes issues for some amorphous customers you keep hearing about, and you have to scramble in an incident to fix it up. No muss no fuss. Sprint planning happens on Tuesday just like always.

That’s nonsense. That’s hiding from the pain.

Engineers would do better to engage with customers, see their reactions, explain the bug. When you see one of your users distraught over the time and effort they’ve spent managing the fallout of a bug you wrote, when you see how they’re worried about how they vouched for your software, when you hear that their team was doing data fixes all weekend, that hot feeling of shame and apology should sink into your bloodstream.

Those visceral feelings from seeing customer impact of bugs are what can help engineering teams radicalize on quality. It’s what can help teams overcome the discomfort of upholding standards and going the extra mile.

Conclusion

People should be exposed to the right trauma. There are certain transformational experiences that are created by the outcomes of your failures. Ignoring them, hiding from them, or otherwise letting anything deflect them from you blocks a critical signal in your reward/accountability function.

Find ways to lean into the experiences that help you learn about your failures. That means doing more of the firing yourself, not offloading to another. It means engaging with the customers you let down.

These experiences are not meant to make you desensitized. This is a common misconception. Good managers can fire people without having as much anguish, not because they’re used to it, but because they learned from their previous experiences and know they did everything they could to hire well and manage fairly.

Finally, if you ever have a cultural issue of people simply not acting up to your values or standards, find them the people that the failure impacts. Make a result of future failures a required interaction with those people. Things then often fix themselves quickly.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

• Which functions are embracing AI

• Will the US nationalize a foundational model?

• Unique software in a world of pattern matching

• Is the future of SaaS 100x designers?

• The bubble

• AI impact on society

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.

It’s Hard to Be a Hard Ass

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:

• Should we fire <some exec>? You almost always already know whether they’re good or not (if you’re asking, the answer is no)

• Should we do a layoff? The answer is less definitive, but you almost always know in your heart whether or not a layoff needs to happen

• Should we cut this product? In today’s cutthroat markets, a middling product tends to be a dying product and the potential of great products is immediate and extreme

• Is it time to sell the business? If you’re out of gas or slowly dying the decision to sell is obvious. On the positive side, a truly amazing acquisition opportunity will typically be very obviously excellent (e.g. several times higher than prevailing public multiples for growth startups, or selling for a 200x revenue as a startup)

• Is it time to shut down the business? Again, in every case where I’ve seen someone grappling with this question, the look in their eyes told me everything that I needed to know

Subscribe now

Do The Right Thing

The fact that the right business decision is so often obvious leads to a few actionable operational steps.

Lean Into Discomfort

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:

• I know we shouldn’t make them a manager, but they really want it and it should be fine if we just do it once

• We just need to give the team another shot at this one

• The team will be really upset if we kill that project, let’s just give it a few more weeks

• We’ll be fine if we just close this next quarter strong

Gather On-the-ground Feedback

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.

Data-Driven Dangers

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.

• The business line sucks: It isn’t showing signs of life, it’s obviously non-viable.

• An executive is screwing up: They’re probably screwing up many dimensions of their job all at once - missing numbers, weak team, cost overruns.

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?”

You Owe Your Team Decisiveness

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.

Share to Twitter, Hacker News, LinkedIn

Subscribe now

• Pragmatic roadmap setting. Balancing listening to customers and executing a vision

• Focusing on product over process

• Technical roadmaps - problem driven development

• Making sure your roadmap is obviously valuable

• Decoupling roadmapping and resourcing

• Roadmap adjustments and executive egos

We’d love to hear any feedback that you have in the comments or on X (https://x.com/staysaasy). We’ll also have more text posts soon.

Let’s talk about how and when to use metrics.

The Golden Rule

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:

• Metrics are expensive to set up, so if you don’t use them, you’re wasting effort

• Metrics are expensive to maintain, so if you don’t use them, you’re wasting effort

• A metric that doesn’t drive action is a waste of time

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.

Using Metrics

Setup

Setting up a metric takes time. You have to:

• Get the data

• Hook it up to a UI

• Monitor it to make sure it’s right and doesn’t fluctuate

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.

Using Metrics

Good metrics:

• Have a regular review

• Have an expectation on the behavior of the metric

• Prioritize action if the metric isn’t what’s expected

Regular review

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.

Expectations

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.

Prioritization of action

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.

Examples

Let’s talk through a couple examples.

The Ambitious PM

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

The Cost Review

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.

Summary

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.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

To kick off our podcast we picked an interesting question from our SaaSy Questions submissions about how to win when you’re in third place.

Tell us what you like and what you want to hear. Ask more SaaSy Questions on our website to get featured in a future episode.

We're super excited for this new medium. We hope you enjoy it and our weird voice modulators. Let's go!