tech_nofounder

Thank you. This attitude helps.

  It's pretty rare to see that kind of effort be paid
  back my a cuckoo maneuver like this. You owe your
  job to this guy, have some decency.

I appreciate yours as good generic advice. Like a few other posters, you're (understandably) viewing this as a lone cowboy jockeying to replace an otherwise well-qualified and conscientious leader, with the limited and somewhat filtered information I've given.

But we are being vastly too charitable to our imaginary subject. He's already been functionally banished by the team, and rarely comes in to the office. So the question is more about how to deal with an already-acknowledged lame duck, and its effect on the team, given my pay grade.

I didn't intend to follow up further because I've gotten what I needed here (thanks again!). But I wanted to try to restore some of your faith in the world that there is one less cowboy out there. I hope seeing that I'm anonymously seeking advice and not doing something brash is also some sign of that..

I appreciate your rant (and someone else said, I sound like an "alpha male" jockeying for position - that's a first in my career, but I guess I'm grateful for the disguise!)

I think it's difficult to defend what's gotten me to even consider this question - after months of looking for better solutions - without getting too detailed.

  Without this co-founder the company was literally NOTHING

I just want to give this as an example -- this is not nearly the origin story of the company. I know you are picturing a classical founder and founding story and, well, it's different.

Thanks everyone for the advice!

I agree, "punt to QA" is a cop-out I resist and detest during hiring.

I really appreciate this frank advice.

I think your discussion of business risks has best reflected the reality upon me: because he is a cofounder, he can't just be simply fired.

(Incidentally my original title was "[How] would you fire..", i.e., I have doubt about the very question.)

  The focus on programming chops underpinning your argument 
  and clawing at a little pie instead of making the pie bigger 
  suggest a narrowness of view that seems to be missing the 
  bigger picture.

Well, I'm bringing a binary/myopic-seeming view of the problem to HN, when in reality it's far from my biggest day-to-day concern. All of my time is spent "growing the pie" and even working to cultivate this engineer.

  It's an experience worth learning from.

Indeed..

  If they are learning and developing, why can't you
  treat them as a very junior developer, help them
  develop their skills, and eventually they will
  become a useful asset to your team.

This has been my attitude so far, and my original title (before being edited) had "[How]" in brackets: I'm not at all sure what to do. But the alternative strategy, the optimistic, mentorship one you outline, hasn't been working.

  They must have skills of some kind if they got the
  product to a point where they could raise money
  and hire others in the first place?

It's absolutely true, and I would never advocate anything but generous treatment of the employee. But not meeting today's expectations (not just mine, the whole team's) also matters.

  As for the equity issue, even if they do get fired,
  that doesn't mean their equity is up for grabs to
  award to new engineers. So it probably won't solve
  your issue their.

Very true, and as others have stated legal matters around termination can make this very complicated.

I bring it up more to worry about simmering resentment from e.g. peers. I'm happy with my compensation, but I worry what an impression of "early, ineffective dead weight" can have on newer recruits. It's something I've seen earlier in my career.

Thanks for the advice.

  tl;dr: I don't think you can make that decision

You're right, it's definitely not my call; but I feel that I owe it to my team (and future team) to make the case to the CEO to do something more than just "oh, find him a desk in the basement".

Imagine how I talk to prospective hires: "yes, he's the engineering co-founder -- but we just let him do QA work while the rest of us call the shots". In the valley there's some expectation that the co-founders are, well, in charge, and keeping someone around like that in a limited capacity seems.. unusual.

  Just curious why do you want him fired over,
  as the CEO suggests, finding a less critical
  role for him? 

It's a great question, and one reason I'm grateful for the comments (thanks!) is that maybe I shouldn't be looking at it in this way.

  Is your reasoning solely based on salary/equity
  the guy has?

It's one of two: 1, yes, I feel we could be using the same massive comp to reward or hire people who are actually high performing. But 2, equally if not more important, co-founder or not I worry about the cultural weakness we get in to by just "burying" or ignoring a low performer.

  Honestly, it sounds more like you're jealous of
  his compensation relative to yours

I know it's hard to sound convincing, but trust me, I'm not: I am well-compensated (and negotiated for such), perhaps even more than he (don't want to get too detailed here).

Where I am upset about compensation is that we've hired an engineer getting orders of magnitude less equity and performing orders of magnitude better work. Even if I can't change comp, I worry about how the "good guy" must feel & how to retain him if I just continue to "shrug off" the cofounder problem.

  Respectfully, you sound like a fresh Alpha Male
  who's found a new pride, topped the old Alpha,
  and now you're looking to push him out entirely
  to cement your dominance.

I can see that it comes off that way. But the reality is, everyone seems to know this guy isn't hacking it, and I could tell almost immediately -- yet decided to do nothing for over half a year. For exactly that reason: I didn't want to risk the appearance of being an ego/power-maniac. But I'm now debating the wisdom of "just ignore it".

It's things that are borderline embarrassing (real example: not knowing what ssh is) in addition to just poor coding habits (breaking every style rule in the book), no systems instincts, and so on. Plainly, I don't think the CEO knew how to vet this guy.