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.

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.

A VP Eng is responsible for providing a human API to engineering the CEO can understand. Its all about creating predicability out of uncertainty, and if the CEO doesn't feel predicability coming out of engineering, that puts his job on the line.

Some CEO's just get it, some need Gnatt charts and resource allocations on slides, some just need to to speak with confidence and act like an alpha male, etc. In short, if you can figure out how he communicates, then you're likely to get along. If not, it's unlikely you're going to make a great API/interface - and that's ok. Better to let someone else take on the role than to be frustrated.

Although I hate to advocate this, having a CTO role is a nice way to vest for another 6-12months, relax a bit and start looking for new opportunities.

Help them find a good VP, if you like the person then maybe they can help run interference with the CEO and let you focus on the things you like. If you don't like the new VP, then it's really time to move on to a new company.

Spot on.

However... if the original poster feels up to it, he might decide for fight rather than flight.

I'm not a confrontational guy, but I like to get my point across when I think it matters.

Assuming the original poster has a significant share of the company, even if he retires it is very worthwhile (for the good of the company) to convince the CEO of a few points that are essential to the well-being of the company:

1) Recognising technical talent is very hard. This CEO is no doubt able to recognise management talent (or lack thereof) but that doesn't mean he will be able to pick a VP of Engineering who actually has technical ability. The VPofE position needs strong technical ability to be able to interface effectively with the dev team (no developer will have any respect for a technically weak VPofE and they'll play him like a fiddle), and so he should be recruited by both the CEO and CTO together.

2) If the original poster doesn't enjoy the whole politics game, he should be happy to step aside out of the political line of fire. However, the VPofE (particularly as a new hire) still needs to be held accountable to someone technically qualified. The CEO ain't it. Management meetings involving the CEO and VPofE should involve both the CEO and the CTO, with the CTO there to ensure that the VPofE is not exploiting the technical inability of the CEO.

3) There's nothing especially wrong with the CTO stepping out of day to day development. However, that's a different job than being part of the dev team. So what should the CTO do? Well, there's plenty to do, I presume, in terms of driving the strategic direction of the company and ensuring the technology part of the company functions well with the non-technology part (which apparently is not the case at the moment). I think it would be a very effective shift for the poster to start focusing on "the real problem": "the front office's lack of vision and an inability to communicate clearly whatever vision they might have". That can largely be done by walking around and talking to people.

Freed from operational and dev duties, I think one of the CTO's primary respponsibility becomes to close that gap - and then any other "high-level" gaps that exist.

In short:

* Let the VPofE deal with development and managing the dev team.

* Hold him accountable in joint meetings with the CEO

* Focus on fixing the larger problems between the company's tech and non-tech silos

Of course, this requires building a stronger relationship with the CEO. However, this need not be such a tall task once the development responsibilities are delegated away, since those appear to be a big point of friction. Also, I imagine the CEO will respect this kind of reaction (much more than "Really? Then I quit! cries", anyway).

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

". 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!

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.

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.

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?

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