"I don't know. If you have a team that is able to consistently ship products that work and are well received by your existing client base, you probably do have some badass tech guys."

From my experience, a good manager can ship with bad enginners but good engineers cannot ship with a bad manager. This is from the perspective from an engineer.

We engineers need to stop kidding ourselves. We are good at certain problems but getting something out the door and running a company requires much more than what we are expected to be good at. This is why blogs like PG's and Joel Spolsky have such a following. They explain difficult concepts to engineers in a way engineers will understand. Not everything they write about are revelations to the whole world but they are to many engineers. Human-centric design? Other industries have done it for decades, etc. We need to know our own limitations if we want to go beyond them or make the conscious decision to not get better at it and let someone else handle it.

Good engineers can ship with a bad manager, but it basically requires one of the engineers "managing up" and taking on the role of manager without pissing off his actual manager. That's a delicate balance to strike, but there are some folks (usually experienced engineers who have been around the block a few times, or folks who have previously held manager/executive positions but "downshifted" because they really like to code) that can pull it off.

That sound like my situation where my team leader is not very experienced (or good in my opinion). As such I often refuse to do things the way he suggests. "Just do it like this". When the word "just" is part of the phrase, it means that he probably hasn't thought it out very thoroughly.

When I've seen this done effectively, the engineer never outright refuses to do things the way their manager says. Instead, they take responsibility for educating their manager, in a way that the manager can understand and without threatening their ego. So if the manager says "Just do it like this", your response should be "That won't work because X, Y, and Z. However, I could do it like this, and it will have these costs and benefits and take me this long, and that's why I believe this is a superior course of action." At all points the decision is still up to the manager, but the senior engineer has brought enough data and experience to bear that they can convince their manager that it was a good idea to begin with.

I am all too familiar with only being good at certain things. My zombie startup almost failed before we had a chance to breathe. I was a developer driving around Houston, beating on doors to sell my product. And of the 30 organizations I approached, it did not result in one single meeting. I suck, so severely suck, at sales and anything to do with communicating with non technical people.

But about going beyond my own limitations, rather than trying to be all things, we just brought on some new partners to handle the marketing/sales, and things are finally starting to look up.

In my experience tech and market success aren't nearly as related as your post suggests. As a 40 year old developer I've worked at a good number of companies (including startups and established ones) over the years including some that were, on average, technically very weak and yet very financially successful and some that were technically extremely strong and failed miserably.

All the tech talent in the world won't help if you are building something nobody wants, and if you are building something many people want you can get away with iffy technology, at least for a while (see: the first years of twitter).

I'm 100 percent on board with your last sentence. But I didn't mean to imply that all you need is a good tech team to be successful. I was simply making an argument that maybe the OP is undervaluing his own / his tech team's technical abilities because he is comparing himself to an elite subset of devs/engineers.

Maybe these CEOs bragging about their rockstars is not so unreasonable when compared against the nation as a whole.

Yep. If technical merit was all the mattered, we would all be using Xerox or Symbolics computers today. Those were some really smart guys. But you can't sell things no one can afford or needs.

I don't think that the mediocrity of other tech organizations implies that functioning ones are "badass". It's a sad state of the world that "actually shipping products that work" qualifies for awesome/genius.

Writing software is hard. To quote Douglas Crockford "Writing software is the hardest thing you can do."

So if as a team you are able to, manage client expectations, deliver on schedule, build a project that works to specifications, has good UI/UX, has a low user learning curve, meets performance requirements (obamacare site), is well received by users, I'd say your team is pretty great.

I know a lot more people who write software well than can guard Lebron James well.

Then how about choosing a higher threshold than writing software well? How many programmers do you know who are above John Carmack's level, for example?

How much of the failure is related to process or project management vs. the tech teams's skills?

Bingo! I have seen the smartest engineers (Princeton PhD in one case) rot in bad environments and mediocre engineers provide solid contributions in strong, engineering focused environments. I have rarely come across an engineer that doesn't want to build great products. If you want to suck the energy and enthusiasm out of team, add in weekly 120min planning meetings, required daily progress reports, and 4-5 product pivots.

I wouldn't be able to make a definitive judgement on that. But what I can say is that at my previous place of employment, we had a number of projects that never saw the light of day because the other organization couldn't meet their milestones. We were in direct contact with their dev team.

Oh, for sure - worked in capital markets and getting any integration between the different teams was an unpleasant affair. However, it usually wasn't due to a lack of talent, but due to politics or personality - somebody who likes to say "no" a bunch, or refuses to allow some other approach. Most of the devs were grumpy, but liked the steady pay and stuck around. Probably the root of the problem - if retention became an issue, perhaps things would change?

But what made you think the primary reason for their failures is the lack of good engineers?

I can't speak for management, but our team would inform their team on what was broken, and it would not get resolved in a timely fashion.

We would get contacted by the client to resolve an issue on our end, and after some debugging we would consistently discover it was broken because of the other company. They couldn't produce code that worked.

This could have been a management problem. For example maybe they simply did not care enough about the project to allocate the necessary dev resources. But it also could have been resolved on the dev side if they did a better job of testing their code that they claimed was complete.

Edit: I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech.

"I guess the most direct answer would be, since it was a problem that I could have resolved with tech, I didn't see a reason why they couldn't resolve it with tech."

That really captures how engineers think. I think I often think the same way but my gut feeling is that there might be a fallacy in that way of thinking. I can't think of it right now but your statement does give me a bit to think about. I'm not saying you're wrong. In fact, I think the same way and that worries me :-)

There can be a lot more that's going on than just they are bad programmers:

- They are solving a fundamentally hard problem: it's a problem that at first glance looks easy, but turns out to be really really hard (for example: http://en.wikipedia.org/wiki/Travelling_salesman_problem)

- They are under-resourced and/or over-committed: they know how to fix your problem, they just don't have time to do it.

- Your not paying them enough to make it worth fixing: similar to the above, but in this case you simply don't represent enough revenue to make the doing the fix cost effective. Especially if it's a problem only you have.

- They have architecture constraints that make it hard to fix the problem: a bad/simple/incorrect design may make fixing the problem very hard

- They have legacy code which was poorly written or simply coded very fast and is now brittle and difficult to fix.

- They have internal political problems which are preventing them from fixing the problem.

I'm sure there are more that others here on HN have seen.

The worse case I saw of this was with a contractor who underestimated how hard the problem was, under-resourced the project and the resources that where on the project where not very good engineers. That project crashed and burned so hard there were lawsuits.