CTO vs. VP Engineering (another take)

Brad had a great post today on CTO vs. VP Engineering.  I can't argue what he says as I believe he hit the nail on the head.    I have seen an amazing amount of confusion over these roles out there.  Many simply see the CTO as a glorified VP of Engineering.  Others use the terms interchangeably (an east coast thing I think).

As the CTO of Raindance I would say I went through phases, and the company probably paid the price a little along the way.   

Early on I was just the software guy that got everyone to do the right thing, and work in the same direction.  Later, I was much more the VP of Engineering.  My focus was always not the let the company "get in trouble", a classic scenario I had seen a dozen times with software engineering projects.  Later, as our company became more diverse I really enjoyed touching all the many and varied technologies it took to cross the Telcom/Internet boundary.  Only in the last couple years, as we really formed a platform strategy to compete with WebEx did I feel like a real CTO – A tired CTO.

But the more interesting thing I learned on the trip was the difference between "C" level people and VP level people.  I like "C" level people that drive the vision without regard to the "how"..  A good "CTO" is firmly in the camp of the CEO.  Specifically a good CTO should envision how a technology can upset a business, and in lock step with the CEO form a complete vision of "difference".  A good CTO should know "grossly" that the technology is possible to deliver with the level of accuracy required for the success of project, but not burdened by, Are my people smart enough? Can we really do it? What if we fail? 

By contrast a VP of Engineering is the last line of defense in the world of "practicality".  In other words, the VP of Engineering should always approach a problem from the "percent likelihood we can do that" point of view.  With a key value proposition of always delivering, on time and working – always - always.  The CTO, should not live with *that* burden and should be the protagonist to the rest of technical organization.

Another way to look at it, the CXO team should all be thinking of the next way to upset the world.  The VP's and their Directors should be huddling on how to deliver the crazy ass stuff the CXO team is thinking of.  Of course, everyone wears a little of both hats, but in my mind that's the focus.

I may be way off here, but that's the way I like it.

Comments

[Brad Feld]

As a board member when you were CTO at Raindance (at least for the first five years), you covered the spectrum of activity and fall in the category of “one of the dudes who gets what a CTO should do.” This is a good add on to the post I wrote earlier today. I love the distinction between the CxO’s and the VPs.

[David Duey]

I never understood the difference between a CTO and a VP Eng until I read Brad Feld’s post and your post. Now that I understand the difference, it makes me wonder why, according to Brad, it’s more difficult to find a CTO than it is a VP Eng. It seems like the CTO’s job is bunches more fun than the VP Eng’s job. Spending time on the “vision thing” and working on wild-ass ideas seems like it’d be tons of fun (even if you do have to pacify the non-visionaries and skeptics).

[Herb]

Todd, great take on the topic. You and I have talked about org structure before, and I’m curious where you would have the VP of Eng. report? To the CEO, COO, CTO? I’m starting to think CEO is best, until the company move to “lines of business” with multiple VPs of Engineering.

[Todd Vernon]

@Herb: Well, I think it depends on the way the rest of the management team is structured. I think purely, if you have a technical business and a technical CEO it works best for the CTO to report to the CEO. However, if the CEO is more sales oriented and COO is more inward focused then the COO. I think it also depends on the needs of the business. If you are in a heavy partnering phase and CEO needs to look out the front window a little more than COO. As for where the VP Eng reports, that’s also very situational. If the CTO is not really that interested in operational things then the CEO is a much better choice.. Another good topic that I should post about is Operations vs Engineering.. I seem companies do it wrong more than right. Bottom line, companies are like snowflakes.. They are all different.

[rando]

I like what you said in this comment--the original entry made me uneasy. I don’t think org charts and titles and boxes and labels every really describe an organization or the way information flows. I suppose charts and titles are needed (not sure why now but it does seem they are). It’s more of a map than a blueprint maybe. Of course my experience is less than yours, but reminds me of a story from when I worked on an engineering project team years ago. The team was so successful that the company called in consultants to see what worked so they could replicate the success. All four of us had to spend a day and a half in the boardroom being interviewed by the consultants. We told them why we succeeded--we respected each other. We had fun. We argued, debated and laughed well together. Our team leader was great at including us in outside matters when needed and insulating us when not. He was great at listening to us, building team consensus, then managing the organization to expect what we were delivering. We had so much fun and enjoyed the challenges so much that people from other projects liked to join in our brainstorming or help us out. The consultants listened politely but wrote none of this down. Then they started asking “so would you say every team should have two mechanical engineers and two electrical engineers?”, “Was it key that the team leader had a master’s degree?”, “was it important that your offices were in the same hallway?” and so on... they wanted labels and specific things they could recommend and got really agitated when we told them none of this mattered. So I agree that there are certain key characteristics that match up with a team and roles, but not sure there is any right division or structure--I think successful leaders adapt the organization to the people and talents they have, rather than try to fit people into a static idea of how the organization ought to be.