2026-09-30 08:00:00
As part of writing Stay SaaSy we speak with and advise a fair number of startups, and one of the most common topics of conversation is how many people they should hire.
The most important factor to consider when expanding a team is that the usefulness of incremental hires is not linear. Sometimes an additional person helps a lot. Sometimes they don’t help at all, due to structural overlap or the quality of the hire (and keep in mind that for some roles, quality is much less reliable). The key point is that the utility of a marginal hire varies dramatically depending on role and whether you’re crossing a key breakpoint in terms of team size. The value of a new hire can even be negative.
And there are a few important breakpoints to consider on the journey of growing your team. These might seem a bit obvious, but the important realization is that at these breakpoints hiring decisions are much more important, so if you keep them in mind as hard thresholds you’ll make better scaling decisions.
Sometimes you just need a single expert on a team who gives you a key capability. There are several different functions where just having one individual will make your whole group much more productive:
For these 0-1 hires, the most important thing to do is not screw it up. A great designer will let you move 10x faster at 10x higher quality; a bad designer will mess up your whole product. A good data person will set up your foundations to scale for years; a bad data leader will set you up for overhauls every 24 months in perpetuity.
But often, confusingly, adding a second person in a function makes things a lot worse. For example:
In a few other cases, adding another person can make things a lot better. For example, it’s often very helpful to have 2 sales team members (classic post on this), or 2 support team members, because they’ll keep one another honest about pace. Sales and Support are highly dependent upon product-market fit to be successful; as a result, both sales reps failing or both support reps struggling often means that the product is insufficient; whereas only one failing usually points you to what the correct bar should be for that role at this moment in time.
For these types of hires: don’t wait too long to hire your second person, especially if the first one is doing well.
Most people cannot manage more than 9 people effectively. The canonical advice on how many people you can manage is 7 plus-or-minus 2 (unsurprisingly, 7 is the median amount of items that you can store in your working memory).
Once you cross into the zone of 7 => 10 direct reports for one manager, it’s very common to see things fall apart. Typically, the dominos fall in this order:
The general rule of thumb: aim to load up all of your managers to their maximum carrying capacity of ~7-10, as each incremental hire will increase velocity, reduce key-person risk, and expand coverage. Past that, tread extremely carefully.
There is a movement going on right now to load managers with significantly more direct reports than before – in some cases that we’ve heard of, 50+. I think that it’s unlikely that advances in AI will be able to dramatically increase the number of direct reports that one person can responsibly manage. Ultimately, even if we have futuristic technology, the neurological hardware that we use for tracking relationships (an essential part of management) is still firmly rooted in 2026 evolution. AI might increase managers’ ideal maximum carrying capacity to 12 or 13; I personally doubt that it will increase it to 50.
Transitioning from ~140 to ~160 employees takes you across the famous Dunbar number, which sits at around 150 people. In essence, the Dunbar number is the maximum number of people in a group that still allows for family-like cohesion. That is, a group of 149 people can operate as a family while a group of 151 people needs to operate more like a corporation (or an infantry battalion, or a bunch of people on a cruise ship, or a prison). Coordination and communication are very easy below the number; they’re very hard above it.
We can debate the exact scientific reality of the Dunbar number, but I will say two things:
In very broad strokes, below the Dunbar number marginal hires typically speed you up because they add resources without dramatically increasing coordination overhead. They aren’t free in terms of overhead, but they’re relatively cheap. You can still yell across the office, or text people, and everyone kind of:
Beyond the Dunbar number, things get crazy and you need to start architecting your organization more like the Navy and less like a sports team.
Generally, my recommendation to companies as they grow past 50 people is to aim for a hiring trajectory that lets them stay below 150 people for as long as they can. This is especially true with advances in AI that give team members more leverage. Past 150 people you are simply going to get less productivity out of each marginal hire, and a team of 149 armed to the teeth with great tools can carry even a fairly complex business very far.
Additionally, once you’ve crossed 150 people, you can and often should hire faster. You’re now fully going to need a heavier structure of internal communications, operations, and other functions to keep everyone rowing in the same direction – you might as well just invest since you’re already incurring the full coordination penalty.
2026-09-20 08:00:00
To have a positive career you need to be appropriately recognized and rewarded for your work.
But there are a lot of ways that credit and/or rewards can get missed. Often it’s something unintentional, like your boss or some other executive simply didn’t realize what you accomplished, or didn’t understand the right way to compensate you for the value you’re adding. Sometimes it’s more nefarious, and someone is trying to take credit for your work or otherwise keep you down. Either way you need to drive defensively - taking actions that allow you to make forward progress even if people around you are negligent or malicious.
All of the techniques below can be approached in a benign way, but I realize that they may come across as cynical. There is a less cynical set of takes at the end as well.
Many organizations basically only know how to value you from what you announce publicly. If your role doesn’t own an explicit topline number for the business, it’s shockingly easy for people (including your boss!) to judge your work performance almost entirely on what you share with them.
This truth often gets lost in tech because many of the most important roles have visible and quantitative outputs (particularly engineering and sales, but also product management, design, and marketing roles that drive pipeline). For the rest, however, you’re basically relying on the last email you sent that your boss saw.
As a result, you need to be visible in a way that isn’t obnoxious or wasteful. To do this, you should pick 1-3 important, public announcements that you always make. Some examples:
Also, in many cases you have to send or speak the note, not your team. “They’ll know it was me” – they likely won’t. Nobody else is paying attention to you, and nobody else cares about you. Own the message, push it gently down people’s throats, and let your team own a different sub-message if they want to.
Other rules: Whatever you’re sharing has to actually be important, or else you’re like those free newspapers full of ads at the coffee shop. And if you send out the update, you are on the hook to really own it and answer questions. Which is kind of the whole point.
If you’re going to have a high-visibility job, like most execs, you can never let yourself get punked: having someone challenge you in front of a public audience and letting it slide.
The number one way that people punk you at work is by lying about you and what you did. Common examples include:
The problem with getting punked is that it makes people think they can mess with you anytime they please. As a result, every time that someone lies about you, you need to politely (or if necessary, not so politely) push back and correct the record. The ultimate goal: You want to be a corporate rattlesnake – spend your whole day chilling in your cave (never lie about others), and if anyone comes after you, rattle once for a warning and then bite them in the face in front of their friends and loved ones.
Companies operate on an ultra-mild version of prison rules. Life operates on an ultra-mild version of prison rules. Unfortunately, that means that sometimes you need to lean way into conflict when someone challenges you in public. This works unreasonably well 99% of the execs who will lie about you are bullies who fear actual confrontation.
There’s a certain personality type that acts very unprofessionally if they think that you got to your position through luck. If someone is undeservedly doing “better” than them, they’ll behave strangely at minimum and in some cases actively sabotage them in order to settle some sort of score.
Doing “better” is personal and can be whatever metric they’ve chosen, but it’s typically some combination of title and lifetime earnings / current compensation, moderated by age. As in, I was a VP with $500k at your age, and you’re a COO making $2.5m.
A few situations that I’ve seen increase this risk dramatically:
The best solution is to simply never let someone who thinks that you got lucky manage you, or control your title / compensation. That’s a pretty hard variable to control, so some of the better secondary ways to avoid this issue are to:
Lastly, you need to maintain leverage at all times. Leverage mainly comes from one place: your ability to walk a valuable asset (your labor) out the door. As a result, for better or worse, it’s usually best to both be very good at your job (obviously) and then make it clear that you could walk, and that you even consider it from time to time.
There’s a balance here. You don’t want to be the dude who’s constantly throwing a tantrum and threatening to quit. So here are a few concrete steps you can take to keep em a little bit nervous. All of these ideas assume that you’re a good-to-top performer in good standing:
I also recommend that you regularly take an interview or two to build your own confidence. You want that “I’m wanted” glow on you at all times.
Of course, if you’re a leader at a company (or the CEO), there are different takeaways. You don’t want your team to feel that they need to follow this advice and drive defensively all the time – you want them driving normally, on the same highway, ideally in unison, as fast as they possibly can. And there are ways to facilitate that:
2026-08-16 08:00:00
As companies get larger, scheduling a decision starts to take longer than making it. Decisions that used to get alignment in an hour now “can only happen three weeks from now, once Michael and Melissa are both back.”
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.
I’ve seen this exact setup take an organization from Slack-thread purgatory to crystal-clear daily alignment on operational next steps.
While the meeting format is simple, keeping it alive takes skill. The necessary conditions are:
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.
2026-08-12 08:00:00
Imagine that you’re in a board room, locked in an intense negotiation. Maybe you’re selling your company, maybe you’re signing an NFL contract, maybe you’re fighting a legal case. During a negotiation, there’s a lot of meaning to what side of the table you’re on. Most significantly, everyone on the same side of the table is on the same team – we might not like each other, we might not always disagree, but we’ll close ranks and look out for one another if needed because we’re representing our shared goal more than ourselves.
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:
(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:
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.
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:
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 that’s in spite of the fact that professional sports teams are famously savage about managing performance, reliably cutting or trading players without warning.
There are practical reasons to close ranks. Blaming people both eliminates any hope of them redeeming themselves, and more importantly instills a culture of fear that 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 people aren’t that dumb. If someone messes up, that reflects directly on their manager too. 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.
2026-08-05 08:00:00
Everyone knows that lying to your team is bad. Only a complete sociopath would argue that lying to your team is a positive, happy activity. But there’s a particular form of lying that many of the most experienced, compassionate, and honorable managers indulge in all the time: overpromising, and in particular overpromising career rewards. When managers are under pressure, and especially when they’re under pressure to retain a high performer, overpromising is one of the most common tools to reach for. The industry is rife with promises that someone will get a promotion, a new role, a large bonus, 5 more days of vacation, or any number of goodies, large or small.
Overpromising carries a terrible risk/reward tradeoff. Here’s how it goes down:
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.
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:
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 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:
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.
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.
2026-07-27 08:00:00
In the course of conversations with startups that I’ve invested in, that I advise, or that I simply encounter, it’s very common to get into discussions about prioritization.
Some common situations that I hear about all the time:
The advice that I give in almost every case – the best way to prioritize is to not prioritize.
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.
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:
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.
Prioritization is a trap. It wastes time, wastes effort, and delivers worse results than just executing faster. Instead of spending your time prioritizing:
