Want to Know the Difference Between a CTO and a VP Engineering?

Posted on Apr 19, 2010 | 250 comments


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 somebodyinside 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 SpringHibernate 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 testssystem 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)

  • http://www.socialannex.com Al

    There are several inherent issues in most startups though that prevent the structure you describe above.
    a) If the startup was started by a non-tech founder (who then hires a CTO) – that founder generally does not understand and does not want to deal with technology and hence ends up having the VP eng. report to the CTO. This happens much more than you would like – and does happen in a lot of well funded startups as well. When I worked for my first startup, that was what happened. As you can imagine, the classic problem of a CTO not being able to manage, now having a VP eng. under him.

    b) If there is a CTO founder as part of the founding team, often the problem is reliquishing control. As you can imagine, people feel a certain power by having other people reporting to them and CTO's generally do not want to reliquish that control to the VP engineering especially if they are founders. That causes the classic internal battle of ownership.

    c) The last classic problem I've seen is the task of hiring a VP engineering where the CTO plays a big role. He often hires for the things he lacks, which most often is the process/people orientation. So the VO eng. ends up being more closer to the “program manager” quadrant in your diagram i.e. lacks the technical expertise.

    All of the above issues cause the startup to go haywire from a technology leadership perspective unless corrected and I have personally experienced that.

  • kamadoll

    Really liked your article – being an ex entrepreneur/CTO and now a VC, it touched a lot of chords with me. Personally I think of myself as the CTO in the startup gene-pool so was lucky to find a good VP Engineering to team up with. We scaled up to do sales, marketing and program management in the early years.

    Further, instead of program management I have always favored a product marketing and product management team which like CTO/VP-Engg require different skill sets.

  • kamadoll

    Really liked your article – being an ex entrepreneur/CTO and now a VC, it touched a lot of chords with me. Personally I think of myself as the CTO in the startup gene-pool so was lucky to find a good VP Engineering to team up with. We scaled up to do sales, marketing and program management in the early years.

    Further, instead of program management I have always favored a product marketing and product management team which like CTO/VP-Engg require different skill sets.

  • http://twitter.com/williampietri William Pietri

    For me this depends on the product. I've worked with some incredibly good product managers who aren't particularly technical. What they are good at is understanding the needs of the business and the users, and in working with the developers to figure out the best way to realize their vision.

    For a technical product, naturally, I'd want the product manager to be technical: you can't make something great if you don't understand the domain. But for consumer products, I'd rather that they understand consumer behavior and the medium we're working in (e.g., web, desktop).

    It might also depend on the process used. I work in highly iterative, highly collaborative environments, where product managers spend the bulk of their time no more than a few yards from the devs. With slower releases or more distance, I could see how a product manager with technical experience would be more useful.

  • http://giffconstable.com giffc

    First time I haven't been nodding my head in complete agreement with a Suster post. I can only speak anecdotally from working at a handful of venture-backed startups, but our CTO's were never the cliche of the artiste coder/hacker. They were brilliant technologists (with coding productivity worth 10 normal devs) and led the charge on technical vision and solving the gnarliest technical challenges (I dislike “CTO's” that are all vision, no coding), but they were all well-spoken and great evangelists with customers. They understood both technical issues and the business issues. Brilliant developers who couldn't cover those bases stayed “lead/senior developer”.

    Whether one calls your startup's technical leader “CTO” or “Chief Architect” doesn't really make a difference to me — I think the title just needs to be strong enough that they can talk to prospects/partners without people wondering who else might be more important.

    I do agree that the VP of Dev is all about process, and it's not a hire you need with few developers. You need people who just roll up their sleeves and get stuff done. At an early stage, process can be managed by your CTO/Chief Architect, or by one of the other coders, or even an ex-coder product manager if you have one.

  • http://giffconstable.com giffc

    First time I haven't been nodding my head in complete agreement with a Suster post. I can only speak anecdotally from working at a handful of venture-backed startups, but our CTO's were never the cliche of the artiste coder/hacker. They were brilliant technologists (with coding productivity worth 10 normal devs) and led the charge on technical vision and solving the gnarliest technical challenges (I dislike “CTO's” that are all vision, no coding), but they were all well-spoken and great evangelists with customers. They understood both technical issues and the business issues. Brilliant developers who couldn't cover those bases stayed “lead/senior developer”.

    Whether one calls your startup's technical leader “CTO” or “Chief Architect” doesn't really make a difference to me — I think the title just needs to be strong enough that they can talk to prospects/partners without people wondering who else might be more important.

    I do agree that the VP of Dev is all about process, and it's not a hire you need with few developers. You need people who just roll up their sleeves and get stuff done. At an early stage, process can be managed by your CTO/Chief Architect, or by one of the other coders, or even an ex-coder product manager if you have one.

  • http://asable.com/ Giang Biscan

    Thanks, Mark and William. The discussion is very helpful for me.

    Btw, Mark, it seems Business Insider posted your article WITH all (?)/most of the comments. Are you using some tool to sync the comments on both posts or did BI just post whatever that was here at the time?

  • http://twitter.com/ravikannan Ravi Kannan

    Spot on! I agree with you and strongly feel outsourcing your startup product development just does not work. You need to have The tech person in house who can show technology leadership and all the attributes you mentioned. I personally was involved in a startup, joined them as CTO after they got their funding from a top VC firm, who had outsourced their complete product development right from day one. Needless to say the product could not really scale, had a tough time making the non-tech founders understand the issues and what was needed to get it fixed. Eventually the company could not scale and folded down.

    Having the The tech person inside is very very important especially if you are building a tech product.

  • http://twitter.com/ravikannan Ravi Kannan

    Spot on! I agree with you and strongly feel outsourcing your startup product development just does not work. You need to have The tech person in house who can show technology leadership and all the attributes you mentioned. I personally was involved in a startup, joined them as CTO after they got their funding from a top VC firm, who had outsourced their complete product development right from day one. Needless to say the product could not really scale, had a tough time making the non-tech founders understand the issues and what was needed to get it fixed. Eventually the company could not scale and folded down.

    Having the The tech person inside is very very important especially if you are building a tech product.

  • Greg Smith

    I don't think outsourcing is bad, I think you just need to know what to outsource. This is a great article about the roles of the techie higher ups. Outsourcing brings your costs down but if you're requirements aren't black and white, then I agree outsourcing doesn't work.

    My rule is not to let outsourcing companies make decisions for themselves in the beginning. But you're CTO and other leaders should be quarterbacking every aspect. It's all kind of subjective though depending on the capacity of the outsourcing team and how good they are.

    fyi. I was a manager of tech recruiting before becoming the nontech owner of a software consulting company. This is great dialogue and would love to speak with you about both sides as I see the pros and cons of both.

  • philsugar

    Why outsourcing doesn't work:

    1. The requirements for a software company are never in black and white.
    2. The ability to have somebody to hear direct feedback in person from both sales and support is priceless.
    3. The ability to have somebody tell you that no, you're wrong, there is a flaw in your reasoning versus yes boss, I'll code that right away boss is just as priceless.
    4. Frankly you as small company are going to self select into the bottom quintile of programmers. Think somebody in India for example is going to want to work for Microsoft, GE, Intel, Huge Investment Bank, or you??
    5. Cost savings in which I do not believe….but I'll take on anyway…..as the company matures development will be 20% of costs or less. Assuming, and again I totally disagree, that you can shave a bit off that…is saving a percent or two overall worth not having a core team?? The sales needle is much more important.

  • philsugar

    Why outsourcing doesn't work:

    1. The requirements for a software company are never in black and white.
    2. The ability to have somebody to hear direct feedback in person from both sales and support is priceless.
    3. The ability to have somebody tell you that no, you're wrong, there is a flaw in your reasoning versus yes boss, I'll code that right away boss is just as priceless.
    4. Frankly you as small company are going to self select into the bottom quintile of programmers. Think somebody in India for example is going to want to work for Microsoft, GE, Intel, Huge Investment Bank, or you??
    5. Cost savings in which I do not believe….but I'll take on anyway…..as the company matures development will be 20% of costs or less. Assuming, and again I totally disagree, that you can shave a bit off that…is saving a percent or two overall worth not having a core team?? The sales needle is much more important.

  • Brett

    Agree completely, William. There are too many startups out there that have a great technical team, a CEO with a great vision but with no good product leadership. If the product is B2B/technical, of course you need a highly technical PM, but for B2C you need a technically knowledgeable PM, but not necessarily one who used to be an engineer.

    I ran into a guy in San Diego who was on his way to the Bay Area to pitch to investors about his Biotech/Mobile idea. His opinion, I quote, is that product managers are just MBA's that don't add value. I cringed multiple times about his answers to questions such as what is your addressable market (the answer, “everyone”).

  • http://bothsidesofthetable.com msuster

    Hey Well. I hope I didn't imply that the CTO/ Lead Architect was unimportant. Quite the opposite. I would hire the chief architect well before the VPE. My point is EXACTLY yours. Too many non-technical founders think this is one role, titled either VPE or CTO. My point is that both are different and both are hugely important.

  • http://bothsidesofthetable.com msuster

    Hey Well. I hope I didn't imply that the CTO/ Lead Architect was unimportant. Quite the opposite. I would hire the chief architect well before the VPE. My point is EXACTLY yours. Too many non-technical founders think this is one role, titled either VPE or CTO. My point is that both are different and both are hugely important.

  • http://bothsidesofthetable.com msuster

    Doesn't everybody! The true definition of an artist. Image how book publishers or music labels must feel! Or the owners / managers of professional sports teams. I think these analogies hold well.

  • http://bothsidesofthetable.com msuster

    Doesn't everybody! The true definition of an artist. Image how book publishers or music labels must feel! Or the owners / managers of professional sports teams. I think these analogies hold well.

  • http://bothsidesofthetable.com msuster

    It's a big topic – I'll pick it up more fully in a future post. Sorry.

  • http://bothsidesofthetable.com msuster

    It's a big topic – I'll pick it up more fully in a future post. Sorry.

  • http://bothsidesofthetable.com msuster

    Thank you. I would like recruiters and n0n-tech managers to read it. It's a source of major confusion.

  • http://bothsidesofthetable.com msuster

    Thank you. I would like recruiters and n0n-tech managers to read it. It's a source of major confusion.

  • http://bothsidesofthetable.com msuster

    absolutely. and you make my point that both of them are actually technical. but one is tech visionary and the other is tech delivery. those are different things and people. but, yes, in the early days wrapped in one.

  • http://bothsidesofthetable.com msuster

    absolutely. and you make my point that both of them are actually technical. but one is tech visionary and the other is tech delivery. those are different things and people. but, yes, in the early days wrapped in one.

  • http://bothsidesofthetable.com msuster

    Totally agree, Al. It's why I like teams where the CEO is at a minimum a great product guy with technical experience and I like teams where there is an emphasis on engineering talent more than biz dev talent in the early days.

  • http://bothsidesofthetable.com msuster

    Totally agree, Al. It's why I like teams where the CEO is at a minimum a great product guy with technical experience and I like teams where there is an emphasis on engineering talent more than biz dev talent in the early days.

  • http://bothsidesofthetable.com msuster

    Yeah, I like strong prod mgmt and prod mktg teams – a future post since these are often confused, too. sometimes having just a “planner” that coordinates across the company can be worthwhile as you grow. the Prod mgmt and prod mktg people are usually not interested in this internal only role.

  • http://bothsidesofthetable.com msuster

    Yeah, I like strong prod mgmt and prod mktg teams – a future post since these are often confused, too. sometimes having just a “planner” that coordinates across the company can be worthwhile as you grow. the Prod mgmt and prod mktg people are usually not interested in this internal only role.

  • http://bothsidesofthetable.com msuster

    well, giff, count yourself as lucky then. I find that more often than not the deeply technical person isn't perfect in most customer situations and often doesn't want to do it. also, having them do a lot of customer meetings can be a drain on their productive time. It's true that there is no “one size fits all” but I wanted non-tech founders to have a distinction in their minds between the deeply technical leader and the technical leader who is a process jock.

  • http://bothsidesofthetable.com msuster

    well, giff, count yourself as lucky then. I find that more often than not the deeply technical person isn't perfect in most customer situations and often doesn't want to do it. also, having them do a lot of customer meetings can be a drain on their productive time. It's true that there is no “one size fits all” but I wanted non-tech founders to have a distinction in their minds between the deeply technical leader and the technical leader who is a process jock.

  • http://bothsidesofthetable.com msuster

    Thank you, you've written my post for me! Seriously, these are the reasons.
    - water cooler matters
    - customer proximity matters
    - team productivity / learning in one place
    - requirements evolve too fast
    - etc.

  • http://bothsidesofthetable.com msuster

    Thank you, you've written my post for me! Seriously, these are the reasons.
    - water cooler matters
    - customer proximity matters
    - team productivity / learning in one place
    - requirements evolve too fast
    - etc.

  • John Scabadone

    Check out http://www.codility.com. I’ve been using it as a first pass test of engineers.

  • Laurent Boncenne

    Great post again Mark ! Thank you !
    One thing I'm not sure I understand perfectly is the work expected from both positions…
    The way I understand your post and how I understand the difference between the two is that a CTO is the one who would be heads down into the documentation of any new technology (or say framework or language, if you were a web technology startup), and break it down for the VP of Engineering to process it for the devs. He would be the one who would try out said technology to see how it can work/apply/scale with the project in development.
    The VP of Engineering would however study how he would apply that new tech to his team of devs to come up with a piece of code. (My understanding again)

    Then again, the CTO and the VP of Engineering would work both at the same level with the CEO (or product guy with the vision of the product who just happen to be the founder of this startup) to streamline every process needed to get the job done.

    For instance, If we take Koral (your last company if I recall correctly), you were the CEO and the CTO would analyze what sort of technology would be best to handle the users problems (file sharing, version control, multi-user, centralized company dashboard, etc.). He would be the one to test if php could handle the job of delivering such data or if python would be more appropriate.
    Then he would meet with the VPE to put things into action, ensuring what is expected is handled the right way before any code is written.
    According to my understanding, the VPE would break down this vision tied with one technology to assign it to dev teams to get the job done.
    Do I get the whole issue right ?

    I've been recently talking with two friends about a project I have (software development) where both have coding skills but one is more on the heavy coding side and the other one seems to try to get away from coding, and I wonder if a team of founders like that could work. Like, one business guy who connects to the dev guy through another (in my mind, to illustrate : CEO to CTO to VPE would be how it would work, the CTO would translate and refine and double check the expectations of the CEO).

    Is there anything I don't get right ?

  • Laurent Boncenne

    Great post again Mark ! Thank you !
    One thing I'm not sure I understand perfectly is the work expected from both positions…
    The way I understand your post and how I understand the difference between the two is that a CTO is the one who would be heads down into the documentation of any new technology (or say framework or language, if you were a web technology startup), and break it down for the VP of Engineering to process it for the devs. He would be the one who would try out said technology to see how it can work/apply/scale with the project in development.
    The VP of Engineering would however study how he would apply that new tech to his team of devs to come up with a piece of code. (My understanding again)

    Then again, the CTO and the VP of Engineering would work both at the same level with the CEO (or product guy with the vision of the product who just happen to be the founder of this startup) to streamline every process needed to get the job done.

    For instance, If we take Koral (your last company if I recall correctly), you were the CEO and the CTO would analyze what sort of technology would be best to handle the users problems (file sharing, version control, multi-user, centralized company dashboard, etc.). He would be the one to test if php could handle the job of delivering such data or if python would be more appropriate.
    Then he would meet with the VPE to put things into action, ensuring what is expected is handled the right way before any code is written.
    According to my understanding, the VPE would break down this vision tied with one technology to assign it to dev teams to get the job done.
    Do I get the whole issue right ?

    I've been recently talking with two friends about a project I have (software development) where both have coding skills but one is more on the heavy coding side and the other one seems to try to get away from coding, and I wonder if a team of founders like that could work. Like, one business guy who connects to the dev guy through another (in my mind, to illustrate : CEO to CTO to VPE would be how it would work, the CTO would translate and refine and double check the expectations of the CEO).

    Is there anything I don't get right ?

  • ramakrishna tumuluri (aka rk)

    Excellent post. The picture captures it all.

    To take it to the next stage, I would add “concentric circles”. The larger, outer circles would have more “roles” such as “R&D chief”, “QA”, “Support” and other dedicated functions. Would be usefull if you map it out to include “sales”, “marketing”, “biz-dev” and other vital functions needed for successfull ventures.

    /rk

  • ramakrishna tumuluri (aka rk)

    Excellent post. The picture captures it all.

    To take it to the next stage, I would add “concentric circles”. The larger, outer circles would have more “roles” such as “R&D chief”, “QA”, “Support” and other dedicated functions. Would be usefull if you map it out to include “sales”, “marketing”, “biz-dev” and other vital functions needed for successfull ventures.

    /rk

  • http://coshrink.com Nancy Raulston

    This is great! I have had this conversation with so many technical founders who think somehow that the VP Engineering role is “more important” than the CTO role — or vice versa — and so are hell-bent on taking the role they are least suited for. I immediately sent this off to several of my clients in the throes of these kinds of decisions. (It has such credibility coming from an entrepreneur and VC)

  • http://coshrink.com Nancy Raulston

    This is great! I have had this conversation with so many technical founders who think somehow that the VP Engineering role is “more important” than the CTO role — or vice versa — and so are hell-bent on taking the role they are least suited for. I immediately sent this off to several of my clients in the throes of these kinds of decisions. (It has such credibility coming from an entrepreneur and VC)

  • http://dancroak.com Croaky

    Great, thanks.

  • http://dancroak.com Croaky

    Great, thanks.

  • http://caterpillarcowboy.com dlifson

    When I was at Amazon.com, we had a role called Technical Product / Program Manager (they watered down the role to Program Manager in 2008 because it was so difficult to find TPPMs). A TPPM is someone with the technical skills to be hired as an entry-level developer, the product vision to define new features / roadmaps, and the people + process skills to manage the design, creation, launch, and maintenance of features on the site. (I was the TPPM for the Personalized Recommendations team, which does “Because you bought this book, Amazon recommends…”)

    I think it's a key skillset that needs to exist within a young startup. I've seen some startups founded by an MBA + CTO pair and the lack of strong product skills is obvious.

    WRT CTO vs. VPE, I agree with you generally. I like to think of CTO as Chief Architect + Technology Evangelist. Someone who is up on the latest technologies and is thinking about their application at a theoretical level, then can go out and present it at a conference and via white paper.

  • http://caterpillarcowboy.com dlifson

    When I was at Amazon.com, we had a role called Technical Product / Program Manager (they watered down the role to Program Manager in 2008 because it was so difficult to find TPPMs). A TPPM is someone with the technical skills to be hired as an entry-level developer, the product vision to define new features / roadmaps, and the people + process skills to manage the design, creation, launch, and maintenance of features on the site. (I was the TPPM for the Personalized Recommendations team, which does “Because you bought this book, Amazon recommends…”)

    I think it's a key skillset that needs to exist within a young startup. I've seen some startups founded by an MBA + CTO pair and the lack of strong product skills is obvious.

    WRT CTO vs. VPE, I agree with you generally. I like to think of CTO as Chief Architect + Technology Evangelist. Someone who is up on the latest technologies and is thinking about their application at a theoretical level, then can go out and present it at a conference and via white paper.

  • http://technbiz.blogspot.com paramendra

    Great post. Found a link to it in the AVC.com comments section.

  • http://technbiz.blogspot.com paramendra

    Great post. Found a link to it in the AVC.com comments section.

  • http://twitter.com/dayski Kapil Bharati

    Thanks for sharing your thoughts Mark! I am myself in the early days of a start-up and often get confused of what title should I use Dir Technology (or VPE) or a CTO – As of now I see myself shuffling between the two roles, there are times when I go deep into silos and there are times when I have to look around and make sure my team is sailing with me.

    My thoughts …

    I feel VPE is a path to a good CTO / Chief Arch, esp for start-ups. The Chief Arch needs to set the technical direction and the one taking decisions: should it be MS Exchange vs Google App, Rackspace vs EC2, Python vs Ruby vs PHP etc. Its like defining the boundaries within which the VPE can play / act. All such decisions have a large impact on the team skills (esp tech), productivity, cost etc – Chief Arch does not need to worry about tracking to the plan but should be able to help VPE deliver on time – by identifying solutions – alternative ways to solve a problem, short term hack vs long term fix, performance / scalability hit vs functionality etc. As a VPE one is learning and being groomed to handle multiple issues – always in the thick of things – from people, scope, customer, tech etc but not necessarily taking decisions outside the defined boundaries or identifying which features to be built. VPE will often need to be pulled out of the weeds and I feel this is one of the critical roles of a Program Manager (in addition to what you mentioned).

    Program Manager is someone who co-ordinates, manages and prioritizes scope – this person has a good view of what features need to be built, by when and why and in a way should be asking the VPE to build ABC features in XYZ time. The Chief Arch needs to be step in on how the VPE intends to “build” those features …

  • http://twitter.com/dayski Kapil Bharati

    Thanks for sharing your thoughts Mark! I am myself in the early days of a start-up and often get confused of what title should I use Dir Technology (or VPE) or a CTO – As of now I see myself shuffling between the two roles, there are times when I go deep into silos and there are times when I have to look around and make sure my team is sailing with me.

    My thoughts …

    I feel VPE is a path to a good CTO / Chief Arch, esp for start-ups. The Chief Arch needs to set the technical direction and the one taking decisions: should it be MS Exchange vs Google App, Rackspace vs EC2, Python vs Ruby vs PHP etc. Its like defining the boundaries within which the VPE can play / act. All such decisions have a large impact on the team skills (esp tech), productivity, cost etc – Chief Arch does not need to worry about tracking to the plan but should be able to help VPE deliver on time – by identifying solutions – alternative ways to solve a problem, short term hack vs long term fix, performance / scalability hit vs functionality etc. As a VPE one is learning and being groomed to handle multiple issues – always in the thick of things – from people, scope, customer, tech etc but not necessarily taking decisions outside the defined boundaries or identifying which features to be built. VPE will often need to be pulled out of the weeds and I feel this is one of the critical roles of a Program Manager (in addition to what you mentioned).

    Program Manager is someone who co-ordinates, manages and prioritizes scope – this person has a good view of what features need to be built, by when and why and in a way should be asking the VPE to build ABC features in XYZ time. The Chief Arch needs to be step in on how the VPE intends to “build” those features …

  • robertsnell

    Nice article Mark. I'd quite agree with you, having seen great tech leaders work well in a startup. Part of the trick is finding someone with a passion for the job, team and product. Someone who clearly ticks all the technical boxes and has proven themselves. And someone who might even be slightly obsessive about getting it done right, whilst remaining pragmatic and not being too much of a “code snob” to the extent that it affects product deadlines. I've also seen at least one case where a decent technical team was put to task on developing a product without a super strong tech lead. The product owner wasn't entirely comfortable that they were doing the right thing. So the PO asked a trusted expert from outside the startup to cast an eye over what's going on and give constructive feedback, which worked quite well.

  • robertsnell

    Nice article Mark. I'd quite agree with you, having seen great tech leaders work well in a startup. Part of the trick is finding someone with a passion for the job, team and product. Someone who clearly ticks all the technical boxes and has proven themselves. And someone who might even be slightly obsessive about getting it done right, whilst remaining pragmatic and not being too much of a “code snob” to the extent that it affects product deadlines. I've also seen at least one case where a decent technical team was put to task on developing a product without a super strong tech lead. The product owner wasn't entirely comfortable that they were doing the right thing. So the PO asked a trusted expert from outside the startup to cast an eye over what's going on and give constructive feedback, which worked quite well.

  • http://twitter.com/juney Juney Ham

    Mark,

    I basically agree with you here in the sense that there are two completely different (critical, depending on the size/maturity of your startup) roles you describe that people tend to confuse and blend, program manager notwithstanding.

    One question though. It is my understanding that the CTO is the most senior member of the technology team. Doesn't it stand to reason it could be the Chief Architect OR the VP of Engineering? If I could draw a simple diagram, it would basically be the CTO at the top, and depending on which role the CTO is (VP of Engineering or Chief Architect), the other would solid-line slot right underneath him/her along with the rest of the organization (e.g., developers).

    I'm guessing I might just be pointing out semantics, but just wanted to share my thoughts.

  • http://twitter.com/juney Juney Ham

    Mark,

    I basically agree with you here in the sense that there are two completely different (critical, depending on the size/maturity of your startup) roles you describe that people tend to confuse and blend, program manager notwithstanding.

    One question though. It is my understanding that the CTO is the most senior member of the technology team. Doesn't it stand to reason it could be the Chief Architect OR the VP of Engineering? If I could draw a diagram (in Balsamiq? Heh, have you tried using it yet?), it would basically be the CTO, and depending on which role the CTO is (VP of Engineering or Chief Architect), the other would slot right underneath him/her.

    I'm guessing I might just be pointing out semantics, but just wanted to share my thoughts.