Learning to model your cofounder

My cofounder Carter and I were friends for a long time (almost 10 years) before founding a company together. During that time, and ever since, we’ve spent countless hours walking and talking about company culture; about management styles; about our grandiose visions for the future and our mundane preferences about code styles. We don’t always have the same exact ideas, but we always understand and respect each other’s views, and spent this time continually uncovering new tools to find a balance between our expectations and preferences.

One might have thought, then, that when we founded a company together, we’d be fully aligned, having already done the hard work of learning about each other in the past.

This…is not entirely how it’s gone.

Let me first be clear about what I’m not saying. I’m not saying that Carter and I get into fights, or even heated debates, nor that one of us keeps having to tell the other that they are just wrong about something. I’m also not saying that I’m unhappy with our current situation, as you’ll hopefully understand in a moment.

What I am saying, though, is that communicating about values is hard, and that there have been some cases where we thought we were agreed, and only were able to discover that there were gaps when forced to apply our values to a real, concrete situation.

Here’s a simple example: Carter and I would both agree with the statement “Modulate is a team, and it’s crucial for everyone to receive recognition.” In particular, we’d agree that we’d prefer this statement to the contrasting “The founders are special and most of the recognition should go to us.”

We’d also agree with the statement “It’s crucial to protect the time of the engineers, since they lose a lot of efficiency if forced to context switch rapidly”, as compared to “just let people know when you need them and they’ll balance things themselves.” (Quick caveat – there are lots of types of engineers, and some are neutral or even positive to context switching! But our current small team largely consists of engineers who find it crucial to spend a few hours at least before they can really start pushing through a problem – especially given the complexity of ML research!)

So, suppose we receive an email asking for an hour of someone’s time during a busy week to speak to a reporter about our work; or we need someone to write a blog post, or attend a conference and speak on Modulate’s behalf. Which should we do?

A. Recommend an engineer who hasn’t been getting enough recognition, this is a great chance to show off the strength of the team!

B. Default to having a non-engineer take it, we need to protect the time of the engineers when it’s already a crunch week!

I suspect many of you are reading this and thinking to yourself something like, “well, obviously it depends on even narrower details.” And indeed, on a case-by-case basis it does. But when evaluating how we’re doing as a team, we’ll need to aggregate. So let me rephrase the question – how do we know if, over a series of 10, or 20, or N moments like the one described above, our culture is actually reflecting our values as founders?

It turns out, when framed with this question, Carter and I have discovered we have different answers. We still value the same things, but with different heuristics and weights – Carter’s answer tends to be something like “assess from the employees’ perspectives whether they feel they’re getting enough recognition, and couple that with some outside evidence about whose names are recognized.” My answer might instead be “First ensure we’ve been hitting our roadmap items on time, then confirm that any time that was in excess to what was needed for that was used fairly to allow the whole team to share their work and expertise.”

Notice that neither of these answers claims the other is wrong, or bad, or even incompatible. But because we have different ways of evaluating these outcomes, it becomes important before we make a decision to not only justify it to ourselves, but also to confirm we can justify it to each other.

The good news is we have a head start – we know the kinds of things which the other finds important, so we at least have few unknown unknowns. That is, we generally can recognize situations where we might not have the same evaluation criteria, and so have the opportunity to ask a question in the first place.

But asking each other to dive deep into these questions each time they arise is costly – we’d ideally like to improve our models of each other to the point that, even if we don’t share the fundamental belief about the right evaluation criteria, we can be aware of our cofounder’s preferences ahead of time and incorporate them automatically.

In “soft” or unwritten form, this looks like us building better mental models of not just what each other value, but how we reason about value tradeoffs.

In “hard” or written form, this looks like a pact around culture which doesn’t perfectly align with either of us, but rather is a pre-organized compromise meant to save us from having to re-evaluate the same circumstances over and over.

We’ve found, at least thus far, that it’s crucial to have both. The written culture document is necessary both to ensure we’ve explicitly codified our agreement – even if we never consult the doc again, the act of writing it forces us to come to this understanding – and also to help communicate our thinking to new team members. But there will always be edge cases, so at least as important as having the document is making sure we’ve outlined the situations where the document isn’t good enough. And in those situations, to actually prioritize having a discussion about it.

How do we know when something’s ready to be added to the culture code? Carter’s found a powerful tactic which not only answers this question, but also helps me to learn his way of thinking more quickly – and is quite simple to boot.

Before telling your cofounder how you’d think about the problem, first ask them to guess what you’re going to say.

I’ve actually been surprised how often my calibration is off. Sometimes I expect that my model is working great, and Carter raises a surprising and crucial point that I’ll have entirely missed. Other times, I lack any confidence in my model, and it turns out that it’s right on the money. In either case, though, the fact that I was forced to explicitly ask my model of Carter what I think he’ll be thinking is hugely important. If he’d simply told me, it might have been all too easy to tell myself after the fact, “Ah, yes, I would have guessed he’d say that.” But taking 15 seconds to first share my expectation out loud prevents me from doing this, and forces me to really digest the lesson.

This is a powerful learning tactic in general, but I can’t emphasize enough how much value it’s brought us in terms of getting on the same page about how we think through problems together.

Will Carter and I ever run out of things to learn about each other – will our models ever become perfect? Much to my chagrin as a physicist, I’d probably say no. So long as we’re both growing individually, and Modulate is growing and pushing us towards new experiences, there will always be new ground to explore together. (And oh boy are we both growing individually – building a startup will do that! There’s a ton to say about how this growth evolves as well, but I’ll save that for another post.)

Ultimately, I’m enormously grateful to have a cofounder with whom I can embark on that adventure alongside who shares my desire to not just appease but to understand each other – and while we’ll always be different people who sometimes disagree, working together as founders has already strengthened the powerful bond between us, and I know it will continue to do so.