The gist of it is illustrated in this simple diagram that Suster created:

The only important nuance that it fails to capture is that a VP of Engineering is NOT a magical creature that’s just as process oriented as a Program Manager and just as technically capable as a CTO. Her ability to straddle both domains will come at a cost of being slightly weaker on each than the pure domain expert (CTO/Program Manager).

As Suster point out, most start-ups bring on board a CTO/Chief Architect as one of their first Engineering hires, and rightfully so, since this is the more pressing need at the time. However more than a few fail to identify the point where the need for a true VP of Engineering becomes pressing, and end up over-taxing their CTOs with managerial responsibilities that they have no ability nor desire to take on.

At Opower we brought our first VP of Engineering when the Eng team was about 10-15 strong. When did you bring yours in? Is there a “magic number”?