
Ask HN: CTO vs. VP of Engineering - safetywerd
Note: I'm posting this under a different account than I normally use on HN because I want to remain anonymous.<p>For the last 2+ years I've been the CTO for a technically successful startup.  I have successfully navigated the company around some very real disasters and have built a highly dedicated tech team that has excelled at realizing the technical vision of the product; despite whatever curve balls have been thrown at us - externally or internally. In those two+ years, I've worn every hat one could wear (from IA to project management to product development to systems admin to front end development to back end development) and have worn those hats as well as I could.  We've staffed up to the point that I no longer am wearing as many hats, which I am grateful for, but still have a few key roles to fill, mostly in the project management category.<p>Several months ago, we hired a new CEO, whom I partially respect, but don't necessarily like.  As is typical, his first criticisms were aimed squarely at the tech team because the tech team is always the first to blame - despite the fact we've always done what we said we would when we said we would.  Obviously, as the only part of the company that produces tangibles, it's fairly easy to square operational issues on us.  I've fought those criticisms as well as I could, but have been unable to make him see the real problem is the front office's lack of vision and an inability to communicate clearly whatever vision they might have.  I've done the best I can given the sheer number of things I am required to do during the day, but, as anyone can correctly surmise, isn't the best I could do if I had a more singular focus.  It's really hard to context switch from installing nagios on our production servers to doing IA to doing project management; all within the span of a few hours, day after day.  It wears one down.<p>So he recommends we hire a VP of Engineering, which I agree to.  It makes sense.  Let that person run the process and let me focus on the bigger picture, architecture, product, etc.  But then I read the job description and notice the line where it says this role reports directly to the CEO.  Which means, since the entire tech staff is reporting to the VP of E, that I lose my staff.  When I bring this up with the CEO, he tells me that I should see this VPE as a peer.  Say what?  It's bad enough that I have to explain to employees that have been with the company for 2+ years they are going to have a new boss, but now that boss doesn't even report to me?<p>Am I being paranoid that I'm being marginalized for an ill-perceived picture of the tech team?  Is the CEO playing politics?  I'm at a complete loss.<p>Advice?
======
spolsky
The CEO has decided that you have technical ability but not management
ability. He doesn't want to lose your nagios-installation skills but he thinks
that an imaginary person whom he has not yet met or hired will be better than
you at leading the tech team. He's happy to let you keep the fancy CTO title
and perks so you don't lose face, or because he doesn't want a confrontation.

I would guess based on your comments and the fact that you're asking this
question that politics are not your strong suit. "Politics", b.t.w., is just
the natural state of people working together... it can be dysfunctional or
functional, but as soon as you have 3 people, you have some kind of politics.

Since politics are a major component of management, you may actually be
happier not doing management.

In situations like this the CEO is probably overestimating his ability to find
a Magical VP Technology that will magically solve all his problems (unless he
has someone in mind, a buddy from a previous company, for example). Likely he
will spend 6-9 months trying to find someone, finally hire someone imperfect
in despair, and spend the next year or two discovering that person is
incompetent, too. But now I'm really just projecting.

If you don't like the CEO it may be time to move on. Life is to short to work
with people you don't enjoy spending time with.

~~~
tonystubblebine
I definitely read the same thing as spolsky, based on your language that
you're not nailing the managing up and out parts of the VPE role, which is why
the CEO is looking for someone else.

I know a lot of people project negative intentions onto the CEO in this
situation, but it's his job to make a call about what's needed here and it
seems like his call is that you aren't up to snuff. At the VPE level, it's not
enough to be technically right, you need to be able to turn the engineering
group into a cog that runs with the other cogs that the CEO is putting in
place.

When I was in this position our board introduced me to some potential mentors
with more VPE experience. They all had one identical piece of advice: measure
everything and then use that to control the dialogue about engineering with
the board and the other managers.

That advice seemed overly political to me (especially the bit about
controlling the dialogue). I've come to two realizations about it.

One, a lot of the people who judge you have extremely strong personalities and
if you aren't presenting an equally strong opinion, then you won't be able to
have a conversation as equals. Facts are what give you backbone.

