The problem goes deeper than big decisions. Daily operational decisions on things like on-call can become impossible to make at all. Teams that need rapid alignment end up in Slack threads that linger and die before end of day, right before the same incident happens again overnight.

The answer is blindingly simple: book recurring time that exists only for as-needed, cross-functional meetings.

A Simple Example

• Every day, everyone in the department holds the same 30-minute block for as-needed operational alignment.

• It may not be booked over by anyone, for any reason, except cross-team operational needs.

• If the day arrives and the block isn’t needed, cancel it.

• If it is needed, the necessary attendees join and discuss.

• Triggering criteria vary by team, but simple heuristics work fine: join if you got paged overnight. Join if you got paged yesterday, or your team caused someone else to get paged.

• Be reachable during the window even if you don’t join. If the people in the meeting need to pull you in, be ready to chat.

I’ve seen this exact setup take an organization from Slack-thread purgatory to crystal-clear daily alignment on operational next steps.

Getting It Right

While the meeting format is simple, keeping it alive takes skill. The necessary conditions are:

• It must be run by someone senior. The minute you hand a big, slightly ambiguous meeting to a junior person to “operationalize,” it will die.

• After a few cancellations in a row, someone will ask: “can’t we just do this async?” If you cave, you’ll find yourself right back in the exact scheduling hell that made you create the meeting in the first place.

• Eventually, the meeting may genuinely deserve to die. Some teams become so operationally autonomous that the block is never triggered. When that happens, kill it. This is another reason a senior person should run it - to spot that condition early and act, rather than letting a zombie meeting haunt everyone’s calendar.

Addendum: Added Benefits

It’s often the only slot your most senior people all hold at the same time. On canceled days, it becomes prime real estate for ad-hoc 1:1s.

The irony in many cases is that people often have “Do not book” private blocks on their calendars, they’re just at separate times. This allows people to just sync up a portion of those for collaboration.

Share to X, Hacker News, LinkedIn

Subscribe now

The cardinal rule of meetings with your direct reports is that you are always on the same side of the table. From the moment you walk in to the moment you leave, every single thing that your team does is a reflection and extension of you:

• If they say something dumb, you don’t get to pile on.

• If they’re at a loss for words, you don’t get to cross your arms and sit there while they squirm.

• If someone on your team is getting hard questions that they’re struggling with, you certainly don’t get to join the tribunal and bombard them with hard questions yourself. Write them down and save them for a coaching moment afterwards.

• If the shit hits the fan during your team member’s presentation, you don’t get to distance yourself and hope none gets flipped onto you. You aren’t allowed to say “well I don’t agree…” to someone who is representing you.

(The only exceptions are for cases that are truly insane, like your direct report assaulting someone or getting naked on a table. In that case you’re of course permitted to physically defend yourself; you don’t need to get naked and assault people alongside them)

Your team isn’t going to be perfect. If you have a large enough team, from time to time they will mess up while you’re in the room. But when this happens you can either handle it well, or poorly.

Here are examples of what to do when someone on your team is messing up. These approaches avoid over-defending your team, which would shield them from autonomy and consequences, but also avoid turning on them as part of the angry mob:

• You can gracefully take the reins from them and start to lead their portion of the meeting (You do know how to lead the conversation, right? After all, you’re their manager). It’ll be moderately embarrassing for them, lightly embarrassing for you, but will keep things moving.

• You can stop their portion of the meeting and request to circle back. Positive work environments are generally understanding, and it prevents a counterproductive corporate public execution.

• You can say things like “I don’t think we’re ready for this conversation” and then play defense on the topic for the remainder of your time, and/or take the ownership (/blame).

• In rare circumstances, someone’s performance can be so egregious that there’s no saving it. In cases where they are presenting something that you specifically asked them not to, AND it’s going terribly, it can be permissible to be neutral - not attacking your team member, but not overtly defending them (after all, they directly went against your advice). I would only take this approach if you’re at the point where you’d be prepared to fire them shortly after.

Finally, you should commit to your team that you will always be on their side of the table in the meeting. A simple statement like “if this gets heated, I will help to navigate the conversation” sends the type of unambiguous signal of support that people often need to hear.

Subscribe now

For a real-world practical example, I once had some mid-level team-members (Senior PMs / Engineering Managers) who were asked to present their product to a very sharp, incisive, but (potentially) intimidating board member. A few steps that I took:

• I gave them a full rundown of the topic, and a bio of the person they were presenting to.

• We had 2 prep sessions, one to kickoff the content and one for presentation prep.

• During prep, I told them the areas where I would need their expertise and the types of questions that I would handle personally (e.g. long-term roadmap strategy). I also asked some questions about the team’s subject matter so that I had at least a high-level understanding, in case the conversation absolutely went to hell and I had to step in and steer the meeting solo.

