You may have noticed that we’ve chatted with a lot of really smart people through our Inside Look interview series. As we wrap up 2015, we’re revisiting some of the sage advice we’ve encountered from these founders, CTOs, and engineers.
We’re starting with a broad question this week: What are the skills necessary to being a CTO? According to our interviewees, key CTO skills include being empathetic, knowing how to ask questions, and recognizing that your code isn’t what makes the money.
Dan Kador, CTO of Keen.io
The first one that comes to mind is just perseverance. It’s what I tell anybody who wants to be a developer, and it continues in this role. A lot of the battle is just being frustrated and banging your head against something and then finally figuring it out 40 hours later — and, hopefully, asking for lots of help along the way. So you need perseverance; not being afraid to ask for help.
Understanding second- and third-order effects is really important. For example, if you’re helping to put in place performance reviews, one of the inputs into the performance review is, you know, “We’re going to measure two or three metrics.”
Just assume that those two or three metrics are immediately going to be gamed, because that’s how people work. Then that’s the first-order effect. That metric’s going to be gamed. So, what is the second-order effect of that? Hopefully, you can get to the third-order effect. How is this going to affect the product? How is this going to affect culture? That’s a really important thing.
Morten Primdahl, CTO of Zendesk
I think creativity is up there. There are going to be many times in a startup where you have to pick between a good solution that takes a lot of time or a solution you can do in a short time. None of us like to leave technical debt behind, but sometimes it’s a reality that we face. Being creative about finding a solution that doesn’t come back and give you ten times as much pain in the long run is super important.
You don’t want to sacrifice the technological, right way of doing things. Don’t get caught up too much in dogmatic thinking. Be pragmatic, work with people, and your code isn’t what makes the money; it’s the product. Those are often the same things but not always.
Madison May, CTO of indico
It’s very important to listen to and gather feedback from the rest of the team. One of my main roles is aggregating opinions and information. Oftentimes, it’s not myself that’s the most qualified to make a decision. It is my role to aggregate that feedback and learn what the organization believes is the best solution.
It’s also important to very quickly understand that your own productivity should not be measured by technical output. Measuring the productivity of a CTO by measuring code output is a very, very poor metric. Productivity, for me, means enabling people to function uninterrupted and helping to break up work into components that are easily handled. Communication is key. It’s my job to be able to communicate our company’s technical aspects to people who perhaps don’t come from a great technical background. Learning to cross that language barrier has been tough, especially when you’re working in an industry like machine learning. Learning to communicate some of the same concepts in everyday language is critical.
Communication is always a huge barrier for any new idea.
I found that there are a lot of analogs between software architecture and good methods of running a company. A lot of the red flags in architecture are similar to the red flags in an organization.
Like the idea of spaghetti code — the idea that there are too many components responsible for a single function as opposed to having each component be responsible for a single action. That was a pain we felt in the early days of indico. It wasn’t clear who was responsible for what aspects of the company. It took a while for us to figure out how to effectively route tasks throughout the organization and to ensure that the proper people contributed to decisions. Having everyone have a say in every decision doesn’t necessarily contribute to a good decision-making process. It just contributes to confusion.
There are also similarities in the principle of redundancy. We have been working hard on knowledge transfer, so that no knowledge resides in the head of a single person. Knowledge should spread out across our organization so we can continue to function in the absence of an individual.
Peter van Hardenberg, founding developer of Heroku Postgres
Know how to ask questions. The first question is always, “What problem are you trying to solve?” If you don’t know what problem you’re trying to solve — whether it’s a technical, product, or people problem — you won’t know if you’ve accomplished your goal. So many people get excited about an implementation, or an idea; but they run ahead of making sure that they’ve documented what problem they’re solving and also what problems they’re not solving.
A good example might be if you’re building a new feature to reduce the amount of time for a log-on. You know you’re building a new log-in page. Why are you building it? Are you trying to reduce the friction in sign-up? Okay. How are you going to know that you did that at the end? You’ve got to make sure that whenever you set out to do something you know it’s use. Is that actually going to be useful? Is it going to be used? What problem does a user have that this solves?
Number two is empathy. You need to have empathy for the user, for the team members, for management, for your reports. Ultimately, software is hard, and people are harder. And people make software, so you’re ultimately going to be solving people problems, whether you’re an engineer, a product manager, or a manager.
Elliot Cohen, CTO of PillPack
I don’t think there’s any “one-size fits all” answer to what you need to know to be a good technical co-founder. What I can say is I think what every founder needs, whether technical or not, is a deep sense of awareness.
The only way that you’re going to build a team around you really fast is being brutally aware of what you are good and bad at and making sure that you surround yourself with people who can fill in the things that you’re weak at. Nobody’s perfect, but teams can be.
Johnny Boursiquot, co-organizer of Boston Ruby Group and Boston Golang
To my fellow developers, young and old, new and experienced, “community” implies ownership, and that puts the onus on all of us to keep ours a welcoming and vibrant one. Let’s never be satisfied with the status quo.
Katrina Owen, creator of Exercism.io
I think that we’ve optimized for burnout. We work and work and work, and we almost never let up. We act as though working more hours is going to give us better results, even though there’s a ton of research that suggests that working more hours causes our productivity to nose dive.
I wish that the industry would be more about taking breaks, staring at the ceiling, and just plain doing something else. I’m all for working hard, just not quite as relentlessly as we do.
I think we need to let our brain check out of the linear, task-oriented mode and flip into the mode that comes up with surprising solutions and non-obvious approaches. We don’t spend enough time connecting the dots between disparate things that we know. We acquire lots and lots of knowledge but develop very little wisdom.
I think we all could use a proper vacation.
| Reference: | What Are the Key Skills to Being a CTO? from our JCG partner Chris Wolfgang at the Codeship Blog blog. |
