How to Not Crash a Startup

Thursday, April 26, 2007

Engineers like problems and businesspeople like solutions. When was the last time you heard any executive say, “let’s sit down in front of this whiteboard and try to better understand the problem at hand”? If it was recent, congratulations, you’re in a lucky minority. The truth is that the majority of executives want to hear solutions, not problems; sales, not internal struggle.

In the software industry there is a fundamental difference in the way problems are approached: [good] engineers spend the majority of their time assessing and verifying that they have correctly identified a given problem, then come up with a suitable solution; [most] businesspeople think of several solutions immediately and spend the rest of their time trying to sell one of them. This difference is so fundamental that entire organizations have risen and fallen by embracing or ignoring it. It might be interesting to see why this difference exists and how it has played out in the real world.

Who are engineers? They are those who build things based on theoretical knowledge of science; whether ships, nuclear power plants, bridges, skyscrapers or software. Given a set of constraints, a set of materials and the time necessary to solve a problem, they will draw on theoretical principles to understand, evaluate and solve a problem. Before any problem is solved the theory must be implemented, tested, verified, fixed, and re-verified in a cycle that can take anywhere from minutes to decades. Engineers build their careers on problems by repeating this cycle and ensuring, above all else, that the problem is adequately understood and can be solved by the theory being drawn upon. Implementation of solutions is certainly part of being an engineer, but it is kept conspicuously separate from the problem comprehension and verification stage. Engineers like problems.

Businesspeople — executives specifically — are taught early on that problems are bad for business and in order to be most successful a skilled executive must get past problems as quickly as possible. All of the money is made after solutions are implemented, so that’s when an executive can do his job best. In order to “execute” one must have resources, customers and partners; but not problems. It’s easy to see then why most executives react to problems with a knee-jerk avalanche of possible solutions, preferring to overcome them before the revenue flow goes negative or they get bored. Businesspeople like solutions.

Under many circumstances this difference doesn’t seem to negatively affect businesses, so why has it ruined other businesses under different circumstances? One word: speed. When the businesspeople want and need to go so fast that the engineers who should be solving their problems don’t have time to solve them, things start to break. This becomes most obvious in a startup where everything moves at an extremely fast pace and the executives’ expectations of engineering are always unreasonable. In larger organizations the processes typically move much slower which means executives have lower expectations and engineers have more (if not adequate) time to understand and solve the problems that the companies face. When things are run on “startup time” companies often end up with frustrated executives, grumpy engineers and a displeased board of investors.

We’re still talking about failures though. There obviously must be companies who make it successfully past the startup phase, engineers intact. Indeed there are, but these companies usually have a conspicuous lack of friction between the executives and the engineers. Why? There are several examples, but the most fitting will of course be Google. Google was started by two engineers with a passion for solving an existing problem in the world: searching the web. Those two engineers were able to bootstrap Google by grounding the success of the company in that engineering passion with no other leading constraints or demands. More importantly, the culture that Google established is an engineer-centric one, catering first to the problem domain rather than to executives in the solution sales domain. This crucial piece of Google’s history explains why they didn’t hire a business-type CEO for years, why they waited so long to go public, why they went public in an unorthodox and successful way, and most of the reason why they are still so incredibly successful today in the face of great competition.

Obviously Google’s model isn’t the only one that can provide success, but it is certainly understandable why so many engineers have a passion to work there and, consequently, why Google has the ability to branch out in so many directions. Their model was certainly at one extreme, with engineers as principals and everything else secondary, but their model worked and has been repeated (though with more modest success) in many other cases. Despite these, there is at least one other model that can reliably usher a company through the startup phase: when executives are humble and recognize their positions as facilitators and catalysts rather than autocrats or prophets. This model depends heavily on hiring the best talent one can find for the critical functions of the company. The future of the company is then put in the capable hands of this multi-disciplinary talent and they cooperate in a way that allows the executives to do what they do best: sell solutions.

The absolutely crucial difference in this case is the immediate and unequivocal delegation of problems from the executives outward to the talented individuals in the many disciplines required to solve the problem, including engineering. These “domain experts” are free to analyze and properly diagnose a problem before coming up with an appropriate solution, thus giving the company its best chance at coming up with a good solution that will have enough value to sell. What can we derive from this conclusion?

First, it should be obvious that executives thrive mainly through the creation of strategy and the sale of solutions, so their position is necessarily dependent upon there being some problem space in which to apply strategy and some set of solutions to sell — other disciplines in the company must solve the problems first before the executives can do the bulk of their jobs. Second, in order for this to work there must be talented and passionate domain experts at the company ready and willing to understand and solve the problems that the company faces. More important than that, though, the executives must understand this model and delegate the solution analysis and construction to the domain experts; executives providing solutions to implement is not a workable or scalable model.

Company cultures predicated on quality can be based on this model, allowing for the best performance of the entire company, including the executives. People who are most passionate and equipped to solve problems are the ones understanding them in the first place, allowing for more appropriate and refined solutions as time goes on. It is consequently much more feasible to create and sell great products and avoid the Failed Startup bucket. This model gives a startup the chance to create a successful company like Toyota, Facebook, or Apple by using the same core values and dedication to quality. Isn’t that type of success worth fighting for?

written by Brad Fults

Add your thoughts | Trackback URL

Archived at: http://h3h.net/2007/04/how-to-not-crash-a-startup/

4 responses

  1. Jed

    Re: your last question. The answer is yes.

    Well done, Brad. I admire the way you think and enjoy working with you.

  2.   Weekly Del.icio.us by Nate Ritter

    [...] h3h.net - Why Businesspeople Don’t ‘Get’ Good Software — Brad and I, and some other co-workers, were discussing this exact point. It’s well worth reading and understanding. Not understanding this point will lead to the ever-present friction between engineers and traditional business folk. [...]

  3. nate

    Confirmation of this topic and the results: Paul Graham in The Hacker’s Guide to Investors:

    If you’re a hacker, here’s a thought experiment you can run to understand why there are basically no hacker VCs: How would you like a job where you never got to make anything, but instead spent all your time listening to other people pitch (mostly terrible) projects, deciding whether to fund them, and sitting on their boards if you did? That would not be fun for most hackers. Hackers like to make things. This would be like being an administrator.

    More towards investors, but generally, these are the same types of people as “Businesspeople”.

  4. Brad Fults

    More discussion of this topic at Overcoming Bias.

  5. Comment Preview

Leave a comment

Comments are posted at the discretion of the site owner. Please try to be respectful, insightful and otherwise useful to society as a whole.

(X)HTML is allowed. You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <blockquote cite=""> <cite> <code> <dfn> <em> <kbd> <q cite=""> <samp> <strike> <strong> <sub> <sup> <var>