• I told the team that I would explicitly act as a spotter to catch things in case the meeting got really contentious, and made sure to stay alert for that during the meeting.

Why It Matters

Sports teams have not forgotten the ancient rules of teamwork even as the corporate world has totally abandoned it. Watch a press conference after a team loses and it was obviously one guy’s fault: teams will go well out of their way to avoid blaming their teammate, no matter how obvious their failure was, because they know that blaming your teammate doesn’t absolve you. And let’s all remember that professional sports teams are famously savage about managing performance, with people getting cut or traded without warning.

There are practical reasons to close ranks. Blaming people both eliminates any hope of them redeeming themselves, and more importantly it instills a culture of fear in your team, which impacts future performance. It’s the curse that keeps on taking.

It’s also simply a matter of honor. People leave their team’s side of the table out of a misguided grasp at self-preservation. But the people around them aren’t that dumb. If a team member messes up, that reflects directly on their manager. By staying on your team’s side of the table, even if it’s uncomfortable, you’re showing that you have honor. And in the long run, the best people only want to work with other honorable people, because they’re honorable themselves.

Share to X, Hacker News, LinkedIn

Overpromising Doesn’t Work

Overpromising carries a terrible risk/reward tradeoff. Here’s how it goes down:

• If you promise something positive, your team member will be very happy for roughly the next 1-72 hours. If their happiness was a 5/10, perhaps they’ll bump to an 8/10.

• After those hours, the future promise will begin to revert back to baseline, because that’s just how human psychology works. Most likely they’ll settle somewhere back where they started – let’s call it 5.5

• If the promised reward does indeed come through, they’ll bump up to a 6/10 for a while.

• But if the promised reward doesn’t come through… their happiness will fall to 1/10 and remain there for a long time, which both feels significantly worse and is much harder to recover from. It can take years, and in some cases can permanently impact how they feel (if you were promised a promotion in year 1 and it’s pushed to year 2, it will permanently feel unfairly delayed).

At this point, you have a very serious personnel problem on your hands that is almost certainly much worse than whatever you had at the start.

How overpromising actually goes

Decent managers routinely overpromise because if you’re an optimist with a can-do attitude, overpromising doesn’t feel like lying at all. You tell someone “I’m going to get you that promotion,” and you really do want them to get promoted. And you’ll be extra tempted to utter a promise that you can’t quite guarantee because you’re in one of the most stressful situations that a manager can face: a high performer on your team is distressed and upset, and you want to give them the confidence to stay engaged on your team. So you say the words.

Subscribe now

But the words are a lie. You often can’t guarantee that you’ll get them promoted. Perhaps you are a department head, and you control all of the budgets and promotion decisions within your group, so you feel confident promising Jeff the promotion to Director. But what if:

• A great new VP is shifted into your group. She’s a star, and everyone likes her, but the reorg that needs to occur (data science moves under her group) means that there’s no need for a Director in Jeff’s role.

• You run a calibration session as many tech companies do, and during that session it comes out that 40% of your team think that Jeff is a real jerk. You noticed some tension, but didn’t realize the extent; he gets great results. But you know the extent now, and you need to wait at least another 6 months for him to work on things.

• The executive team decides that title inflation has gotten out of hand, and promotions are going to be frozen for this cycle while they rebalance. Jeff is a top performer (hence why you wanted to promote him) and as a result he will get a nice equity grant, but not a promotion.

• The company misses numbers and conducts a layoff, and all compensation and title changes are frozen. Sorry Jeff, at least you still have health insurance.

All of these things can and do happen.

Even though overpromising doesn’t feel like lying, it will absolutely be interpreted as lying by your team. Contrast it with a much more mild form of deception: omitting the whole truth, for example by failing to mention that you’re fielding acquisition offers. Despite the fact that this comes from a more deceptive place (you technically really are intending to deceive your team in order to change behavior), people are generally much, much more understanding of merely unrevealed plans. But any untrue statement leaving your mouth, no matter how well-intentioned, runs the potential of causing a huge problem.

The Solution

The solution is simple: Never, ever overpromise. Never let happy promises leave your lips until you are absolutely, 100% certain that you will be able to follow through on them beyond a reasonable doubt.

Of course, you don’t need to run your team like some sort of psychological experiment where you never share anything positive about the future. The way to navigate the landscape feels weird at first, but you should caveat any forward-looking career promises like you’re a paranoid lawyer and/or running down the list of scary-sounding disclosures on a pharmaceutical advertisement. I have literally said “I’m gonna try really hard to do X, but I need to add a disclaimer because I don’t ever want to make a hard promise I can’t keep.”

