In our First Line of Code series, Commit co-founder Beier talks to prominent tech founders and tech leads building the next generation of companies to hear their experiences and lessons learned from their early days.
Nicholas Clark is the chief technology officer and co-founder of Divvy Homes, a property-technology startup that helps renters become owners. Prior to starting Divvy, Nicholas was the CTO of DoubleDutch, a provider of cloud-based geosocial mobile applications, where he helped scale the engineering team from two to 40 engineers.
Commit co-founder Beier Cai sat down with Nicholas to talk about the early days of Divvy Homes and DoubleDutch and what it was like writing the first lines of code. See the first post here.
Beier: Let’s talk about building early-stage teams. What was your early hiring strategy for the first few software engineers? Did you look for seniority, personality, something else?
Nicholas: At DoubleDutch I think the strategy was finding people who were passionate about software development and had a lot of energy to solve problems. It skewed more junior.
At Divvy it was a bit different. There were two engineers at the beginning with me. One I knew before—I’d worked with him—and one I hadn’t. They both had six years of experience or more—so, fairly senior. The first eight people I hired all had six, seven, eight years or more of professional experience. That was very intentional. I wanted to hire people who could work autonomously, who were comfortable in a business environment working with non-technical people to understand what problems they were facing, and describe the opportunities that software had to impact those problems.
So it was more senior from the beginning. Even today just about every engineer has five years of experience or more. That was just a personal preference, for people that can work more autonomously.
In terms of technical ability, it doesn’t matter to me too much if people have experience with Node.js or not, as long as they have strong technical ability. Learning a new language or framework takes time, but it’s pretty easy. Most people we hired early on were generalists. They were comfortable doing frontend work if they had to, dealing with the database, networking, backend work and all that stuff. I think when you’re early you don’t know exactly what your business is going to look like. I think generalists are just a bit more adaptable to solving different problems.
There are certain situations where specialists are helpful. We hired data scientists early, because we knew we were going to have to build models to estimate risk. There are certain specialities where you want to hire someone who’s not just a generalist engineer. But for the most part generalists were helpful.
Values are where it really starts to matter a lot. We’ve been pretty unbudging on hiring for values since the beginning, and I developed clarity around what those values are.
The first is ownership. People who not only take ownership for the code they write, but also take ownership for the domain they’re solving problems for. If you have somebody who’s working on our ledger system, not only do they write code for the ledger that they’re accountable for, but do they spend time with the people on the capital markets team to understand what they need to do their jobs appropriately? If you need to spoon-feed people the problems they have to solve, they’re never going to be truly autonomous. So ownership is really important.
Work ethic is second. A lot of times people think of startups working 80-hour weeks. That’s not what I mean by work ethic. I strongly believe in work-life balance. I want people to be at Divvy for five years, 10 years—and you don’t do that by burning people out.
Work ethic means a willingness to take on hard problems and push through until you get a solution. It’s like I described at DoubleDutch. It’s that passion, that drive, that hunger to solve problems with tech.
The third core value, which I think is the most important for team dynamics, is a combination of humility, empathy and collaboration. People who make other people better. A lack of ego, zero tolerance of aggression, not being rude or dismissive. That’s critical to creating a diverse and supportive environment.
Beier: One of the challenges tech founders face is that, as the team gets bigger, it becomes harder to do everything by yourself. But sometimes people struggle with when to let go, how to count on other team members to take ownership. Is that something you’ve faced?
Nicholas: Yes, at DoubleDutch I had a problem with that. I think I’m naturally a pretty fast developer, but as someone who’s there from the beginning, you have so much more context about the system and the business than anybody else. So of course you’re going to be able to do things faster.
I had a lot of trouble handing things off. I was like, ‘No, I’m just going to go do it and I’ll show you.’
It wasn’t until leaving DoubleDutch where I just had a much more intentional mindset of not letting it get to that point. Having a team allows you to leverage yourself to accomplish more. I think early engineers—including myself—have to get past the ego, thinking you can do it better.
The first thing to accept is that someone who’s completely focused is going to do a better job than you, if you’re only using one-eighth of your time. That’s why it’s so important to create an ownership-based culture, because you end up with people who are more of an expert than you would be yourself. It’s your job to give context on high-level business goals and rough guardrails on how to make technology decisions. But they’re responsible for deeply understanding the problem and coming up with the solution for it.
The other thing that I realized is that it’s really, really unfair of me to spend a bit of time writing some code, forcing it into production, and then ultimately making everybody else accountable for any issues that arise with it. So I’m at the point now where I’ll help out with SQL queries or debugging or something like that, but I don’t tend to write a ton of production code.
No smart, ambitious engineer wants to be told exactly what to do. They want agency and decision making. So it’s good for me to allow them to go and solve problems without me and it’s good for them to have agency.
Beier: How did you manage work-life balance on the team? How do you introduce a sense of urgency without burning the team out?
Nicholas: One of our company’s core values in our first two years was something called healthy urgency, or sustainable urgency. The tagline somebody came up with was: It’s a marathon, not a sprint—but it’s still a race.
I have a lot of thoughts about it. First off, I don’t believe in arbitrary deadlines. There are very few situations in our business where it’s problematic if something takes a day or two longer than estimated. There are situations where you have a customer deadline or deliverable, but for the most part deadlines tend to be a managerial tool to generate false urgency. And I think that breaks trust with people on the team.
What’s important for me is to not be surprised. I tell people on the team that it’s okay if you discover additional complexity in something you’re working on and it ends up taking longer. What’s not okay is to find out about it at the last minute. It’s a communicate-early-and-often mentality.
Beier: That makes sense. Let’s switch gears—have you experienced any interesting technical or engineering failures? What have you learned from them?
Nicholas: I’ll give you two. One was at Divvy Homes. It was in the first couple of years of the company. I wrote a script to take production data, pull some subset of it, sanitize it and create a dummy dataset that would inject into your local environment.
It was using some of the same environment variables as other parts of our application, one of which was database URL, which, when set to nothing, would default to localhost.
One of the engineers on the team had exported the database URL to match the production database, because sometimes, early on, when we had three or four people, we would run locally against the production database just to see what it looked like. The engineer ran this local test data script. It picked up the production database URL, wiped the production database and injected it with dummy data.
It was mad panic for a minute or two. We happened to have per-minute snapshots of our database, so it was as simple as rolling back to a couple minutes earlier, which is why I say there are a handful of things you have to be very careful with at the beginning to prevent catastrophic failure.
The other one was a result of a lot of smaller failures. Our backing codebase had gotten so large and had a lot of technical debt—this is at DoubleDutch. It was difficult for new engineers to onboard and have an impact, so we embarked on a journey to rewrite our backend. Long story short: It went a year over the budgeted plan of nine months or so, and we scrapped it entirely because it ran into a ton of new issues.
I think the failure there was allowing technical debt to get to a point where we felt rewriting it was necessary. Doing a rewrite from scratch is a horrible idea—versus pulling out pieces. The people working on the rewrite were not the people who wrote the original system, so there was a lot of context lacking. Rewrites in general are a bad idea without a very, very clear plan.
There’s a fantastic article I read about Netscape back in the ’90s, when they were working on Netscape 2 or 3 or 4. There were so many little hacks in the code that they decided it was worthwhile to do a rewrite of the browser engine. They spent all this time rewriting it, and there were all these weird edge cases that didn’t work properly anymore. They realized that the little hacks that were sprinkled throughout the code were actually solving for those edge cases. So, oftentimes there’s a good reason for some of the weird things in a codebase.
Beier: I’m interested in your personal career decisions and growth. The decision you made jumping from Microsoft to an early stage startup—what went through your mind in terms of personal financial risk? How did you approach that decision?
Nicholas: I left college with zero debt, so I came from a privileged background where I didn’t have student loan payments every month. That does make it easy to save. For my first apartment out of college I rented a house with five other guys and I saved money. I didn’t go out, I didn’t really go out to dinner, I didn’t spend any money. I just saved everything. And again, I was in a fortunate position that I could do that.
So I had a rainy-day fund in case something went wrong. So that was a piece of it. I was promoted quickly at Microsoft and was well-reviewed there, so that built some confidence in me that other people saw my skillset as valuable. When I jumped to DoubleDutch I was too afraid initially to take the offer, and I interviewed at Google to make sure I could get an offer there first, so I knew if it didn’t work out for some reason I could go to another company.
What I tell engineers now about joining a startup, especially the ones who are scared of the risk, is that if it doesn’t work out you can get a job wherever you want, especially in this environment, within a couple of days. So it’s not actually that much of a risk anymore, aside from wasting your time.
If you go to a startup and don’t make it big, you don’t get that time back. So make sure you’re at least going to learn something.
Beier: As an early technical founder, beyond building technology and product what are some of the experiences you didn’t expect?
Nicholas: I started with Divvy with my co-founders. I didn’t have a ton of real estate experience, I didn’t have much finance experience at all—and we’re a FinTech business now. The language that I’ve picked up to talk about financial concepts is a lot broader than I was expecting. I was recruiting an engineer once and they said they thought I was a banker. I was like, that’s great. I guess I’m doing well.
Other surprising moments? It’s always a little surprising how comfortable you can get in situations that initially make you really anxious or nervous. I’m typically very introverted. Historically I got nervous in front of groups or when I had to present or something. Like anything else, the more you do it the more comfortable you get.
The little trick I told myself, especially for board meetings, is when you’re presenting something, keep the mindset that you know more about what you’re talking about than anybody else in the room, and nobody’s there to make you look bad. It’s about going in with confidence: I know what I’m talking about and the people here want to learn from me and use me constructively, not look for little flaws in everything I say.
Beier: How do you deal with stress?
Nicholas: There’s stress and there’s anxiety. I define anxiety as worry about something you don’t have control over. Anxiety’s the real devil. I think stress is worrying about something you have control over that has some sort of urgency. Distinguishing between the two is important.
With stress, it’s about making sure you put your attention towards it. With anxiety it’s about trying to find ways to release it.
I like to stay very active. I try to exercise every day, whether it’s playing tennis or lifting weights or riding the bike or something else. I think that’s a good way to start your day.
As you get older you have more perspective that some of this stuff doesn’t really matter. It might feel like the world is ending, but you have to show up and try to solve the problem, and you’ll figure out a way out. Everything’s not world-ending. Having some perspective helps.
Having people you can talk to about it is really important. It can be very lonely when you’re running a team or when you start a company, because you don’t have a ton of people who understand what you’re going through. Finding people who do understand, and not being afraid to let them know that everything isn’t all sunshine and rainbows—that’s a good way to realize you’re not alone.
Do you want to stay up-to-date with Commit news? Subscribe to our newsletters!