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

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.

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!

Networking For People Who Don’t Network

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.

How to Meet People

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:

  • There’s no pressure to build a super strong connection with any given person. It’s completely fine if you don’t like everyone, or if someone doesn’t like you. This is the normal state of the world, but some people feel like they need to “work the room” or hit some sorts of arbitrary networking goals. In my experience great networkers never act like this.
  • You really do need to put yourself out there and meet a lot of people if you want to expand your network. It’s bit of a numbers game.

Your Coworkers

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.

Out In the World

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.

Nurturing Your Network

Reach Out When You Think of People

This is a well documented “trick,” but whenever someone comes to mind, you should reach out and say hi. It can be for anything:

  • “We just refactored that code you wrote 3 years ago on the scheduling service – forgot how clean your design was, hope you’re doing well at Meta!”
  • “Did you see that Jimmy [our shared peer] is running his own startup now? Some crazy AI thing.”
  • “Yo, I was watching this snowboarding video where some dude falls off the lift, it reminds me of when you fell off the lift on Spring Break.”

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.

Meet In-Person Semi-Regularly

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:

  • At least once a year for casual acquaintances (“we met at a conference”)
  • At least every 2 years for close acquaintances (“we worked together for two years”)
  • At least every 3 years for very close friendships that involve a foundational bonding experience (“we were college roommates and spent every weekend together for years afterwards; we worked at a startup together for 5 years”)

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.

How to Engage

Trade Personal Details

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.

Don’t Act Weird

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:

  • Don’t ask someone to be your mentor (this is like asking someone to be your boyfriend/girlfriend on the second date; either let it happen naturally or get deeper into the relationship before you broach the question)
  • Don’t get all weird about paying for stuff (very similar to dating: the default should be that the person who can expense the meeting from their job pays, and if neither or both can, then it’s whoever initiated the conversation)
  • Don’t send strange thank you notes (don’t text anything weird after the date, although a quick non-desperate text is fine)
  • Don’t brag about having met someone (don’t reveal personal details about your dates)

It is shocking to me how often people violate these basic rules and inadvertently act like creeps.

Networking Matters

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.