Here are some common fixes to lines that feel totally normal to say, but run a very real danger of overpromising:

• “I’m going to get you promoted during the next performance cycle” => “I will work with you to put together a promotion packet, and I will advocate hard for your promotion during our calibration session” (Focus on what you can control)

• “We’re going to make you the manager of this new team” => “Assuming that we’re still using the current org structure, my current plan is that you will manage the new team” (Provide accurate disclaimers)

• “I’m going to get you a large equity grant in the next cycle because you’re running short on equity left to vest” => “I fully understand the situation you’re in from an equity vesting perspective, and when we’re issuing grants I am going to do everything that I can to make sure that it’s accounted for” (Skip details that you can’t guarantee)

Avoiding overpromising doesn’t mean that you can’t be sincere with your team. If you feel an emotion, like the fact that someone is really great and you hope they get promoted, it’s usually okay to show it within reason. Emotions that you really feel are authentic by definition, so they don’t run the risk of letting a lie leave your lips.

Takeaways

Your word as a manager is your bond. And if you want to be a good manager you can never break your word, especially to people you manage.

Management is an asymmetric relationship where you hold the power to enable someone to put food on the table, so your word is sacred. It’s better to be honest and painfully disclaim future looking statements than to risk being an optimistic, confident liar. And in the long run your team and your blood pressure will thank you for it.

Share to X, Hacker News, LinkedIn

Some common situations that I hear about all the time:

• We don’t know how to balance incremental features that our current customers want versus more differentiated / futuristic features that would help us sell.

• We don’t know how to balance tech debt or supportability investments versus business-oriented features.

• Our platform consists of 3 main products. One of them has the most revenue opportunity, one of them has the most upset customers, one of them has the most scaling problems. We’re figuring out which one to focus on first.

The advice that I give in almost every case – the best way to prioritize is to not prioritize.

Prioritization Sucks

Prioritization sucks for a few reasons.

First off, frameworks are BS. People have written breathless blog posts about product prioritization frameworks like RICE or the Kano model which are designed to generate imposter syndrome about your decision-making and encourage you to buy some online course. These frameworks are often largely vibes, or rooted in such completely abstract concepts or unknown assumptions that you might as well just ask ChatGPT what to do. Like what’s the meaning of “Reach” (the “R” in “RICE”) when we’re in a market that’s growing 50% YoY, or when we’re a startup with 10 customers? How do we calculate “Effort” (E) when AI coding is going exponential?

And just as importantly, the quality of your prioritization skills is unprovable. You’re only going to set your team on a single path, and proving that it was optimal retrospectively will be a purely philosophical exercise. Your business is going to thrive or it’s not, and it probably isn’t going to hinge 100% on this decision anyway. So while we can debate various merits going into prioritization, you’ll never even really know if you were right; you’ll just know whether the business overall worked or you got fired. As a side effect, this sort of unprovable philosophical argument is also a recipe to make people furious (“I told you that we shouldn’t have done that!”).

And of course reprioritization also takes a lot of cognitive effort. It’s wild how many planning meetings, summits, planning spreadsheets, and program managers can get rallied to answer the question “what do we do next week.” If your startup has less than 50 people and you see a Gantt chart, you should pull the fire alarm, throw out your employee badge, and run.

So there’s basically two alternatives to prioritization that work well.

The first is to just build faster. If you can only build one thing, what you choose to work on matters enormously. If you can build 10 things, you only need to have a vague sense of what a good idea looks like, and a sensible way of determining whether it’s actually working once it’s done.

The better you are at moving fast the worse you can be at prioritization. Prioritizing well requires being very clever. Building fast is great because you don’t need to be clever at all.

And I don’t mean this in some facetious, philosophical trick-question kind of way, I mean literally cut time spent on prioritization and refocus it on being faster. Instead of a week-long planning onsite with 2 travel days, have a half-day planning session and then spend an abbreviated offsite streamlining the build process, making sure teams are well-resourced, helping teams get into a better operating rhythm, and actually hanging out so that people are motivated to build faster. And then just do actual work for the rest of the week.

Speed pays dividends in basically every scenario and it’s empirically proven to work. There are many winning companies that make dumb prioritization decisions that they have to unwind all the time. There are no winning companies that move slowly. Also, shipping faster teaches you more about good prioritization than reading blog posts about backlog grooming. You’re unironically probably better off building 3x faster and going down your list of product roadmap candidates in alphabetical order.

Subscribe now

The next strategy is to take cross-goal prioritization off the table entirely.

Team A is working on increasing sales for our new product, but what if they helped reduce support on our core product instead? Which is a higher priority? I dunno. What if we just literally didn’t ask that question, and teams stayed in their lanes forever?

