I recently did a post for startups on understanding sales people.
A few people have asked me to try and define the perfect startup organization chart. I don’t believe that one exists. Every team configuration is different. But I do have more insight into understanding your startup team. This time I thought I’d try and address engineering talent. Often I’m asked by startup CEO’s about how to best build an engineering team. I have much experience in this domain.
Because more technology people probably read startup blogs I’m guessing this post will come under more scrutiny. The terms “CTO” and “VP Engineering” have such stigmas associated with what they are that I’m sure some people will feel uncomfortable with the definitions I’ve put forward. Still, I believe I’m offering an accurate representation of the ideal configuration of the main technology leaders.
This post is designed mostly for non-technical founders. I hope many will read this and have an answer for the question, “what’s the different between a CTO and a VP of Engineering?”
Let’s start with the basics. What makes a great tech team?
1. The CTO / Lead Architect - If you want to build a great technology company, you’ll need a “rockstar” engineering lead. Every great tech startup needs one. Whenever I meet a team that had a consulting firm (even a great one) build their product it’s an immediate “pass” from me. If you don’t have somebody
inside your organization who is setting the technology direction then I’m convinced you’ll never head for greatness. I know this will fall like a lead balloon to the many people who believe it is possible to have a [insert: startup incubator or technology accelerator or technology consultant or outsource firm] build your technology. I don’t believe it. Either your core is innately technical or it’s not. It’s what makes Google Google and Facebook Facebook.
So I believe that every great technology startup has the technology visionary inside the company. This is the person who lays the foundation of what should be built. They’re up to date on the latest platform decisions whether it’s understanding Spring, Hibernate and Lucene. Or whether it’s a big data set problem and they’re familiar with Cassandra or Hadoop. Or whether it’s a choice between using MySQL vs. Postgres. They’ll have a view on whether Ruby on Rails is worth the hassle. Some CTO’s swear that it is a huge improvement in development timeframes and doesn’t cause performance issues. Others think you should never build anything highly scalable on Ruby. I’ve heard both arguments from CTO’s.
Trying to work without this person is like wanting to build a world class sky scraper but not having a great lead architect and civil engineer. They provide the vision for your infrastructure.
But the problem that many inexperienced startup CEO’s make is confusing these people for the people who lead the technology team. Most often they are not. Your deepest thinkers on technology architecture are seldom good team leaders. They often aren’t great at planning development work. The best technologists often aren’t amazing people managers. Sometimes they are introverts.
In fact, it my experience the best technologists are akin to artists. They’re highly creative. They’re sometimes moody. They work on their own schedule and are often hard to manage. They may work strange hours such as 2am – noon. They don’t love documentation. They often don’t love testing. Of course I’m generalizing. But barely. The characteristics are so prevalent. These people are your purists. Your Howard Roarks.
So what is the difference between a “chief architect” and a “CTO”? Simple. Experience. A “chief architect” is a young version of a “CTO.” It’s your hedge. A chief architect still has a lofty title but they still need to prove themselves in order to become CTO’s. You still have some leeway to hire above them if need be.
The best CTO’s / Chief Architects are purists. They care about the quality of what is build more than they care about end customers. They should be setting the standards for how code is developed. Let them be perfectionists – this will serve you well.
2. VP Engineering – In my view it is important to distinguish the difference between the CTO and the “VP Engineering.” Because these titles are so often used I’m sure that some people will have hardened views about what they mean that are different than mine. But for non-technical founders let me offer you a definition that you can use when you build a team. The VP of Engineering is the person who still has great technical chops but prefers not to be a coding monkey (that term is meant in the most endearing of ways).
The VP Engineering aspires to manage teams. They feel comfortable with C++ but also have a black-belt in Excel. They are sticklers about managing unit tests, system tests and regression tests. In fact, they are passionate about automating testing overall. They know how to estimate work units, how to manage the agile development process and how to get the most out of their teams. VP’s of Engineering are essential to making sure the trains run on time. The VP of Engineering is also your primary interface to your head of product management and often the VP of Engineering is somebody you would drag in front of clients to win big deals.
And first and foremost a VP of Engineering is a people manager. They still have the respect of their team because they’re technical by training. But they’re that rare breed that also understand the human element. They know how to motivate their people. They understand the different character types and which prefer carrot vs. stick. They know how to get people to hit deadlines. They know when it’s OK to push hard for the team to hit a deadline even if it means yet another all-nighter or weekend. And they know when to tell YOU to get stuffed because the team has reached maximum stress / effort. A great VP of Engineering manages as well up as they do down.
So if I were a pure startup with 5 people I’d want a Chief Architect. As the company and therefore the team size grew I’d want a VP of Engineering. For me the inflection point is usually when you have 5+ developers. CTO’s max out at about 3. Remember, “management” is often a hassle for CTO’s, not a sign that you respect them by giving them people who report to them.
3. Program Manager – This title almost sounds like a consultant’s job. It is not somebody that I would have on a small startup team. However, it is one of the more critical roles as you scale your organization. As you head into the phase where you’ve had real customers paying real money for a period of time you’ll have a whole new set of issues. Examples:
- every time you release new features you need to update your technical documentation
- you also need to update your marketing documents including your website
- somebody needs to be sure that customer service is alerted to the new features and are trained in how to handle these functions with customers
- new features need to be rolled into PR strategies and competitor analyses
- new features need to go into the sale people’s slides so that they know the latest and greatest about how to differentiate from the competition.
Many startups have never faced these challenges because they haven’t hit scale. Trust me, as you grow these issues become “gating items” to winning large customers and keeping them happy. My company never became Google but at $14 million in recurring revenue and $36 million in backlog revenue we certainly had enough big clients to necessitate a very solid program management function.
In summary. If you’re starting a company make sure you have your chief architect. If you’ve outsourced this to a firm that has guaranteed that they know how to launch you more quickly I’d tell you that’s like trying to launch a movie but outsourcing the script to a focus group. People will tell you it will work, it won’t. Don’t take the easy road. I’d rather delay by 3 months and have the right DNA inside the gate. As you have a 5-10 person startup you don’t need a lot of technology process management. As the CEO you can personally help manage deadlines and the Agile process. So no need immediately for the VP of Engineering.
But as you company grows to 10-20 people you’ll want to consider adding “technology management” skills, which means a VP of Engineering. In my view each of the CTO and VP Engineering should report directly to you and you should remain very hands on vs. “trusting them to make the right decisions.” As you cross the $5 million mark and have lots of customers don’t forget to add the program management function. Coordinating new product releases into the entire fabric of your company will become vital.
OK. Post done. Engineering teams – feel free to attack! (or add your 2 cents)
