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:
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!
2024-12-11 20:59:22
These are the heuristics that I use for professional networking. I think I’m a pretty good networker, but not any sort of natural networking savant – I’ve just been able to find good results by following a few easy habits.
Networking is kind of like working out: It’s easy to get started and a relatively small amount of effort gives you significant benefits. If you follow some incredibly basic rules and aren’t lazy, you can build a great network with ease.
Networking is probabilistic. Most of the people that you meet are not going to wind up being long-term connections that matter in your life. This is fine and normal, and as a result:
By far – by far – the most important way to build your network is to positively interact with your coworkers. People that you work with are the most accessible and high-quality network that you can build. They are right there. You have a shared experience, a similar industry focus, and are often of a similar age and life situation. The #1 missed opportunity in networking is failing to take the achingly simple steps to build a network from people you work with every day.
How do you do this? At a bare minimum: Literally just be competent, be a good teammate, and don’t be actively antisocial. Say hi to people in person. Be friendly in meetings; have a brief Slack conversation if it makes sense in context (don’t be annoying, of course). Remember names. Eat lunch with other people. You barely even need to talk at lunch – just be pleasant. If you do these things and are a good, reliable teammate, it is almost impossible to not build a network.
When you talk with your coworkers, be positive. Many people find it tempting to use shared grievances to build relationships, which can work well in the short run but sets you on the wrong course. If you try to manufacture rapport by complaining about your boss or the sales team or your CEO, all that you’ll construct is a network of complainers. Winners are inspired by ambition and shared victories, and complaining is pretty much the polar opposite.
For the more advanced level of building a workplace network, actively identify people whom you’d want to work with in the future. The reason that coworker networks are so valuable is that judging compatibility is incredibly difficult outside of work and incredibly easy at work. Whether as a peer, boss, cofounder, or subordinate – doesn’t matter. Do not waste this information asymmetry.
It’s also valuable to expand strong relationships outside of work, even if it’s very simple (we’re coffee buddies, or we get a beer every few months). You want to broaden the context of your relationship beyond your job, because your network will ideally outlast the context of your current team.
Beyond your coworkers, the next rule is simply to get out there and meet people occasionally, in ways that work for you. For myself: I like nice dinners, I like expensive cocktails, I like talking to people, and I don’t like approaching people speed-dating-style. That means that I prioritize dinners for senior Product leaders – and I will not go to a meetup, conference, hosted talk, or virtual event unless I’m forced or paid to attend. I also like chilling with my family, and won’t travel to an offsite unless I really like the group.
When you’re at these events, just be yourself and never brag. You’re going to get asked where you work; my quick tip is to have a very brief description of your background that hits the highlights concisely. Mine is about 12 words, and I’ll only elaborate if prompted. Keeping it brief is essential because nobody likes a person who only wants to talk about themselves.
This is a well documented “trick,” but whenever someone comes to mind, you should reach out and say hi. It can be for anything:
People do love being thought of… but more importantly, life is made up of all of the tiny events that happen in between the big ones. Take advantage – bring people along for the ride of the micro-moments that are happening in your life, and it will help to keep your relationships alive.
Staying connected in these tiny moments is great, but if you want to maintain a deeper relationship with someone, you must meet in person at least semi-regularly:
Past 3 years of your last in-person meeting, assume that your friendship is going to erode.
We are social primates, and in my experience humans do not fully trust people they haven’t seen and ideally physically contacted. Vista Equity Partners, one of the most successful PE firms in tech, literally enshrines this with their culture of giving hugs. Vista are not preschool teachers; they are not sensitive artists; they are not running a sentimental business. They are apex predators of the capitalist wilderness. But even they realize that in order to build trust people rely upon close contact, and giving someone a hug is a good way to get there.
You need to meet in person to build a network. For a tiny example of this: my Stay SaaSy co-author and I don’t actually find ourselves in the same office very often anymore, but I always prioritize speaking with them for at least a few minutes face-to-face when I can.
Swapping some amount of personal information is an important part of building a connection. There are a few reasons that this works.
The first is that it just feels nice if someone remembers a few personal details about you. This is true even if you suspect that someone is only remembering personal details for relationship-building purposes, because 99% of the time people will treat you like an NPC even if it’s not in their best interests. I suspect that the guy who makes my bagel only remembers my name so that I keep giving him money; he’s a smart guy and probably likes recurring revenue. But at every other shop I go to weekly they act like I’m a goddamn stranger, so I still like Javier more.
The second reason this works is that people like you more if they know personal details about you. It’s just natural: You know the most about your close friends and family. You also (largely) like your close friends and family the most. People perceive a strong association with knowing others’ personal details and liking them.
If you stand far away and squint, networking is kind of like dating: Two people talk and decide if they want to spend more time together. As a result, networking and dating share the same patterns for when they get weird. Don’t fall into these patterns:
It is shocking to me how often people violate these basic rules and inadvertently act like creeps.
Many jobs kind of suck – that’s why they pay you to be there. They suck because they don’t pay enough; they suck because they don’t provide enough opportunity; they suck because you don’t like your coworkers. Networking is a solution to all of these problems: If you network effectively, you’ll work with people you like, at more successful companies, which can pay you more.
There’s not a whole lot more to ask for than that. Over a third of your waking life is spent at work – that’s too much to spend with people you don’t like or respect. So get out there, and follow these incredibly basic steps to build a better network.