Two, when you put down an engineering process, half the value is in making
your team more efficient, and the other half is in presenting a predictable
interface to the rest of the company so that they can get their jobs done.
That outward part of your responsibility was the key realization as these
people took on more responsibility.

I don't think all is lost for you. Some people would probably project onto the
CEO that he has a personal dislike for you, but all you can really infer is
that he wants a different type of leader in the VPE position. You would show
that type of leadership if you went to him, explained the problems/risks of
finding an experienced VPE, and then laid out your plan for becoming that
person including asking for a mentor and a proposal for an engineering process
that gave him more insight into the company.

Now you might not want this role or might not have the opportunity. In that
case, life is too short. Go start your own company.

I think the situation if fascinating and wish you'd left some way to contact
you. You should definitely put together a strategy for any of the roles, VPE,
CTO, or former-employee, and get some good advice.

------
code_devil
In my company, the CTO and CEO are the co-founders. The CTO has a PHd and our
revolutionary product is pretty much his brain child implemented by the tech
staff under them. We also have a VP of Engineering that they hired. (a
Director of Eng in their previous venture). However, the VP of Eng reports to
the CEO. The CTO has his own set of staff and they basically brainstorm on new
ideas. We engineers respect all of them, but the CTO is definitely placed at a
higher pedestal because the bread & butter produect being his idea. But, the
CTO does not deal with most of the engineering staff except a few members who
are working under him for some latest ideas or our product in the R&D phase,
not released to the market yet. As an analogy, the CTO is more like a College
professor with a bunch of RA's under him :)

I am not sure what your background in your company is. Just wanted to share
what i saw in my company.

------
pg
Sounds to me like he's trying to push you aside.

------
sah
It's normal for the VP Eng to be a peer of the CTO and report directly to the
CEO. That said, you are almost certainly being marginalized. Your CEO likely
knows he needs your irreplaceable understanding of the company's technology,
but otherwise wants you out of the way.

Replacing you as manager is probably not going to work out well unless he
already has someone good in mind. CEOs rarely understand how much difficulty
they'll have identifying competent tech managers. He's in danger of finding
someone who does a great job of "managing up" and a poor job of getting things
done efficiently and correctly.

If you can't prevent the hire, making sure you hire someone competent is
probably the most significant thing you can do for the company.

~~~
sah
I should have added: if you _can_ prevent the hire, probably the most
significant thing you can do for the company is to learn how to correct the
problems, real or perceived, that have led to the desire for a new engineering
manager.

------
dennykmiu
It sounds like from what you are describing, you are more like the VP of
Engineering and less the CTO of the company. VP of Engineering should report
directly to the CEO and should be responsible for the entire engineering
staff, similar to the VP of Sales who also reports directly to the CEO and
should be responsible for the entire sales staff. If the CEO believes that he
needs a new VP of Engineering, then essentially he is telling you that he is
not happy with your performance and he needs to replace you.

------
ajju
I worked in a company where the VP of Engineering didn't report to the CTO. It
made some sense because the CTO mostly directed the 6 months into the future
vision of the company (next features, next product). This worked ok because
the CTO had a research team that reported to him and the VP of Engg had the
development team reporting to him but it was not optimal.

The issues we faced were:

\- CTO+Research team builds some amazing enhancements for the product but have
to fight to get them into the next release (Dev claimed there was no time for
regression testing..but next cycle there will be)

\- Dev team thought the research team were ivory tower elites (even though
this was not the case). There were Ph.D.s and people who never went to college
on the team.

\- Research team eventually thought they were superior (reaction to having all
their input regularly ignored by dev team)

In short, if your company has a legitimate need for a research or forward
looking team, there may be a way to make this situation work, but not without
regular political disputes and bitterness between teams. Try to find a way to
have the VP report to you.

------
marhar
At my old company we called the CTO "chief termination officer". It was
basically the de-staging area for tech people who had enough visibility that
they didn't want to get rid of them outright.

