Developing domain expertise: get your hands dirty.

Recently, I’ve been thinking about developing domain expertise, and wanted to collect my thoughts here. Although I covered some parts of this in Your first 90 days as CTO (understanding product analytics, shadowing customer support, talking to customers, and talking with your internal experts), I missed the most important dimension of effective learning: getting your hands dirty.

At Carta, I’m increasingly spending time focused on our fund financials business, which requires a deep understanding of accounting. I did not join Carta with a deep understanding of accounting. Initially, I hoped that I would learn enough accounting through customer escalations, project review, and so on, but recently decided I also needed to work through Financial Accounting, 11th Edition by Weygandt, Kimmel, and Kieso.

The tools for building domain expertise vary quite a bit across companies, and I found the same tools ranged from excellent to effectively useless when applied across Stripe (an increasingly expansive platform for manipulating money online), SocialCode (a Facebook advertising optimization company), and Carta (a platform for fund administration and a platform for cap table management). Here are some notes about approaches taken at specific companies, followed by some generalized recommendations.

Uber

Uber likely had the simplest and most effective strategy of any product I’ve worked on: each employee got several hundred dollars of Uber credits every month to use the product. This, combined with the fact that almost all early hires lived in markets that had an active Uber marketplace going, meant that our employees intimately experienced the challenges.

This was particularly impactful for folks who traveled to other cities or countries and experienced using Uber there. Often the experience was pretty inconsistent across cities, and experiencing that inconsistency directly was extremely valuable.

Carta

Returning to my starting paragraph on Carta, Carta operates in a series of deep, complex domains: equity management is a complex legal domain, and fund administration is a complex accounting domain. Ramping in either, let alone both, is difficult.

Carta has an unlimited individual book budget, and they pay for the Certified Equity Professional (CEP) test. These are good educational benefits, but are more a platform that you can build on than the actual learning itself. Teams working on products tend to develop deep domain expertise by building in that domain, but that approach is difficult to apply as an executive as I’m typically simultaneously engaging with so many different products and problems.

In addition to the standard foundation of domain learning (talking to customers, digging into product and business analytics, etc), I’ve found three mechanisms particularly helpful: our executive sponsor program, reading textbooks, and initiative-specific deep dives.

For our executive sponsor program, we have a C-level executive assigned to key customers, who are involved in every escalation, periodic check-ins and advocating for those customers in our roadmap planning. By design, being a sponsor is painful when things don’t go well, and that is a very pure, effective learning mechanism: figure out the customer’s problem, and then track resolving it through the company. Some days I don’t enjoy being a sponsor, but it’s the most effective learning mechanism I’ve found for our exceptionally deep domains, and I’m grateful we rolled the program out.

Second, I’ve found book learning very effective at creating a foundation to dig into product and technical considerations in the accounting domain. For example, soon after joining I found a short refresher on accounting, reading Accounting Made Simple by Mike Piper in a couple of hours. Later, I worked through the Partnership Accounting course on Udemy, and now I’m working through two textbooks, Financial Accounting, 11th Edition and Understanding Partnership Accounting.

Finally, initiative-specific deep dives have been a good opportunity to work directly with a team on a narrow problem until we solved a complex problem together. This taught me a lot about the domain, the individuals, and hopefully provided them with a better sense and relationship with me as an executive sponsoring a project they also cared about. My first big project was working with our payments infrastructure team to support automated money movement in our fund administration product, and I learned so much from the team on that project. I also know there’s no chance I’d understand the complexities at the intersection of money movement and fund administration so well if I hadn’t gotten to work with them on that project.

Stripe

At the time I joined Stripe, all new employees were encouraged to read Payment Systems in the US. More ambitious folks usually built a straightforward Stripe store of some sort: David Singleton created a site to sell journals, and Michelle Bu maintained a store that sold t-shirts with the seconds since epoch printed on them. Building a store was a great educational experience, but maintaining the store live was significantly more valuable in understanding the friction that bothered our users. Things like forced upgrades or late tax forms are abstract when imposed on others, and illuminating when you experience them directly.

As Stripe got increasingly broad and complex, it became increasingly difficult for anyone to maintain a deep understanding of the entire stack. To combat that trend, executives relied more on mechanisms like project-driven learning on high-priority projects, and executive sponsors for key customers. They certainly also relied on standard mechanisms like talking to customers frequently, frequently reviewing product data, and so on.

Intercom

I met Brian Scanlan some years back, who told me that executives at Intercom would start each offsite by doing a quick integration of their product into a new website. The goal wasn’t to do a novel integration, but to stay close to the integration experience of their typical user. I still find this a fairly profound idea, and I tried a variation of this idea at Carta’s most recent executive offsite, making every executive start the offsite by performing a handful of fund administration tasks on a demo fund’s data.

Felt

Chatting with one of the founders at Felt, Can Duruk, about this topic, he mentioned that they maintain an introduction to Geographic Information Systems for both employees and users to understand the domain. They also hired an in-house cartographer who helps educate the team on the details of map making.

Recommendations

The recommendations I would make are embedded in the specific stories above, but I’ll compact them into a list as well for easier reference. Some particularly useful mechanism for senior leaders to develop domain expertise are:

• Reviewing product analytics on a recurring basis. Your goal is to build an intuition around how the data should move, and then refine that intuition against how the data moves in reality.
• Shadow customer support to see customer issues and how those issues are resolved.
• Assign named executive sponsors for key customers. Those sponsors should meet with those customers periodically, be a direct escalation point for those customers, be aware of issues impacting those customers, and be an advocate for those customers’ success.
• Directly use or integrate with the product. Find ways that closely mirror an important customer cohort rather than only performing the most common actions. For example, if you only used Uber in San Francisco in 2014, you had a radically misguided intuition about how well Uber worked.
• Make an executive offsite ritual around using the product. Follow Intercom’s approach to routinely integrate the core parts of your product from scratch, experiencing the challenges of your new users over and over to ensure they don’t degrade.
• Use executive initiatives as an opportunity to dig deep into particular areas of the business. Over the past year, the areas at Carta that I’ve learned the best are the ones where I embedded myself temporarily into a team dealing with a critical problem and kept with them until the problem was resolved.
• Use a textbook or course driven approach to understand the underlying domain that you’re working in. This applies from Uber’s marketplace management to Carta’s accounting.

The details of ramping up on a specific domain will always vary a bit, but hopefully something in there gives you a useful starting point for digging into yours. So often executives take a view that the constraints are a problem for their teams, but I think great executive leadership only exists when individuals can combine the abstract mist of grand strategy with the refined nuance of how things truly work. If this stuff seems like the wrong use of your time, that’s something interesting to reflect on.