Ask HN: CTO vs. VP of Engineering • Hacker News Board

Re: Ask HN: CTO vs. VP of Engineering

#21

Post by known » Tue, Mar 10, 2009, 3:02 PM UTC

Traditionally, CTO is responsible for eliciting business requirements, designing and developing technical solution and coordinating project activities.

VPE is responsible for deployment, technical support, bug fixing and coordinating marketing activities.

Re: Ask HN: CTO vs. VP of Engineering

#22

Post by psranga » Tue, Mar 10, 2009, 4:59 PM UTC

You're being marginalized. But I'm not sure if you're capable of being VPE but are being passed over because the CEO wants to bring in a buddy or because you are genuinely extremely unsuited for the job.

If you don't want to be marginalized, fight to get the VPE position. If you're going to get fired or further marginalized for fighting, you might as well learn now so that you'll win next time. If you get VPE, learn the skills required to be a great VPE and prove him wrong. Ask point blank for the position and find out why the CEO thinks you're unsuitable for VPE.

For some reason suits think management is not learnable/teachable. You sound smart; it's quite possible you'll be able to learn the required skills.

IMHO, people who think management is about "people skills" and "politics" are the clueless ones. Read up "High Output Management" by Andy Grove, a hard-core geek if ever there was one. He turned out to be an amazing manager too. Bill Gates, even harder-core nerd also turned out be an amazing manager.

To my mind, management is more similar to programming than to party planning (where people skills are really required). The manager's job is to set up systems and processes which will result in maximum output. To do this, you need to be analytical, quantitative, data-driven, open to being proven wrong etc. Do you see how you've been practicing all of these skills as a techie? Do the same for a proper manager's job skills and you'll see the overlap.

As an aside, I think all managers should have some individual responsibility also. Otherwise they will be tempted to create problems that can be 'solved' to justify their existence.

Re: "politics is not your strong suit" comments: you're expect things to work rationally but they seem to be irrational. Being techie who's always open to the possibility that you might be wrong, you're getting a second opinion to check your conclusions. Nothing wrong with that; that's a strength.

Re: Ask HN: CTO vs. VP of Engineering

#23

Post by cpierret » Tue, Mar 10, 2009, 11:19 PM UTC

New CEO probably thinks that the engineering team is a mess and someone has to fix it. Stop implementing Nagios yourself (and any non business critical issues), and ask the CEO for some freelance to do the job instead. If he argues that he has no money for that, run away fast (he has money to hire a VP Eng...). If he agrees, then start building a trust relationship with him quickly. Tech tasks usually can wait, where your CEO cannot (yes computers are nicer than CEO, but CEO signs your paycheck) Focus on customer needs and your colleagues' need: how can you help sales/presales and marketing do their job ? Ask them what they need to succeed and give them the product they need. If you cannot because you don't have the resources, be clear about it and have them decide which tradeoff with you (or have the CEO allocate more resources). Become accountable: Learn to say "No" to mission impossible and avoid saying "No" when you could if you had more resources, just say "I could if ..." and have them participate in the tradeoff decisions. Write things down once the decision is made and email it after the meetings. If you think that this is too late for that, or that the sales/marketing guys have no clue (or are trying to cover), quit... and start again elsewhere.

Re: Ask HN: CTO vs. VP of Engineering

#24

Post by ooorrr » Wed, Mar 11, 2009, 3:10 AM UTC

I'm the guy on the other side of the table: I'm the VP of Engineering who gets brought in. The circumstances are always the same - the CEO/COO/BoD doesn't believe that the CTO is the person they can trust to build great software and great processes. (This may or may not be true, and the company may or may not be doing that already - I've seen both. This is subjective even if you know what you're talking about.)

A few simple notes, and please know I don't wish to be insulting, just clear:

--This person is absolutely going to report to the CEO. The CEO is the person making the decision, and if he trusted you to build and run the organization, he would have had you hire the VPE. (On a related note, you missed an opportunity to fill a hole for the company that the CEO recognized.)

CEOs (and any leader of a large, multi-fxnal organization) want their direct reports to be the people they can trust to get something done. You aren't that guy - the CEO doesn't want to go through you to find out how the engineering org is working, or he would have kept you in charge - so the VPE isn't going to work for you. Done.

--The CTO/VPE peer relationship is perfectly reasonable. Sometimes it's a hierarchy, sometimes it's not. Usually when it's a hierarchy, it's because the CTO also runs other groups (like ops, tech support, etc.), and so is known by the CEO etc. to be a capable manager. You are not.

So when I read your note, I can't tell if

1) you're upset because you want to keep doing the VPE job, but you aren't going to get the opportunity; 2) you're happy doing the CTO/Chief Architect job, but are frustrated/saddened by how it was handled.

You really do need to make this call. If it's #1, sorry - best you can do here is help hire a great VPE and leech on to learn from her. (Lot to be said for that.)

If it's #2, the good part is that if the VPE is the right kind of egg, this can be very good for you:

1) Many VPEs do this job because they don't want to be the Chief Architect. Some have the capability, some did once, some just don't, but you rarely have someone competing for your job or responsibility.

2) You get to wipe your hands of everything besides making sure the company technically designs great software. As a company grows, that's a huge bonus. You have to genuinely _want_ to do this job when things get ugly or when negotiations get tricky.

3) Your time with the CEO almost certainly diminishes, but that's ok, because you get to work with the people who matter more to you.

I like what I do, and when I find a great CTO, that's awesome - it means that I can help on architecture occasionally, but really I get to focus on the problems I'm there to solve, knowing that many eyes are keeping us out of architectural trouble. So, make a friend (and if you're in Seattle, I'm always available).