CTO vs VP Engineering

I have been thinking how to answer the question raised in my prior blog post on technical debt -- the tradeoff between development speed/cost today vs development speed/cost tomorrow.  In particular, what is the right organizational answer to that question.

I soon realized that this is just one example of a fundamental business organizational challenge:  It is generally difficult (but not impossible) for one person to deliver both short term and long term results.  As a result, we typically see:

	Short term	Long term
GTM	VP Sales	VP BD
Product	VP Eng	CTO

This framework helps divide the roles of the VP Engineering and CTO, as shown below:

	Short Term (VP Eng)	Long Term (CTO)
Goal	Deliver Product (Execution)	Right Technical Vision/Roadmap
Internal Priorities	New Releases People Management Program Management	Architecture New Technologies/Roadmap Security
External Priorities	Minimal time	Evangelize Ecosystem
Skills	Manager (plan/schedule, risk mitigation, recruit, communicate, motivate)	Technologist (Architect, strong technically) Strategic thinker Good writer

Many differentiate the two roles based on management vs technology, such as Elaine Chen, Mark Suster, and Fred Wilson.  That distinction helps clarify the different skill sets for the two roles.  I tried to differentiate them based on business goals.

In earlier stage companies, long term can be an unaffordable luxury.  There, CTO's clearly focus on the short term -- and even write code.