Tell me about yourself. What’s your background? Where were you before Ironclad?
My background is in software engineering. Before Ironclad, I was a software engineer at Palantir, where I worked on their government platform. And before that, I was a Physics and Computer Science major at MIT.
Did you always want to found your own company?
No, actually. It’s kind of funny because the very first thing Jason, my co-founder, did after leaving Fenwick and West was to incorporate a company, and the very first thing that I did after leaving Palantir was to open a repository and start building.
I wasn’t sure about starting a company. The only thing I did know was that I wanted to keep building.
Why did you decide to go into legal tech?
I’ve always been really intrigued by this idea that you can take tools that software engineers use to make themselves more effective and build analogs of those tools for other people. So at Palantir, for example, we were building software for government workers that made them more effective at their jobs, software that augmented them as opposed to replacing them.
After Palantir, I was looking around at a number of things and really was drawn to legal technology because I think it’s an area where software can really help people do their jobs more effectively. There’s a lot of potential for augmentation in this space.
I also just love working with lawyers and legal professionals. They’re these incredibly intelligent but underutilized group of people who I think are a lot like software engineers.
How so — how are lawyers like software engineers?
Well for one, I think they think and approach problems very similarly. For example, the way that lawyers design contracts is very similar to way that engineers think through code. We’re both constantly thinking about edge cases, about what could go wrong and how we’re going to deal with those things. We’re thinking a lot about how to make something so elegant that it catches a lot of the wrong stuff that I can anticipate today and hopefully even some of the wrong stuff that I can’t foresee.
So in that critical way, lawyers and engineers are really similar. One big difference — and a crucial reason for Ironclad’s existence — is that engineers tend to have a pretty low pain threshold, and can build tools for themselves that makes their jobs easier. Lawyers tend to have a higher pain threshold, and don’t often build tools that make their jobs easier.
What have you learned as CTO of Ironclad?
That’s such a hard question. I’ve learned so much, it’s really hard to pick out specific things!
A big one is that, balance is really hard. “Work-life balance” is the most common term people use for what I’m talking about, but I think it underrates the number of things you’re actually trying to balance.
I’ve learned that there’s always more to do than you can actually do. And it’s important to make time for yourself, because if you don’t, you’re just going to fill it with other stuff.
What advice would you give to someone trying to start their own company?
You have to be prepared to work really hard, to give it your all. But also know that even if you put your all into it, there’s a lot that’s beyond your control — you need to be lucky. So it’s important that the team, culture, and product are things you’re truly passionate about.
Tell me about Ironclad’s engineering team. How is it unique?
So, one of our core values is integrity. To most people, I think integrity is about being trustworthy. At Ironclad, we add an additional layer of meaning to integrity, and that is that we need to not only be worthy of trust, but we also need to be trusting of each other. We trust each of our teammates to have integrity: to tell the truth, to make their own plans, to be experts at their domains. We also trust our teammates to know when to ask for help.
There is something incredibly liberating about being able to work with a team where you don’t need to second-guess your teammates. You just know that they’re going to do their best work — that often, they can do a better job than you can, and that if they can’t, they’ll ask for your help and your feedback.
What do you look for when you’re hiring software engineers?
We look for superb technical skills and people who share our core values — Integrity, Drive, Empathy, and Intent.
Aspects of our values translate into very concrete engineering things. For example, when it comes to Drive, we’re looking for self-starters who are going to take initiative on projects, who are always looking to improve themselves, their teams, and the product.
When it comes to Empathy, we look for people who really care about the end user. From the most extreme back end to the most extreme front end, everyone on the Product Team is constantly thinking about, what is the end user going to be experiencing? We’re looking for people who want to be involved in all aspects of the product’s development, who are interested in jumping on sales calls and customer development calls to learn more. They should be thinking critically about what they’re trying to accomplish, not just building from a spec but participating in the creation of the spec.
Another super important thing we look for is Intent: engineers who understand that the right solution today is almost certainly not going to be the right solution five years from now. And so, they’re not just thinking about the best plan to execute right now, but also, how far is that going to take us? This kind of Intent-ful, forward thinking is important because it’s all too easy for enterprise companies to fall into a pattern of spending a lot of effort on urgent fires and failing to make important investments in the rest of the platform. You put out a fire, but you fail to make sufficient investments in the product or team velocity — all things that are very important to long-term success.
How do you think about prioritizing work?
We have four buckets we allocate certain percentages of time towards. We spend 50% of our time on the first bucket, which encompasses company priorities. These are features that are critical to the success of our company in the medium to long-term.
We have a second bucket for platform feature requests. These are things that aren’t necessarily company priorities but will benefit all areas and customers on the platform. We spend about 35% of our time here.
Third, we spend 5% of our time building things for certain strategic customers. And finally, we spend 10% of our time on the fourth bucket, which is Product Team velocity: projects that will make us as a team faster and more effective. Oftentimes people refer to this as developer experience. It includes things like, internal systems to help track bugs, investments in deployment and monitoring, etc.
What’s been the hardest part of working at Ironclad? The most rewarding?
The hardest part has been building the team — finding the team that’s going to take Ironclad from 10 to 20 to 50 to 1000 people. It’s hard to find people who are on the one hand, low ego and extremely capable today, but also have the potential to constantly transform themselves to grow more and more.
We’ve got an incredible team and every single time we bring someone new on, there is this question of how is the team going to change? Is this going to change this great team dynamic that we have?
But you know, building the team has also been the most rewarding thing about Ironclad. Because every time we’ve taken a chance with someone, we’ve learned so much. I’ve learned so much from everyone on the team and I think it looks like everyone on the team is learning so much from each other. So it’s definitely building the team has also been the most rewarding part of it.