Doing things that don’t scale as a leader

A question from this week that got me thinking.

I was talking to another leader earlier this week and they asked me an interesting question:

Is there anything that you intentionally keep doing yourself even if it doesn’t scale?

My first reaction was, I would love to hear your answer (and lots of other people’s answers). So I’m sharing this in the hopes that I’ll learn from your responses too.

As to whether I intentionally do things that don’t scale: yes. Over the course of Coda’s history, there have actually been a few examples of this:

Customer support

For first few years of Coda, every person in the company rotated into the support queue for a day at a time. That included engineers, designers, executives – everyone. Eventually, it added too much complexity to scheduling and forecasting product timelines when engineers, designers and PMs would rotate onto support and pause their work for a day. But I think it was incredibly valuable during those years and I’d do it again in an instant.

Our team gained so much empathy for customers when we knew them by name and felt personally responsible for resolving the issue. Nowadays, we’re fortunate to have an incredible Support Team that is regularly cited by customers as a reason they love the company. And we also have multiple rituals to connect our product teams directly to customers. But as we were finding fit in the market, being in the queue was immensely valuable.

Reading pull requests

This seems a little crazy as I write it, but for the first few years at Coda, I read every pull request from engineers. I had an email label and a filter and usually 2-3 times per day, I’d go read every pull request from Github coming through.

As our engineering team grew beyond 20+ engineers that ritual couldn’t scale, but it was insanely helpful when designing the product and working closely on some of the core capabilities that make up the product today. It often helped me have faster conversations with engineers because I knew the context in advance of our discussion. For example, feedback from other engineers in code reviews, or technical constraints that we needed to sidestep.

Product copy

One thing that doesn't scale as the product’s surface area grows, and that can sometimes feel surprising to teams I work with is copywriting. I’m a big believer that product copy in the product IS an essential part of the design. So sometimes it surprises people how strongly I might feel about the words we use in descriptions or help text. But it’s critical to how customers perceive the product and so I pay close attention to Slack channels and Coda docs where this work is happening.

Finally, not exactly things that don’t scale but perhaps closely related, I subscribe to Amazon’s leadership principle of ‘Leaders dive deep.’ There are so many benefits to staying close to what’s shipping to customers, and having enough context to quickly help a team think about a problem differently or help unblock an effort. Here’s how it’s described on their website:

Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdote differ. No task is beneath them.

So that leads to my question and attempt to learn from you. What do you intentionally keep doing yourself that doesn’t scale? What are the ways that you dive deep? Reply to this email or post a comment, and I’ll share a few of my favorites in an upcoming newsletter.

---

👋 This little newsletter experiment is just getting started. So if you enjoyed this post, I’d love it if you subscribed and shared with a friend. Have a wonderful day! ✌️

---