MoreRSS

site iconStay SaaSyModify

We started this blog to share what we’ve learned on how to scale product and engineering through all stages of startup hypergrowth.
Please copy the RSS to your reader, or quickly subscribe to:

Inoreader Feedly Follow Feedbin Local Reader

Rss preview of Blog of Stay SaaSy

Judge Your Coworkers

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.

A Sad Story

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.

A Different Way

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.

Ground Rules

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.

How To Do It

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:

  • The difference between superhuman performance and expectations (people often glamourize or mythify people just doing a really good job)
  • The ingredients of certain people’s success. Sometimes it’s as simple as highlighting that a strong performer works really hard.
  • The differences in leveling and experience. That person is doing a solid job, but they’re three levels above you and a lot of what they do is quite expected in role.

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:

  • What the role of a person actually is. Many times critical perceptions are driven by a misunderstanding of what someone is actually supposed to do. No, actually, your PM is not your project manager.
  • The differences in leveling and experience. Sometimes people think someone isn’t good at their job, but they forget that they are 4 levels beneath them in the ladder.

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?

Closing Thoughts

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.

Assorted Notes

  • Holding people accountable doesn’t always mean severe punishment. In fact it almost never means severe punishment. At a small scale, it simply means having clarity on who actually owned a thing that didn’t go well. At a large enough scale, it should mean some action is taken, and that action should be referenced in performance reviews. A lot of the industry moved too far into blameless culture in the last decade. A lot of stuff is someone’s fault, and it’s ok to say it.
  • It really is inexcusable for a senior leader to not have a point of view on a peer’s performance. Senior leaders should be knowledgeable enough to evaluate and heavily incentivized to care how their peers are doing. Apathy from a leader about peer performance is smoke that one or both of those is not true of the leader you’re evaluating.
  • One of the biggest opportunities of letting people judge their peers is coaching them when they’re wrong in that assessment because they don’t understand the person’s role. Very few people have intuition about other roles and responsibilities, and almost no companies are going to make explicit time to teach you about them. These conversations can be one of the only places to learn what other people are supposed to be doing.

This Is How You’re Eroding Accountability

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:

  • People display both agency and urgency
  • People follow through on what they say they’re going to do
  • The company reinforces these expectations via positive and negative reinforcement

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.

Not Checking That Things Get Done

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:

  • Know the top 1-3 priorities of every one of your direct reports. Check on them regularly, and do not accept the same excuse twice in a row or any excuse more than 3 times in a row.
  • If you’re a manager of managers, know the top 5-10 overall priorities for your management chain. Have a sense for how they are going, and require that your team keep you up to date on them if they’re off track.
  • If something is off track, follow up fast and get a full understanding of what’s going on.
  • Understand what your top 1-3 priorities are, and if your manager isn’t checking on you regularly (perhaps they didn’t read this post), provide proactive updates.

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.

Strategic Whiplash

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…

Incorrect Incentives

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:

  • Narrow Goals: Teams set goals that are too narrow, and focus on them entirely to exclusion of other things that matter. The classic case of this is a sales team that does anything to close the next deal, even if it means overpromising or undercharging the customer.
  • Overly Broad Goals: Teams set goals that are too broad. Teams end up “owning” metrics that they obviously don’t completely control, and their managers (somewhat reasonably) don’t hold them accountable when those metrics go sideways. For example – maybe you make your Product team solely responsible for Net Dollar Retention (NDR). What happens if your support team underperforms, your engineering team introduces a bevy of bugs, or your sales team closes a slew of bad-fit customers? If you hold the Product team to an NDR outcome regardless, you’re an unfair tyrant; but if you don’t hold them to it, you’ve just degraded 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:

  • Objective Goals: Goals need to be objective – it’s normal to have debates about whether a goal is reasonable, but there should never be debates about what the number actually was.
  • Clear Evaluation: When goals are evaluated, it should be clear whether a team actually hit the goal, and also whether that goal was hittable in the first place.
  • Reasonable Practices: Managers must evaluate whether teams used common sense and didn’t sacrifice some other area of the business to hit their targets; the expectation should be set upfront that compromising other business areas isn’t okay.

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

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:

Overlapping Roles

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:

  • If a project fails or a target is missed, do you know who gets fired?
  • If a project wildly succeeds, do you know who will be rewarded and praised?
  • Do you use any version of the phrase “dotted line reporting?”

Org Charts That Are Too Deep

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:

  • A VP
  • Who manages 3 Senior Directors
  • Who each manage 2-4 Directors
  • Who each manage 3-7 Managers or Senior Managers
  • Who each manage 5-8 Individual Contributor (IC) direct reports

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.

Takeaways and Quick Solutions

Happily, if you have a smart team, all of the issues above can be combated in simple ways:

  • Set up regular check-ins for all of your department’s most important projects. Keep a running, written list of how they’re going.
  • Avoid strategic whiplash. Plans shouldn’t get cancelled without a discussion or written doc, and when you’re at capacity new projects shouldn’t get added unless prior projects are explicitly cancelled or deprioritized.
  • When you see accountability eroding, check on team incentives to see if they’re a cause.
  • Check for broken org charts – every 6-12 months, do a cursory check for overlapping roles or org charts with too much “depth.”

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.

Management Mantras

2025-01-24 20:59:22

Don’t Do Me Any Favors

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:

  • Sometimes someone will say “I’ll help you out here” when really it’s just their job. Them saying they’re helping you out is either an exercise in self-marketing, a power move, or confusion.
  • Sometimes someone will say something like “Alice really did me a favor in onboarding me so well”. But if Alice has to onboard you as a favor, that’s a gap in your team responsibilities that needs to be fixed.
  • Sometimes someone will “help” you out by breaking prioritization rules that exist for a reason.

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.

Employees Don’t Get Charity

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.”

I Can Fix 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:

  • It’s recruiting’s fault for not getting me people.
  • It’s sales’ fault for not selling the product
  • It’s my managers fault for not doing the thing I asked them once

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.”

Management Happens Every Day

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.

Bottleneck Dirty Webs

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 Webs

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.

Examples of Dirty Webs

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.

Be the Bottleneck

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:

  • It’s a morale improver for the most valuable team members because high output doers hate toil disproportionately more
  • It sets the right cultural precedent that toil both can be and should be removed – people often just accept toil, or think that it’s not their place to remove it, and this breaks that pattern

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.

A Call to Action

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.

A Brief Note On Other Teams

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: A SaaSy Year In Review

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.

The Numbers

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.

Top Posts

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:

Top Tweets

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.

Musings

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!

Problem Driven Development

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:

  • There’s little industry training on how to do it
  • It can be daunting to prioritize against professional PMs who are specifically selected and trained to be persuasive
  • Some organizations expect PMs to be responsible for all prioritization in teams, making Engineering roadmap ownership ambiguous

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.

Development Without Problems

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:

  • Without time to think, people give bad answers.
  • People over-index on opinions of people in positions of authority. “The Chief Architect said this was a good idea!” They did, but they said that after a 2 minute chat, not after a deep understanding of the project and your roadmap.
  • People offer solutions, not problems to solve.

You get a list like:

  • Upgrade our library version to the next minor version
  • Refactor the Foo class to be composable
  • Try out the new hot SaaS thing for X

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.

Problem Driven Development

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:

  • Pages
  • SLO violations
  • Wasted time in projects/tasks
  • Wasted time in development (e.g. slow CD)
  • Application alerts
  • Cost
  • Change failures

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:

  • We get too many pages. 80% of them are the WizBang service. We need to drive that to 0.
  • We spend 12% of our time on manual tasks and we think we can reduce that by 50% with a month of work.
  • SLOs have been great, no work needed.

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.

Problem Driven Development: Tech Debt

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.:

  • The class sucks, ok what problems does that cause?
  • The problem is that it’s hard to code in.
  • OK how big of a problem is that?
  • What do you mean?
  • Besides it being gross, how much time are we wasting with it.
  • Well we only change it like once every two years.
  • OK so is that worth spending a month refactoring?
  • No, but this other file has the same issue and we modify it every week and its change fail rate is super high.
  • OK let’s fix that one.

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: Summary

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:

  • If you find yourself in a position of needing to make a technical roadmap - find the problems, figure out the biggest ones, and make a plan to solve them.
  • If you’re a junior engineer wanting to work on your advocacy and vision, look at where your team’s problems live. Don’t stare at one class of code and lament the lack of design patterns. That’s where a single problem lives. Instead, look at the repositories that host the patterns of behavior that justify prioritization.
  • If you’re an EM that wants your team to have more vision, expose and educate them on the problems you’re having. I remember working at a major tech company and I was never remotely close to a holistic view of the problems my team was facing. If you only ever show people tickets, don’t cry when you have a team full of ticket-takers.
  • Whoever you are, always ground your team in the why of what you’re doing. Once you lose sight of the problem, you’ve definitely lost sight of the solution.

Problem Driven Development: Appendix

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!