Enforcing that teams always focus in one area takes a huge amount of total prioritization effort off of your plate. All of your decision-making turns into apples-to-apples comparisons within a fixed domain – for example, do I want my core product:

• To have less support issues

• To have more features that customers want

• To be cheaper to run

• To have higher reliability

These are vastly simpler questions than the apples vs. oranges comparisons like new product vs. old product. You can just ask customers or your CFO what they need, and all the variables are simpler. Also, your business would be stronger if you did all of these things (bringing us back to the prioritization point above).

Keeping teams together through thick and thin turns your prioritization problems (hard, difficult to prove correctness, cause significant context-switching) into resourcing problems (easier to reckon with, faster overall). Resourcing problems are far better because they’re less contentious and force you to transact in the world of facts – how fast is this team actually moving, how much actually needs to get done to ship. The fact that you solve resourcing problems by hiring, downsizing, or reorging teams is also an advantage because those activities take longer, which means that you’ll move slower on the decision, which causes less thrash, which gives more focus, which drives higher velocity (see above).

Teams that stick together are also a better match for certain types of problems. For example, if you’re running a high-upside experiment on a new product area, you could pare off a varying amount of resourcing every month to try to breathe life into it. Or you could just have 1-2 engineers spend 3 months seeing if they can go 0-1 on their own. The 2 engineer model is significantly more likely to work (simulates an early stage startup) and it doesn’t require any ongoing logistics. If the product takes off, add more resources. If it doesn’t, spin it down to 0.

This strategy is almost unfair in how well it works compared to constantly reprioritizing work. Stakeholder management also becomes dramatically easier. “When is that new product shipping?” is much simpler to answer if you don’t need to jump through the mental hoops of whether or not you could prioritize some other team’s project, and what that would do to other promises that you’d made. Even if that time is technically longer than pulling everyone onto the key project, the certainty and confidence that you can project typically make customers and internal partner teams happier overall.

Takeaways

Prioritization is a trap. It wastes time, wastes effort, and delivers worse results than just executing faster. Instead of spending your time prioritizing:

• Spend more time focusing on building faster (or literally just spend the time building)

• Shift everyone into durable teams that don’t have to do cross-business prioritization at all, and manage your “prioritization” by the resourcing decisions of growing, downsizing, or splitting teams

Share to X, Hacker News, LinkedIn

***

If our market has any value at all, we’re going to have competitors. Many of them will be formidable, because the thermodynamics of capitalism dictate that competition always eventually appears. If it didn’t, it would mean that we were doing something useless.

If our market is as large as we think it is, competitors will continue to spring up and get funded until there’s no longer positive expected value in trying to own it. VCs need to make money, and they will pay an endless train of Stanford dropouts to try to kick our ass. Our goal is to instead kick their asses so quickly, decisively, and publicly that people stop signing up to take shots at us.

You’re gonna read stuff written by rich people who tell you that competition doesn’t matter. They’re going to not-so-subtly imply that even thinking about the competition is some kind of weak behavior. These people are wrong, and they were typically late joiners at dominant consumer monopolies like Google. Assume that we are not Google. Once you’re at scale (i.e. not a tiny startup), competition matters and there is no shame in recognizing it; the fact that you have competitors who deserve respect doesn’t make you somehow lesser.

They will sagely make pronouncements like “Startups die from suicide not homicide,” but I will tell you now that I have seen startup homicide with my own eyes. They’ll write that competing is some kind of beta loser move, because they’re standing so high up on the shoulders of giants that they don’t even know how they got there. We aren’t standing on the shoulders of giants yet, we are the giants, and if we do our job well, then one day we can explain to some kids that we, too, needed to compete like maniacs years before.

Subscribe now

Even if you don’t personally feel like conflict, it will still be brought to our door. We cannot unilaterally declare a stalemate and have competitors disappear. They are coming whether we like it or not, so we can live in only one of two worlds. In the first:

1. Win-rates lag

2. Sales lag because win-rates are down

3. There isn’t enough revenue coming in, so Finance will reforecast the business

4. The reforecast will require cuts, leading to a layoff

5. Morale will sink and resourcing will get tighter, necessitating strategy changes (hard but sometimes effective) or tougher execution (harder and never effective). Top performers will quit

6. Beset by these challenges, win-rates will fall even further

7. More layoffs will happen

8. We’ll shutdown or be forced into a fire sale of the business

The odds of us getting fired at Step 4, 6, or 7 are high. In contrast, there’s Scenario #2:

1. Win-rates increase

2. Sales swell as the win-rates rise

