Team Charters are a trap. @ Irrational Exuberance

Hi folks,

This is the weekly digest for my blog, Irrational Exuberance. Reach out with thoughts on Twitter at @lethain, or reply to this email.

Posts from this week:

- Team Charters are a trap.
- A bit late, but I did leave Calm.
- Benchmarking.
- Getting lucky isn't a plan.

Team Charters are a trap.

I’m cleaning out old lingering drafts. This one’s on why I dislike Team Charters.

Recently an email came in asking about writing team charters. I’ve worked at a number of companies that asked teams to write charters, and I think it’s an interesting project. That said, it’s not a project I’d generally prioritize. If you pushed me on this topic, I’d probably suggest you write an engineering strategy document from the perspective of your team. A few thoughts on what team charters try to solve, and then why I think they’re generally not very useful.

What team charters try to solve:

• Building team alignment around their mission
• Building team alignment around their approach to accomplishing that mission
• Helping folks on other teams to understand your team’s mission

These are all valuable problems to solve, but I find charters pretty ineffective:

• Teams want to involve their members in writing their team charters, turning them into a bottoms up initiative
• Team members generally write charters based on solving the bottoms-up initiative they’ve identified, rather than accurately reflecting their organization and leadership’s view of what the team needs to do. Said differently, teams often select the mission they want rather than the mission they have
• For example, teams doing a lot of maintenance work will often omit that work from their charter, even though their leadership and organization expect them to do it. Then team members might say that leadership isn’t respecting their charter, and get upset
• If you approach this from a top-down perspective, you get the right content, but generally wouldn’t call it a team charter and it would skip the consensus-building aspect where charters generally go wrong

The reality is that teams must work within the scope that their leadership wants, and exercises that encourage them to forget that are harmful to the team rather than empowering. Empowering bottoms up mission-setting in an organization that practices top-down resource allocation is a trap.

A bit late, but I did leave Calm.

I meant to post this when I left Calm earlier this year, as a ending note to my post on joining Calm, but instead I got focused on joining Carta and writing An Engineering Executive’s Primer. I’m cleaning out some of my old drafts, and posting this as an artifact of that moment. Although I ended up starting a role sooner than expected–it was the right opportunity to accept–I did get to spend more time with my kid, finish my next book, and get my running distance back up, so I’ll call it a successful sabbatical even if it was a compacted one.

tl;dr – today’s my last day at Calm. It’s been a truly remarkable three-and-a-bit years. I’ve learned so much and I’m grateful to the founders, my peers and the team I’ve been privileged to work with. Next up, I’m taking a sabbatical to work on a few projects, and I’ll start thinking about my next role in June or July.

Sometimes I find myself writing something, and trapped in that thing’s narrative structure. At this moment, tapping on this keyboard, I find myself trapped in the “I left my job, but I’m really, really proud of the folks I worked with” retrospective. Because, well, I today is my last day at Calm, and I am really, really proud of the folks I worked with over the past three-and-a-bit years. So anyway, I’m just going to embrace the narrative structure here and see where it takes me.

I joined Calm in January, 2020. A few weeks before, I’d pulled together Your first 90 days as CTO based on my notes, but I had no idea what was really coming my way. Two months later, the pandemic hit, followed a few months later by our first child. Did things slow down then? Certainly not.

Calm had an extraordinarily good 2020, we launched our B2B business, kicked off landmark partnerships with Kaiser Permanente and American Express, a viral sleep story from Harry Styles, and enough subscriber growth to briefly threaten site stability. The next year was good, too. We embraced machine learning to allow us to grow our content catalog without making users feel like we’d grown it (with the best meditation or sleep story for each person, always right where they expect it), which allowed us to significantly accelerate how our content team launched new content. As one must anticipate from this kind of post, I’m going to say that last year was also good, but it’s true: it was good! We acquired Ripple Health Group to support an expansion into healthcare, scaled our B2B business significantly, and remained the #1 DTC mindfulness app on the AppStore.

There’s so much other stuff I don’t even know how to fit it into the “I left but I’m proud” narrative! We successfully executed an incremental migration to TypeScript, and a whole sail migration to AWS Aurora, while speeding up product velocity rather than slowing it down. Calm got a new CEO, who’s fantastic. I weathered some medical challenges and managed to come out the other side whole. Staff Engineer was released! Even now, I’m leaving out a bunch.

I’ve also learned a tremendous amount! It was a chance to get back into Product engineering after my six year detour into Infrastructure, and a return to working on a consumer-facing product with millions of deeply passionate, highly engaged users. It was also my first chance to be the functional engineering leader at a scaled company, which was quite different than being the functional engineering leader during Digg’s last year.

Most importantly, I am deeply grateful to the people I’ve gotten to work with: David Ko, Alex Tew, Michael Acton Smith, Alex Will, Dun Wang, Mads Johnsen, Anastasios, Anne, Scott, Mike, Brenda, Ellen, the many Chrisses, Nate, Maya, Melissa, Andrew, and many, many others. This was a great group, and I’m excited to work with y’all again soon.

My decision to leave Calm is the happy confluence of a few different events. First, our acquisition of Rally Health Group brought on an experienced engineering leader who was more than able to take on my responsibilities leading engineering and data science at Calm. Second, our son is almost three years old, and spending time with him is uniquely wonderful right now, and that’s not something I want to take for granted. I’m excited to have some focus time with our son and with myself before sticking my head back up in a few months to decide what to do next.

