Notes on Operating Well
June 27, 2022 • #Sam Gerstenzang wrote an excellent piece a couple weeks ago with operating lessons for growing companies, driven by his learnings from the product team at Stripe. Personally, Iâve got a decade or so of experience as an âoperatorâ at a âstartupâ (two words I wouldnât have used to describe my job during most of that time). Since 2011 Iâve led the product team at Fulcrum, a very small team until the last few years, and still only in the medium size range. So my learnings on what âgood operatingâ looks like are based mostly on this type of experience, not necessarily how to lead a massive product team at a 10,000 person company. I think a surprising number of the desirable characteristics translate well, though. Many more than BigCo operator types would have you believe.
Overall this list that Sam put together is especially great for teams that are small, early, experimental, or trying to move fast building and validating products. There are a few tips in here that are pretty contrarian (unfortunately so, since they shouldnât be contrarian at all) to most of what youâll read in the literature on lean, agile, startuppy teams. But I like that many of these still apply to a company like Stripe thatâs in the few-thousands headcount range now. There isnât that stark a difference in desirable characteristics between small and large teams â or at least there doesnât need to be.
On the desire to enforce consistency:
Consistency is hard to argue against â consistency reinforces brand and creates better ease of use â but the costs are massive. Consistency just feels good to our system centric product/engineering/design brains. But it creates a huge coordination cost and prohibits local experimentation â everything has to be run against a single standard that multiplies in communication complexity as the organization gets larger. Iâd try to ask âif we aim for consistency here, what are the costs, and is it worth it?â I think a more successful way to launch new products is to ignore consistency, and add it back in later once the project is successful. It will be painful, but less painful than risking success.
Iâd put this in the same category as feeling need to âset yourself up to scaleâ. When a team lead is arguing to do something in a particular way that conforms with a specific process or procedure you want to reinforce through the company, itâs an easy thing to argue for. But too often it ignores the trade-offs in coordination overhead itâll take to achieve. Then the value of the consistency ends up suspect anyway. In my experience, coordination cost is a brutal destroyer of momentum in growing companies. Yes, some amount of it is absolutely necessary to keep the ship floating, but you have to avoid saddling yourself with coordination burdens you donât need (and wonât benefit from anyway). Apple or Airbnb might feel the need to tightly coordinate consistency, but you arenât them. Donât encumber yourself with their problems when you donât have to.
Enforcement of consistency â whether in in design, org charts, processes, output â has a cost, sometimes a high cost. So itâs not always worth the trade-off you have to make in speed or shots-on-goal. With a growing company, the number of times you can iterate and close feedback loops is the coin of the realm. Certain things may be so important to the culture youâre building that the trade-off is worth it, but be judicious about this if you want to maintain velocity.
On focus:
People think focus is about the thing youâre focused on. But itâs actually about putting aside the big shiny, exciting things you could be working on. The foundation of focus is being clear upfront about what mattersâbut the hard work is saying no along the way to the things that feel like they might matter.
True focus is one of the hardest parts once your team gets some traction, success, and revenue. Itâs actually easier in the earlier days when the sense of desperation is more palpable (I used to say we were pretty focused early on because it was the only way to get anything made at all). But once thereâs some money coming in, users using your product, and customers are growing, you have time and resources you didnât have before that you can choose to allocate as you wish. But the thing is, the challenge ahead is still enormous, and the things youâve yet to build are going to get even more intricate, complex, and expensive.
Itâs simple to pay lip service to staying focused, and to write OKRs for specific things. But somehow little things start to creep in. Things that seem urgent pop up, especially dangerous if theyâre âquick winsâ. You only have to let a few good-but-not-that-important ideas float around and create feel-good brainstorming sessions, and before you know it, youâve burned days on stuff that isnât the most important thing. Thereâs power in taking an ax to your backlog or your kanban board of ideas explicitly. Delete all the stuff you arenât gonna do, or at least ship it off to Storage B and get to work.
On product-market fit and small teams:
Start with a small team, especially when navigating product market fit. Larger teams create communication overhead. But more importantly they force definition = you have to divide up the work and make it clear who is responsible for what. Youâre writing out project plans and architecture diagrams before you even should know what youâre building. So start small and keep it loose until you have increased clarity and are bursting at the seams with work.
To restate what I said above, itâs all about feedback loops. How many at-bats can you get? How many experiments can you run? Seeking product-market fit is a messy, failure-ridden process that requires a ton of persistence to navigate. But speed is one of your best friends when it comes to maintaining the determination to unlock the job to be done and find just enough product fit that you get the signals needed to inform the next step. Therefore, small, surgical teams are more likely to successfully run this gauntlet than big ones. All of the coordination cost on top of a big, cross-functional group will drain the team, and greatly reduce the number of plate appearances you get. If you have fewer points of feedback from your user, by definition youâll be less likely to take a smart second or third step.
The responsibility point is also a sharp one â big teams diffuse the responsibility so thinly that team members feel no ownership over the outcomes. And it might be my cynicism poking through, but on occasion advocates for teams to be bigger, broader, and more cross-functional are really on the hunt for a crutch to avoid ownership. As the aphorism goes, âa dog with two owners dies of hunger.â Small teams have stronger bonds to the problem and greater commitment to finding solutions.
Overall, I think his most important takeaway is the value of trust systems:
Build trust systems. The other way is to create systems that create trust and distributed ownership â generally organized under some sort of âbusiness leadâ that multiple functions report to. Itâs easier to scale. Youâll move much more quickly. A higher level of ownership will create better job satisfaction. But you wonât have a consistent level of quality by function, and youâll need to hire larger numbers of good people.
A company is nothing but a network of relationships between people on a mission to create something. If those connections between people arenât founded in trust and a shared understanding of goals and objectives, the cost of coordination and control skyrockets. Teams low in trust require enormous investment in coordination â endless status update meetings, check-ins, reviews, et al1. If you can create strong trust-centric operating principles, you can move so much faster than your competition that itâs like having a superpower. The larger teams grow, of course, the more discipline is required to reinforce foundations of trust, but also the more important those systems become. A large low-trust team is incredibly slower than a small one. Coordination costs compound exponentially.
-
Donât take this to mean Iâm anti-meeting! Iâve very pro-meeting. The problem is that ineffective ones are pervasive. ↩
