In our First Line of Code series, Commit co-founder Beier Cai talks to prominent tech founders and tech leads building the next generation of companies, to hear about their experiences and lessons learned.
Dieter Shirley worked as Chief Software Architect at Axiom Zen before becoming CTO of Dapper Labs, the blockchain company behind CryptoKitties (which he co-created), NBA Top Shot, and the Flow blockchain.
Commit co-founder Beier Cai sat down with Dieter to talk about his journey in tech and all he has learned along the way.
This is part two of this interview. See part one here.
Beier: What was your hiring strategy in the early days? What qualities were you looking for when it comes to the first few engineers that you hired, and what worked or didn’t work out for you?
Dieter: I think the only way to build an early-stage team in any kind of startup is to hire people who are multi-capable. They need to have some amount of product and business sense. You need somebody who doesn’t need to be told that you shouldn’t spend time on something because none of the customers care. They should just naturally know.
They should be people who are flexible about technology decisions. That means they aren’t going to freak out if you use new technology and aren’t going to freak out if you use the tried and true. They are going to be really comfortable with change and ambiguity because the only thing that is certain in a startup is that whatever you thought you were building when you launched the company is wrong.
What you need to do is hire people who, even if the mission stays the same, the product, the way it’s marketed, the way you go to the customers, the way the customers use it are all likely to change a lot. The way you’re going to be successful is by having people who aren’t perfect for that first thing, which means that they won’t be imperfect for the next thing. They’re people who can fit into just about anything.
When I think about early-stage Dapper employees and early-stage Axiom Zen employees, the ones that stuck with us and created a ton of value were the ones who moved from project to project and did different things. The lead architect of the core protocol for Flow was originally hired at Axiom Zen to do machine learning and he worked on a bunch of different things in between. Those are the kinds of people that you need to find.
Beier: It seems like you really prioritize the human skill or the soft skill side of things. Rather than, for example, the best technical coder.
Dieter: Yes, and I would stay away from experts.
This year we made an effort to hire a bunch of experts, and I’m glad we did. We’ve got some amazing experts on staff now, but it would never have worked if we had brought them on earlier. When you give experts a task in their area of expertise they destroy it. It’s amazing, it’s a beautiful thing. But if you ask them to do a little something outside of that they get awkward. They’re better at their area of expertise than the generalists who have been at the company for a while. Until we needed that expertise, having them on staff wasn’t really necessary.
Like I said, you’re probably wrong about what your product should look like. So bringing in somebody who’s an expert on X is a mistake because your product may not need X in the long run. People who are real generalists are going to be the most valuable.
Almost every startup has to figure out what the market wants and how to reiterate the tech to make sure we’re meeting the needs of the market.
The people with the vision are never going to have the time to tell the people who are executing what to do. They have to figure out how to share that vision with them. There are still going to be discussions, but you have to trust that 90 percent of the time they’re going to answer the question the way you would’ve answered the question and then you can talk about it the other 10 percent of the time.
If you have to talk about what the right answer is even 50 percent of the time, let alone 80 percent, you’re not going to have enough bandwidth. As soon as you have your third engineer, suddenly you’re spending all of your time explaining to them what they need to do now that the project direction has changed in this subtle way.
It’s better to think of it as a collective. It’s a hilarious analogy but it’s like a slime mould. In a slime mould every single cell is the same as every other cell and is able to do all of the functions of a slime mould, but they work together because that’s more efficient and effective. It’s not a single cell organism but it’s also not a mammal where cells have specialization.
When you’re small I think that having the collective, having everybody working together is helpful. But I also think that you want to err on the side of getting people who have similar skills to you rather than trying to find people who are the exact opposite to you because that communication bandwidth is going to be one of the highest barriers. That’s been my experience.
Beier: Let’s say you’ve put a team together. How do you introduce a sense of urgency to the team, especially in the early days when things can get demanding?
Dieter: This is a tough one because when you have the right team you don’t have to. When you have people who understand what the mission is, it’s intuitive.
Sometimes you have to give them the facts and say, “You’re not talking to people in the developer community. You don’t know that people are complaining about X, Y, and Z.”
At the end of the day, the number one goal is to get the product in people’s hands and then react to their complaints. It doesn’t mean fixing everything and giving them everything that they want. But if people aren’t using your thing and if people aren’t annoyed at you, you’re doing it wrong. When people care about something and they want it to be better, that’s when they complain.
Nothing in the world is perfect and there’s always a trade-off where you could do it this way and those people will complain, or you could do it that way and those people complain, but there’s never a right answer where everyone is happy.
So the question is not ‘did you make a good thing,’ the question is did you make something so valuable that people are invested enough into it to want it to be improved, because they can’t imagine their lives without it. Of course it’s going to have flaws, but the easiest thing in the world to do if you don’t like something is to just push it out of your life. If you can’t push it out of your life, it means it has value and that’s how you know you’re successful.
That’s why the hardest time to build a sense of urgency on the team is at that moment right before you get a product to market, when you’re getting people to understand how important it is to have something that people can interact with, even if it’s flawed.
In my experience, over half the time you ship something with five things wrong with it, people complain about one or two of those things, but they almost never complain about all of them. And then they complain about something that you would have never expected.
You could have fixed those five things and you would have made two of those complaints go away, but you would have never solved the thing that you hadn’t seen. You can then use the time you saved fixing the things that they do actually care about.
The best answer, in my mind, is to make sure you have the right people on your team who get that and who understand that we don’t have an infinite amount of money or time. At the end of the day, regardless of how much money we have in the bank, what we really need is confidence from our investors and customers and we’re never going to get that if we don’t ship something.
Beier: One thing that I experienced in the early days when the team first started expanding is delegation. I’m busy with a bunch of stuff, we have new people who joined us, and I have to spend a lot of time communicating, guiding and mentoring them when I could just get this task done myself in half a day. I think it took me a while to change my mindset. Did you struggle with this at all, and if so how did you deal with it?
Dieter: When I moved from being an IC to being a manager, it was really hard. I started by being way too micro-managey, way too in their faces and in their code. Literally reviewing and making code changes rather than giving feedback. Then I realized that was a mistake and I went too far in the other direction: way too hands-off. I wasn’t seeing people or giving them that feedback.
Building Flow was hard, because it started as just a very small group of us talking for months. Then when we had it all in our brains, other people started joining the team and building up parts of it, and we ran into the same problems. It comes back to whether you’re giving them enough context to answer 90 percent of the questions by themselves without talking to you. If not, you’re going to spend all your time working with them.
The best advice I can give is that it all takes time. The weird thing is that it takes more time to give people the context and let them answer a question themselves than it does to actually solve the problem yourself. The terrible situation that happens to us quite frequently is that we wait until we get to the point where we realize we don’t have the time to solve it ourselves or teach it.
So what you have to do is project forward and ask yourself, ‘is this a problem I want to be solving a year from now?’ If you’re going to be an engineering leader at the tip of the org chart for the whole engineering team and you’re going to have a healthy engineering culture where everyone’s getting regular performance reviews and salary reviews and you’re going to keep up with what everyone needs, then you’re probably not writing code a year from now.
The real inflection point is that product-market fit. Before product-market fit, the right mindset as a founder is, when you see a light bulb burned out, you change it yourself. It doesn’t matter what the problem is. That’s what it means to be a founder at that stage.
But once you’ve got traction and you start feeling like you’re running after the boulder rather than pushing it, you have to immediately switch to asking yourself, ‘how do I build a process such that somebody else is going to walk around and either proactively or reactively fix light bulbs as their job?’
I’m having to learn that, but I’m also seeing lots of people at our company who started as ICs who are now having organizations form around them having to learn that as well. It’s something that I’m having to coach other people to do, to tell them that if they continue to be the person that solves this class of problems, this class of problems is going to 10X in size in six months or in a year and they’re not going to be able to solve it all, so they’re probably going to burn out.
In the same way that being aggressively careful about technical debt before you’ve hit that product-market fit is a mistake, I think being overly careful trying to build systems and structures and processes to solve problems before you hit that product-market fit is dangerous as well, because you might spend a bunch of time codifying something that doesn’t actually meet the needs of the product you’re going to end up building.
That product-market fit moment when you start to see traction, that’s a time when you should really ask yourself, ‘a year from now, if we keep up with this, is this what I want to spend my time doing? And if not, how do I get somebody else to do it?’
Beier: After one of our engineers joined a startup as a CTO recently, he was invited to a board meeting, which caught him off guard a bit. He came to me and asked, “Beier, what do I say in a board meeting? I have no idea.” I’m curious, what are some of the memorable non-technical moments in the early days for you as a technical founder?
Dieter: I was really lucky in that my career led me into that. Several of my previous jobs involved working at software consulting firms, usually product-based ones. When the iPhone came out and everyone needed an app, we were one of the teams that would build apps for people. So I already had some experienced with pitch meetings, business meetings and sales meetings.
At the end of the day I think the most important thing to keep in mind with this stuff is that we’re all just people. It doesn’t matter who you’re talking to: they’re just a person, and they have strengths and weaknesses, and they have things they know and they have things they don’t know. And at the end of the day, they have no illusions about the fact that they’re investing in deeply flawed products and people.
That’s why they’re getting a good deal. The fact that your org is messed up and you don’t have any customers and you don’t know how exactly this technology is going to work: that’s why they want to invest in you. Because if it was really obvious that you were going to be successful, then it wouldn’t give them the returns they want.
So the most important thing is to be clear about what you know and don’t know. Be clear about what your vision is and where the gaps are in your organization, because if you are, they’ll invest in the things they like and will support you in those things where you’re weak. If you don’t get a sense that you’re talking to an investor who’s going to support you with more than just money, then you probably just need to move on.
I’ve also been lucky in that our board consists of people who are emotionally invested in what we’re doing. It’s not just, “I’m giving you money and I expect money to come out,” they like our vision and they have a fiduciary duty to their LPs. One of the reasons why they wanted to invest into this is because they found the problem interesting and they want to work through it with us, they don’t want to just be told that everything is going well. So I actually find those board meetings very productive and interesting: they bring different perspectives.
Interviewing was another big one, especially interviewing senior people. It is really interesting to interview CFOs, chief legal officers, marketing people and put together an executive team in general. The biggest mistake I think that I have made and I think I’m getting much better at it is to pay too much attention to their resumé and to pay too little attention to how the interview goes.
There are many reasons why people end up with fancy titles or working at impressive-sounding companies. You need to make sure that you’re finding the people who are a fit for the role you really need and not the job title.
I’ve been fortunate enough to meet a bunch of CTOs, and they run the gamut. On one end you have people who write code all day and have the title of CTO because that’s what made sense when the company was small and they never gave it up, and on the other you have people who haven’t written code in 25 years and it’s all about engineering organization and structure and it’s not about the actual day to day practice of engineering.
Both of those people are incredibly valuable to the organizations they’re a part of. But they both have the same job title, so you really have to be thoughtful about what that means in your org.
Beier: You’re in a CTO position at a high-profile company. I can imagine that gets pretty stressful at times. How do you personally deal with stress?
Dieter: The stress has been less of an issue than the fatigue. The reason why the stress isn’t that much of a problem is that I have learned to recognize that what we’re doing is hard and that no one in the world has a better answer of how to do it than we do.
If I screw this up, it’s not the end of the world. It’s just a hard thing. If it were easy, somebody else would be doing it, and no one else is doing it. Of course I’m going to screw up some things, but no one can ask any more of me than what I’m already doing, and so I don’t get too stressed about it.
I do stress a little bit about the team, because I think there are many people on the team who have a harder time feeling that way. They hold themselves to an impossible standard and that’s difficult. I guess I’ve held myself to an impossible standard long enough in the past that I’ve realized that it’s counterproductive.
The harder one is the fatigue. I’m not stressed, I’m not burned out, I’m just really tired. It’s been a lot of time, work, long hours, planning and executing. The first five times you realize that you were going in the wrong direction for the last two weeks and you have to start over, that’s actually not that bad. But the 10th time it gets difficult.
Fortunately we’ve got enough of a profile and we’ve had enough success this year that we’ve been able to find some really great folks to join the team and take over some of those things that have been draining me.