Startup CEOs: you are overestimating your tech talent
I know that there are dark days and uncertainty within a startup, and that you do have to "fake it until you make it", but there's a real danger in drinking that kool-aid and missing out on the fact that everything reverts to the mean, and not everyone can even be "above average", let alone the smartest people in the world. The reality is that your startup that's survived to series A likely has pretty decent tech talent, but it's unlikely that they're significantly better than the tech talent at other startups that have survived similarly.
In particular, it is a big mistake to assume that your tech team is going to be able to solve problems that were really hard for other tech teams, unless you're willing to make solving those problems one of your core competencies (and the other tech teams were not willing to do so).
As a tech co-founder, I am extremely appreciative of the support that I get from my CEO, but I would never want her to (nor does she) assume that I will be able to solve problems that other talented teams have failed to solve for way less money and/or in way less time and/or with way less organizational focus than they have.
So if you're a tech CEO who believes that your CTO and tech teams are far superior to everyone else out there, I would say: the confidence is good, and probably necessary, but you have to make sure that you spend some of your time sober enough to acknowledge reality.
129 comments
[ 4.2 ms ] story [ 202 ms ] threadYou don't necessarily have to claim that you are better than all other startups, you just have to claim to have a tech team that is magnitudes better than average teams at other companies.
It is crazy to me how many failed projects are floating out there. And once you are tasked with trying create a solution that requires coordinating with another tech team from another company, you will realize just how badass your team really is, and how many terrible tech teams are out there eating as if they create value.
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).
Maybe these CEOs bragging about their rockstars is not so unreasonable when compared against the nation as a whole.
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.
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 :-)
- 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.
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.
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.
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.
I am under no illusions of my superiority; I am a developer at an investment bank.
The best engineers I know are usually quite humble. They don't lose their sense of wonder and are always hungry. Everything they see is shit, including work they've done. They have a relentless drive to improve.
Hell, look at Walmart's tech team: https://github.com/walmartlabs
There isn't necessarily a correlation between intelligence or talent, and the industry or company you work in.
When I work on EE or mechanical projects the physical elements involved have the opposite effect and create a negative feedback loop and (perhaps) lead to more deliberate development and more realistic views of the relative difficulty of the development effort. Anyone who has studied controls knows that negative feedback is generally what is wanted to reach the point you're aiming for.
I don't think there are that many truly talented teams out there even though you get impression every other hip startup has one.
1) Throwing engineers at something without asking the engineers
a) Twitter b) Spotify c) Soundcloud
Tweetie.app Lorens vs current twitter application.
2) Not allowing remote work.
3) Shitty domain knowledge that isn't worth crap.
Where can I learn to be so incompetent!?
Startups I see here are usually looking for the same kinds of people to help build their products (Rails, iOS, UI/UX, etc.).
They look to really only hire people who are really good at things like this to build their product. Are these people the best people to have around later? Once your company has bigger problems than just getting something out the door are these people a hinderance?
I don't want to sound like these people are not smart but being REALLY good at one thing generally means you are lacking in other domains (only so many hours in the day right?)
I ask because I'm honestly curious. I'm not involved in the startup world at all but this was always a question I had when reading job postings here.
People who are equally mediocre at everything are worthless. People who are savvy and hustle at everything are worth their weight in gold. But it's hard to sell that.
No-one appreciates a bad generalist, but a good generalist, who can pick up any piece of code or system you happen to have lying around or need to work with (e.g. can use tcpdump to debug a problem connecting to a client's server, or write a useful shell script, or do some C# coding for an integrated version of your Ruby app) is worth their weight in bitcoins.
I've seen plenty of such job postings, though typically for big boring companies; not startups.
I haven't seen that. Usually I see the whole "my tech team are all the best awesomest rock ninjas" tripe from the CEO, and entirely because it is an extension of their personal arrogance and massive ego. You talk to the CEO and they have the best tech team in the world solving impossible problems nobody else can do, and you talk to that tech team and they are like "We're making a website, there's nothing special about it". The CEO believes the quality of their tech team reflects their ability as a CEO, thus they must have the best team since they are the greatest CEO.
A sidenote you can ignore but I just need to vent: these massive ego CEOs then insist on making their tech team do this: http://theoatmeal.com/comics/design_hell because they "know people", so they know what people want.
When dealing with externals, winning isn't important. It's the appearance that you're winning, and having the CEO brag about tech talent is just part of the game.
Just like when CEO's brag about having former MSFT, GOOG, FB, engineers on staff, or having someone who went to MIT, Caltech, and yada yada yada.
In the end, what really matters is building a great product that helps your customers scratch an itch.
But that team is not enough for being successful and you are overestimating it if you think it's enough. Marketing and Selling capabilities are the other side of the coin.
Is text chat hard? No. Facebook? Nope. Video Chat? Yes that is a bit harder, but still relatively solved. Social _____? Probably not. Any casual video game? No. Salesforce.com? Nope. Zoho? No. Airbnb? Nope. Dropbox? Nope.
The more interesting things are the google self driving car, machine learning and the occulus rift to a point. But those things are few and far between.
This is what happens when a company hires genuinely exceptional people to do easy but non-trivial work:
http://www.quora.com/Working-at-Google-1/Whats-the-worst-par...
Do you know about Facebook's architecture? I'll give you a hint which was brought to my attention a couple weeks. PHP is sitting on their front end, but trust me it is NOT doing any heavy lifting...
Lately I feel much more like "everything has its place" and I'm not so invested in hack hype. Java I'm seeing is a great language because it's kindof nestled between C++ and the web scripting/framework world. Lots of possibility for unique, almost C++ desktop-software-level but many strong frameworks and libraries for the web as well. And there are a lot of JVM languages that tie neatly together, so there is kindof a well-knit multi-lingual toolkit that is slightly less daunting than working with alien PHP-to-C++ RPCs (though this may be all psychological).
Defined 'frontend' in that context? Also, are you referring to the HipHop compiled PHP as the 'backend', or are there some fancy Go/Erlang/Lisp/whatever tricks acting as MQ layers, shuttling data around that I'm not aware of?
https://developers.facebook.com/blog/post/2010/02/02/hiphop-...
I WAS referring to PHP as frontend, but based on the article it seems like there may be a lot more HipHop PHP than I suspected, because they mention that it would be too niche to write a ton of C++ code. However, there is this line which I think clarifies somewhat -- "HipHop allows us to write the logic that does the final page assembly in PHP and iterate it quickly while relying on custom back-end services in C++, Erlang, Java, or Python to service the News Feed, search, Chat, and other core parts of the site."
It seems like even though PHP is compiled & heavily utilized, it is still used mostly for page assembly on top of a Service-Oriented Architecture, with services written in C++, Erlang, Java, & Python.
That said, I must point out that the scaling issues all of these super modern "change the world" companies, such as Twitter and Facebook, have are purely for the purpose of centralizing power. It's a self-inflicted headache. It's great business to be in control of millions of users. But it's a sad state of affairs for the internet in general. We've gone from open, decentralized, and peer-to-peer protocols to one company controlling everything.
There are interesting scaling problems. But Facebook isn't one of them.
No, you could duplicate a narrow piece of Dropbox's functionality in a day. You could not even get anywhere near duplicating the product and the service in anything less than months.
Polishing any product takes time. But that's universal and has nothing to do with engineering. What exactly is non-trivial about Dropbox?
1. Version control.
2. LAN sync.
3. Dropbox probably also does a lot to try and minimize their S3 costs - so probably a good deal of compression/duplication-detection on the backend.
4. Any and all networking issues. Even if using OSS gets you 98% of the way, Dropbox probably gets you 100% of the way.
5. Performance. I don't know what Dropbox is doing, but about a year ago I tested out Google Drive, SkyDrive, Dropbox, and SugarSync. I didn't want to use Dropbox because it gives you the least free storage, but Dropbox was consistently 2x faster than the competition (without using LAN sync). That makes a huge difference so I switched to it, and if Dropbox engineers are beating out Google and Microsoft engineers, they're clearly doing something special.
In all seriousness, from a highly abstracted view, Dropbox isn't all that complicated. However, the same things are said about numerous other projects. I remember when Stack Overflow took off, and everyone around here said "I could build Stack Overflow in a weekend".
It turns out that, yes, you can build Stack Overflow in a weekend. However, all you've managed to build is a basic Q&A site. What you've missed is practically everything that makes Stack Overflow work. The rep count probably doesn't work as well, the moderator controls aren't there, the OpenID integration isn't there, the markdown controls aren't as sophisticated, it's slower, etc.
I don't have a link to it, but not long ago there was a repost of the original "Show HN" for Dropbox, where there were similar criticisms of how "trivial" Dropbox is to implement. The devil is in the details.
It seems to me that successful business is not just about having the smartest solution, but having the right solution at the right time... and having a thousand other things fall in to place perfectly as well.
Previously I completed a master's thesis on audio signal processing / machine learning. Trust me, the work I was doing in that world was 1000x more advanced because it was essentially ALL r&d, but you get paid more in today's world to implement CRUD sites at an acceptable flow rate. It's a good way to sharpen some CS skills I was missing, but I think algorithmic development is much more of a dream job.
If you'd said that the challenges facing most start-ups don't involve solving a particularly interesting technical challenge on day one, I'd agree that this was likely.
However, if most start-up level stuff more generally were solved, everyone would be running successful start-ups, which clearly most people aren't.
"Necessity is the mother of invention" but what is the mother of a start-up....? There are few who understand this realistically.
The talent is there but where is the business plan? It's not very often you hear a start-up idea that rattles you. If I heard one I'd hop on board just for some stake in the company. Also founder/managers are a pain... I imagine it must suck to be the engineer-slave of an ivy leaguer who is going out to another bar for a fund-raising meeting that will affect your future salary working on their hair-brained idea.
What kind of people make this money?
> A year into his new job he had a job offer from UBS, the Swiss bank, and a promise to bump up his salary to $400,000 a year. Serge didn’t particularly want to leave Goldman Sachs just to go and work at another big Wall Street firm, and so when Goldman offered to match the offer, he stayed.
http://www.vanityfair.com/business/2013/09/michael-lewis-gol...
But yeah, realistically only a few programmers in the world are probably pulling down the kind of salary.
You could live in a nice, cheap country with a good standard of living instead, and spend a tenth of what you make while living very well with your family. People keep wanting more money and what do they do? Get a car. Get a house. Get a second car. Bigger house. Big whoop.
Few people spend their money on experiences, or enjoying their life, because they work too much to have any free time, just so they can go back to their stately home, which becomes "eh, my house" after a month anyway.
My "recipe for success" is "make enough money so you won't have to think about it, make sure you have many good friends, and try to make others happy from time to time". Most people don't even seem to know what makes them happy, really.
Want to write good secure texting application that works on all major desktop and mobile OSes and make it fully open source? You could do that if you were financially independent. You could also hire people to do so if you wanted to.
Also real estate is expensive in NYC/SF where you would get these kinds of wages.
Another is that the CEO says nothing about the engineering team itself at all, and it's all product, product, product. On that path lies Apple, and I have heard many say (myself included) that we would not work somewhere where engineers are rarely seen and never heard. Although, obviously some smart people do.
And when CEOs give praise to the teams, they get flack like this.
So I mean, what do you want them to say? This is hacker culture; don't whine, submit a patch. If you think they are better ideas, go work at DilbertCorp, or for Apple. Or, if you think there is some other path, describe for us what it is. Or better yet, go start a company that behaves that way.
But the way I see it, CEOs like this are just following principles that we ourselves have asked for: we want to be taken seriously, we want to make decisions, we want to sit at the executive table, we want to be perceived as an integral role that uniquely contributes to the success of the venture. Saying "our tech team is really great" is a direct consequence of those principles.
"Our true strength is our team. They're the best and most talented group of programmers/butchers/bakers/candlestick makers ever assembled by mankind."
There's really no downside for the CEO to saying this. If he doesn't say those things it seems like he's trying to steal all the credit.
Over praising your tech talents, saying nothing about them or saying something that isn't particularly good in nature are just all extremes.
It's really not a two side of a single coin, either this or that.. No, it's more of a spectrum.
Humility has never demoted a person nor has it affected their odds of succeeding in their endeavor. I think the real issue at hand here is the line of thoughts that "My company just got itself a VC round, I must be the BEST".
Well, maybe they are good, maybe they are even really good. But by all means with 7 billion humans on this planet, I'm pretty sure someone else is better out there.
But how about "Our team is competent?" "Our team are subject specialists." "Our team are pretty good." ?
...
And then I find myself wondering, how much domain knowledge do you need to identify a hard problem. Are founders just bad at estimating difficulty?
The toplevel post is a warning to not drink your own kool-aid when making executive decisions about what your team can and should accomplish; e.g. your team may be extremely smart and talented, but so are the teams of everyone else, therefore don't think your team will be able to accomplish miracles.
Pretty sound advice.
We figured since we're so small and unknown at this point, it would make sense to wear the partner badge high on our chest...but your msg makes complete sense.
In case the website didn't make it clear, we provide course creation tools so any educator can create or curate a textbook replacement.
As long as you don't believe your own hype, I think its okay.
The CEO is supposed to be inspiring leader and a good teamworker, if he praises the CTO as a genius he is perceived as both, with the plus that, if he is a good salesman, the investors believe that the CTO is a genius. So there it is, the startup dream team, a inspiring leader and a tech genius, the next Jobs+Woz.
And the best performances are usually of those who actually believe in it, so no surprise that after a few years successfully saying that, they start to believe in it.
The quality is something very important when your company is made by two developers. When you go up from this, you have lots of interactions and complexity.
You have love, hatred, you have admiration and envies, you have people that need money or need time to see their family. You have people that is afraid of their own mediocrity that try to protect their knowledge or "own" part of the company(fiefdoms).
You have people in some areas fight against others(marketing or sales vs it), you have different personality types that don't understand each other.
If you get all this right, life becomes easier and you have time for writing in HN, or kissing your kids, because it is a fantastic machine that works alone, and yes your tech people will kick ass.
Get this wrong, and most people do it not wrong, terribly wrong, and life is hell(I know because as a geek I did terribly wrong in the past).
If the best engineer does not sleep, you have a sh*t engineer(Chernobyl).
what is right - focus on technical excellence and product fit or are you meaning trust and honesty levels in the company?
"Unless you're willing to solve hard problems, don't try solving hard problems"?
For a limited subdomain (data anlytics, content distribution, Internet routing), I think it can be true that startups that are focusing on those areas are started by, or attract, world experts in those areas. Not because their brains are bigger than the random startup geek but because they have experienced frustrations in the space, have seen the history and evolution, and wake up thinking about solving problems in a particular space.
Also, the comparable. An environment where people can protoype, implement, test on customers, and then flesh it out will be > 10 x cheaper and 10 x faster than a 9-5 environment where you have 10 engineering and ops groups to convince and add headcount to to do anything, and often non-technical product managers in the way who need to be educated and can block or at least massively slow down GSD.
1) Find some benchmark, and reset internal expectations if they're wrong. Replace the technical talent if they're not great.
2) Claim that they're the best, and set high expectations.
My belief is that once you've chosen your team, you're better off going with #2. This isn't to say putting your head in the sand is good, but setting a high bar can be better than second guessing folks in an area you're not knowledgable about.
Perhaps it's ok to make a good judgment over time, but I think there's a lot to be gained from saying, "You're the top team, I believe you can do it." If over time they struggle to make the grade, then you have to recalibrate.
This is very tough, because studies have shown that most people of all fields do believe they are better than average.
Much more on this phenomenon here -> http://www.cbsnews.com/8301-205_162-57568186/
Thank you for starting this discussion.
I'll add a question though... "What makes you think you know your boss's job enough to judge their performance?" This isn't aimed at you, but people in general. As a manager of managers, I've seen people 2 levels below think that their failing manager was outstanding. The reality is they didn't see the things that were important in that manager's job. (This goes for the CEO valuing the CTO)
Understanding other people's performance is very difficult.
I've worked in four startups in the valley and while each team had a large number of really smart engineers, all but my current one had some real lackluster ones as well. Maybe it just takes time to figure out who those folks are. I've been here less than a year.
This company has extremely high hiring standards and will turn away viable candidates who fail to impress. We spend a ton of time in recruiting, but I'd like to think the result is worth it.
Reminds me of a talk about 10x engineers I watched recently:
http://www.youtube.com/watch?v=bGkVM1B5NuI
That was from the Eng VP at joyent.
Since then, I've had a really bad experience working with one or more joyent engineers who were anything but 10x. More like x/10.
I wonder if that's a good explanation to give a VC - "Our guys are pretty decent, but it's not the quality of developer you are investing in. Our idea does not require rocket science right now."
Exactly what highly technical problem is Evernote, Airbnb, Snapchat, or Twitter, or Facebook solving?
I mean really deep technical problem like the news feed absolutely will not work with out some sort of huge breakthrough in AI, not that deep learning is 5% better than an SVM. Look at how well something simple like the points*timedecay system than HN uses for ranking works.
Fuck, even Google was a 20 year old algorithm.
We're building CRUD apps on what 20 years ago were $75 million dollar computers, not putting men on the moon with pocket calculators.
Whether they solve new technical problems in the context of computer science is irrelevant to needing a great tech team to properly execute something like the aforementioned companies.
eg. Hire the guy that can optimize queries rather than the guy making PAXOS algorithms.
That's what I mean by great, and to be clear about startup I mean Facebook, et al, when they were at the stage of only having raised $5 mm, not Facebook post-IPO.
But it seems as though, solving how to scale a CRUD app is a problem whose solutions are still being discovered.
Evernote is far from a CRUD app, while the challenges of scale at Twitter were noticeable very early on. Facebook also had to overcome some serious scalability issues, though they were able to push those out to later in their growth.
AirBnb and SnapChat, you are probably correct about.
The thing about being a great brilliant tech team, to me, doesn't necessarily all come down to being the smartest technologists in the room. It's about being the best team for the chosen product. Developers who understand what they are building and why can influence and make good decisions for the long-term of the company, where others who may be smarter developers might not be able to see the long-term implications of some of their design decisions.
Now, we're maybe not talking cutting edge computer science research here, but I'm skeptical that the average programmer could put the same thing together in reasonable time. The algorithms involved are fairly complex and who knows what they had to discover on their own to achieve the desired results?
How hard is it going to be for the "average programmer" to a) read a fucking research paper. b) optimize based on aforesaid paper to "achieve the desired results.". After all, every company in the bay who is anyone asks you enough C.S. fundamental questions.
* HHVM (open source) - A PHP runtime and JIT compiler (http://www.hhvm.com/blog/)
* Presto (open source) - A distributed SQL query engine working on hundreds of petabytes of data (https://www.facebook.com/notes/facebook-engineering/presto-i...)
* Running graph algorithms on a graph with a trillion edges (https://www.facebook.com/notes/facebook-engineering/scaling-...)
* Open Compute (open source) - Custom designed data centers down to the motherboard (http://opencompute.org/)
In the same way that Google Reader, Google Wave, Google Base and dozens of other products were essential to continued success of Google for a while (before they were discontinued), just because they were developed at Google?
The nature of Facebook (or Twitter, LinkedIn, Snapchat) is a simple CRUD application that many people are capable of writing. The additional complexity is mostly due to the size of their user base.