In addition to family time, I have a few projects I’ll be focused on over the next few months:

• Writing my next book. I don’t have any specific details to share quite yet, but if you look at my most recent posts you’ll get a sense of what the subject matter is about. It should be available digitally by the end of the year, and in print early-ish next year
• I have a couple of software projects that I’m excited to spend some time on. Nothing too sophisticated, just enjoying the motions of personally building something from scratch
• Doing more running. Building from 3-4 mile maintenance runs back up to a weekly ~10 mile run, and also getting in a weekly speed session

My current plan is to take on another engineering leadership role after my sabbatical, and I hope to start chatting with folks about opportunities in June.

Benchmarking.

Many of the most important questions for running an organization don’t have clear answers. In most engineering organizations, both the teams working on infrastructure and the teams working on product feel they are undersized. It’s also true that most individuals feel they are undercompensated. In the boom times, there is often enough investor money laying around to say yes to all these questions, but many leaders are acutely learning the long-term costs of expanding our budget too far.

While there is no perfect way to answer these questions, the best way to answer them is benchmarks. By collecting a reasonable set of data points, you can understand where similar companies operate, and ensure that you either operate in a similar location or have a clear rationale for choosing a different spot.

Here are some concrete benchmarking examples from my work over the past couple months:

• To better understand how companies size their engineering team, we evaluated how we benchmarked against other companies R&D costs as a percentage of revenue over the past 12 months. If your company is similar in size to public technology companies like Gitlab or Datadog, then you can gather this data from their quarterly profit & loss statements. If you’re smaller, you can ask your investors for their datasets, which they will almost always be glad to provide because it will help you run a more efficient business.
• Adi Noda of DX has an upcoming blog post that explores the size of platform engineering teams at different companies. This sort of data, which you can collect by asking your network, is extremely helpful to understand whether your platform investment is typical or whether you should have a more nuanced defense given it’s abnormally high
• On the most structured side of things, compensation bands are aggregated by a number of companies (including my employer’s offering, Carta Total Compensation)

It’s easy to lean too heavily on benchmarks by believing that they answer questions: they don’t really do that. Benchmarks only ask questions, they never answer them. It’s up to whoever is using the benchmarks to extract the questions and do your own work to answer them. If you look at “R&D costs as a percentage of revenue” across companies, you’ll notice that some are four or five times higher than others. Are the high spenders early in making a calculated bet into releasing a new service, or are they just inefficient? Either, or both, could be true, and that’s the sort of interesting question-answer pair to work through when using benchmarks to evaluate.

Finally, it’s also worth noting that sometimes people don’t want data, and that’s a different problem. I previously worked at a company that wanted to improve their cost structure, and I worked with another executive to bring in benchmarks on the appropriate size of spend for each function, with the goal that we’d all set per-function targets to move towards. In that case, there was an active disinterest in looking at that data, and instead the wider team wanted to make individual pitches to the CEO about increasing their functions’ budget.

Getting lucky isn't a plan.

One piece of flippant commentary that you’ll hear occasionally is that it’s “Better to be lucky than to be good.” On an individual level, it’s almost certainly true that being very lucky outperforms being quite good: I certainly know a number of folks who are financially successful after working at companies that succeeded, but where their direct impact was relatively small. Companies get lucky, too. This is true both in the sense that the door to acquisitions was much more attractive last decade than it is today, and also in the sense of Ben Horowitz’s quote from The Hard Thing About Hard Things, “Wartime CEO knows that sometimes you gotta roll a hard six.”

I was thinking about luck and strategy recently while talking to a friend whose company’s strategy is best described as finding an irrational buyer before running out of money. I was _also _thinking about luck when dealing with a dilemma involving several disagreeing, frustrated individuals with relatively poor resolutions: maybe, I joked, we could just get lucky.

There’s nothing wrong with getting lucky; rather there’s quite a lot right about getting lucky. I don’t know any individual or company whose financial success is not to some extent the result of getting lucky. The important bit is that getting lucky isn’t a strategy, it’s an unreliable, probabilistic bailout. It’s good to get lucky, but you still need an actual plan that doesn’t rely on luck.

Even if a situation is grim, there’s always an option that puts you, or your company, in a better position:

• At Digg’s end, we were running out of money and user engagement was dropping. We made a major swing towards Facebook-driven virality through publishing events to the news feed. This didn’t work that well for us, in the end, but it did open up a series of new discussions that culminated in our acquisition
• Operating within China and Russia was extremely challenging for Uber given local competition, but by going in briefly we were able to cause enough disruption to those marketplaces to capture significant equity stakes in local competitors as compensation for leaving the markets
• As Yahoo’s search share shrank, we were able to do enough innovation in search to drive a compelling search acquisition from Microsoft rather than dwindling without commensurate compensation

If you can’t think of any option that advances the cause, consider whether you and your job have already gone separate ways without either of you realizing it. Getting lucky is always a bad strategy, even if you see successful people around you relying on it.

That's all for now! Hope to hear your thoughts on Twitter at @lethain!

This email was sent to you why did I get this?    unsubscribe from this list    update subscription preferences Will Larson · 77 Geary St · co Calm 3rd Floor · San Francisco, CA 94108-5723 · USA