------
andrewf
I'm skipping over the issue of your CEO's motives - he could hate you and want
you out, but assuming he doesn't..

 _despite the fact we've always done what we said we would when we said we
would._

So you've got the commitment thing down: you make commitments and then stick
to them. That's a reasonable baseline for reliability, but there is a whole
world of value-add beyond it. The VPEng should be working to improve the
company's ability to deliver product - even when the problems that need
solving aren't with his direct reports.

In particular, you say the front office has problems communicating their
vision. Do you work to improve their flawed and/or vague requirements, or do
you let them hang themselves, and point to the requirements document when
they're unhappy with the end result?

Longer term, have you tried to move towards more iterative processes
(prototyping during requirements gathering, agile processes, etc) to reduce
the damage done by poor requirements?

You sound like you are happier around, and have performed better in, the
technical aspects of your job than the management aspects. Your CEO may
(grain-of-salt) have noticed this. He could even be trying to give you what he
thinks you want.

Consider that your CEO may have a management structure in mind where the
process-and-timelines guy sits between him and the development team. Maybe you
could have this job if you wanted it - but it would mean hiring a CTO to worry
about the bigger picture, architecture, product etc. Your boss probably
doesn't want to pervert the reporting structure he has in mind just so that
roles in it matches what you want to do.

------
vseloved
[http://www.feld.com/wp/archives/2007/10/cto-vs-vp-
engineerin...](http://www.feld.com/wp/archives/2007/10/cto-vs-vp-
engineering.html)

------
cpierret
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.

------
seshagiric
The new CEO is taking away your advantage of working in a startup: \- when you
were CTO, you were critical for the company. When the VP comes, you will
eventually become commodity (and expandable) \- your influence in the company
is being cut into half \- you will lose your flexibility (or agility) in
getting things done (the process guy also now has to put his say)

Talk to the founders and the new CEO. If the VP engg. makes sense have him to
report to you. If not move on like Spolsky says.

------
psranga
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.

------
danbmil99
work on your resume dude, and start going to lots of parties. Or just suck it
up and make yourself as useful and unobtrusive as possible (times be rough out
there). The CEO wants to sideline you; you're not his guy. He needs someone
malleable and loyal to him only.

Read The Prince.

------
gfodor
Two cents here. Similar situation happened to myself, except I wasn't the CTO
but the de-facto "lead architect" of a major project/death march that had all
of the stereotypical problems you read about again and again: product
mismanagement, feature creep, overzealous salesforce, and heightened
expectations reaching the impossible.

Much like yourself, I had been put in charge of an incredibly difficult
project and somehow managed to grow a solid engineering team and build the
system with them and get something out the door. 500k lines of C#, unit tests
integration tests, the whole 9 yards over two years. We had finally launched
(late and with much more baked in than accounted for) and started to tighten
up iterations and bring in customer feedback. (Yes! We really had no customers
using our system for two years during development!) I of course was under a
lot of stress as feature backlogs grew and defects lists exploded because the
software wasn't rolled out slowly and incrementally to clients but instead
sold from day zero as if it was 100% rock solid.

So, as you probably had, I had my lunch with the CEO where I was being asked
(ie told) that a new VP of Engineering position was going to be pursued to fix
all the horrible problems plaguing the software development team. The problems
which, at least from our perspective, had little to do with us since we pulled
off not one but a series of those small miracles that only happen at 4AM by
yourself in the tech room. However, taxed was I and naive, so I figured hey,
what the heck, maybe I'll be able to write code some more if this magical
hypothetical person can swoop in and take care of all that other nasty
business like "talking to the sales guys and telling them not to sell features
that don't exist."

So, we interviewed for this position fully unaware of what it was, exactly, we
were looking for. Being young engineers if a candidate came in and had managed
teams before _and_ knew what unit tests were we were thrilled. We had no idea
though what to look for, what red flags there were in hiring this person, so
the third person or so who came in to talk to us ultimately was hired since
it's hard to say no to someone who you don't even know how to judge. (And you
can't, of course, just hire the first or second candidate that walks in the
door because then you just look like you don't know what you're doing!)

