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! ✌️
I continue to attend every live design critique, but realistically I won't be able to continue doing that after this year. First, it's something I enjoy. It's a privilege to be able to watch designers apply their craft, their creativity, and talk things out. Sometimes it leads to deep - yet productive - debates about how we can better serve customers in ways that work for the business. Second, my presence provides designers with valuable context on the business, customers, and internal stakeholders, enhancing their ability to create robust solutions and develop systems thinking skills. In my opinion, systems thinking is one of those core craft skills that differentiates great product designers from exceptional ones. Third, it's a mechanism to help the team make sure the framing of any given product problem is as crisp as possible. If a problem is not crisp, the corresponding solution will be half cooked, which means we won't attain the desired outcomes. Aside from driving outcomes, it has the benefit of helping designers develop their product thinking skills. The more of team members have great product sense - not just PMs - the more chances we have to meet the needs of our customers, drive innovation/differentiation, and achieve company objectives.
I'd like to understand how you ensure that product copy is impactful and consistent across the user experience (e.g., app, emails, etc.). We currently do that by having Marketing and Design partner together, but it's not that great. We don't achieve consistency and as far as impact is concerned, I feel Marketing and Design have misaligned incentives. More often than not, the copy sounds like we're trying to sell something to users as opposed to using content to support their experience. My tentative solution is to hire someone who would lead UX Content Strategy in collaboration with the Design System team, but I'm always cautious deferring to hiring to solve a problem...Thanks!
I'm going to be that guy, but isn't copyrighting = copywriting? 😅