One of the first things my CEO told me is that things move fast, so you have to get things done as completely as possible and move on to the next thing. I think about that advice a lot, and I find myself telling people that same thing again and again.
However, execution of that sage advice is not easy. Of course everyone wants to get stuff done completely. But I find people make four common mistakes when trying to get things done:
In a fast-paced environment, having more than one focus is a recipe for getting nothing done. The best people may have many things in-progress, but always have one thing that they are trying to get done; they fanatically focus on finishing that thing.
Think of it like being a Ninja Turtle. You’ve got your one main focus - that’s defeating Master Shredder. There’s other stuff going on, like chowing on pizza and skating the sewers, but you gotta make sure your main focus is always defeating Shredder. As long as Shredder is still active, you can’t also be saying you’ll definitely learn a kickflip by next week - if you truly try to prioritize both, you’ll end up doing neither.
So whether it’s a project, or a new process, or whatever - every week (or handful of weeks) should have one main thing you are finishing:
While having a main focus is important, sometimes you focus to a fault. Some managers protect teams to a fault. The fault lies when things that you can’t ignore - bugs, customer issues, feature demand - get ignored.
While having one main focus at a time, you need to knock back the other non-ignorable stuff that always comes up, and you must do it as completely as possible, so you can get back to your main focus..
Think of the distractions from your main focus as Shredder’s minions. You never see a Ninja Turtle fighting Shredder while having a minion grab their legs. No - minions arrive and you knock them out ASAP. Then get back to Shredder. The problem is that many people either ignore the minions or don’t knock them out.
So, don’t ignore things you can’t ignore, for example:
Whether it’s bugs, feature requests, or minions - if they’re not going to lay dormant, you must knock them out, lest they creep up on you and overwhelm you, letting Shredder sneak out the back door.
The third mistake people make is not finishing things. This was the crux of the feedback I got in the early days. It’s easy to let minions linger, still conscious, coming back again and again. These are support tickets and bugs and stability work that many people will keep pushing forward but never quite getting complete.
Progress is better than perfection, but it’s important to not fall into the trap of what I call procrastgress - little bits of progress that are not getting any closer to done, and in fact are just a form of procrastination. Procrastgress is particularly pernicious because it gives the appearance of progress and resourcing - surely we’re not ignoring something, our on-call is working on it! No, they’re not, they’re just kicking the can ever so slightly down the road until the next on-call shows up.
Procrastgress in the Ninja Turtle World would be going around and jabbing each minion in the face. Yeah, you’ll stop them for a second, and maybe you’ll feel like you’re in a fight, but you’ll fall behind quickly. You have to knock things out; finish them. Practically, this often means three main things:
OK, say you’re doing all the things above - the final trap people fall into is taking too long to get their main focus to a stopping point and milestone. Sometimes people say “we need to focus for twelve months.” If you’re at a startup, you don’t get twelve months. We’re a different company twelve months from now.
Many companies have year long plans and many people get upset when those year long plans are disrupted 6 months in by urgent and important work. But guess what - that’s not the fault of the urgent work, it’s that your year long planning set expectations wrong. The most important thing changes and you must be ready to change with it. This means doing things in reasonable time frames (e.g. 1-2 quarters) and then looking around to make sure whatever you planned next is still the right thing to do.
Think of it this way - if the Ninja Turtles spend an exorbitant amount of time with Shredder, some other bad guy will show up and now you’ll have two main focuses (see section one). Every superhero needs to defeat their villain before the end of the episode, so don’t expect multiple seasons to get your main focus to a stopping point.
]]>As I wrote this list, I found that there were a few main themes that drove my interest in these works. These were:
In any case, I hope this list is useful - I love these books. Also, I’m always on the lookout for recommendations - let me know what I should read next!
Management
This is probably the best “ramp up to being a VP Engineering” book there is. It provides four main metrics to measure and modernize your engineering team:
This is an old book that still applies decades later. There are two ideas that truly stood out for me:
Biographies
Teddy Roosevelt was the definition of high output. Reading this book should give you at least a decade of If-Teddy-Can motivation.
Malcom X’s biography is one of the most page-turner books I’ve ever read (tied with In Cold Blood and Fight Club). Malcolm X’s life was defined by his ever-evolving worldview, executing each iteration with intense conviction; laudable traits for any leader.
Economics/Finance/Stocks
A Concise Guide To Macroeconomics
If you lead for long enough, eventually someone will ask you a question about inflation and how it impacts their compensation. Becoming reasonably versed in macroeconomics has been helpful in thinking about compensation systems that live in the real world. This book clearly concepts like monetary policy and inflation.
The Intelligent Investor was, for me, Investing 101.
I will say, however, as much as I’ve loved the Intelligent Investor, Martin Shkreli’s Intro To Investing series was even more useful for me. The videos are hands on teaching on how to do basic company valuations, how to think about future cash flows, and their impact on valuation.
If you’re a leader in tech, you want to know things like why your (growth) company valuation would go down if interest rates go up. These books/videos help you understand that, and how you can help drive business value, as a result.
The Economist is a great realtime drip of information on the economy and world events. Anyone who tells you that they read it all every week is a liar or a bore, but even skimming it regularly has given me much more awareness of the global environment we’re all operating in.
History
A History of Medieval Europe: From Constantine to Saint Louis
Paul Graham recommended this book on Twitter and I found it quite interesting. Any good history book that covers individual leaders reminds me that leadership across the past thousands of years is more similar than it is different. From Charlamagne to Phil Jackson to Lincoln, the core tasks of keeping people happy, managing the skills and egos and ambitions of the leaders that report to you, fending off external threats - it’s all the same.
I’m particularly always fond of reading about wild direct reports. I talk to people sometimes who say they have a strict no jerk policy. Well, General Patton was a bit of a jerk. Should Eisenhower have just fired him?
While we can’t see and learn from specific HR situations in other companies, history offers us endless examples of management decisions and outcomes.
Runner up: Lives Of The Caesars
Habit
This might be the best bathroom book of all time. Daily Rituals has very short descriptions of the working habits of great artists. Ideas that stuck with me:
The book on managing a TODO list.
Religion
The Bible
I found reading the Bible later in life an illuminating experience. Reading it cover to cover gave me a grounding in the foundation of Western culture that has helped me understand nearly everything better, from Shakespeare to the founding of America and more.
Humanity
Even if you’re not about to have a kid - maybe especially if you’re not having a kid - reading this economist’s takes on pregnancy decisions is both interesting and revelatory in terms of the things people go through during a pregnancy. If you manage parents and don’t have kids yourself, reading books like this - and Mom’s Oncall - can be a great way to empathize more deeply with the experience.
Studs Turkel went and asked a ton of people about their job. The resulting book is a fascinating insight into the ups, downs, banalities, and commonalities of the working world.
Evicted is a powerful book about how screwed up the system can be for lower income households. Not only is it a good empathy-builder for people out there in the world, it’s also a look into how laws and rules can go awry with local interests and bad actors.
The Alcoholics Anonymous Big Book is a look into the original vice of humankind. I found it illuminating in it’s timelessness.
Oliver Sach’s tales of the human brain’s function and dysfunction are a popular entry point to the wonder of cognitive science. Beyond the brain stuff, Sachs was a super cultured person, littering the pages with things like “at forty, it is said, a man has the face he deserves,” which sent me on a big fitness push.
Government
What is leadership if not forming a little government. This look into local governments - towns, villages, counties - and their operations was an eye-opener, both for how the world is working around me, but also for how similar some challenges are in local government and a growth SaaS company.
Strategy
This essay feels like reading math - so crisp and concise it’s like it was sitting in the universe all along. It provides a great primer for how to think about business strategy.
Ethics
Define Business Ethics. Well, maybe just define ethics. Peter Singer’s spicy take on ethics is a head scratcher, and I believe any good leader should be occasionally scratching their head about the ethical implications of all that they’re doing. The best thing this book did for me was halt any aggressively strong ethical opinions I had - the world is complicated and ethics are tricky, the best we can do is probably to be even, measured, effortful, and not a dirtbag.
Literature
I love literature. Great literature has helped me learn nuanced ideas about humans that transfer directly to being a thoughtful manager.
For example, when I read the following in The Brothers Karamazov, I immediately realized I needed to never again fall into the state of angry do-gooder:
The more I love humanity in general the less I love man in particular. In my dreams, I often make plans for the service of humanity, and perhaps I might actually face crucifixion if it were suddenly necessary. Yet I am incapable of living in the same room with anyone for two days together.
Here’s a collection of other literature that I’ve found insightful:
Drown - these short stories are imminently consumable, and, for me, eerily realistic/reminiscent.
The Magic Mountain - sometimes I think I’d like to retire, but then I imagine I’d end up like ole Hans Castorp, feeling weird, restless, and stuck.
Ulysses or Infinite Jest - I wouldn’t recommend both, but a lot of management is just about keeping going even when things are messy and you’re not sure what’s going on, which is what reading these is like.
Beauty: When the Other Dancer is the Self - I read this short story 15 years ago and still think about it.
My Struggle - insight into the Scandinavian brain, and you learn about Bergen which lets you seem more cultured when you talk about cities in Norway that aren’t Oslo.
To Kill A Mockingbird - I recently reread this and think it’s the purest example of the craft ever. It’s like reading the Unix manual.
The Solace Of Open Spaces - A recent favorite that is a palate cleanser after a day of tech work.
]]>For example, agile team planning sometimes tries to make engineering resources seem interchangeable. This is wrong. People have different skills and abilities. You want me to score this ticket? OK, it’s a low effort if Alice does it because she’s an expert, and we’ll literally never get it done if anyone else does it. Which field in JIRA should I fill in to represent this?
This commoditization of engineering is most problematic in hiring, because it compounds with other hiring issues.
The first hiring issue is that recruiting is difficult and ongoing, and people aren’t good at consistency, even for easy things; e.g. if you ask someone to send you an update every week forever, about ½ the people will just stop doing it after a month. When a consistent requirement is also difficult, those numbers get even worse.
The second issue is that people don’t deeply understand that you need to always try to hire great to be great:
Other pressures to fill seats include:
So where does this all lead us? People holistically underestimate the need to hire great all the time, and you need to fight that bias constantly, especially in light of organizational pressure to just fill seats. If you fail in this endeavor, you fall deeper into the trapping of commoditizing engineers, doing simple algebra for project planning, thinking you just need to hire someone good enough to hit your numbers.
If you’re building a great team you have hire like it, every day, every month, every year. You can’t take a week off. You can’t delegate this stuff. You need to have quality control on the people you’re bringing into a growing org and you need to be demanding and consistent. You sprained your knee last week? Doesn’t matter, hire great people. Honeymoon planning is stressful? Doesn’t matter, hire great people. Whatever it is, it is not an excuse to have a mediocre hiring operation.
As you bring great engineers into your organization, avoid treating them like input into an assembly line. Acknowledge skill differences instead of trying to pretend they don’t exist.
The second you start thinking engineers are interchangeable and undifferentiated is the second you destine your product to become interchangeable and undifferentiated, another middling footnote wondering what could have been.
]]>It’s important because (done well) they will inject very useful experience into your organization. There are many high-consequence business moments that you cannot easily prepare for by reading a book. In some cases, no book can ever actually prepare you for the emotional challenge, and in other cases there’s simply no useful material to learn from, because nobody who’s written about the situation actually knows what the hell they’re talking about.
SaaS-industry moments that especially benefit from real-life experience include:
These situations are nuanced, high-consequence, rare, and inevitable. While agile decision-making and iteration work well in many situations, these sorts of major changes often need to be exactly right the first time. An experienced executive who’s climbed a similar mountain in the past can save you significant time and heartache when climbing the next one – especially when there are no do-overs.
People who’ve Seen It Before can also help you move faster – when you’re 51% sure that you need to replatform your technology, reorg your sales team, or raise that massive funding round, they’re 90% sure and help to push you over the edge. My own career was shaped for the better by several experienced execs whom I worked closely with at formative moments – I’m forever grateful that I had the opportunity to work with those individuals.
But hiring experienced executives is hard, and when done wrong can be highly destructive.
One typically hires experienced executives into positions of importance, where a mishire is very costly. A lousy engineer is annoying but probably largely inert. A poor-performing executive can be devastating if they cause regrettable attrition, misallocate resources, or slow momentum.
There’s also a tendency to scrutinize the work of fancy outside hires much less:
It’s hard to argue with anything that Jimmy does:
The biggest challenge: In many cases your board, investors, advisors, and even friends will advise you that you must hire certain experienced big-company executives in order to be successful. This advice will often come with a mild dose of negging, which makes it even harder to ignore. For our advice on how to handle this, read on.
Beware executive hires who will not be getting any of the following benefits:
All of the above are good to great reasons to take a job. But if they aren’t getting any of them, and if they were so great at [Fancy Prior Company]… why are they talking to you? In my experience, experienced executives who are open to jobs that don’t bring any of the benefits above are frequently weak performers who can’t cut it. They will say things like:
“I am just fed up with corporate bureaucracy [after 20 years], I want to work in a faster-moving environment [like I have never seen before]. I’m really excited for my next journey [which is completely different from anything I’ve done before].”
Unfortunately, these hires usually simply don’t have better options, which is a bad sign after they’ve had so many years to build a great reputation and network.
There are exceptions. People who are returning to the industry after a sabbatical, time spent caring for or building a family, or after exiting a burnout-inducing startup stint can all be great hires. I’d also factor in whether candidates have real startup experience in their past and know what they’re getting into. But consider it at least a yellow flag if your company will be the “smallest” job that someone experienced has recently held, as defined by a combination of company size and role scope.
You hire experienced leaders, and pay them a lot, so that they can adapt their experiences to your situation.
You do not hire them just because they have experience; you actually hire them because they increase your organization’s versatility. Their experience gives them ideas for operating that you don’t know about, increasing your team’s range. If an exec shows up and just imposes what they’ve seen elsewhere, they are actually reducing your versatility. One way to check for this is to ask people what their previous company did wrong, and more importantly, why it was flawed.
If experienced execs can’t wield their experience effectively, they might as well have been dog walkers in their past.
Big companies have issues identifying talent:
But big companies are actually pretty good at identifying great talent in high-visibility places. If you’re a superstar in a reasonably identifiable location, you’ll probably get noticed eventually.
So while getting promoted a lot doesn’t necessarily guarantee that someone is great… pretty much everyone great will have gotten promoted frequently (this includes being tapped to move diagonally upwards). If they’re missing this positive flag, figure out why.
We’ve written before about the dangers of a resume comprised of many short stints.
Executives are typically highly incentivized to stay at companies for a while – typically due to compensation schemes that are heavily skewed towards equity and company performance. Constant job hopping at the executive level is often a sign that someone is a better interviewer than executer – you need to stick around to maximize comp at the executive level.
But you can build an impressive resume in big tech by coasting on the compounding momentum of tech companies on the rise, and you can link several impressive names together if you’re a great interviewer and good company picker. As an executive, it’s very possible to land and leave at several companies before your bad decisions or lack of ability to catalyze action catch up to you, which means that the ranks of tech executives include many people who’ve spent years failing upwards. If you see a long pattern of short stints in an executive’s resume, be very wary of what might be hiding beneath the surface.
I’m a long-time executive. I’ve seen it all. Billion dollar M&A deals. Directors from the highest-flying FAANG companies interviewing to be on my team. CEOs of public companies have abased themselves in front of me in glass fortress conference rooms, hoping to get a partnership going. I’ve seen our company spin up new product lines, enter new countries, all without a hitch. These people I’m interviewing with haven’t seen anything. Half of them are in their twenties. Their VP of Product is wearing fucking Birkenstocks. They’re making what was it, $15M in annual revenue? $50M? I forget – I can’t count that low. They need me, and I don’t need them.
You would think that if you were trying to get a job, you would leave this attitude at the door when interviewing. And you would definitely think that you would leave this attitude at the door when you take the job.
But I’ve seen much more arrogant or belittling content in interviews than I would have expected, and arrogant interviewees have reliably brought that attitude to the job. Every situation will be colored by the lens of this executive’s awe-inspiring former employer; they will discount your team, talent, product, and progress. Your future will never be as bright as their past.
Arrogance is a sign that people think growth and leadership are easy, and anyone who’s been even a moderately successful executive knows that they are not. The only people who claim to know everything and assume that the journey is easy are teenagers and fakers. Even the cockiest, most self-reverential veteran leaders I’ve ever met all understand that the journey is hard.
So if you see an arrogant interviewer, just ask yourself – are you ready for an arrogant teammate?
A trap that I sometimes see teams fall into:
Don’t fall in love with a fancy resume – it’s better to hire for what you need, rather than what you wish you needed.
You should typically start a new hire of any experience level with a smaller role and then ramp them up. Small wins compound into big wins; a lack of wins decays into systemic distrust. This is common advice because it works.
But with experienced executives, there’s often a temptation to ignore this canonical wisdom. It can feel like someone is just such a badass that they can onboard faster and better than anyone you’ve hired before. This is especially true when the executive is working out and actually is as great as you had hoped – it’s just so tempting to put more on their plate as soon as the first week.
My recommendation is to not skip the step of starting small even with the most experienced executives. In fact, one of the only ways to screw up an otherwise great hire is to ramp their role too fast. Great hires are destined to succeed – don’t kill the redwood tree by over-watering it when it’s a sapling. Let them onboard and get their wins like anyone else, and if they’re really great you have the rest of their career to accelerate their growth. But don’t skip the step of starting small at first.
From what I’ve observed, it’s optimal to find a balance of home-grown and external talent as you reach tens to hundreds of millions of dollars of ARR. Both early stage startup people and gray-haired executives bring distinct value, and having a balance prevents one side from sidelining the other.
Having a balance of internal and external leaders allows you to retain strategic continuity and startup DNA from the old guard, while injecting industry best practices and perspective. You’ll also avoid the demotivation of older employees feeling like they were replaced and kicked out of the family, while expanding your company’s network more broadly.
For a quick example of finding balance, look at the wildly successful Snowflake:
In my experience, big company people strongly prefer to hire other big company people. The reverse is not true – startup people are generally pretty open to hiring both corporate veterans and fellow startup savages. If you allow your company to be completely taken over by big-company people, they will fill it with people like themselves.
This can be fine in some situations, but many (perhaps most, perhaps literally all) companies benefit from the pirate DNA that genuine startup people bring. Most of the largest Fortune 500 companies eventually run critically low on entrepreneurial startup DNA, and try to recapture it through acquisition – they’re drinking the blood of the young to reclaim their youth. It’s fine if you feel like you don’t need startup DNA, but if you’re going to lose it at least let it be a conscious decision.
]]>In some cases you’re worried the company could literally collapse. It’s bad.
Luckily, as ridiculously bad as situations can seem, most teams break in very similar ways. And, even more luckily, most teams can be fixed in similar ways. So, let’s talk about diagnosing and fixing the most broken of teams.
Poor performing teams share common ingredients:
All of these issues collectively add to what feels like an organizational gaslighting. Nobody really knows what the truth is, what good looks like, whose fault anything is. People are angry and nothing ever seems to fix it.
If you get to a place where you see a team like this, take a deep breath - things are going to be tough for a while. But then take another deep breath, because it is fixable.
The two most important steps to take are:
Whoever takes over this broken team has to know what good looks like and be willing to drive towards it persistently, every day, for as long as it takes. Their energy can’t be thrashing like a lion, but non-judgemental and focused, like a river. The new manager also needs to understand nuance, that the team has legitimate gripes and non-legitimate ones, and it is willing to arbitrate which is which.
Fix the Process
One of the first things a new manager should look to do is fix broken processes. Broken teams have lots of broken processes with lots of symptoms that would be fixed by better process, such as:
In any case, getting good, simple processes in teams is a great way to get the team doing better and at least acting like a good team. It’s a good way to show value to the team.
The more cynical members of the team will often claim no process changes are needed. Ask them to just try it out for X amount of time. Good process often works fast and can help cynical people learn they don’t know everything.
Out With The Bad
As the new manager makes incremental gains, former leaders on the team feel threatened. Their entire political capital is built from bashing managers. Negative culture carriers might need to get managed out. Occasionally they change their ways, but this does not happen frequently.
In any case, the biggest mistake is to elevate negative culture carriers further. Do not do that. Don’t think that, for example, by making a negative IC a “team lead” you’re solving any problems. You’d only be making things way worse.
When engaging with negative culture carriers, it’s important to remember a few things:
In With The Good
It’s very important that at least some new people are brought into the team. New people bring fresh perspective, at least some allegiance to the new manager that just hired them, and are often not able to be swayed to the pre-existing cynicism.
It can be stunning how quickly one good new hire with a good new manager can change a team. Many teams are broken because a few loud, negative people have taken over without any strong objection. The first time the passive teammates agree with the new manager/new hire, the cynical members of the team often lose their cynical courage.
Fix The Mission
Broken teams often have missions and responsibilities that need to be revisited, fixing foundational ownership issues that over-taxed their ability or created organizational friction. Blurred lines of ownership are often major catalysts for toxic teams.
About 3-6 months into your tenure with a new team, you should have made progress on process and progress on people, and you should know enough to see where the team mission needs tweaks. Figure out what to clarify, what to abandon, and what to give away in the team’s mission, and then do it.
At some point, with 1 or 2 new people in and 1 or 2 cynical culture carriers out, new process, and a fresh mission, there’s a day where everyone joins a meeting and things just seem to work. This is often 6-18 months after the new manager joins. You can often get initial results in 1-2 weeks, but a complete solution is often 6-18 months of work. 6-18 months is often about 1-2 performance review cycles, where high integrity decisions force in-or-out decisions for people; it’s also enough time for new teammates to get onboarded and help change the team culture; it’s also about how long it takes for people to kind of forget what the old vibe and complaints were and start living in the new reality you’ve created.
But remember - a good team can always regress. So once you fix a team, be extra vigilant to not let things get back into that state.
Sometimes the team you are fixing does quit en masse. If this happens, don’t panic - fears about everything exploding are almost always exaggerated. You need to go into a recovery mode right away:
The steps you need to follow to fix broken teams are:
What is tech reacting to?
Broadly, the last 5+ years: Low interest rates, employee-advantaged hiring conditions, DEI programs, polarizing politics, remote work, new iterations of HR-led processes. A large and growing sentiment has been “just cut the fat and build”, with some people suggesting cuts for processes and vocations that long pre-date the ZIRP years, including: User Research, Product Management, Data Science, Chiefs of staff, OKRs, titling, and more.
While that “just build” direction might be correct, swinging the pendulum to the other side too far or for too long will bring problems just as severe as the inefficiencies that caused the reaction.
Of the “cut the HR process” category, one of the more common sentiments is: “Get rid of performance reviews, they are stupid; people should just get feedback in real time, reviews are ceremonial.”
This is wrong.
Performance reviews matter a lot. In this post we’ll aim to explain why they matter, and give options to trim down your process. You may be in wartime, and temporary changes could be necessary, but too little process for too long is a problem, even at war (there’s a reason that the military has very stringent career progression processes).
A lot of knowledge workers have no concept of what it’s like to not have performance reviews. This is in stark contrast to most of the world, who don’t work knowledge work jobs, and who don’t have performance reviews.
I’ve worked a job before without performance reviews and I know a lot of people who don’t have reviews. What that looks like in reality is a never ending treadmill of hoping to get some more opportunity, not even knowing what’s possible. You sit in the kitchen, or the job site, or the workbench, day in and day out, wondering if a raise or a promotion is 1 month away, 1 year away, or never going to happen. There’s no 1:1s. Most feedback is “don’t screw that up again.”
If you ask about a promotion or more responsibility too often, you might get labeled annoying. What is too often? Depends on your boss. Could be once a quarter. Could be once a year. When a new opportunity does come along, it often feels like magic happened. Why did the boss decide this was the time to let me do something else? Who knows. And when someone else gets promoted over you, don’t even think about asking why.
In those conditions, if you were asked if you like the status quo, or if you would like to chat transparently every 6 months about feedback and your growth path – which would you choose?
You may think these are contrived descriptions, but they’re not. Even in knowledge work, many environments are still a lot like the example above.
So let’s talk about why reviews matter and how to streamline them.
If you’re a company that does regular comp increases, promotions, and/or bonuses – you need some method of evaluating who gets what. Performance reviews are this method. Without them, you’re letting managers just make things up. This is a disaster – see example description for how that looks and feels.
If nothing else, performance reviews at least provide a regular mechanism for evaluation that shows people some sliver of how they’re being judged for rewards.
Everyone should be giving feedback in real time.
You should also not smoke or drink, you should exercise 3 days a week, and you should definitely get 8 hours of sleep every night. In reality, almost no manager gives the perfect amount of real-time feedback, and you don’t follow those health guidelines every day.
Giving feedback is hard, and for many, unpleasant. If you remove the guardrails that force feedback to happen, many people will default to giving essentially no feedback.
Even if your manager did give perfect real-time feedback, you need milestones to reflect over longer periods of time. “That design could have been simpler” is one form of feedback. “You have had a pattern the last 6 months of over-designing systems. Also, it seems you use the decorator pattern as default in many cases, when you should think more about what’s needed from first principles.” is more durable feedback on an intentional change in behavior – the kind that is more easily distilled from a look back in time, not just real-time feedback.
Performance reviews make sure that feedback is given at a minimum viable frequency and that feedback considers a longer timeframe than just recent memory; they raise the floor of management effectiveness, ensuring nobody goes longer than a certain period with some level of focus on these critical areas.
Performance Reviews are a critical way of understanding manager efficacy. Performance Reviews act as the major avenue through which leaders can review and audit the feedback and growth plans that managers reporting to them are generating.
Furthermore, many Performance Reviews include upward and peer feedback about managers. Both of these mechanisms are often invaluable signals to help ensure people are being managed well.
OK, maybe you buy that reviews are necessary. I’ll concede that most companies are terribly inefficient at them. Let’s align on the most necessary parts of performance reviews, and tips for streamlining.
First, let’s talk about the timeline. If you’re doing reviews every 6 months, you could get away with moving to 12 months. I’d advocate making reviews faster and running them every 6 months, but the sky won’t fall at 12 months, especially if your back is against the macro wall.
Second, reviews often have elongated timelines to coordinate all the writing. Employees often spend too much time on their self review, hoping to build a durable artifact of their work. You could set one day for the whole org and say: everyone writes their self, upward, peer reviews today.
Third, when it comes down to it, reviews are really trying to get < 10 critical points of information: a few big things you did, a couple places to improve, some feedback from peers, some feedback to managers, and some sense if people are doing poor, ok, or great. This is not that much information. Ways to streamline generation of information:
Finally, you might be part of a very small growth company, or a company in bad shape. You can (but don’t have to) put a moratorium on performance reviews for up to ~2 years if one of the following is true:
Performance reviews are necessary. Done right they give feedback and growth pathing over periods not covered in day to day management. They allow for a history of performance and an auditing of management.
If you’re an IC and you think performance reviews are bad at your company – demand they get better, not that they get removed.
As much as people say they don’t matter, reviews matter. Of all possible things that people reference 4+ years after-the-fact, low-quality performance reviews are the most frequently referenced gripes about past companies – people remember the words and phrases and tone and effort far into the future. Ultimately, a thorough, fair performance review is one of the best ways to show that you care about a direct report; a shoddy, phoned-in performance review is one of the easiest ways to fracture employee trust.
One final anecdote. I used to think Performance Reviews weren’t very critical. I had a hard worker on my team who was a very solid, low drama employee. I delivered the review with medium energy, not bad, but just not great. They resigned a week later, saying the review left them uninspired. While they were already on the fence, I was probably 3 sentences and 2 ideas away from retaining a solid performer for at least awhile longer.
Performance Reviews Matter.
]]>The person selling your product matters.
The person selling your product is not an optional add-on, or a glorified landing page who exists just to give demos. If the person selling your product is successful, you will sell more of your product for a higher price to happier customers. For many businesses, the speed gains when acquiring customers (deal velocity) and the higher price points their sales team allows them to command may be the difference between a fundable vs. unfundable startup, or a viable vs. unviable business. You need the person selling your product.
Contrary to stereotypes, only part of sales actually involves convincing a customer to buy your product. The person selling your product spends a very large amount of time helping customers successfully navigate their own complex organizations, and purchase a product that they already want (yours).
To do this, the person selling your product has real, tangible skills that help software purchases happen. They may not be “hard skills” like TypeScript or algorithms design or linear algebra, but they are real sales skills that are obviously identifiable when you see them. For example:
For proof that sales plays a critical role in getting deals done, consider that even the most dominant products – Alphabet and Meta – employ salespeople. At the most foundational level, sales works because spending money is an emotional decision, and the person selling your product provides the emotional lubricant to break through obstacles.
The person selling your product is a high-end matchmaker, not a used-car salesman. One of the most important roles that they play is efficiently screening bad fit prospects, saving your entire business time. You can waste a shocking amount of time trying to close or support bad leads. The person selling your product is adept at qualifying leads and preventing them from poisoning your customer-base or sales process.
On your team, the person selling your product seems kind of like a high school sports mascot – going to conferences, taking customers to steak dinners, banging gongs at the office. But at your customer’s company, they’re often a hero. The person selling your product can be a therapist, a political strategist, and at times a hostage negotiator. They’re both good cop and bad cop. The person selling your product, if they’re effective, operates with very high integrity. You would be surprised at how often great salespeople get invited to their customers’ weddings.
The person selling your product has a difficult job.
The person selling your product started their career in one of the most unforgiving jobs in tech – as a Sales Development Representative (SDR), effectively a cold-caller. They were tracked with productivity metrics such as number of calls taken and demos booked. Their calls were recorded and listened to by their manager. The person selling your product was one of the best cold-callers, and was only then promoted to the lowest rungs of salesperson. The fact that they still work in sales is confirmation that they’ve consistently hit ever-increasing targets since.
If the person selling your product has a big account fall through, they’d better have other opportunities that can take its place. Even if losing that big prospect wasn’t their fault – the budget got cut, the buyer got laid off, the CEO got abducted by fucking aliens – this quarter’s commission check is now at risk and that nice gift for the kids might be gone with it. If the person selling your product misses the next quarter, they could be dusting off their resume.
Every quarter means a newly reset quota for the person selling your product, and while their skills and network compound, the rest of their work does not. There’s no concept of understanding a software system better and using that as a foundation for greater things. The person selling your product respawns from the first checkpoint with no items on the first of every quarter.
The person selling your product needs you.
Great salespeople can largely sell anything – the key skills of sales (e.g. empathy, customer discovery, and general ability to keep a group organized) do transfer to an extent. But the place where the person selling your product can really shine is when they have a differentiated offering: One that is obviously more powerful, easier to use, cheaper, or easier to support than others. With a differentiated offering, the person selling your product can focus on all of the repeatable skills that will help your product fly off the shelves. As a product builder, you help determine whether the person selling your product ventures into the wilderness in a fully-stocked camper van or naked and empty-handed.
So get closer to the person selling your product. Hop on a few sales calls – in aggregate, sales teams usually have a good sense for what it takes to win in your market. Help them sell your product better; let them help you build a better product. The person selling your product will make you both rich if you let them.
]]>What a year it’s been: AI started eating the world, crypto and banks felt the heat, and the software ecosystem was a mixed bag - some winners kept winning, there were more layoffs, lots of hope, but also lots of continued belt tightening.
Through it all, we had a lot of fun posting ideas, getting feedback, and engaging with the Stay SaaSy community.
This is the 2023 Stay SaaSy year in review.
Some high level numbers and milestones for the year:
Our most popular posts of the year were sometimes a surprise to us, and sometimes more expected. Either way it’s always great to see something resonate.
Numbers To Know For Managing (Software Teams)
Our first popular post of the year was about numbers to manage software teams by. This post started as a question from the SaaSy engineering manager to the SaaSy product manager: “What do you think about one of these Buzzfeed style number posts?”
This was an experimental format, but it resonated with a lot of people. Management is often a very hard-to-define task, and engineering managers especially seek refuge in numbers. Hard-earned anchors that can act as guideposts in an otherwise ambiguous journey can be very useful.
A Practical Guide To Executive Presence
This post was written by the SaaSy PM, and was inspired by observing how different various individuals’ career trajectories could be based upon their executive presence. What initially started out as a single thought (“Don’t show up to work dressed like a ski lift operator, unless you’re actually a ski lift operator) became a broader set of observations on the behaviors that give companies the confidence to put you In Charge (™).
The popularity of this post led the SaaSy engineering manager to start wearing different shoes to work after reading this post – remember to never be in both the youngest and shabbiest 1/3 of your company!
This post on the market and workplace dynamics driving remote work got a fair amount of popularity and some really thoughtful commentary. The central concept seemed to resonate: That remote work discourse gets it all wrong because people can’t emotionally separate the concept that remote teams have issues, from the concept that remote hiring often opens up a stronger workforce.
Your Small Imprecise Ask Is a Big Waste of Their Time
The popularity of this post made sense in retrospect - one thing we’ve learned through previous posts is that pithy advocacy for avoiding bad management behavior strikes a chord. One of our most popular posts of all time had a similar theme - Don’t Joke About Firing People.
Posts like this often find lots of people commiserating about being on the receiving end of the behavior we’re saying to avoid. If there’s one takeaway from the continued popularity of these articles it’s that manager behavior can have asymmetric downsides to employee morale, and while managers shouldn’t feel it’s their job to make their team happy, it is their job to not make the team frustrated (which is harder than it may seem).
Practical Ways To Increase Product Velocity
The authors of Stay SaaSy have been fortunate enough to invest in and advise a few companies. In our conversations with these teams, we’ve found that a very high percentage of discussions essentially boil down to “how do you think we could build products faster?” We went back and forth several times about whether this
Posts we thought would be more popular
EM: Hidden in Plain Sight: Unraveling Big Problems Disguised as Small Unrelated Issues
Listen, I screwed up. I posted this article on the Sunday after Black Friday when everyone’s inbox was filled with deal emails. Not only did this post not get traction, it led to a spike in unsubscribes as people had their “no more email” fingers on the trigger.
That said, I was really bummed that this post didn’t start a conversation. The core idea – that disparate symptoms can have one root cause – is one of the more challenging management problems to solve. I’m reflecting on how to better articulate this idea in the future.
PM: How Acquirers See Your Company
People in tech are obsessed by liquidity events, and this was our first foray into pulling back the veil on how to actually get acquired (or acquire someone else). The questions laid out in this post really will lie between you and a profitable exit, and much of the advice that I’ve seen on the internet appears to come from people who haven’t actually seen what intensive M&A due-diligence looks like.
If you’re running a startup, check this post out – my goal was to help somebody out there make some money!
I was surprised that this post on how startups unwisely mimic larger, more successful companies didn’t resonate more. I see this happen all the time – startups try to copy a bunch of “best practices” from Google and end up shooting themselves in the foot (if not the face). Having indulged in my fair share of startup make-believe, this was my best attempt to save people months of time that they’ll never get back.
Post we thought wouldn’t be as popular
EM: Numbers To Know For Managing (Software Teams)
Not only was this post experimental, but it made some bold claims about a lot of different numerical values. I figured we’d get some more debate and criticism on numbers that clearly advocated; I was really surprised that there wasn’t much by way of opposing thoughts.
Posts people liked the least
EM: DEI For Dummies
It was likely predictable that people were going to spew vitriol over a post about DEI. I was surprised at how diverse the vitriol was: comments on this article claimed I was liberal scum, conservative scum, and everything in between. And all of that for saying you should pay people fairly, leverage your team effectively, and get some variety of backgrounds on the team.
Short Stories: The Tweets
We had a lot of fun tweeting this year. You can see our highlights here. It’s worth mentioning that we both post from the same account with 0 coordination, and as a result typically don’t know what the other is going to say.
Our most popular tweet of the year (and all time) was:
95% of why big company people and startup people can't get along is that the optimal move at a startup is to play to win and the optimal move at a big company is to play not to lose. This is a much more important factor than speed, bureaucracy, size, politics, stability, etc
— staysaasy (@staysaasy) November 7, 2023
EM: My favorite Tweet from the year by the SaaSy PM was:
The ratio of "times I've regretted acting too slowly" to "times I've regretted acting too fast" is probably 99:1 in my work life, and 1:99 in my personal life.
— staysaasy (@staysaasy) July 3, 2023
That tweet sent me spiraling a bit about how I’ve made choices in life. Luckily I had a good episode of The Deadliest Catch queued up and the crab count pulled me out of existential despair. In any case, I found the Tweet to be a really interesting and useful observation.
PM: This tweet by the SaaSy engineering manager really struck a chord with me, as I’ve noticed recently that a strangely high percentage of my strongest team members seem to share a relatively mild but clearly suboptimal pattern of behavior. This post helped me to acknowledge what I think I always knew deep down – I’m probably the root cause of the issue in some way that I don’t yet understand. I’m still reflecting on where to go from here but I have a renewed sense of purpose about it.
If more than 20% of your team have a similar thing they need to improve, that’s almost always a sign you’re not managing that thing properly.
— staysaasy (@staysaasy) December 11, 2023
“You need to take more initiative” means “my process makes no space for proactivity”
“You need to provide updates” means “I haven’t set…
We really enjoyed all the feedback from the community this year. We answered a number of emails, including interesting and in-depth conversations about management issues. Reminder you can find us at hellostaysaasy@gmail.com.
Well friends, that concludes the year in review for team Stay SaaSy. We want to thank you again for all the feedback, engagement, and encouragement. We hope you have a great end of 2023 and an amazing start to 2024.
One final note – we did get a good amount of questions about who we are this year. We continue to post anonymously because it gives us the latitude to write freely and frequently, and to let our ideas live on their own merits. That said, we’ll offer some clues to our dear readers about our identities. If you think you know who we are, shoot us an email and maybe we’ll buy you a soda. If you don’t, look out for more clues in the future.
The first and most important fact that we’ll address: We occasionally get questions that essentially boil down to whether we actually know what we’re talking about. Are we running teams at a Series A startup with $17.99 in ARR? Are we just 3 interns in a trenchcoat using ChatGPT?
All outcomes are relative, but suffice it to say that everything in Stay SaaSy is based upon real experiences that led to venture scale outcomes.
Here are some other clues as to who we are. We hope they’ll help humanize our account and make it feel less like you’re engaging with a GPT:
Speed determines victory for technology companies. Since the internet was invented, the fast have killed the slow. And out of all the ways that speed matters, product velocity – the pace at which you evolve your product – matters most of all.
But improving product velocity is hard. It’s common to view velocity as an engineering consideration, but a modern cross-functional team’s velocity is just as influenced by product management, design, or even sales and marketing. These teams form a complex machine that’s only as fast as its slowest component.
This post contains my go-to steps for debugging slow product velocity, particularly in SaaS. While I believe that these tactics are generally applicable, they’re heavily informed by my personal background. I have an engineering background and a reasonable sense for when I’m getting bullshitted about how hard something is. I also have a degree of control over both what teams work on and how they work – without that, some techniques may not apply. So while your mileage may vary, I hope that it’s helpful to lay these tactics out in one place.
Product development is like climbing a mountain – there are a lot of ways to the top and seemingly small decisions have large impacts on when you’ll reach the summit. It’s a lot faster to climb a mountain if you’re not waiting around for others.
Some organizational structures and cultures create dependencies, and dependencies directly cause slowness:
Crafting a sensible organizational structure is one of your most important responsibilities as a product or engineering leader. Here are a few steps to reduce dependencies and speed your team up:
Overall, teams should be willing and able to act like smaller sub-startups within a broader organization. Removing dependencies is something that can be done fast and pays dividends almost immediately. There’s a selfish benefit here, as well – if you’re a leader, dependency hell is going to get escalated to you.
Climbing a mountain takes longer if you don’t know the route.
When there’s no clear narrative for your goal and the steps you’ll take to reach it, requirements become slippery and product velocity grinds to a halt. Customers always need one more thing; there’s always an edge case you didn’t catch. “Done” becomes a moving goalpost that permanently hovers about 4 weeks in the future.
Requirements can shift for many reasons:
These teams all share one trait: The lack of a clear plan enables aimless wandering towards a fuzzy goal.
The best way to resolve shifting requirements is to require clear narratives for what it will take to get a project done, and force teams to document them. Teams must clearly explain:
The first advantage of requiring clear narratives is that it reveals whether your team has a complete end-to-end plan. Unclear thinking is a reliable cause of slowness, and gets revealed under a microscope.
Additionally, demanding clear narratives on why something is hard is the best way to reveal when the root cause of slow development is product management (typical failure modes: poor definition, executive stakeholder dysfunction) or design (typical failure modes: over-analysis, poor understanding of the problem). Otherwise, it’s easy for teams to use hot potato accountability where fault lies with whoever touched the project last – typically engineering.
Bonus points for documenting plans in writing. One of the largest advantages of a strong writing culture is that it forces much clearer narratives than meetings, powerpoint, or five Slack threads spread over 8 business days.
It’s faster to climb a mountain if you’re fit.
Engineers are the largest subset of a cross-functional product development organization, often outnumbering PMs or designers 10:1. As a result, it’s especially important that engineering teams are efficient. Technology companies live and die by the health of their engineering teams.
If you care about speed, the most important operational metrics for product velocity relate to development efficiency and stability. For example:
Deployment metrics are like an engineering team’s resting heart-rate, blood pressure, and BMI. If you have a BMI of 30 and a resting heart rate of 85, I don’t need a stopwatch to figure out that you’re not crushing your local half-marathon.
Stability is also a strong indicator of velocity, because it’s a strong proxy for engineering team quality and effectiveness:
No matter what your job function is, part of your role is ensuring that your engineering team has enough time to get their vital metrics in order. Especially if you’re a product leader, it’s essential that you resist the temptation to push relentlessly for more features and give your engineering counterparts the room to get fit.
It’s a lot easier to climb a mountain with a guide.
To an outside observer, the following situations can all look identical:
Some of these reasons for slow product velocity are due to your team being weak; some occur in spite of your team being strong. To the untrained eye a great team climbing K2 can look like a terrible team tripping on a staircase (this inability to tell great teams vs. hard problems from bad teams vs. easy problems is also why unwise non-technical leaders reliably drive technology companies into the ground).
The best solution to this conundrum is to find great engineers who can identify and resolve the root causes of slowness. Finding these truth-tellers is the best way to debug whether your team is weak or your problems are hard, allowing you to actually resolve the root causes of slowness.
To find these guides:
It also goes without saying that it’s especially important to build a strong relationship with all of your engineering partners, and especially these trusted guides. More on how to be a PM that works well with engineers here.
It takes a really long time to climb a mountain if you have to climb a different unrelated mountain first.
Finally, if you still can’t figure out your velocity woes at a SaaS company, look at your feature adoption. In particular, look for a pattern where your products share two key traits:
This usage pattern is often a sign that you’ve stretched to close deals that are outside your ideal customer profile. This adoption pattern can actually be even worse than a useless product, and often occurs when sales and marketing fail to generate enough pipeline:
Once you’ve found product-market fit, the majority of customers that you do business with should be good fits for your offering. You’ll move slower if you’re stretching your product in strange directions hoping to close business.
The best way to avoid this issue is to build a great marketing team once you’ve found PMF. Great products and great marketing naturally reinforce one another.
It’s also your role as a leader to break the cycle of one-off demands and interrupts. At the extremes, this can mean saying no to deals and accepting the consequences personally. It can be scary (and sometimes you should build custom features, so it requires judgment), but as a product leader your reputation will ultimately hinge more on your product velocity than it will on how much sales likes you.
Ultimately, some amount of interrupts has to be Enough. Your sales team can’t be trusted with the call because they’ll just do whatever it takes to retire their quota. Your team builds the product, so it has to be your foot on the brakes.
Here are some final thoughts on product velocity that I’ve found to be reliable.
First: Fast-moving teams can regularly outpace partner teams’ and customers’ ability to absorb new products. You want to reach the maximum pace of innovation that your customers (and support team) are able to absorb.
Also, realize that in order to fix velocity problems you may need to replace team members. Unfortunately some people move slow and some move fast and no amount of refining or encouraging is going to speed them up. There is no amount of hard work or motivational speeches that will turn a water buffalo into a gazelle.
Make sure that you’re always moving a little bit faster tomorrow than you did today.
]]>The instinct of high initiative do-ers will be to tackle each symptom rapidly and independently: let’s look at team boundaries, let’s look at burnout, let’s look at making the product more innovative, let’s look at each thing that burns the caching service, let’s figure out why this person hates slow service. But you find that as fast as you fix little problems, new ones arise, which can be confusing and demoralizing.
The problem is that you are treating symptoms, not the root cause. When pressure is introduced and baselines have risen, otherwise dormant issues cause problems. This concept is powerful and not uncommon.
While the above examples shine a light on these kinds of problems, these problems can still be very difficult to diagnose while they are happening. The diagnostic process looks like the following:
Another framing here is that in some cases, there really is something or someone at the root of a bunch of problems, for example:
In a world of signal and noise, one of the most powerful skills you can have is to identify foundational trends and search for deeper, driving factors. When the only explanation is unlikely happenstance, zoom out and start looking for more plausible explanations.
]]>This is not uncommon. Junior managers, or experienced managers with rockstar reports, or in some cases, non-profit boards with celebrity CEOs – all of them have the auspices of power, but when attempting to yield it, they find out that their power is toothless:
What’s even more challenging is that everyone knows when weak power exists; this can result in behavior that is some combination of insubordinate, flaunting, bullying, or simply indifferent. This, in turn, lures the weak power into trying to take disciplinary action. After balancing the posturing of weak power and the reality of wherever the real power resides, the situation is always resolved in a manner that’s messy and unsatisfying – typically with the weak power embarrassed, and overall faith in the institution undermined.
These cycles create unfair realities, like the fact that good junior managers get abused more than bad experienced managers - the latter being worse at the job but often more powerful.
There are only two solutions to these situations:
In any case, leaving weak-power in place for too long is begging for conflict, so don’t be surprised when that’s what you get.
]]>Imprecise asks from managers and leaders cause a disproportionate amount of turmoil and wheel-spinning. To combat this, leaders should be very precise with the amount of time investment they’re asking for when they ask for things. A little bit of awkward precision up front can save major headaches down the line. Here’s some examples:
On the flip side, if you get an ask from a leader:
We’re knights in King Arthur’s court, and we’re going to seek the Holy Grail. We’re astronauts on a mission to outer space, and the backyard is an alien planet. We’re building a pillow fort – it’s our castle for the afternoon. Make-Believe is a fun, harmless fantasy game for all the kids in the neighborhood to enjoy.
Just like young kids, young companies love to play Startup Make-Believe: Pretending to be something that they’re not, in particular a much larger and more mature business. Our enterprise SaaS competitor throws the best industry events, and sends 100 people to AWS’ annual conference – we need to send as many people as we can afford. I heard of a company have teams of 50+ engineers just to maintain their deployment infrastructure – we need at least 4 people to make sure that our deployments are world class. Internal alignment on velocity is vital – we should have a department just for internal training on how to be more efficient.
The problem is that:
If you catch yourself playing Startup Make-Believe, I recommend that you consider very heavily whether the behaviors you’re emulating actually make sense for you. In the earliest days of a startup, all that really matters is finding product-market fit (PMF); once you’ve found PMF, tightening it by building everything that your customers need (and finding more customers) is the next order of business. Startup Make-Believe activities won’t help you find or strengthen your product-market fit, because they come from companies that found PMF decades ago.
Don’t fake it if you haven’t made it. Let’s dive into the common temptations of Startup Make-Believe, why they exist, and why they don’t make sense for an early stage business.
The Fantasy: All the best companies are data-driven, and we need to be data wizards so that we can make decisions “correctly” / “better.” Let’s invest heavily in data tracking and analytics to make sure that we have a best-in-class data program.
The company that gets emulated the most here is Meta. Meta has built an extremely strong data-driven culture over the years, and it’s truly inspiring to see how they’ve used it to align and scale their business. Everyone knows what matters to them, and how to prove that they’re making an impact (move the number, make more money).
But you’re not Meta. Meta’s business is complicated to operate but conceptually kind of simple – people open app, people see ad, we make money. More importantly, as a startup your data is small and probably incomplete, if not actively incorrect. This means that being doggedly data-driven will be useless in many cases and sometimes actively counter-productive.
This isn’t to say that data is useless to startups, but you need to use your judgment and focus on gaining high confidence on decisions for low effort. For example:
The Fantasy: Velocity wins, so we need to optimize all of our internal processes so that we’re the most efficient team out there. Let’s hire an internal communications lead as our 50th employee, and bring in experts (or consultants) to help optimize internal processes like sprints and program management. We’re going to run this place like a goddamn Toyota factory.
The temptation to fine-tune your internal processes is high. Messy internal processes feel bad, and more successful companies appear to have things optimized operationally, so it’s an easy factor to point at to explain why they’re thriving and you’re not. More importantly, having messy internal processes drives certain OCD personalities absolutely crazy, and the act of cleaning up messy processes makes some people feel less anxious because it feels like progress.
Some common areas that are common traps for premature optimization of internal processes:
The reality is that having a process for important tasks is important, but the specific system that you use rarely matters that much. Especially beware of expending effort on:
The Fantasy: We’re going to take over the world, and as a startup we’re going to move fast. When a new technology shift arises, we need to hop on the train and make sure that we’re taking full advantage.
New tech trends arise all the time, and some (but critically not all or even most) end up reshaping industries or even the world. Many startups are born out of a major technology shift. But shifting with the winds of every new technology change kills startups due to distraction.
Large enterprises have the resources to pursue many ideas – Alphabet was once famously working on multiple chat apps simultaneously. Moreover, enterprise software companies in particular actually need to have many pokers in the fire. Buyers of enterprise software essentially outsource some of their innovation to their vendors, and as a result to maximize sales most enterprise SaaS companies position themselves as (effectively) doing everything.
One of the best examples of this is Salesforce. Every year at their conference Dreamforce, Salesforce is excited to announce that they provide every technology use case that any human has ever heard of. This works incredibly well for selling 8-figure software contracts, but doesn’t work for startups because:
Instead, you need to follow the simple but boring advice of simply focusing. When you’re large (say, after $100M ARR), you can start to chase every shiny new object, but until then you should focus to ensure that you actually catch what you pursue.
The Fantasy: For this one, we can MadLib it out:
I heard that {some famous company} has a unique role for {internal / cross-team / industry / market segment}-specific {communication / operations / alignment / strategy / evangelism / excellence}.
We should hire that role, too!
No, you shouldn’t. Large companies with thousands of employees have all sorts of positions that match their business but not yours. Here are a few common reasons why:
Don’t emulate large organizations’ org charts. Innovate on your technology and marketing, because product-market fit is unique and human nature is the same everywhere. As a rule of thumb, if a particular role doesn’t exist at any of your five closest competitors, you should begin your analysis from the default position that it won’t make sense for you.
By far the worst company to emulate in Startup Make-Believe is Google / Alphabet. Google has a number of structural advantages stemming from its Search monopoly that mean that it’s able to be almost completely divorced from reality, and that has allowed it to grow in strange and unique ways.
Google Search is so profitable that you literally could not stop that 1,000mph freight train if you tried. As a result, everything from Google’s hiring policies, HR customs, technical infrastructure, sales culture, and more are able to be completely divorced from your reality. Google has gourmet meals, perfect build systems, and pays at the 99th percentile – we need to do the same! Well, Google also has an all-powerful money printer, would you happen to have one of those too? Your startup probably literally has more in common with the Wendy’s down the street.
By contrast, as uncool as they are, Amazon is actually a company that you can copy as a startup. Amazon’s willingness to play in competitive, low-margin business lines has forced them to remain scrappy in ways that many other mega-cap companies have not, and as a result their pragmatic approach has more in common with startups. But of course, Startup Make-Believe isn’t nearly as fun when you’re pretending to be a competitive low-margin business.
]]>Product-market fit is the point at which everything starts to work for a startup – the point when there is a market that is excited to buy what you’re offering to it (the product). Before PMF you definitionally are not a viable business: Product-market fit is necessary but not sufficient for success.
If you’ve been fortunate enough to see a company find true product-market fit up close, you often get a lot of questions from startup folks who are on the journey themselves. So let’s dive into what product-market fit is and isn’t, and what to do when you’ve found it.
Finding product-market fit is sort of like a scene towards the start of the movie The Matrix. The protagonist Neo is awakened from the computer simulation that he’s been living in, only to find himself naked and disoriented in a vat of liquid. Just moments ago, he was a successful software engineer with a mild existential crisis. Suddenly he wakes up in the “real world” naked and covered in goo, and needs to immediately fight to survive.
A minute later, he’s unceremoniously flushed down a toilet
Product-market fit marks the point where a meaningful proportion of a coherent market (Tech HR teams; SEO marketers; transportation industry CFOs) will be willing to pay for your product. This occurs when and only when you are solving an important problem better than customers can solve it today – meaningfully better, cheaper, faster, anything.
The days before product-market fit are a simple time. You don’t truly know who your product’s customers will actually be, nor how they’ll actually find value from it. The hallmarks of a lack of PMF are infrequent, useless customer feedback (when you aren’t solving an important problem, nobody has meaningful asks) and lack of usage (you might be onto a real problem, but you can’t credibly solve it). At this point you might have a product, and even an identified market, but no fit.
But a lesser known fact about startups is that pre-PMF is usually a very happy time, if you can shake the existential dread that not finding it means you’ll be out of a job. Since you can theoretically become anything before product-market fit, the world is bright. Every exciting potential future is still on the table, and you also have no responsibilities because nobody is relying upon your product. You can only stress about your runway so much, and critically pressure is always lower when your ego isn’t (yet) intertwined with success. Pre-PMF products are perpetually second-semester high school seniors, full of promise and without a care in the world.
The world after product-market fit is completely different. The start of product-market fit is truly marked by the moment when your market is only just barely willing to make a purchase. Since customers are now depending upon your barely-viable product and paying you to solve an important problem, the hallmark of achieving product-market fit is actually urgent feature requests, scaling problems, and a line of suddenly demanding customers leading out the door.
When you hit PMF you transform overnight from a graduating high schooler to a single mom with 2 kids and rent due next month. You have a backlog of 100 product requests that seem like good ideas, and the bandwidth to build maybe 15 of them in the next quarter. This wouldn’t necessarily be a problem, except that the list is growing by 10 requests per week. And so begins the great journey.
Product-market fit pulls back the veil hiding what your startup will actually do, and as a result is the most powerful focusing moment in the life of a company. Before product/market fit you can do anything, but your exploration is broad and unfocused, leading to many aborted ideas and adventures down rabbit holes:
Once you’ve found product-market fit, the world focuses and all of your future bets will be more directed and have much higher odds of success:
There are a few takeaways as a leader navigating this focusing process.
First, don’t optimize anything until you get to product-market fit. Everything before PMF is just playing startup make-believe – you don’t know for sure what you’ll need to be or do after you find PMF, so there’s no point in investing in anything other than iterating faster to find that fit. You don’t want to devote years learning how to be a plumber if you’re going to grow up to be a chemist.
This means avoiding obviously frivolous activities like conferences and networking events. But it also means ignoring canonical startup advice, and avoiding activities that will only make sense after finding PMF. This is an important distinction! While there’s a ton of advice saying that you should avoid conferences, there’s a lot less advice telling you to (say) barely test your product, ignore performance reviews, or forget writing a clear mission statement. However, I would endorse all of these shortcuts if it accelerates the road to PMF.
Next, realize that the attitudes needed before and after PMF need to change. Before PMF, two of the most important skills are creativity and the ability to work very hard in the absence of positive feedback. These skills allow you to test many ideas to see what sticks, and to continue to press forward even without the constant string of dopamine hits that comes from achieving goals (I suspect that this is why many engineers can find meaning in their work pre-PMF while others struggle; engineering provides its own rewards to keep teams motivated for longer).
After PMF, the requisite skills pivot immediately to prioritization and endurance in stressful situations. Once product-market fit is achieved, companies have many more things to build than they have time to build them, and prioritizing nice-to-haves while missing need-to-haves poses an existential risk. You need to know how to tell a “good idea” feature apart from a necessary feature. Of course, the best way to close a wide array of feature gaps is just to work harder – the faster you move, the less excellent you have to be at prioritizing. This is exhausting and stressful, which is why endurance under duress is one of the hallmarks of successful startups.
And finally, learn to ignore advice on the nature of your particular product-market fit: The magical combination of who your buyers are, what they want, and how you uniquely meet their needs. For every market, PMF looks slightly different – there are very nuanced reasons behind why customers love Zoom or Excel and hate other, relatively similar products, and you’ll rapidly find that only you really know them. I’ve seen many mistakes made by teams that underrated their own expertise on customer needs and overrated the expertise of competent advisors, investors, or “industry experts.” For universal lessons about management and strategy, come here and read some more Stay SaaSy; but for specific lessons on what your customers want, you’re on your own (and that’s a good thing).
]]>One thing is certainly true - companies cannot provide the same opportunity to every employee. Each position in a company has a unique set of opportunities, for example:
Even though companies can’t provide perfectly consistent opportunities, companies should minimize foundational problems in opportunity. Let’s break down how to deal with this at two levels: across a department and inside a team
The biggest thing to avoid when managing multiple teams in a department is to avoid creating B teams. Or, more narrowly, avoid creating teams that are structurally B teams – missions that have a lower priority mission. Any team with a long term roadmap that can’t have reasonably good opportunities compared to the rest of the organization should be avoided at all costs.
The following are symptoms you have a B team:
If you have a B team, consider a few options:
Whatever you do, do something. B teams are always just teams dying in slow motion, so better to do something sooner rather than later.
A notable thing you want to avoid is hiring people under the advertising of your average team, while possibly putting them onto a B team once they join. Then you’ll have a dying team and someone who is upset they had the old switcheroo done to them.
Note that not having B teams doesn’t mean you can’t have A+ teams. I.e. Some teams are the Seal Team 6 of your department, and that’s ok.
Another version of department opportunity diversity is team resourcing. Some teams have great managers and some don’t. Some teams have great mentors and some don’t.
While you can’t promise everyone perfectly equal opportunities, you should aim to make sure that everyone has a good opportunity. This means:
What you absolutely must not do is let the reality of differing resources be an excuse for poor performance, unless, of course, it truly is the reason for poor performance, in which case you must act immediately to stop having people operate in an environment that leads to their failure.
Inside of teams, managers provide some level of project routing intentionality. I.e. don’t make project selection some Lord of the Flies process where if you show up late on Mondays you never get a good project.
Often problems of this type are called out by employees: “why do Bob and Alice keep getting all the good projects?” Upon inspection, you find out that Bob and Alice both jump ship when projects get into maintenance mode and get first dibs on the next thing, and the management of that team is tacitly encouraging this behavior by rewarding it.
Managers should be methodical about who leads what projects. It should not be random or first come first serve. You will not always have the most capable person on a top project. This is the price companies pay to grow their team.
Furthemore, as an individual, you should be holding your team accountable to reasonably fair project allocation. Partner with your manager, talk about what you want, and look at the roadmap ahead to pick things that align with your goals.
The one thing that makes all this diversity of opportunity ok or a disaster is how it’s rewarded. In performance reviews, acknowledge opportunity differences and give credit where difficulty is higher.
Say someone had a project that saved the company $10M, but it was kind of a straightforward project. Whereas you had a grueling, necessary project, that was much lower ROI. Do you reward the $10M project person more?
The answer varies per company:
Let’s talk more about weighing impact and difficulty. Consider these factors:
Impact - the value to the business. This should always be the dominant factor in the equation. If there’s no philosophical way to spin work as having impact, the work shouldn’t be done. Impact includes nuanced things like coming up with ideas, which we won’t discuss further here.
Replaceability - could anyone else have done the work? The more unique your impact is, the more it should be worth. This is really what difficulty is measured by, because if work is necessary and nobody else could have done the work, the impact of the execution of the task is higher.
For example, doing Senior Engineer level work means you couldn’t be easily replaced on the task by a Junior Engineer. Doing top quartile work means that only the top quartile of Senior Engineers could have done it. When it comes to team resourcing, you can ask how many other Senior Engineers could have done this without a Principal Engineer mentoring, for example.
It can be claimed that impact can be measured not only in the benefit of the work being done - the positive outcomes realized - but also in the avoidance of worse outcomes had a hard-to-replace person not done the work. Note that replacement cost shouldn’t account for things like time to recruit, to avoid cases where you ascribe value to someone because you have nobody else to do the work and recruiting takes effort.
All of this is to say that impact assessment should include a variables accounting for the opportunity and resources available to you.
A couple more examples to tie everything together:
In summary:
For example, say you’re an IC engineer and you want to propose moving our Critical Service from python to Go for speed improvements. When you get to architecture review, you get feedback that we can’t do that because Critical Service doesn’t need to be super fast and porting it isn’t a priority - the risk incurred is not worth the return on investment.
In short, you are wrong. Your proposal is not good. And, in good organizations, that’s ok. In fact, as you get more senior, you’ll only make bigger mistakes. The bigger the stakes, the bigger the mistakes. Your goal should be to limit big mistakes and learn from them when they do happen.
However, in that architecture review, many companies will not clearly tell you that you were wrong. Instead they’ll do one of the following:
The problem with this ambiguity is that people walk away from meetings like that not understanding they were wrong. And if there’s any ambiguity, people will decide that they were right, and the organization is messed up: “we’re just not innovative”, “our managers are bozos”, “this place is just a feature mill.”
In trying not to hurt your feelings, your team gave you enough rope to emotionally hang yourself. As a result, you not only didn’t learn something, but you also think your team is problematic. This is a recipe for a downward spiral of morale and impact. It is this same downward spiral that often, paradoxically, leads to people being both a low performer on a team while also believing everyone else is the problem.
So remember, much like many other management problems, trying to be “nice” where you should be clear is one of the worst things you can do. Make sure there’s no ambiguity when someone is wrong on a big thing. Be empathetic, be polite, but be clear.
Note: you shouldn’t tell people they’re wrong every time they make a little mistake. However, the bigger investment of time - i.e. the bigger the mistake - the more clear you need to be.
]]>One of the very best parts of working at a startup is that you get to work closely with your company’s leadership team. Startups are small and everyone works together, and if you’re a strong performer there are often very direct routes to directly collaborating with or becoming a member of a company’s senior leadership. Because of these opportunities, it’s wise to make sure that you can communicate upwards effectively.
There are obvious benefits to communicating well. You’ll sound smart, and if senior teammates think you’re smart they have the resources to promote you faster or compensate you better. People in high-responsibility roles also tend to have more leverage to help (or harm…) the business overall, so communicating with them well is a good way to get things done for everyone’s sake.
Being able to communicate in a way that matches executives’ expectations is also a very useful skill for people who are ambitious, because among other things this is how senior leaders talk to each other. If being a CEO is in your future, these skills will help you work better with future peers or board members.
Senior leaders need to context switch a lot. At a startup, it’s hard to find focused blocks of time to work; at a larger company it’s often nearly non-existent. I’ve spoken with executive coaches whose primary role was essentially just organizing CEO schedules in order to carve out just a few hours of focused thinking per week (think 5-8 hours total across 6 work days).
The day-to-day experience of working in a fast-paced environment is a little bit like playing dodgeball without your glasses, with new issues getting constantly thrown in your face with little warning. This isn’t some woe-is-me situation – it’s the nature of the job and there’s absolutely no problem with it. But it dramatically reduces the cognitive bandwidth that people with large teams have available to pick up a novel problem. It is much easier to pick from choices that have been laid out in front of you, rather than inventing a new solution from scratch (“Bring me solutions”).
That said, effective executives can handle open-ended problems and in fact are getting paid to do so. You can bring very heavy and amorphous problems to good executives, but what you bring should consist of specific problems framed with a high degree of context, and clear criteria for resolution.
When setting context for a senior audience, you want to act as a magnifying glass that focuses on the most relevant information about a problem area, not just a window that shows everything. Doing this well will make you seem smart and help you get what you want from conversations, whether that’s advice, resources, or simply a better informed boss. Not setting context or setting it poorly will generally get you the opposite.
Some of the best ways to be concise and structured about context setting are:
One of the reasons that there’s so much value in the concept of bringing someone solutions rather than problems is that it inherently demonstrates initiative: There’s a problem, and even if it’s bad, we at least have a plan to solve it. Executives love when people on their teams take initiative, because proactive teams don’t require as much attention, and teams that don’t require much attention allow them to context switch into their domain less.
You should strive to always show how your team already has forward momentum (or your own personal plans, if you’re an individual). That puts your area of responsibility firmly in the camp of “be aware, course-correct if necessary” rather than “I need to personally instigate change” which is inherently not what execs want to do. The more initiative you take, the more room for initiative you’ll be given.
The final lesson to draw from the concept of bringing solutions rather than problems is that following this advice will inherently make you less political. This is a good thing.
There’s a class of “problems” related to workplace politics that will essentially force you to bring up a problem without a solution. For example, “I should run this project, not [rival],” or “[other team] doesn’t know what they’re doing.” Executives hate it when you drag them into your politics, for several reasons.
First, most executive compensation structures are set up to reward whole-company performance. Many execs receive performance bonuses based upon growth, revenue, and profitability; key CEOs often have massive equity boosts based upon hitting stock price milestones; and on the other hand, senior leaders can be fired for failure to hit targets (even when it’s arguably not their fault!). So while they themselves may unfortunately get distracted by politics, they’d really prefer if their teams didn’t.
At the same time, it’s hard for most people to detect all but the most obvious political activities happening junior to them in the org chart. Half of the politics game is presenting a rosy upward picture; as a result one only sees the outputs of politics at layers below them.
The combination of these factors means that bringing your political baggage to someone more senior will usually be both surprising and upsetting. It will be surprising since they’re probably not deeply aware of the state of the team’s internal dealings. And it will be upsetting, because it means that people have been messing around posturing instead of, you know, actually doing their jobs.
I’m not here to say that you need to entirely avoid politics, because realistically unless you’re the CEO you probably can’t. And I’m not here to say that any of this is right or “fair,” because many execs are themselves unfortunately highly political. But you should definitely avoid bringing politics into conversations with people senior to you in the org chart.
One thing that I find many people don’t realize is that if you’re an executive who is doing your job, you hear a lot of bad or unpleasant news in a given week. Generally speaking bad news bubbles up due to a confluence of factors ranging from escalations of conflicts, to sharing of confidential information, to people simply covering their asses.
This gets even more extreme with certain roles like CEO, General Counsel, Chief People Officer, or CISO, where almost everything that’s put on your plate is bad, and some of it is both bad and scary:
Different personalities handle this stream of bad news with varying levels of skill, but everyone that I’ve ever met, even the most unflappable, finds it tiring at minimum. It’s just human nature. People would rather be surrounded by positivity than negativity, even if it’s their job.
To be more effective when communicating with executives, try not to be one more boxcar in a train of shitty news that someone has been inundated with. One of the best ways to make sure that you’re getting the most out of executives is to be someone that they’re excited to hear from. I’m not saying that you should hide bad news, but there is value when communicating with senior leaders to being what I’d call “emotionally optimistic.” Try to avoid bringing in bitterness, defeatism, or cynicism. In addition to this just generally being a nicer way to live, it’ll also help you bolster someone who presumably is pretty important to your career.
This is doubly true if you are a senior leader yourself. If you’re a VP or beyond, you’re far too senior to treat your boss as your therapist. If anything, you should be an emotional shock absorber for them. Help to distribute the total stress load on the company by taking on a bit of it yourself.
]]>The premise of Optimize Onboarding is that you should start doing real work right away when you join a new company.
The premise of Build Your Career on Dirty Work is that you should find the unsavory streams of work in an organization because they’re big opportunities.
Here we marry these two concepts: When you start a new role on a software team, you should immediately immerse yourself in the tooling and data on how things fail.
Most software teams have the following:
These processes, data, and tooling are invaluable to see where your system fails and learn how it gets fixed. Your system’s failure ecosystem is important and valuable for a whole host of reasons.
First, onboarding into mature systems often can be an extremely daunting, many month (or year) process. This is true for both managers and ICs. Failure streams are a short circuit to understanding the system, because failures are where the system is interesting and nuanced. Failures are where the heart of complexity, entropy, and flux in the system are. Everything that doesn’t fail behaves like the architecture diagram. Failures show where the architecture isn’t working as intended. By focusing on failures, engineers can onboard quickly into the most important part of the system - the part with problems.
Second, failures are where opportunity lives. Technical visions, for example, are ultimately a way of addressing failures; understanding failures are a warp-speed button for being able to thoughtfully craft a technical vision.
In one of my early jobs I spent 9 months trying to find opportunities to improve things. I worked philosophically, from the features down. Around every corner I would find “we already optimize for that” or “it’s not really broken, probably not a priority”.
In contrast - a lot of things were breaking in the system, I just didn’t know about them. If I had tapped into the steam of failures, I would have been thinking about the actual issues that were occurring. That approach would have narrowed the space of consideration from millions of lines of code to hundreds of lines, and from hundreds of services to a few.
Finally, the tooling to detect and triage failures is often the most critical tool set in both the manager and IC toolbox. Knowing how to navigate your team’s observability software and release/revert mechanism is a superpower. Not only does learning the ins and outs of your team’s DataDog / New Relic / Honeycomb… etc. setup give you a much deeper understanding of the system, it gives you a language to inquire and investigate the system whenever you have questions or hypotheses.
Here are some very specific recommendations for your first month at a new job:
Note: While much of this advice is engineering focused, most of it is also entirely doable by a somewhat technical PM. In fact, if you’re a somewhat technical PM and want to become a titan, I think these are high value ways to get there.
Also note: a lot of managers/teams might actually intuitively do the exact opposite of this advice – they try to shield new people from the problems to try and make things more pleasant, not scare them… etc. This is a classic case of good intentions working against people. You hire people to solve problems, so show them your problems right away.
]]>Many companies find it tempting to hire a first PM somewhere in the range of $250K to $1M ARR. Several factors combine to make hiring a PM especially tempting around this point in the life of a company:
Although tempting, I believe that hiring a PM early in the life of a company is usually not optimal, and often stems from misdiagnosing fundamental needs. This is particularly true before $1M ARR.
In this post we’ll discuss when to hire your first PM, when not to hire your first PM, and what to consider doing instead. This post is addressed to whoever is running product at your early stage company. This is typically a CEO or CTO, and occasionally a technical CPO – essentially, whoever writes the most documentation that engineers use to build the product itself.
The job of a PM is to figure out how to turn code into happy customers in a way that makes money.
But PMs don’t personally output any of the components above: They don’t write code, they don’t close customers, and they don’t make those customers happy. What PMs produce are great decisions, and since anyone smart can theoretically make great decisions, PMs are best conceived of as highly specialized resources for when you need to make frequent, important decisions, particularly about how to build and guide your product.
The situation of having many important decisions to make occurs most frequently when you need to:
These criteria don’t actually pertain to most early-stage, post-traction startups. Early stage businesses are small and have little surface area to expand, and relatively immature so most workflows are still simple.
As a result, most PM hires are worth less than the same salary deployed elsewhere. PMs hired too early end up either optimizing a lot of unimportant decisions (should the button be green or blue?) or splitting hairs on trivial tasks (let’s calculate the exact optimal order of the 9 items in our backlog). When you have precious few resources, it’s a mistake to spend them on a team member who won’t be fully utilized.
There’s product management work to be done, of course – but probably less than you would expect, and it should probably be done by you. You’ll do it faster and be able to express a unified vision.
There is also a related situation in which hiring a PM too early actually becomes a detriment: When PMs don’t actually have that much work to do (say, because you don’t actually have product-market fit…), there is a not-particularly-rare species of ambitious but uncreative PM who will actually start to invent work like a mad scientist in a lab – adding processes, tweaking sprint ceremonies, setting up new meetings, the works. This is poison to a young startup.
A related danger when hiring a first PM is deploying them on menial tasks, rather than strategic product work.
One reason that I see founders hiring an early PM looks a little bit like this:
This strategy of hiring a PM to do the tactical dirty work pencils out on paper, but I believe that it is a serious mistake for several reasons.
First, it doesn’t actually provide the leverage that PMs are meant to create. The magic of a great product team is that it allows you to split your organization into smaller units, all of which can strategize and execute autonomously. As a leader, you want to divide your resources and your brainpower across major product areas and trust that teams will find and exploit opportunities.
PMs are the strategy arm of this process, and should be empowered to own the roadmaps for how they’ll better the business, not just the execution of getting things built. In an ideal world, PMs will have better decision-making and execution than you within their domains due to focus and proximity to customer needs. This is how you scale. If you continue to hold all of the strategic decisions close to the vest and use PMs as glorified interns, you’re wasting all of the focus that they could be bringing to bear.
Second, this strategy of having someone help turn strategy into execution adds an additional translation layer to your product development process. As a startup your only true advantage is your ability to move quickly; more layers of reporting impedes the only thing keeping you ahead of the curve.
Finally, the type of person you can hire to do a tactical PM job is generally not a real killer. Who wants to just be an order-taker for someone else? A great PM with a good background would probably rather start their own business (venture capital is everywhere) or take a job at a more established company with momentum and higher pay – ironically, they’ll get more autonomy at that sort of job, even if it’s at a much larger company. By cordoning off the strategic side of the PM role, you’re tasking worse candidates with a less important job.
There are 3 main times when it’s fine to hire an early PM.
PMs are ideal when you’re fully in the mode of exploiting a huge market opportunity. As mentioned above, the primary advantage of PMs is that they help you split your company’s strategic function and go after many customer needs (or markets) all at once – this isn’t the move at $500K ARR for a single use-case, but it is definitely the move when you have 3 major customer use-cases (or revenue lines) and you need to make all of them best-in-class.
This criteria tends to come into play when you have both strong product-market fit and a business that can fully take advantage of fast-moving product advancements: Strong sales reps, mature support, solid marketing.
This is the standard point to hire your first PM.
Some products are more complicated than others and demand PMs sooner. Many SaaS businesses are glorified note-taking apps, but some products like Procore (construction) or Zuora (billing & accounting) or ServiceTitan (trades) are highly nuanced and industry-specific. Because designers and engineers will have less familiarity with these domains, these products hit a point where the problem distillation that PMs provide will speed up development early in the life of a company. In these industries it’s fine to hire PMs much sooner than you otherwise would.
Sometimes you can just get a great PM onboard – and due to their high leverage, they can reshape your company:
But most startups don’t have access to special talent at the earliest stages, because the way that you build your career as a PM is by running a successful product, which usually means scale. Be honest with yourself and only make an opportunistic early PM hire if they’re really special.
If you’re going to pull forward a PM hire, I recommend that you make sure they have a secondary skillset to avoid the case where they start to create work out of an attempt to help. You ideally want them to be able to double as a designer or engineer so they can accelerate velocity, although doubling on product marketing or customer success / support duties can also work.
But just because most teams hire their first PM too early doesn’t mean that you shouldn’t hire anyone. There are a few vital hires to consider instead.
There are diminishing returns on great design, but the returns diminish very slowly. Nobody likes a poorly designed product and design expectations are rising constantly. Immature product design slows you down twice: Once at the start of a new product when you second guess all of your decisions, and a second time when you realize that you need to rebuild your product due to its unintuitive design choices.
Product design can be make or break. It can break a company at the low end – many businesses (for example, bottoms-up SaaS) are essentially non-viable without great design. And it can make your business at the high end – you can sometimes enter huge markets with fierce incumbents and differentiate on Design or UX alone (think of Monday.com, Stripe, Figma).
“But I’m great at design!” you might be thinking. Maybe… but I’ve found that many people think that they’re a lot better at design than they actually are, because:
Hiring a great startup-ready product designer is a great way to accelerate your execution and improve your product’s quality at the same time, and if you don’t yet have a PM or designer, the designer is almost always the wiser hire.
If you’re struggling with execution in vague, unspecific ways, a better engineering manager almost always helps. Think of cases when you think:
All of these questions are improved by better engineering management. Bringing in great engineering talent has immediate benefits and essentially non-diminishing positive returns – many of the greatest companies have been propelled by their superlative engineering. You’ll ship things faster, with more predictable timelines, and at a higher level of quality. This always helps.
Of course, sometimes execution is slow too because the product isn’t defined well enough, leading to the temptation to hire PMs. This is actually where great engineering management shines the brightest. One of the first critical skills that every great engineering manager learns is how to identify and flag poor product definition, because simply accepting shoddy PM work and failing to deliver impact is a career killer in engineering. If the problem is that you are defining products poorly, great engineering management will actually help you become better.
One of the easiest ways to have poor results on important metrics like retention and new bookings is to try to sell to the wrong market. And one of the best ways to sell to the wrong market is to be bad at demand gen, forcing you to try to force your product down the throat of anyone who you can get your hands on.
If you can improve your demand gen to the point that you’re able to sell to your ideal customers, and you have a good product, you’ll see marked improvements in many of the core metrics that make your business tick. Poor demand gen forces you to warp your product to fit the wrong customers, as bad-fit buyers ask for things that your core market doesn’t really need. Great demand gen allows you to strengthen your product-market fit by building the right products for your target market.
Of course this can start to play into a happy fantasy of bad companies – our product is the best, nobody wants it because we just haven’t reached them yet. Demand gen probably won’t help you if you don’t have any paying customers. But if you have even a bit of demonstrated non-trivial traction, Demand gen is a great way to continue to establish strong product-market fit, which is a core part of the product management function.
]]>Good reasons for wanting to become an engineering manager include:
Bad reasons for wanting to become an engineering manager include:
If you are a manager working with someone who says they want to be a manager, your first job is to make sure their motivations are good. This is important, because misguided motivations lead to a painful 12-24 month period where a new manager realizes the pros weren’t as good as they thought, and the cons were much worse than they imagined. When there are bad motivations for becoming a manager, it almost always leads to a departure from the role and even the company.
The reason for these requirements is that management is often more thankless, isolating, and stressful than IC work, and the growth trajectory, prestige, and long-term compensation opportunities are often (or at least ideally) not meaningfully different than the IC path. Many managers have entered the role thinking it would mean everything would be much better than the IC role; over time, many realities set in, including:
For these reasons and more, if you’re not in the management game for the right reasons, the role will wear you down.
You’ll learn a lot of stuff as an engineering manager - project management, performance reviews, budgeting. All of that is learnable on the job. However, there’s some things that you should really be good at before you step into the role. Without these, you’ll be set up for failure:
If you’re a clear-communicating, durable, patient, technically-competent IC that doesn’t need everyone to like them all the time, you can probably be a pretty good manager.
Note: you specifically do not have to be an extrovert, an inspirational speaker, or someone who naturally does things like remember birthdays or throw celebrations.
The biggest mistake people make when transitioning people to manager is being indecisive. The classic form of this is making someone a Team Lead.
The Team Lead role is often used when some combination of the following are true:
When these things happen, people often make an IC a Team Lead. Team lead roles are commonly “be the manager except the HR stuff”.
This setup is often bound for failure, because:
If you want to make someone a manager, make a decision - they either are ready, or they aren’t. If they aren’t ready, they likely aren’t months of training away; the prerequisites for becoming a manager are more deep skills, not simple mechanics.
While you should be decisive about moving someone into management, you shouldn’t just throw them into the deep end. When you promote someone to manager, you should start them out with training wheels - tell them something like this:
“Management is 95% smooth sailing and 5% tempest. You don’t need to steer the ship by yourself through a storm. Manage the team through all the normal stuff, and when things get very difficult - hard conversations, tough meetings, rough decisions - just gather information and tell the person you’ll follow up soon. Then we can partner on it and you can go back with what we decided is best.”
The biggest mistake that happens with new managers is making them do all the hard stuff by themselves. In fact, new managers should do almost none of the hard stuff by themselves. Performance evaluations, PIPs, big decisions - these are all things that should be done in deep partnership with the new manager’s manager. The antithesis of this advice is when new managers have to defend compensation decisions by themself to an upset direct report - this is like sending a foot soldier to negotiate an armistice.
When done right, new managers have total ownership of the easy stuff and a hedge against the hard stuff.
Moving to manager can be a curse or a calling. Doing it well means having the right motivations, the necessary skills, and the right support.
Note 1: all of this advice is not applicable at bad companies. Some companies have managers who are little dictators and the company rewards and encourages that. If you’re at one of those companies and want to stay there, you’ll need to follow different advice.
Note 2: this post focuses on one direction: IC to manager. However, this is not to say that the IC role is not more stressful than that of a manager in many ways. Notably, the IC role often has a much clearer picture of impact (coding output), whereas managers often have less auditable output. As a result, mediocre managers - especially of good teams - are often harder to diagnose than mediocre ICs.
]]>The remote discussion is complex and hard to discuss rationally. As a result, this post includes:
The discussion of the value of remote versus in-person work is highly nuanced, but if we’ve learned anything from the pandemic that precipitated the remote revolution, a lot of people don’t do nuance at all. Many statements can be true at once:
Complicating the matter further, even the statements above have their own shades of gray. For example, I prefer working remote in general, but I think that it probably hurts my job performance to be remote too often – and I honestly don’t know where the line of “too often” actually is. I think that high performers generally prefer to be physically present for projects that they care about, but many high performers also have kids, and view their children as their most important projects, not work.
More significantly, people naturally gravitate towards either getting things done, or not getting things done, and remote work allows them to become the fullest versions of themselves. As a result, there is a strict bimodal distribution of remote work advocates:
In short there really isn’t a good and obvious answer. So let’s break the remote debate into a few components.
In my opinion there are two competing factors that impact remote work, and these factors have almost nothing to do with one another. The two dynamics are the experience of remote and the marketplace dynamics of remote.
Overall, the experience of remote work is less intense and more independent than the experience of being in-person. This is a good and a bad thing.
Remote work provides a number of benefits. You remove commutes, recovering 30-120 minutes that employees can of course spend however they want.
From what I’ve seen, remote employees spend some of that recovered commute time on work and most on themselves, but as a manager you want this. They’ll be less stressed because they could get a nice haircut or pick up their kids after school. They’ll have more home-cooked meals and exercise regularly. As an employer it’s vital to optimize for your employees as whole people, rather than hours of productive work. Sports teams optimize for their players’ sleep and nutrition; the software engineers on your team are probably not built like pro athletes, but the same principles apply.
Remote work also provides benefits if your team is doing deep work – particularly for engineers and designers, but also for many marketing teams, product managers, finance, and more. People get more done with deep work and it’s just easier to avoid distractions when you’re at home with a comfortable setup rather than getting bothered by Jim from accounting.
The minuses of the remote experience are more significant.
Remote work makes it harder to make fast, difficult decisions. The core of executive decision-making for all of human history has been small groups hashing shit out face-to-face. When it comes time to decide whether to pivot your product, pause the roadmap to take a detour for a big customer, or reorg your company, even small groups tend to get to decisions much faster in person.
The other problem with remote is that it pushes many communications to Zoom, and Zoom is a low-pass filter on positive emotion. It’s easy to delegate tasks or share facts over Zoom – no problem at all. But it’s really hard to communicate the emotional wins. We know that you’ve been working your ass off, we will reward you for it, we care and it made a difference. I know that we lost that deal, but don’t be discouraged – I believe in you and we’ll get them next time. These messages just don’t work well over Zoom; the signal gets flattened by the low-pass filter.
Unfortunately, the same isn’t true about negative communication, which means that Zoom has asymmetric communication downside. It probably feels about half as good to get a raise on Zoom; the low-pass filter tamps it down. But it feels 10x worse when someone uses Zoom to terminate your project, or your employment – the negatives get amplified.
Most significantly, it’s harder for a fully remote team to build the camaraderie necessary to sustain outlier output for a long period of time. In hard moments, the X factor that keeps people striving together is a sense of teamwork and shared purpose. This esprit de corps is almost impossible to build without being physically present with one another. Being in close contact with another human or especially contacting them physically (handshakes, hugs) without getting harmed forms the bedrock of trust. We evolved to trust people that we feel close to, not boxes on a Macbook screen.
Sure, some in-person teams have awful, mercenary cultures and some remote companies share a strong sense of mission. But all else being equal, given two equivalent teams where one is fully remote and another meets in-person weekly, I’d bet my money that most of the time the second team works harder and kicks the first team’s ass.
The other side of the remote work debate is the market of remote work. Remote can be set up to be cheaper in terms of labor and office space, of course. But even more critically, remote is a key that allows companies to unlock the strongest talent in the world with less dollars or prestige.
There are many companies that need very strong talent, but there are only a few companies in the world that command the highest salaries and prestige. FAANG companies and their dozen-or-so peers aren’t the only ones that need top-tier talent; they’re just the ones who can sustainably pay for it. Every boring enterprise SaaS company that you’ve never heard of has legitimately hard problems – complex workflows, high scale, sophisticated go-to-market motions. These companies make a lot of money and have strong product/market fit, which means that higher performing team members can make a big difference.
In 2019, most companies had almost no chance at hiring top-tier talent away from the likes of Google, Meta, or other equivalents. The only ways to find top-tier talent as a less well-known tech business were:
Without any irony, remote work is changing that. Companies can now pay higher equivalent salaries (say, a solid Bay Area package to someone working in Cambodia). They can provide great lifestyle perks: Live in Montana, ski 4 days a week, and work on interesting problems with other strong team members. These jobs now fully exist.
Sure, maybe you’ll make $30k, $50k, or hell even $100k less per year than you would at the top compensators. This is serious money. But what if it means that you get to play with your kids, spend time with your parents, and live in a National Park? There are people who would take that lifestyle tradeoff, especially as FAANG-equivalent companies and finance (the top compensators in the market) have mandated hybrid work.
Remote has fundamentally shifted the economics of tech hiring. It has encouraged a broader swath of strong companies to pay remote employees more, and in doing so has allowed them to unlock a much longer tail of talent. While many of the world’s top experts may still prefer the intensity of in-person work at the most famous employers, remote allows companies outside of tier 1 employers to potentially access 90th or even 95th percentile talent when before they would’ve been capped at perhaps 75th percentile talent at best.
Close collaboration and tight interpersonal bonds make your team more effective. But do you know what also makes your team more effective? Having really smart people.
Companies like Instacart, Zillow, Intuit, Atlassian, and Elastic are just outside the Hall of Fame, in the Hall of Very Good. They will struggle to compete for talent with tier 1 companies like Meta, Alphabet, or OpenAI – they don’t have the economics to pay as much, and they don’t have the types of explosive growth or world-changing impact (at this moment) that would put them head-and-shoulders above others as places to build a career.
These companies do need talented people, though! Their problems aren’t trivial, they have strong product/market fit, and they’re at scale – more great people really will help them thrive. These aren’t broken-down ZIRP startups that don’t have PMF, they’re real companies with real business models making real money.
The beauty of remote is that it gives companies in the wide zone between bottom feeders and top compensators a huge boon to recruit top talent. As the FAANG companies mandate return-to-office, remote becomes a massive perk for all of the also-rans who can also effectively deploy FAANG-level talent but are a pace behind in terms of resources and prestige.
The ergonomics of remote also work especially well for larger, less-sexy businesses:
The equivalent of Horseshoe Theory for software is that the smallest bootstrapped technology companies and the largest enterprise companies actually have similar business dynamics. They both care about free cash flow, efficiency, high gross margins and growth where possible. As a result, both are perfect for remote work like the enterprise companies described above.
Bootstrapped businesses almost always grow slower than venture-backed startups, because the main reason to seek venture funding is to accelerate R&D investment, Sales & Marketing, or both (the other typical reason for raising venture money, for better or worse, is to try to look cool to your friends). Bootstrapped companies grow more gradually and more profitably, again obviating the need for many of the high-intensity benefits of in-person work.
Bootstrapped companies’ lower resources also increase the costs of bad strategic decisions such as poor marketing, bad UI decisions, or sloppy technical architecture. Without surplus funds, it costs you dearly to revert bad calls. This means that highly talented employees are at a premium, and opening up the remote talent pool is one of the best ways to get them as a bootstrapped firm.
Early stage startups, particularly of the venture-backed variety, are a lot like being a castaway on a desert island. You don’t have food or water and are going to starve by default. You need to build a boat and sail it to safety before your limited resources run out.
In this situation, it’s very important to optimize for speedy and decisive decision-making. This is not the situation in which you want people kicking back and taking Summer Fridays. In-person and the intensity it brings is a natural fit for early stage companies.
But there’s a much worse situation you can find yourself in as well. Being stuck on a desert island with a shipbuilder, a sailor, and a fisherman is a much better proposition than being stuck with a furniture builder, a schoolteacher, and a software product manager. Team quality is so important that it dominates the probability distribution of success and failure.
As a result, all else being equal I’d try to be in-office or hybrid as a startup – but I actually don’t think that it matters that much. It’s much more important to ensure that your founding team and the first 5-10 people that you hire are the right ones.
Also, at the earliest stages, startups are just about hurling spaghetti at the wall as fast as humanly possible until you get PMF. This requires focused work (which is actually perfect for remote!), but doesn’t require a high volume of the type of no-look passes that in-person work facilitates. Collaboration is dead simple on a 5-person team because you only need to share, like, 3 pieces of information with each other per week. You can share those 3 pieces of information by shouting them across an office, but you can also do it by repeating yourself ad nauseam on a Zoom call or in Slack. So you might as well optimize for team fit and quality above all else.
If you are the best company in your field, or in contention for market leadership, and you are growing fast, then you need to work at least partially in-person.
High growth companies that are in contention for category leadership face two simultaneous challenges: Their product / market fit is typically evolving rapidly, and their team needs to significantly outperform others over a sustained period.
In order to take a dominant market position, companies need to rapidly evolve their products and GTM motions. These companies have to build fast as they rapidly scale up their product, and they need to make sure that their sales and marketing efforts work in harmony with a quickly changing offering. At the same time, they’re usually growing headcount fast which requires extra coordination. Sustained best-in-class execution is a necessity.
My opinion having seen this journey firsthand is that teams should do everything they can to navigate these critical years in-person, ideally all in one location. The hyper growth journey is simultaneously a marathon and a sprint – it requires working with intensity for a long time as the window to win the market opens up. Even more challenging, you have no idea how far you are from the finish line – the best companies may experience 50%+ growth for a decade.
Put simply, high-growth category leaders need to optimize for intensity of work environment. Luckily, these companies also don’t need to worry about the hiring headwinds of in-person as their growth path allows them to recruit the strongest talent who are seeking a seat on the next rocket ship.
Some final thoughts on remote work. We’ve seen a number of companies come out with absolute declarations about their remote / office stance, which they then had to double back on. The two classic examples are:
Both of these situations make you and your leadership team lose credibility, and management credibility takes a long time to regain. I urge you to avoid putting yourself in a situation where you declare one policy and later reverse it. Do not punk yourself.
Also, people perceive losses as much more severe than gains. If you let everyone go remote after being in-office, people who are remote proponents may be excited and more inclined to stay at your company. But if you set a firm expectation of remote and are going back to 5-day in-office, get ready for your team to stage a French Revolution reenactment in your cafeteria.
]]>Well, sometimes they do, but it’s a slow process, and people almost never change their mind because you convinced them to. Journeys of self-discovery, traumatic events, and loss of faith in leaders are much more likely to change minds than arguments.
This idea is backed by psychology, experience, and all sorts of other empirical data - we know that facts don’t change minds. Ideas that are long-held, deeply-held, highly incentivized, highly personal, or tied to someone’s identity are even harder to change.
There are some interesting conclusions from this idea that you can apply to your organization, notably:
While healthy organizations have processes in place to ensure that decisions are made thoughtfully, you should expect that even your strongest team members will occasionally (if not regularly) seem impervious to what you consider flawless logic.
You shouldn’t try to change everyone’s mind, because you can’t, especially the people whose mind is made up. As you debate decisions, your goal should be to:
Like all management, this idea is a statement of nuance - if too many people are seemingly intransigent too often, you have a problem. However, periodic disagreement on grounds you find somewhat unreasonable is expected.
As a manager, you will often desire perfect logic all the time. However, you should avoid overworking disagreements, especially if people are willing to disagree and commit. Avoid things like:
You can’t change everyone’s mind, so don’t try to. Get to decisions, even if some people are seeming to disagree illogically.
One of the biggest unforced errors that companies make is pushing people into making decisions when they either don’t need to. Forcing people to make up their minds is an easy way to entrench beliefs, often when people don’t have the context or time to have an informed opinion.
A common example of forcing unnecessary decisions is asking your team to vote. If you ask your team something like “should we prioritize making tests faster” and then do what the majority says, everyone who answered against your path will disagree with what you did. In this case you forced them to make up their mind, and then decided against it. Alternatively, you could ask things like:
Both of these questions give the surveyed population the ability to give feedback without having to make a decision. Some people may have their mind made up, but those that haven’t are not pushed into a decision. In this way, you avoid people having to pick side.
Another common example is having teams do significant amounts of research and development before design and architecture review. Many organizations have uniquely capable decision makers that are inserted too late into decision making processes, pitting the right decision against the one people have spent a lot of time on. By inserting stronger partnership earlier in the process, you avoid the cognitive dissonance of getting the right answer at the wrong time, after you had already gotten your heart set on the wrong one.
The most blatant example of this anti-pattern is when software engineering cultures explicitly value “strong opinions” as a thing for growth in role. That often creates a culture where you’re encouraged to make your mind up on everything and be fanatical about it. This is a mistake.
A nuanced example of this anti-pattern is when people agree with people instead of ideas. Bob might say in a meeting “I think we should expand to Europe” and Alice will respond “I agree with Bob’s idea.” This creates many problems:
Instead, Alice can say: “I agree we should expand to Europe.”
To avoid “strong opinion” culture, you should encourage everyone hold only two three strong beliefs:
If you value doing the right thing and figuring out how to do the right thing, everything else is just inputs into an equation. As inputs change, outcomes can change, and no cognitive dissonance is introduced in the process.
To enact this kind of culture, you consider the following methods:
Create a culture that avoids encouraging people to strongly form unnecessary beliefs. The more you do this, the more you limit your ability to find the truth and execute well. Stop making people make up their mind.
]]>Given the high stakes involved and the fact that all of this is happening in public, there’s a lot to be learned. Let’s talk about what we can take away from these recent events.
Social media is like, the most luxurious of luxury hobbies in our modern society. It serves no societal utility other than organizing the occasional protest or helping you read up on the hottest new conspiracy theories while you’re in the bathroom. As a result, you would think that reliability would not be a huge worry. Nobody ever missed their ambulance ride because Snapchat was slow.
Twitter has never had a reputation for reliability in the tech world – if Google and Amazon are Toyotas, Facebook is a Ford, and Twitter is a used Kia Sorento that bought you from a stranger on Craigslist. But their extended rate limiting / outage on the weekend before July 4th, and the bizarre communication around it, finally appears to be falling below the community’s already desperately low expectations.
Twitter may survive all of this just fine, and everything might blow over. But it certainly looks like a lot of people said “what the hell, I’ll try it” about Threads because of the amount of trust that Twitter has managed to squander.
Reliability is especially interesting because it is a cultural problem that gets worse over time. If you’re an unreliable but highly viral product, what lesson do you learn? “Reliability doesn’t matter, the users will never leave.” Elon and Twitter are like that friend who never shows up when you make plans, and are salty when you stop inviting them.
The first rule of product management, just like in healthcare, is to first Do No Harm: Never, ever allow your product / market fit (PMF) to degrade. The #1 way that you accomplish this is by not building useless features, and even more importantly not fiddling in a way that makes previously viable features useless.
Elon’s Twitter has been breaking this rule left-and-right. Some of the main steps that I wish he had taken include:
The change to lock down Twitter to non-logged-in users was a great example – they launched it all at once (with bugs!), don’t appear to have verified that it will induce the behavior that they want, and are now also unique in their approach to discoverability (even TikTok will let you see a few public videos if you’re not logged in!).
It all screams product management by instinct rather than science, and leaves them open to completely unforced errors. You might not need abundant product managers, but you do need to actually do bare minimum product management.
Facebook, by contrast, has played this brilliantly:
There’s already crowing that Facebook are dumb for launching without features such as search or direct messages. My brothers and sisters, Threads hit over 50m users in 24 hours. If you think they should have waited, you are the dumb one.
Commentary is already trickling out about how Threads has copied Twitter’s UI, and it appears that Elon may actually be filing a lawsuit (hilarious – I love everything about the last few weeks).
People love to talk down to companies that they feel are copycats, and in my opinion this is entirely foolish. I can practically feel the condescension sparking out of my phone like bacon grease off a pan: “Zuckerberg hasn’t launched an original feature,” “Facebook only knows how to copy and acquire,” “They just aren’t innovative anymore, maybe they never were.”
The reality is that drawing heavy inspiration from other products can be an effective strategy, if not an optimal one – this is not your 5th grade math homework, this is real life and real users and real revenue. Product / Market Fit is capital-H Hard to achieve, especially in the chaotic world of social media.
If you find a model that works, whether TikTok-style feeds or Tinder-style swiping or Twitter-style message threading, and you have a massive user base to leverage, why tempt fate by testing some new product experience? What are you going to do, try to invent some entirely new paradigm just to prove a point, and make a burnt offering hoping that people like it?
One of the most important lessons that we believe at Stay SaaSy is that reinventing the wheel is foolish. If viable social media paradigms are as rare as they appear to be, it would actually be insane for a company with Facebook’s resources to compete in any way other than copying others.
But of course, operating at the scale of Twitter and Facebook is absolutely non-trivial, and building a “clone” that is snappy and actually works reliably is no mean feat. The fact is that despite a 15 year head start, Twitter is a buggy piece of shit and Threads actually works just like the rest of Facebook’s products. This is of course utterly shameful for Twitter given the money they’ve spent to date on engineering, and if Threads loads correctly 100/100 times, then baby that looks pretty differentiated from Twitter to me.
Scale is extremely meaningful. I can cook a better cheeseburger than McDonald’s, but McDonald’s serves over 250 burgers per second. My grill is not a better business than McDonald’s.
Elon and Zuckerberg are, in my opinion, two of the greatest founder CEOs of the last few decades. You might disagree with their politics or their weird speech inflections or their stance on any number of sociopolitical issues, but when you get down to the brass tacks of “can this person build a business around what people want” they’re both truly incredible.
But Twitter is Elon’s side piece, and Facebook is Zuckerberg’s life partner. Zuck literally started the company before he was 20 years old, has never worked anywhere else, and has devoted his life to making the business have the sort of impact that he envisions. Behind the dead, shark-like eyes and robot voice, you can see that he’s actually a little bit loco and there to take over the world riding his steed of a company, not just out to look cool on Joe Rogan.
Not only would Zuckerberg not screw up any Facebook properties the way that Elon seems to be screwing up Twitter (note that most major Facebook properties remain highly successful), but he’s still willing to make the fast bets that are necessary to expand product / market fit. Generally speaking, this sort of rapid, voracious forward momentum only comes from companies that still have core entrepreneurial DNA; Facebook has this and we’re seeing them run a master class on how to move fast at scale.
This is, of course, coming against the backdrop of a potential Musk / Zuckerberg mixed martial arts match. If this fight comes to be, it will unironically probably be a top 10 day in my life.
It’s too early to say where the social media wars will shake out, but we are getting to watch two of the defining business leaders of this generation duke it out and there’s a lot to be learned for all of us cheering them on. Good luck to both companies, and it looks like this week is going to make Musk vs. Zuckerberg, Live at the MGM, into a grudge match for the ages.
]]>People and teams and companies around the world fail at this every day, constantly, disastrously, by not following this simple equation. The main reason goals fail is simply the lack of one of the above elements, i.e. you have bad goals or bad check-ins.
Bad goals are one of the following:
Your sprint velocity increased, you got all the tickets done, you got 70% of your OKRs done instead of 62% - who cares? Absent other context, these are just numbers that have nothing to do with business value.
Valuable goals have obviously valuable outcomes. The more people and teams and companies shift to second order outcomes, the more your company is headed towards a bureaucracy where storytelling is valued more than impact.
You should have a constant existential itch that can only be scratched by confirming your goals actually matter. Rechecking that your goals matter is often faster than you’d think, and time well spent.
Another main problem in goal setting is choosing goals that aren’t actually a priority.
Common prioritization patterns/heuristics include:
If you ask “who owns this goal” and the answer is “we all do” - you’re in trouble. When everyone owns the goal, nobody owns the goal. Success will have everyone taking credit and failure will be an orphan.
Someone must own the goal. That person must do the check-ins. That person must have a first name, last name, and email address that we all know. It can’t be “everyone,” but it also can’t be “the project manager” or “whoever is running X.” That person must plot the course and correct it when it strays and they are held accountable if it misses.
Bad check-ins are everywhere. Really smart, senior people screw up check-ins all the time. Ways they do this include:
The simplest way people screw up check-ins is by not doing them.
One version of not checking in is never doing check-ins from the start, e.g. “people at this level don’t need hand holding”. Everyone needs check-ins.
Another version of not checking in is check-in atrophy: you did a few check-ins, then they lost steam, and suddenly they just disappeared. This is often a self-fulfilling prophecy - once you miss any check-ins, check-ins become less useful, and then it becomes easier to cancel future ones.
Automated check-ins are also a great way to fail at check-ins. Automated emails without human interaction are digital toilet paper. The power of the check-in is actually checking in.
Not checking in is always a mistake, it’s like coaching a basketball game without ever talking to your team.
A classic naive move is the team that thinks they’re special and wants to do standup once a week instead of once a day. This is almost always a mistake. A check-in is a chance to take stock and course correct holistically, which almost never happens organically.
Doing too few check-ins is like a basketball team saying they’re happy to just have less timeouts.
Another classic failure is partial attendance:
You need to hold the check-in meeting every single time with full attendance. If people can’t make it, reschedule.
Not having the right attendance in a check-in is like a basketball team having a timeout without their point guard there.
Ok, so let’s say you have a good goal, with an owner, and periodic check-ins, in a meeting people attend - by far the biggest failure from there is just having a bad check-in meeting. This looks often like:
These are all symptoms of trying to “get through” a check-in meeting instead of actually using a check-in to audit and change outcomes.
Every check-in should have a status check-in on the goal, something like: we’re behind, on track, or crushing it. Say the status out loud and get alignment on the status.
Not saying the status of the goal in the meeting is like playing a basketball game without ever looking at the scoreboard.
It introduces cognitive strain to actually think about getting a goal done; people would often easily spend 40 hours doing stuff they know how to do than 15 minutes thinking about how to do things differently. Check-ins exist to course correct and introduce the energy needed to do so.
Once you know the status you must ask how to fix things that are going off course. The plan should be compelling. If you can’t figure it out, keep trying. Good basketball teams make changes when they’re losing; bad teams just keep doing the same thing and wonder why they lost.
Sometimes people avoid doing real check-ins because an honest accounting of the situation would surface an awkward truth, like the fact that a person or a team is not pulling their weight. The answer is absolutely not to ignore the situation. The healthiest solution is to just be transparent and clinical. Maybe a low performing engineer is stuck on a ticket - better we can say out loud they need help than all pretend they don’t and miss our goal. The more you can destigmatize honest evaluations, the more you can manage effectively.
Another common pattern is that the mere effort of earnestly trying to hit a goal - check-ins, meetings, follow ups - reveals that people don’t actually have the time to make something a real goal. This often happens with executives who try to delegate goals that they don’t personally have the time to hold people accountable to. If you don’t even have the time to check in on a goal, you shouldn’t be telling people to do it.
The worst kind of check-ins go around and ask everyone what they’re up to. Imagine a timeout in basketball asking everyone for their thoughts on how it’s going.
Good check-ins often include everyone giving updates, but the updates are specifically in context of how we’re going to hit our goals.
Sometimes everyone agrees we’re off target but nobody has any good idea on how to change that. Here’s a standard list you can use to prompt the meeting:
One of my favorite movie quote comes from Michael Clayton where the lead character tells his son “You’re not gonna be someone that goes through life wondering why shit keeps falling out of the sky around them.” That quote reminds me of all the times people wonder why goals aren’t getting done. Then you zoom in and see that the infrastructure for their goal (or lack thereof) destined it for failure from the beginning. Hopefully with this guide, you too can not go around wondering why shit keeps falling out of the sky around you.
]]>Onto our first question:
I am at a Series A stage company where the first wave of hires are all on a salary cap (seed employees) and with the recent funding, new hires are coming in above the salary cap, creating disparity of pay for the same roles/ seniority. How should this be managed?
I’m not sure exactly what deal was made with your early employees, but it sounds like you’re probably paying some early employees below market rate in exchange for larger equity stakes. This seems like a modified version of salary compression, where new unproven hires are paid the same (or more) than equally qualified people who are already succeeding on the team. This could understandably cause friction, but it also doesn’t necessarily seem crazy provided that these team members also have much more equity than more recent hires.
It’s hard to answer your question without knowing more details about the situation. So I’ll propose some compensation heuristics that I think likely apply, and for each, a quick test of whether you’re on the right track strategically:
The first heuristic of compensation is that you’re never going to make unhappy people happy with compensation alone. The hedonic treadmill means that once new, higher compensation has sunk in, people’s happiness will tend to adjust back down to baseline, and they’ll be just as upset about their manager, the build being broken, annoying customers, or whatever else is on their mind.
As a result, it’s very rare for moderate increases in compensation to make employees permanently happy. What isn’t temporary, however, is compensating well enough that you take compensation off the table as a reason to be discontent. You can keep increasing compensation to the moon and people will still complain about their boss. But if you pay people generously, they will at least not complain about their compensation, and you can remove pay from the equation as a retention risk.
This leads us to the Thanksgiving Dinner Test. Imagine that your employees go home for Thanksgiving or Christmas, and their parents ask how work is going: Do you like your boss, do you like your team, are they paying you fairly? The situation that you want to avoid is one in which compensation causes the conversation to go downhill: It sounds like you’re underpaid, is that pay structure normal, have you brushed up your resume?
Interviewing is a pain. If things are good at a job, many people will happily remain as valuable team members for a long time. By paying your team generously before they become discontent, you can take advantage of this natural momentum and avoid a situation where compensation causes them or their loved ones to start to build a case to look elsewhere.
The second heuristic of compensation is that you can unfortunately make people extremely, problematically angry with compensation alone. There’s a special kind of righteous anger that people feel when they believe that they’re being treated unfairly in regards to comp. And one of the worst perceptions of unfairness comes from salary compression, where newer and less experienced hires are paid more than existing team members.
To make this even more complicated, you should assume that a significant subset of your team (say, 10-30% at minimum) will talk to one another about their compensation (even more problematically, some non-zero subset of that group may also lie). This creates a chaotic situation in which snippets of compensation information are floating around your organization without context, and tees up the awkward comp situation where someone asks why one person is making X and another is making Y, and you need to respond with a logical explanation (even if you don’t confirm the numbers).
As a result, compensation decisions should pass the All-Hands Test: If you had to publicly defend the compensation decisions that you’ve made at an All-Hands, would it cause a riot? Your compensation philosophy should be sufficiently fair and logically sound that this hypothetical nightmare All-Hands would be uncomfortable but wouldn’t end with windows smashed and fire alarms pulled.
The compensation rules you follow don’t even need to be perfect – as long as they’re logically defensible (usually via a compensation philosophy and pay bands), you’ll avoid enraging your team due to perceived injustice. Passing the All-Hands Test also inherently confirms that your compensation philosophy isn’t working solely because nobody has enough information to realize how upset they should be.
It’s also worth mentioning that compensation’s ability to cause problems is stronger than its ability to make employees happy. You can pay someone 1.5 what they would get on the market, but if someone who they don’t respect is making twice their salary, it’s still infuriating.
The final compensation heuristic applies to startups: The only reliable way to get people to exhibit high degrees of ownership is by giving them a realistic chance at a significant reward.
Early stage employees are looking for high upside – they’re taking on the risks of instability, long hours, and an uncertain future for the chance of financial success. They also want to act like owners – if they wanted to phone it in, they’d work at a larger, slower company. People who act like owners are the engine that creates winning companies. The real potential for upside is what motivates people to grind out unpleasant tasks late on a Friday or think about how they can help you win while they’re in the shower.
But ownership is a relative concept; owning 50% of a lemonade stand and 0.15% of Apple are very different concepts, and our emotional brains run on dollars, not percentage points. This leads to the Millionaire Test: Employees whom you want to be highly motivated should reasonably believe that they have a chance at making at least a million pre-tax dollars if the company hits ambitious targets. For example:
In my experience, a million dollars is an arbitrary emotional bar that most startup employees are looking to clear in order to feel that the long nights and existential stress of a startup were Worth It. You may not ultimately get to a good exit, but employees need to credibly feel that there is a chance. If that possibility goes away, all of the ownership and initiative that the team feels will drain away with it.
So be generous with equity, and similarly to the first heuristic, do so proactively. Try to get as many people as you can to the point where they feel truly invested in your success because they’ll participate in the upside. Without this your team will feel limited, and if they’re doing well they deserve to participate in the upside.
The art of effective compensation is largely the art of managing expectations and calibrating compensation proactively, in a world where everyone has imperfect information and the underlying topic is very important to people’s lives. To figure out if you’re on the right track, consider the following: