Tuesday, September 30, 2008

What does a startup CTO actually do?

What does your Chief Technology Officer do all day? Often times, it seems like people are thinking it's synonymous with "that guy who gets paid to sit in the corner and think 'technical' deep thoughts" or "that guy who gets to swoop in a rearrange my project at the last minute on a whim." I've tried hard not to live up (or down?) to those stereotypes, but it's not easy. We lack a consistent and clear definition of the job.

When I've asked mentors of mine who have worked in big companies about the role of the CTO, they usually talk about the importance of being the external face of the company's technology platform; an evangelist to developers, customers, and employees. That's an important job, for sure, and I've been called upon to do it from time to time. But I don't think most startups really have a need for someone to do that on a full time basis.

So what does CTO mean, besides just "technical founder who really can't manage anyone?"

I always assumed I wouldn't manage anybody. Being a manager didn't sound fun - deep down, who really wants to be held accountable for other people's actions? I mean, have you seen other people? They might do anything! So I initially gravitated to the CTO title, and not VP of Engineering. I figured we'd bring in a professional to do the managing and scheduling-type stuff, and I could stay focused on making sure we built really awesome technology. But along the way, something strange happened. It became harder and harder to separate how the software is built from how the software is structured. If you're trying to design an architecture to maximize agility, how can that work if some people are working in TDD and others not? How can it work if some folks are pre-building and others use five why's to drive decisions? And what about if deployment takes forever? Some options can improve the performance of the softare at the expense of readability, deployability, or scalability. Should you take them? These sounded to me like technical problems, but when you do any kind of root cause analysis they turn out to be people problems. And there's really no way to tackle people problems from the sidelines.

So I wound up learning the discipline of managing other people. Turns out, I wasn't too bad at it, and I found out just how rewarding it can be. But since I spent a long time in a hybrid CTO/VP Engineering role, I still have this nagging question. Just what is the CTO supposed to do?

Here's my take. The CTO's primary job is to make sure the company's technology strategy serves its business strategy. If that sounds either too simple or too generic, think for a second if any companies you know do the reverse. Have you ever heard a technologist use technical mumbo-jumbo to make it sound like a business idea he or she didn't like was basically impossible? That's what we should be trying to avoid.

I'll try and break it down into five specific skills.
  • Platform selection and technical design - if your business strategy is to create a low-burn, highly iterative lean startup, you'd better be using foundational tools that make that easy rather than hard. Massive proprietary databases? I don't think so. Can the company dig into its tools when they fail and fix them? If not, who's going to insist we switch to free and open source software? When projects are getting off the ground, who can the team check with to make sure their plans are viable? Who will hold them accountable for their project's impact on the platform as a whole?

  • Seeing the big picture (in graphic detail) - the CTO should be the person in the room who can keep everything your technology can and can't do in their head. That means knowing what's written and what's not, what the architecture can and can't support, and how long it would take to build something new. That's more than just drawing architecture diagrams, though. Being able to see the macro and micro simultaneously is a hallmark of all of the really great technologists I've had the privilege to work with.

  • Provide options - another mark of a good CTO is that they never say "that's impossible" or "we'd never do that." Instead, they find options and can communicate them to everyone in the company. If the CEO wants to completely change the product in order to serve a new customer segment, you need someone in the room who can digest the needs of the new (proposed) business, and lay out the costs of each possible approach. Some technologists have a tendency just to "decide for you" and give you the "best" option, but that's dangerous. You can't have an honest dialog if one party knows all the answers.

  • Find the 80/20 - this was my favorite part of the job. Sometimes, you're in a meeting where someone wants to build a new feature. And in their mind, they've got it all spec'ed out. It slices, it dices, and probably washes your car too. In my mind, they're racking up costs (one month for that part, two months for that other part, uh oh). On a bad day, I'd just give them the sobering news. But a good day looked like this. Once I understood what the objective of their feature was for customers, I could sometimes see a way to get 80% of the benefit for 20% of the cost. "Would you be able to learn what you need to learn if that feature just sliced, but not diced? Because if we don't have to add a dicing module, we can repurpose the flux capacitor via solar flares...." I was constantly amazed how often the answer was something like "really? dicing is what's expensive?! I just threw that in there on a whim!"

  • Grow technical leaders - I like to formalize this responsibility by eventually designating some engineers as "Technical Leads" and delegating to them the work of guiding the technical direction of more and more projects. This is the only way to scale. It also forced me to get clear about which aspects of our company's technical direction were really important principles, and which were just artifacts of how we got there. With multiple people trying to work to the same standard, we had to be a lot crisper in our definitions. Was the fact that we were primarily using PHP essential, or could we add new tools written in other languages? Was it an important or irrelevant fact that most of our web code was procedural and not object-oriented? What if someone wanted to write their module in OOP style? By delegating and training, we create a corps of leaders who could step in to provide CTO-like services on demand. And by working together, we created a team whose whole was greater than the sum of its parts.
I want to add one last idea, even though I recognize it is controversial, bordering on the boundary between the CTO and VP Engineering. I don't know how much I'm being influenced by having worn both hats, but I think it's important enough to go out on a limb and add.
  • Own the development methodology - in a traditional product development setup, the VP Engineering or some other full-time manager would be responsible for making sure the engineers wrote adequate specs, interfaced well with QA, and also run the scheduling "trains" for releases. But I think in a lean startup, the development methodology is too important to be considered "just management." If the team is going to use TDD or JIT scalability, for example, these choices have enormous impact on what the architecture must look like. At a minimum, I think it's the CTO and Tech Leads that have to be responsible for five why's-style root cause analysis of defects. Otherwise, how can they find out what their blind spots are and make sure the team and the architecture is adjusting? That job calls for someone who sees the big picture.
Your CTO might be a great architect, evangelist, interface designer or incredible debugger. Those are great skills to have, and I'm curious what you've seen work and not work. I'll be the first to admit that my experience is limited, so I'm collecting anecdotes. Have you worked with or for a great CTO? What made them exceptional? What's one thing a brand-new first-time CTO could learn from them?


  1. Dont startup CTO perform the dual architecture and manager roles until the company has an engineering team over 10+ people?

  2. Wow I think you just wrote my job description for me. Well it will be my job description once my team expands some more and I can delegate some of my daily engineering tasks.

    Great article you're now in my rss feeds :)

  3. Great post!

    I would love to see some blog posts on any experiences you have had with set-based design. Especially w.r.t. platform choice.

  4. While reading this article I've been thinking about my role as "CTO". I do have constant time collisions to mange my time for managerial and engineering work I must do.
    The question I need to answer here is how to divide time to succesfully manage people and other resources to plan ahead, and still have some time to lead the technical work: plan, review and code (the part i still like the most)?
    Anyone has any usefull thoughts on this?

  5. Hi Eric,

    Great article - I've added you to my regular RSS reads.

    In my roles as CTO for various startups, it's been an interesting repeating cycle for the CTO to have to wear lots of hats especially in the early days: from start-up systems architect to code monkey to development manager to ops manager then finally to CTO as the business scales over time and these roles warrant dedicated full-time staff. This has been true for all of our online business ventures to date.

    You hit the nail on the head regarding knowing the entire platform and system architecture in both macro- and micro- detail off the top of your head.

    For an online business, the role of CTO is almost more important than any other role in the business, since it's not sufficient for you to just know your department inside out like most other depts have to; you often have to understand everyone else's too since you're often building backend tools or supporting automated business processes for marketing, customer service, production, management, etc, and need to respond just as timely to feature requests from internal users as you do for dev features.

    Good to see that your thoughts on what a CTO is aligns with my own experiences.


  6. Great article! I can tell you that even for non-startups the description is pretty much accurate. I'm the CTO of a company for quite a few years now and what you write is still part of my job; there are just a number of additions that were added over the years.

  7. All I have to say it WOW! I've been looking for a good definition (if that makes any sense) for a CTO. Even though I haven't performed the roll before and don't have the experience of any of the other posters, this hits home. I am very impressed and will use this and a direct reference many times. This is more than just an "I think so..." this is real life wisdom and experience speaking. I've forecasted the issues you have spoken of without entertaining the thoughts of solutions like you have. It's inspiring to be aware that others have faced the same problems that I am now facing. I appreciate you laying out your for all to gain from and expect that you will do very well in your endeavors. Thank you once again!

  8. Very good article, I've been a CTO for different startups for over 5 years Always asking myself how to remain effective as a CTO. The answer was that it all depends on what stage your company is in. I've been coding, debugging, coaching, building a strong team, managing and during all this time stayed abreast of the new technologies to adopt the best for the team and the business.
    Recently i've been focusing more on the management, sitting with clients, lowing their expectation (80/20 rule), protecting the team by any means. When the team became solid and reliable, the question hit me again ... How can I remain effective ... My answer to that was to be part of the team whose whole is better that its individual parts as it's mentioned in the article, a team leadership rather that a point leadership.

  9. I feel reminded of one of Jerry Weinberg's laws of consulting: Regardless of what it might look like at first, it's always a people problem.

  10. Excellent post!

    I think 80/20 is key. Everything else in my view can be "outsourced" to VP of Engineering or other engineering managers, but 80/20 requires a kind of unique perspective only a CTO should possess.

  11. As a CTO, you need to get inside the CEO's head. Not all CEO's have business sense. Try to first understand how much your CEO comprehends technology and architectural concepts. Blabbering on about technical mumbo jumbo won't sell the CEO either. You need to be prepared how to paint stories. For example, how are you going to explain that component drive architecture like .NET isn't going to work for cross platform open open source business models? I've seen cases where a CEO thinks they know tech. However, they insisted on using a platform that totally contradicted their business model.

  12. As a CTO and co-founder of a few startups, I have always found myself being the leader of the technology side of the business. Often times being even level with my other technical staff working directly with everyone under me to make sure that the technology side of our business runs smoothly and efficiently. Several times I had to spend weekends debugging code, or reschedule meetings so that I could help a programmer solve a problem with code, or I'd find myself at the Datacenter helping the system administrators put equipment on the racks. Why do I do this? Because the CTO has a responsibility to make sure the Vision of the company is realized and that the employees know that he cares as much about the company and its future as they do.

    I've always had to do the regular C level staff meetings, board meetings and public relations stuff, but I always focused on making sure that Corporate Ambition never interfered with developing a solid product that fits with the vision that the company had at its start.

    In other words.. a CTO to me is a Leader, Manager, Colleague and Technologist all in one, and I think if you don't do at least 3 of those at once, you aren't doing your job correctly.