2025-02-17 20:59:22
One of the most counterproductive things that companies do is coach people to not judge their coworkers. Having an understanding of your coworkers’ performance means that you understand what they do, and understanding what they do is critical to making sure you collaborate with them effectively. This is especially important if you’re in a leadership role or a cross-functional team. Also, raising the alarm on peer underperformance can be both necessary and highly impactful.
In the early days of a startup, teams are in survival mode - if you’re not pulling your weight, we’re not sharing food with you. Startups that became successful rarely stifled peer feedback in the early days.
Then you hire more vocations. As you add PM and Design and Product Marketing, you eventually hit your first conflict between these groups. It’s usually an engineer alleging that another vocation is not doing their job because, amongst other reasons, engineers are usually hired first (more tenured). And then the big lie begins - you don’t understand what we do, stay in your lane.
Your company dies a bit on that day.
Eventually someone again alleges someone is not doing their job, and the leader of the target employee agrees with the assessment, but they’re not gonna let someone who’s never been in their shoes tell them how to run their team. So they drag their feet and nobody does anything about it.
Your company dies a bit more on that day.
Meanwhile, the leaders you’ve hired are trying not to get into fights while ramping up, and your CEO is trying to avoid criticism that they don’t know how to hire executives or manage different kinds of employees. Everyone is trying to avoid being accused of being a fraud; they don’t cast judgement on others to avoid getting judged themselves.
Finally, you get to a place where there’s enough mediocrity that the few truth tellers left start to get punished because they’re the only ones who won’t pretend that standards have fallen.
As then your company is officially dead.
You’ll make it until the last of the good tenured leaders stick around to keep the boats afloat. Eventually the whole company will be mediocre and a company that throws underperformers off the island will invade and take your land.
It doesn’t have to be this way. In fact, with the right guidance you can encourage your team to judge their coworkers’ abilities, learn from it, and have it be part of a healthy ecosystem of accountability and growth.
Here’s how to do it.
First, things fail when people start attacking others directly and publicly. People can disagree in meetings, but people should not be making judgements on their teammates in public. Performance is public, performance management is private. Make it clear to your team that any and all feedback shared on a coworker’s ability is shared either in a private conversation between a person and their own manager, or in the peer feedback section of a performance review.
Second, follow-ups are done privately. There is never the expectation that people are privy to the details of some else’s performance management. That said, if a peer’s performance is causing significant issues for an individual, team, or the business, it may be appropriate to talk about how to work around those issues while performance management is happening.
Finally, you must make clear that nobody is promised a perfect coworker. All teammates are imperfect, and the average action is not termination but coaching. One of the teachable moments in a discussion about peer performance is making clear that people are expected to succeed despite imperfect coworkers; imperfect coworker performance is a reality, not an excuse.
OK, here’s how to productively encourage your team to think about evaluating their coworkers’ performance.
First of all, you should set an expectation that your reports actually have an opinion on their peers’ performance. Sometime in the first few months you should say out loud something like: We strongly value peer feedback and the ability to understand and evaluate peer performance. As we work together, I’ll periodically ask you how your peers are doing and I’d like you to be able to have thoughtful conversations about it.
Furthermore, if they’re in a leadership position, you might add something like: It’s quite important that you have a mature opinion on how your cross-functional partners are doing. Please make sure that you’re thinking about the different roles and responsibilities you share, how they are performing, and where you see opportunities for improvement.
Next, you should periodically ask your report (e.g. once every 6-12 months) how they think their peers are doing. This is now when the productive conversation starts.
If they think someone is doing well, why? This is a teachable moment - what do you think good performance looks like? Through this exercise you can help people understand:
If they think someone is doing poorly, why? Again, this is a very teachable moment. It’s a critical opportunity for you to be aware of underperformance, the perception of underperformance, or a misunderstanding. This is often a great opportunity to help people understand:
These conversations are also a very important way to get real time updates on the performance of teammates. Getting significant critical feedback from many people about a specific person is almost always a signal of underperformance. Getting this feedback in a continuous fashion is quite valuable, as many companies leave it to very infrequent performance review cycles to solicit that signal.
Finally, an awareness of the strengths and weaknesses of a peer lets people supplement their work more effectively. OK, Bob isn’t great at meeting follow-ups. His manager can work on that for him, but can you, as someone who is great at it, help the team not fail when something is missed?
All of this boils down to not letting tension relief run your company.
When people work together and things fail, it’s somebody’s fault. One of the most evil things a company can do to people is not hold people accountable. I’ve felt bad for people who have had mean bosses, but I feel terrible for people with overly protective bosses. I’ve seen people literally ruin their career because they spent years under a manager who didn’t have the guts to give them feedback, even when other teams were complaining.
Especially for leaders, not knowing how to evaluate the performance of your peer leaders is a major miss. If you don’t know what they’re supposed to do, how can you make sure you’re working together to create a business outcome? How can you improve processes across your vocational boundaries if you don’t even know what their job is? This is why it’s important that all leaders have some sense of how the business fundamentally works. This is why telling people to stay in their lane is so messed up - the minute you tell someone they couldn’t possibly know what they’re talking about when it comes to other vocations, they can never be held accountable to end to end business value again.
And for junior hires, how can they learn without knowing what good looks like? How can you learn what good looks like without ever having the ability to point to someone and talk about their performance?
Judge your coworkers, lest you not be judged, because to not be judged is to never learn.
2025-01-29 20:59:22
Accountability is the only way that anything gets done at scale. Businesses are complex and as any organization scales up, a larger and larger amount of work gets done out of the direct line-of-sight of senior management.
As a result, a culture of accountability is key. I’d define a strong accountability culture as one where:
Most management teams aren’t dumb and do their best to establish strong accountability cultures. But we wanted to share a few common ways that smart people screw up accountability on their teams, often despite the best of intentions – and what to do about them.
What you’re thinking: “I need to hire smart people and get out of their way – that’s how we move fast.”
If you want people to follow through, you’ve got to check on how things go.
Accountability does not require perfect project check-ins, analytics, and heavyweight OKR processes (although if you can find the time, these steps will generally increase accountability on the margins). However, accountability does require some consistent checking.
You would be surprised how often managers literally don’t check that things are getting done until something breaks. At a bare minimum, you should:
Many leaders get busy as their teams scale, and don’t have the time to check on key projects under their control. But instead of rearranging their work cadence to check on how things are going, they blindly trust local leaders to enforce accountability. This is the easy way out both logistically and emotionally, but it’s essential to make time to check in because ultimately accountability rolls up to you. Anything else doesn’t work.
What you’re thinking: “We’re a versatile team – we adapt our strategy as new data comes in. We aren’t like those big companies that operate like cruise ships, we’re a small nimble speedboat.”
Everyone knows what strategic whiplash looks like. Your plans change every 4 weeks; you’re always adding new projects, and worse, the newest project automatically becomes the company’s top priority. As a result, new initiatives are added and subsequently cancelled like a revolving door.
Let’s say that your top priority as of January 1st is to launch a new product line that will help to expand market share. But then your cash forecast comes in, and making sure that we hit profitability becomes an all-hands-on-deck emergency for February. And at the end of March, a competitor launches a new AI feature that we need to respond to. By April, people are barely thinking about whether the new January product line stands and accountability for it evaporates. If you can’t trust that plans will remain the same, you don’t have any incentive to follow through – urgency goes out the window, timelines slip, and the trickiest 10% of every project remains perpetually undone.
Changing course on priorities should be possible, but not easy – it should require real thought and a conscious decision.
Luckily, strategic whiplash is pretty obvious. Anyone can enter your business and immediately see that you’re constantly changing course. Unfortunately, this isn’t true of other problems that crush accountability…
What you’re thinking: “I need to tie teams to metrics to make sure they’re getting things done.”
On balance it’s better to goal teams based upon clear metrics. But incorrect incentives can destroy accountability when they attempt to hold people to poor or impossible to achieve KPIs.
There are two main ways that incorrect incentives break accountability:
There isn’t a one-size-fits-all answer here, but incorrect incentives are such a common cause of broken accountability that it’s always worth considering in any situation where accountability is eroding. Some heuristics to look for when setting goals:
In general, my recommendation is to set simple goals and explicitly set a broad expectation that people will be reasonable in hitting them. For example, “Your goal is to generate pipeline. But my expectation is that you do not meaningfully harm other key metrics or reasonable practices to get there, and I’ll look at those other factors when we determine whether your pipeline goals were actually hit.”
Broken org charts are bad in general, but in the worst case they destroy accountability by diffusing responsibility across multiple people. This is the worst way to destroy accountability, because it can remain hidden until someone does forensics.
There are two main ways that org charts get broken, and both have to do with overlapping accountability:
What you’re thinking: “This is really important, so we need to make sure that more than one person is accountable.”
It’s very hard to establish accountability when more than one person is responsible for some important goal or metric. There are people who can work together to be jointly accountable, but this creates compounding risk – if even one person isn’t highly responsible, the whole system fails. A classic example would be that both sales and customer success are responsible for customer renewals, but as a result neither ends up fully owning the outcome.
This is conventional wisdom nowadays, but worth reinforcing: If more than one person is accountable for an outcome, then no one is accountable. The best litmus tests for this:
What you’re thinking: “We need more management coverage so that we can scale up our team – let’s hire another layer of managers so everyone gets individualized attention.” Or worse – “if I don’t make this person a manager, they’re going to quit.”
A different, equally dangerous accountability risk comes from org charts that are too deep. For example, let’s imagine a situation with:
If there is a very serious issue in the zone of control for IC #55 (let’s call him Bob), who gets woken up at 4am to help fix it? Is it their manager? They’re too junior to know anyone in the executive team. Is it the Senior Director or VP? They probably barely know Bob’s name. Even worse, everyone is able to look a level or two up or down the org chart and think “someone else has got it.”
The net result wrecks accountability. Problems get relayed up the chain of command slowly, because nobody likes escalating to their manager. Because everyone else is assuming that someone else is accountable, many otherwise solvable issues seem to just… disappear. Except they don’t actually go away – they just disappear from the radar, and only materialize when they’ve become so significant and problematic that they’re impossible to ignore.
Then, when it’s time to actually debug the problem, you’ll find that accountability is nowhere to be found. Managers subtly blame their reports. Direct reports subtly blame their managers. The standard response is that some ICs get scapegoated for the first few incidents, some managers get blamed when the pattern continues, and eventually the leader of the department gets axed when someone realizes how broken their organization has become. This process can take years to unfold, with worse and worse outcomes occurring the whole time.
The faster solution is to structure your org chart correctly, and not end up in this situation at all. It’s essential that you fix this as a leader – unlike many other cases of eroding accountability, broken org charts are relatively easy to identify and fix proactively, but you have to actually check them because there often aren’t explicit external symptoms that they’re broken.
Happily, if you have a smart team, all of the issues above can be combated in simple ways:
And finally, reinforce accountability via your company’s reward system. It’s critical that people who consistently don’t perform are managed out, and people who consistently perform well are rewarded. This sets the foundation for all other elements of accountability and gives the system teeth.
2025-01-24 20:59:22
In the course of getting work done at a company, nobody should be doing anyone else any favors. Everything you do at work should be the most important thing you could be doing to add value to the business, and those things should be aided by people whose job it is to support that prioritized effort.
In the course of doing work, favors are either misunderstood responsibilities, gaps in company process or design, or people working on non-priority things:
One of the most challenging instantiations of favors are things people want to take credit for when they’re easy, but bail on when they get difficult.
A subset of the “Don’t Do Me Any Favors” mantra is Employees Don’t Get Charity - business and managers should never claim to be doing something altruistic for their employees. People don’t want your charity, and if you’re doing something for your employees it’s almost certainly not charity and instead a reward that you are giving them because they’ve earned it, or an action you’re taking to help your team, which is your job.
Relatedly, my number 1 piece of advice on delivering compensation information is that when people say thank you, you respond “no thanks needed, you’ve earned it.”
As a company scales there becomes an increasing roster of people you can blame when things go wrong. E.g. it’s not my fault this didn’t work out:
This can get totally out of control to the point where people ask for raises for work that never had any impact, because they did their part. Good companies don’t allow this to happen - they fire people that can’t seem to get correlated with success.
To be 100% clear: at good companies, if the projects that you touch always seem to fail, you are guilty until proven innocent.
As a manager, it’s imperative that you coach your team to take ownership of any problem that causes your work to not succeed. You might risk a very short term hit on optimizing your bonus, but even in the medium term this strategy is much, much more optimal.
If there’s a problem, say “I can fix it.”
99% of management is doing uncomfortable stuff every day: pushing people to do a little better, pushing yourself to be a bit better, resolving conflict, giving feedback. As a manager, your literal value add is what you do to make people and teams perform better than they would have without you there.
Your job is to change behavior.
This can’t be a job you do once a quarter. Many managers dream of big inspired moments of super high leverage decisions that make their whole year. Management is simply not that job. Management is the accumulation of daily nudges, assistance, enablement, help, and toil.
Management happens every day.
2025-01-06 20:59:22
Delegation, specialization, and federation are critical to scaling companies. But scaling doesn’t mean stepping back from everything. Especially for unsavory, cross-functional, time intensive tasks, leaders should position themselves as bottlenecks - owners that feel pressure when the work grows too much, forcing them to find ways to push back on the growth in time and effort.
Dirty Work is the tedious, unglamorous, necessary, tasks that quietly pile up in organizations.
Under the umbrella of Dirty Work, there is a particular subset which we’ll brand Dirty Webs. A Dirty Web is dirty work that is shared across multiple teams.
Dirty Webs are often owned by a team in charge of completing the task but not directly incentivized to complete the task extremely well. In the worst cases they may even be incentivized to not make the work be more efficient - reducing the work reduces the need for their role.
Dirty Webs often include: compliance, incident follow-ups, onboarding checklists, software procurement.
Too often, leaders hand off dirty work to other teams that hire, delegate, and forget the dirty work, creating dirty webs.
Dirty Webs are insidious because they are shared across teams.
For example, leaders defer onboarding ownership to another team. Now those leaders have to risk having friction with someone both more junior than them and not in their reporting chain if they want to provide oversight. So they don’t.
What happens instead is that dirty webs grow unbounded. They become a creeping organizational debt. And when that dirty web starts to slow things down, you’ve officially lost control.
Take compliance. It starts small—maybe a couple of approvals or audits. Somebody asks you if it’s ok to involve your team in the process. Sure, why not? You figure if it becomes a problem someone will escalate. Then, one day, you wake up to find your team buried in checklists, forms, and deadlines devised by a mid-level, under-performing new guy on a different team. Upon inspection you realize it’s a nightmare. You ask people how could this be. I don’t know, they say. Not my job. Shrug. You have $8M of engineering headcount wasting 1% of their time on a process created by a mid-level employee with no oversight.
Onboarding? Same thing. Everyone keeps adding “just one more thing,” and before you know it, new hires are spending their first week watching outdated videos and completing tasks no one remembers the purpose of.
These aren’t isolated examples. They’re patterns. And if leaders don’t step in, dirty webs metastasize into sprawling, morale-killing messes.
Leaders need to be the bottleneck for dirty webs.
One of the most valuable things a leader can do is look at potential dirty webs and say, “This needs to stay small and simple enough that I can understand and oversee it.” If you don’t, who will? No one else has the perspective—or the authority—to keep complexity in check.
You must be a bottleneck for badness.
This is like founder mode, but not quite the same. Founder mode is about doing super high leverage things and keeping close to the most important stuff. This is different. Operating as a badness bottleneck is about strategically positioning yourself to suffocate creeping toil in your organization, ensuring the dirty webs stay manageable and the system doesn’t collapse under its own weight. When done right, a dirty web is not the most important thing because you’re keeping it unimportant.
When a new compliance process is proposed, insist it’s simple enough that you know how to do it. Insist any new compliance requirements are signed off on by you. Push back on unnecessary steps. Redefine what “good enough” looks like. Actually do the compliance steps yourself once a year to make sure they’re not a total time waste.
Onboarding? Same story. Insist on having visibility into any new onboarding steps being added, no matter where in the company it comes from. Be the person who asks, “Does this make sense?” or “Why are we doing this?” It’s not glamorous work, but it’s critical. Beyond saving time, reducing toil also has other benefits:
Too often leaders delegate and forget. Being a Dirty Web bottleneck doesn’t mean you’re involved in every decision of a process, it means that you have some recurring oversight of the things that take up your team’s time. It means you position yourself to have little involvement if things are sustainable, but you become a significant obstruction if things become more time-intensive.
Own the dirty webs. Fight to keep them small, manageable, and in your control.
Because if you’re not bottlenecking the mess, you’re letting it spread. And no one else is going to stop it.
Be the bottleneck.
Note that the teams owning onboarding and compliance and other dirty web breading grounds are not the bad guys here. In fact, they are often the victims - people given incredibly high leverage work without the proper oversight, enablement, or partnership. Compliance is important. Onboarding is important. Given the leverage, all of the places dirty webs spring up are important.
Often these teams get ignored until some leader has a temper tantrum. Compliance and onboarding are inherently high value. They only become dirty webs when leaders partner in the classicly bad way - not at all and then way too much. Being the bottleneck for dirty webs means you partner with teams owning these processes to keep them as great as they should be.
2024-12-29 20:59:22
Well SaaStronauts that’s another year in the books, which means it’s time for the Stay SaaSy Year In Review.
Our audience grew by about 30% this year. What is more valuable to us is the number of really impressive companies and people represented. It’s a joy and an honor to see the domains come into our subscribe list, a who’s who across the SaaS ecosystem.
To everyone who has subscribed - thank you for your readership.
To everyone who has written in - we deeply appreciate your feedback.
Sometimes the dopamine of a good post wears off, and I start to wonder if our content is resonating anymore. Several times this year, this happened, and I looked back a couple of months to see a post that got a lot of good traction. In aggregate, all those 2-month-apart resonators created a nice handful of high traction posts for the year.
Our top posts were essentially an even split of SaaSy PM and SaaSy EM posts. They span topics ranging from core management techniques to networking and beyond. Without further adieu:
We tweeted a lot this year. We shared shower thoughts and deep reflections, crude jokes and serious analyses. We got in a couple scuffles but tried to remain civil. We poked and prodded and nudged the zeitgeist where we saw it. These are our best tweets of the year.
I fucking love how unreasonably optimistic people with early startup experience are. There’s a brick wall, no problem, I’ll go through it!
— staysaasy (@staysaasy) July 2, 2024
And I fucking loathe how easily people who don’t have that experience claim they are helpless. I have to talk to someone I don’t know, nooo!
Do I really miss working at a startup, or do I miss being 25 and working with my friends all day?
— staysaasy (@staysaasy) June 4, 2024
Startups are hard but you sure do learn a lot. I regularly see CEOs of companies at $1-2m ARR who are noticeably more poised and *wise* than directors / VPs of companies at scale - even ones with 10x larger teams than the startup CEO's entire company.
— staysaasy (@staysaasy) April 9, 2024
Some people are salivating at the idea of software engineers being replaced by robots. Y’all forget like half of SWEs are just hardcore smart people that went to where the money is. If robots come for our jobs, we’re coming for yours.
— staysaasy (@staysaasy) February 16, 2024
Also, AI could only replace good developers…
At over 1k people in any org, even if you do everything perfectly, you’ll have at least one person that thinks you’re a scumbag just for being an executive, and will assume nearly everything you do is nefarious. The sooner you become at peace with this reality the better.
— staysaasy (@staysaasy) January 20, 2024
It’s hard to convey to people who have never worked at an early startup that if you don’t work hard your competitors will eat you alive.
— staysaasy (@staysaasy) September 18, 2024
Not like a little bit.
There are startup competitors that would slit your throat for $10 of revenue in the most boring industry you could imagine. So no, we’re not going to do summer Fridays.
Tech companies in 2018: we’ll fly you in for an interview, put you up in a hotel, take you out to dinner, pay for your full service move across country, signing bonus of $20k, catered lunch every day, and a partridge and a pear tree.
— staysaasy (@staysaasy) July 27, 2024
Tech companies in 2024: congratulations on…
There's a beautiful thing happening in your comments where she called out VC/PE for being mansplainers, and they're now in your replies mansplaining.
— staysaasy (@staysaasy) July 10, 2024
(they have good points but it's still funny)
Software is at an interesting place right now. AI is eating the world (right?). Companies are expected to be more efficient than the previous era. 2025 is supposed to be a big year for M&A.
Through all of this, we find ourselves at Stay SaaSy headquarters with more conviction than ever that good management is critical. The times are as dynamic as they’ve ever been, and good management is decisive, sure-footed, reactive without being over-reactive, stable without being in stasis. The winners of this phase of software will be a small group of extremely performant and lucky mega-companies (the next centicorns), followed by a very sturdy cohort of extremely well managed companies.
So we wish you a Happy New Year and a great start to 2025. Please keep reading and please keep writing us. Tell us what you want to read about, tell us what we got right, tell us what we got wrong. Stay SaaSy friends!
2024-12-17 20:59:22
Figuring out what to do is a big part of senior tech roles. Senior Engineers and Engineering Managers often struggle to define technical roadmaps. Reasons include:
Oftentimes, good technical vision can feel like it has to be some gift from the heavens or a skill you’re born with. In reality, good technical vision is often a very simple and boring review of small amounts of data.
An easy playbook for technical roadmap development is Problem Driven Development. In short, it means you develop your technical roadmap based on fixing things that are going wrong. It sounds simple, but it can be very empowering.
The classic first-attempt by EMs/Senior Engineers at roadmap development is to ask people what they think the team should do. This usually ends in sadness, because:
You get a list like:
The implicit “we should do this because it solves X problem” gets lost. Three sprints later people start debating the solution in abstract without ever remembering why they were doing it in the first place.
The main fault with this approach is that it does not capture and solve the biggest problems.
When you prioritize solutions, your job is done once everyone agrees to do your idea. You can prioritize solutions for years and execute effectively without fixing your problems.
When you prioritize problems, you prioritize fixing the issues you actually have. You cannot prioritize problems for years and execute effectively and not solve your problems.
The a-ha moment is this: everything you’re doing should be solving a problem. Align your team on the biggest problems you have. Derive your technical roadmap based on solving those problems. Periodically revisit your problems list to make sure it is still accurate.
OK, if you’re going to solve problems, you must figure out where they live. Most software teams have problems that live in the following places:
These failure repositories are auditable and you can directly build prioritized list of problems based off of them. When building a technical roadmap, you might end up with something like:
From here, you can figure out solutions you think solve these problems. It sounds very simple, but it’s a powerful way of figuring out what to do.
Tech debt prioritization is notoriously fraught and challenging in industry. One major contributor to this is that engineers are pretty bad at saying why tech debt is important. Another contributor is that PMs often require PM-level prioritization research to prioritize against product work, which is unfair. Teams then get in fights and land on %-based tech debt allotments to not have to deal with each other.
In any case, engineers ought to be better at doing reasonable due diligence on tech debt reasoning, e.g.:
Pretty quickly you can get to tech debt principles about wasted time, fail rates, and change frequency of issues if you frame things as solving problems and believe it can be done.
Regular-sized tech debt should just be addressed as people code other work in that area of the codebase. But if you’re asking a team to take the time to scope and prioritize work, you should have at least a miniscule amount of data to back up your claim. I’ve often found myself high conviction on a piece of tech debt until I actually researched the value in this way.
Problem Driven Development is a theory so simple it sounds obvious. But I’ve seen many Engineers and Engineering Managers struggle to figure out what to do. And I’ve seen even more not have a framework to say no to a Senior Engineer who loves a solution that doesn’t solve a problem.
Some next steps:
Problem Driven Development is basically just ersatz product management. One irony, however, is that PMs can do Problem Driven Development to a fault. Customer’s problems are often much harder to get information about and take a very long time to gather. At the same time, your competitors might all have one feature that is clearly valuable that you don’t have. In that case, you shouldn’t be spending a bunch of time researching the problem just to get to the solution your competitors all have. More on this in a future post. Stay SaaSy everyone!