3. There’s too much revenue coming in, so Finance will reforecast the business upwards. If we want to, we can raise significant additional capital

4. All of that money will flow back into the business. We can grow headcount faster, or simply throw the dollars at fungible resources for durable growth (tokens, discretionary marketing spend, lavish perks that boost employee retention)

5. Morale will rise and high-upside projects that require higher risk tolerance or more resources can be put on the table. Your favorite teammates will make plans to stay here for years, because they see that they will propel their careers and likely get rich right here

6. Buoyed by this strength, win-rates will go up even more

7. The business will go public unless an amazing acquisition deal comes in first

8. Meanwhile, our competitors’ sales will lag, and they’ll go down the first scenario that we outlined above

The competition wants to force us into Scenario #1. They want us to go out of business. They want to put you at your kitchen table at 9pm explaining to your wife that you’re going to need to cancel that vacation or trade in the car for something cheaper. Perhaps they’re not envisioning that actual scene, but every day they wake up and take actions that can literally lead to that conversation. I don’t want that for my kids, and I don’t want it for yours.

To really move win-rates we need to be far better than competing offerings – half as expensive, 10x faster, 3x better results, etc. 10% improvements won’t cut it because it’s so annoying for our customers to change or do literally anything. Even finding their credit card and verifying their email for some $29/month PLG product is enough hassle that most won’t do it.

So we aren’t going to get higher win-rates with incremental feature improvements. It’s great that some 5% product improvement that you want to prioritize is a good idea, but it’s probably not going to move the needle and put us in a stronger market position unless it’s part of a story where we fix literally everything. So if you’re looking at a modestly good idea, you either need to build it really fast or not at all. We are looking for knockout blows rather than love taps.

This is going to take a long time. In B2B you win deals one at a time, so it’s house-to-house fighting. You’re hearing us talk about beating the competition right now; you’re going to hear about it for years. Software companies, particularly enterprise ones, are like bugs that can survive a nuclear blast and live off of discarded Kind bar wrappers and half-empty Mountain Dew cans for decades. We’re going to have to track down every last bug in the landfill.

But luckily, focus and hard work are the two easiest things to control. So if we actually focus and do the right things, we won’t be the ones that need to cancel Christmas.

Share to X, Hacker News, LinkedIn

As technology has advanced, technology waves have become larger, more frequent, and more sudden. In just the last 30 years (less than a full career, literally less than the time between graduation and your first 401k payout) we’ve seen:

• The rise of the consumer internet, creating massive companies like Google, Amazon, Meta and Netflix, and essentially killing dozens of industries from print media to Blockbuster videos.

• The rise of cloud (enterprise internet), which was an extinction event for on-prem B2B software that companies like Adobe, Bloomberg, and Microsoft managed to survive.

• The rise of mobile, creating massive companies like Uber and Instagram, turbo-charging companies like Apple and Meta, temporarily shoving Microsoft into a corner, and reshaping where we spend our attention.

• Aborted technology waves for 3D printing and Virtual / Augmented reality.

• The “rise” of crypto / Web3, creating a large public company (Coinbase) and a large illicit marketplace (The Silk Road) and some stablecoin infrastructure, but few other major businesses or use-cases. More on this later.

• The rise of AI, creating lightning fast growth for OpenAI, Anthropic, and Cursor, turbocharging Nvidia and AMD, and shaking essentially all industries to their core.

This has happened for thousands of years. I’m sure there was some Bronze Age metalsmith in 3000 BC who had to explain to his pissed-off wife that he lost his job because some asshole figured out you could make a better sword out of iron. Disruption from technology waves has been happening for thousands of years and will continue for the indefinite future.

What To Do

I’ve been around long enough to watch multiple technology waves swell and break on the shore. There are a few super simple questions below that I ask as early as possible in a technology wave that I’ve found invaluable for orientation. The key is to ask them, in order, every time:

1. Does this technology actually matter? Does anyone that I know actually use it? Is anyone changing their habits because of it? If it’s a new speculative technology (e.g. internet, AI, blockchain) does it like, actually do something anyone cares about?

2. If it matters, you need to ask how the new technology actually functions. Could I explain it to my mom at a very high level if I had to? Talking points from social media or (worse) traditional media don’t count.

3. Once you know how new technology works, you need to ask what new functions it will enable. Since we’ve established that it matters and understand how it works, what behaviors will it change? You’re looking for ground truths about the future, even if they’re obvious: AI lets people create images faster, AI lets you synthesize huge amounts of text, AI generates working code. Establish the facts in a boring way; inoculate yourself from hype and grifters. For mobile, instead of “all of the internet, directly in your pocket,” go with “it will be possible to perform business tasks in places with broadband, as long as they work on a small touchscreen.”

4. Finally, you have to ask whether your product or business is impacted. Do buyers care about any of the things that the new technology does? Does it impact your cost structure? Does it impact your customers’ businesses? If you gave yourself a cold enough shower at the previous step, you’ll be left with the distilled reality of whether this wave matters for your business.

These questions are not hard to answer. They do not require a deep math background or Machiavellian cleverness. If this is a road trip, you’re not trying to find a shortcut through backroads, you’re just trying to figure out if the bridge you’re about to drive over has collapsed. But it is essential that you actually take the time to ask them, which is surprisingly hard because…

People Are Lazy

Whenever a new technology wave comes along (like the internet, mobile, or AI), a huge number of businesses simply ignore it because change is annoying. Maybe if we ignore these dumb phones they’ll go away. This GPT thing can’t count how many Rs are in the word “strawberry,” it’s useless.

(Worth noting that the tendency to ignore new technology waves seems to have gone down over time. There were many, many more internet skeptics than AI skeptics)

Ignoring new technology waves feels good because most technology waves do sputter out. The few big businesses built on crypto have (so far) been mainly related to speculating or buying drugs. VR games never got mainstream adoption. Only weirdos and tinkerers have 3D printers in their homes. Being lazy pays off pretty often. It also lets you talk down to others, which many people unfortunately enjoy.

Additionally, just assuming that nothing is happening is a somewhat self-correcting problem. You can ignore iPhones for a long time, but eventually literally everyone you’ve ever met has one, and you can just shamefully pretend that you never said they were pointless. As a result, being lazy is often less dangerous than the other trap…

People Fear Embarrassment

A lot of senior leaders, even “leaders” at tech companies, are fundamentally insecure about technology. They’re either not technical by training or so out of practice that they don’t know how their products work. This is especially true in fields where projecting confidence is a key part of the job: Sales, Marketing, Human Resources, and arguably even Security are all examples.

So in order to instill confidence in their teams, or to win whatever political battle is being fought this week, whenever a tech wave appears on the horizon many execs feel compelled to project wisdom and understanding.

Critically, these execs don’t actually understand what’s going on – they haven’t followed the steps outlined above, and they often also fall into the trap of being lazy. So instead they follow the hype: This is popular on X (or worse, LinkedIn), all our competitors are leaning in, or “Gartner said this is the next big thing.” It’s classic herd behavior. Once the hype is loud enough, these leaders’ next step is to declare that the new technology is the birth of a new machine god, and that they will be its prophet.

Going all-in on something you don’t understand can work out fine if you capture something like the iPhone moment and build a mobile empire. But it’s deeply damaging if it causes you to mortgage your business’ future on some Web3 technology with 0 actual users. Or if you cancel your entire roadmap to put a hat that says “I ♥️ AI” on top of your product, when your customers actually wanted you to add better approval flows.

Blind over-rotation is the default strategic mistake in times of major change. To avoid it, you need to make sure that you and your team aren’t falling into the trap of avoiding embarrassment by leaning in on whatever is hot.

Takeaways

New technology waves can make or break your business, but only some of the bumps in the water actually matter.

Follow the steps of thoughtfully asking whether the technology is impactful, researching how it functions, establishing the facts on what it makes possible, and considering whether it impacts your business. Beyond that, don’t assume it’s just nothing, and don’t let embarrassment drive you to go all-in just because everyone else is.

Most importantly: The greatest sin of technology waves is missing an obvious wave and pretending it wasn’t real because of your ego. If you miss a wave, the single most important step is to swallow your pride and immediately take strides to catch up:

• Acknowledge that you have a problem, potentially publicly to your team if you missed badly enough. Take personal responsibility.

• Pivot appropriate resources towards catching up. Be prepared to cancel projects, and be prepared to put your best people on the task even if that means hurt feelings. When you’re playing catch-up during a wave of industry change you need to actively put your best people on the frontlines, and doing so will actually rebuild your team’s confidence.

• Follow through on that personal responsibility by staying close to the project and making sure that you actually fix the error.

The silver lining of technology waves is that when they matter they’re big, and when they’re big they’re eventually obvious. Missing them, more than anything else, is truly business-killing, but luckily you don’t need to be that clever to detect a wave that matters.

Subscribe now

Share to Twitter, Hacker News, LinkedIn

This is almost never the case.

Almost every leader has at least one major weakness. The great strategist is weak operationally. The great technician is weak strategically. And so on.

The real damage happens when you stack weaknesses - when a leader is weak at something and their direct reports are weak at the same thing. This is a disaster, and it happens far more often than you’d think. Part of the reason for this is that leaders tend to hire people with the same skills they have. They’ll dress it up as hiring for “values” instead of “skills” so it doesn’t look like they’re cloning themselves - but people ultimately search for and evaluate the things they’re good at.

An even more challenging reason leaders do this is that they often don’t even know that they should try to hire for a skill - a true unknown unknown.

When you stack weaknesses, you warp reality. Put two operationally weak leaders in a row and the odds that the organization beneath them is operationally strong are zero. These leaders can’t run operations themselves, and they don’t even know how to hire or manage people who can. It’s like asking two monolingual English speakers to hire a great French translator. What the heck do they know about le chat noir?

Avoiding stacked weakness starts with admitting weakness, which is hard for a lot of leaders. The great ones know out of the gate what they’re good at and what they’re not, and they hire for the gaps. An org with no meaningful stacked weaknesses is robust to the changes and challenges that cause stacked-weakness orgs to collapse.

If you need a quick guide to covering your gaps - most roles have a component of the following skills: technical/domain knowledge, management, process/operational, strategy, presentation/speaking, raw aptitude. Rank yourself on those honestly and fill the gaps with strong hires. And the simplest way to not trick yourself about your abilities is to never say “I could do that if I wanted to” when evaluating that list.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

When baby sea turtles are born, they immediately rush by the thousand towards the ocean. Every predator in the area swarms to devour as many as they can. Only a few dozen make it to the water. An even smaller number make it to adulthood, and ultimately return to start the next generation.

Startups, like Mother Nature, are a brutal numbers game. This is what it’s like to become one of the few turtles that makes it back to the beach.

12 Years Before

You’re standing awkwardly in a one-room office. A guy in a T-shirt hands you a laptop, but tells you to factory reset it first. It belonged to a different engineer yesterday. The startup doesn’t have enough money for excess laptops. It’s 10am and there’s nobody else in the room.

He’s talking about how there’s a form to early-exercise your stock options, and you’ve got 30 days to mail a different form to the IRS, and do you have a check, and this is really important if there’s a “liquidity event” one day… you can already feel your eyes glazing over. You ask where you can grab a notepad and pen to take notes for the rest of onboarding. Laptop Guy stares at you blankly. This conversation is the entire onboarding, and there aren’t any notepads or pens, either. He says that if you need office supplies you can buy them at CVS and he’ll reimburse you.

“So, uh… what do you want your email address to be?”

6 Years Before

You go to Thanksgiving and tell your grandma the name of the startup, again. Your mom tries to describe what it does and gets it about 40% right. It doesn’t matter. Everyone’s moved onto discussing their fantasy football teams.

You were a smart teenager. You went to an amazing college, and your family was so proud. How did you wind up here? Your startup’s CI runs on a Mac Mini under your desk. It burns your legs. You have $0 in revenue. You’d think that this was rock bottom, but you’d be wrong. The startup used to have some revenue, but you churned it away, so now you’re back to $0. You’ve had 3 Heads of Sales in as many years – this at least does make sense, since they never seem to sell anything.

You have no idea whether more funding will land, but you can tell that you need it. Your best friend from high school just graduated med school. Pass the gravy.

* * *

12 Hours Before

The stock market has closed for the day, and the IPO is now inevitable. Aspects of the deal are still being discussed, the Book is being built, but there is nothing left that can disrupt it. You have spent weeks worrying about disasters that could have caused an issue in the markets and canceled the deal. It’s become a paranoid loop running in your head. But the big day has finally arrived and there aren’t enough hours left to fuck it up.

The adrenaline dump after a decade of white-knuckling the steering wheel is intense. You’ve worried about the company’s fortunes constantly, for years, and you can’t really turn it off, even on the eve of the IPO. You check your phone – same email address, same Slack handle that you picked in that office years ago. When the menus arrive for the celebration dinner you barely have the mental energy to order.

9 Hours Before

You’re looking at memorabilia that you’ve kept stuffed in a folder at home, relics from when the startup was tiny, seed stage. You opened up the printed (!) directory of an event from a decade ago. Techcrunch Disrupt. You remember it well – huge waterfront venue, full soundstage, two days of presentations, hundreds of booths, your team tucked in the back by the water coolers with the other fledgling startups. So much positive energy, so many excited faces, so many teams with such bright futures.

Based on a quick scan, your company is the only one that’s still in business. None of the other turtles made it home.

1 Hour Before

You arrive at the stock exchange to an extensive corporate buffet. It’s a huge reunion with people flying in from across the world. You haven’t seen some of them in-person in years. You’ve never seen any of them in a suit this early in the morning.

The CEO, founders, and early execs are celebrities. A Director who joined 8 months ago comes up to you – this is their chance to meet in person. “Did you expect this day would come?” Dude. That’s like asking if I expected to get hit by a meteor.