So soon after this new hire we began interviewing for additional developer
positions, but all folks that came in to meet us for interviews were
developers this new VP of Engineering worked with in the past. As it turns
out, the first candidate didn't know how regular expressions worked, so I said
"no hire." The second, turned out, worked with a friend of mine some years
back and spent days on end simply reorganizing the file structure of their svn
repository, and so again, I said "no hire."

Well, they both still work there and I have long since left. Our system we
worked on for years completely thrown out for yet another re-write from
scratch, now to be done the "right way". The all stars on the team I helped
build are all gone except one who has a family to support, all moved on to do
startups or larger more innovative software companies.

A long story, yes, but I'd urge you if nothing else to consider the impact a
hire like this can have on your entire team, since they will now be the ones
making the hiring decisions. If you cannot trust them with that (and it's hard
to trust anyone with that after just a few interviews), I'd say push back as
hard as you can on this particular decision and try to, as PG says, "be
resourceful" and bootstrap solutions from folks already in the organization
you _can_ trust.

~~~
plinkplonk
". Similar situation happened to myself, except I wasn't the CTO but the de-
facto "lead architect" of a major project/death "

Ohh that brings back memories. A Senior Vice President at one of the largest
software companies in the world asked me to meet him because he was looking
for a "lead architect" for an "elite group" he was putting together. I met him
and went over what he needed in detail and it seemed like there was a good fit
(and the senior VP was a very nice person).I specifically asked him " So who
makes technical decisions? " the answer "You do of course, you are the
architect. You'll be reporting to me so just keep me in the loop". So I
accepted the offer.

By the time I joined a week later, I found that I would be reporting to a
(newly hired) "Director of Engineering" and would have a "dotted line
reporting relationship" to a "Chief Architect" (who in turn reported to a
[Company] Chief Architect. The VP Engg chap I reported to (he turned out to be
a very Dilbertian middle manager type) reported to a VP India, who reported to
a Senior VP, Emerging Markets, who reported to yet another VP who reported to
the CEO. The "Chief Architect" who I had a reporting relationship with was a
very nice person but couldn't code to save his life and always spoke in very
abstract terms like "scaling Enterprise SOA across business units".

The VP who hired me led a "product development" group totally disconnected
from what we were doing.

I found I could make hardly any decisions but had to attend plenty of meetings
about meetings. A memorable meeting was when I had to deal with the "General
manager (SCM)" to demand Licenses of the company standard proprietary Version
Control system for my team and he asked me "Do you really need Version
Control? Couldn't you just use directories? Make a directory per version and
save your code in it. We back up all the directories every day "(!!).

Long story short, I felt like I was working in Arkham Asylum but the money was
good so I stayed a few months and left with a nice bank balance and am now
back in consulting mode.

Getting back to the point, from what I've observed of company politics it
looks like the CEO has a two step plan to get rid of the Original Post-er.
First, cut away your power base by having all the dev chaps report to the new
guy and then ask " so what does he do here anyway?". He probably just wants to
keep you around for a while as "insurance" . If I were you (depending on how
much power you have with the board/founders) I would either (a) make sure I
had some real work to do as CTO (in the corporate world this often means
having people report to you )even after the VP chap were hired (b) make sure
the hire didn't happen, in practice this depends on how much clout you have in
the existing setup or (c) start making plans to leave.

The good news is that even in he case of option (c), you have some time to
make your move. If you have a sound enough financial base, you should probably
quit immediately.

My 2 cents. But ultimately only you know the finer details of your situation
that make a difference.

Good Luck man!

------
known
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.

------
acgourley
The VP need not marginalize the CTO, often he just removes tedium from the
CTO. If you get a VP Eng and modify the company org chart, and at the same
time your influence in the company dwindles, I don't believe it will be
causation.

------
jwilliams
This is a rough question - but are there areas in the tech area that you see
requiring improvement? If so, what are they? Irrespective of the political
state, do you see the CTO/VPeng setup redressing them?

------
ooorrr
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).