10 Minutes Before

You’re in a sterile, brightly lit holding pen. The exchange has sent in what can only be described as a corporate hype-man to get everyone fired up before the big moment.

The experience of having this high-budget camp counselor run a 5 minute pump-up exercise is utterly bizarre. For you, this is the most important day of your career. Your grandparents fled their home countries under literal gunfire to help you get here, to America, to the center of the capitalist universe. Today is a crowning moment in that saga. For Gary the hype-man, it is Tuesday.

Subscribe now

5 Minutes Before

You’re standing on a street level sound stage. You’ve seen this place dozens of times: on the news, in the newspaper, on the glossy websites of the world’s most famous venture capital firms. Surreally, this time you are on the stage looking out. You see the city through soundproofed glass.

Above you on the soundstage are a semi-circle of TVs showing news channels across the globe – Bloomberg, BBC, MSNBC, international versions of CNN that you didn’t know existed. Screens are showing everything from bored looking news anchors to commercials for some Malaysian soap, killing time as the US markets prepare to open. Someone yells final instructions – there will be confetti, remember to smile, clap until we say stop, you’re about to be on TV.

10 Seconds Before

The countdown begins. The emotional tenor of the room reaches a fever pitch. You look down for a moment, and think of the steps that brought you here. Closing that first enterprise contract 9 years ago, the database incident that almost sank the company, the panicked breakfast in the lobby of a Marriott in Seattle after your biggest competitor’s product launch, the conference room you were in when you hit $30M ARR. You can remember everything, and nothing, from the decade-plus journey.

You look up as the TVs change, showing the opening bell ceremony of the stock markets of the United States. You are on every channel.

For a brief moment, all the spotlights in the grand arena of capitalism arc towards a single point, the exact coordinates in the global economy where you’re currently standing. Everyone goes wild – you probably didn’t need Gary hype-man. The guy who handed you the laptop all those years ago triggers the “bell” just a few feet to your left. You clap and cheer for what feels like 5 seconds and 50 minutes at the same time.

10 Minutes After

The confetti has dropped and it’s time for a brief photo op outside. People are taking selfies. As you walk off stage, the thought crosses your mind that you’ll most likely never be in this room again.

You’re hugging people outside – a small group of elated people in suits and skirts taking selfies on the street, like tourists in business casual. There is a fire in your team’s eyes that you’ve never seen before: Relief and excitement, like you’d expect, but in some of them, there’s also a novel confidence. The ones who endured years of anonymity and struggle to get here will retain that fiery, intense confidence forever.

A disoriented Argentinian family is shuffling their children away from an increasingly insistent person in an Elmo costume. Life in New York City goes on. Nobody gives a shit.

1 Hour After

Back at the exchange they’re going through the actual offering itself. People are popping champagne as the numbers tick up, and up, and up. All of the startup’s private venture rounds were run as cloistered secretive events. This time, they’ve literally got some guy with a headset running the deal with the price fluctuating on a live ticker. Bankers and venture capitalists are wandering around everywhere. It isn’t necessarily a bad thing, but you’re starkly reminded that all of your efforts were ultimately distilled into a financial product.

2 Hours After

The numbers stop. The “offering” is over. The Company’s shares, trapped in suspended animation in Carta for ⅓ of your life, are now being bought and sold by total strangers. You call up your stock tracking app and see a name that you’ve typed a hundred thousand times staring back at you. You’re like a caveman looking at the touchscreen console of a Tesla; you can’t process it.

As you walk off the floor, you look back at the screens and see the frozen price where the offering concluded. You remember when you made your 83(b) election after that confusing onboarding session years ago. It wasn’t a lot of money to exercise that initial grant, but exercising options in such a tiny startup felt vaguely irresponsible, like you were getting scammed. The shares you purchased are up 50000x.

Your mind starts calculating. Share Count times Current Stock Price – this is a calculation that your brain will become exceedingly good at over the coming years, as your share price rises and falls, as you learn what it feels like to make (or lose) sums of money that you didn’t imagine you’d ever have over the course of a day, or an hour, or 5 minutes of after-hours earnings market gyrations. But this moment, staring at a small white number on a cool blue background on an anonymous trading floor monitor, is the first time you’ve run the calculation for real. So it takes you a few seconds. You never need to work again.

6 Hours After

That afternoon, you open up Slack. The fanfare is over, and people in faraway countries are still sending you messages, and you’re going to be reporting numbers quarterly… forever. So you open up your laptop – same email address, same Slack handle. And you start crawling your way back towards the open ocean.

Share to Twitter , Hacker News , LinkedIn

Subscribe now

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