Feed
Subscribe to SolipBlog using RSS: Blog Feed
Solipblog 's:
Internet Startup Success vs Failure: The Intangibles
Publish Date: Sun, Jun 1st 2008
Tags: internet start-ups, developer, hackers, technology(6)
Conflicts Even Happen Between
Everyday Pieces of Hardware
(Image Copyright © 1998 John Bell)
Is There a Problem Here?
(Not Sure What This Image Means)
On Internet Startup Best Practices

I've been lucky enough to work at several Internet startups in my career, which has allowed me to experience a wide variety of cultures, teams, technologies, and ideas.

Recently, two articles were published that discuss one of my favorite subjects: Internet startup best practices. Since I don't want to detract from the main point of this post, I'll give a very brief summary[0] of both articles:

Desipte the fact that I called them both reasonable, I also think they both failed to mention the two biggest risk factors associated with startups that determine whether the startup will fail or not. Both articles deal with material assets - desks, computers, espresso machines; and while both mention the age-old (and obvious) hire the right people, what happens immediately after hiring said people is what makes or breaks a startup, and it has absolutely nothing to do with offices, cell phone bills, espresso machines, or lunch.

What follows are the two biggest [seldom-discussed] risk factors for Internet start-ups.

Risk Factor #1: Team Integration & Avoiding Disenfranchisement

When a person, or small group of individuals, form a company, they begin to share a common dream: the dream of unlimited success for their company. One of the first things that they then do is seek to hire the right people to help the company grow.

Who are the right people? Qualities that are highly sought after are intelligence, motivation, work ethic, and passion (the more of each the better). Finding these people is like finding gold, because they're quite rare. Once you've found someone with those skills, and you think they'll care as much about your dream as you do, they're an automatic hire, as finding people who truly care about your company is the most difficult task of all.

(Paul Graham aptly calls these programmers Great Hackers)

The problem being, the same qualities that make these people the best suited for a startup also potentially make them the most difficult to integrate into a team (which IMO is why the same [small] teams tend to work together across multiple companies).

Team integration is particularly difficult in that, if you're asking someone to care as much about your dream as you do, then they're really going to care - and with that comes ideas, some of them in conflict with other employees ideas, and that's when the problems begin.

To illustrate this point, consider two hires on opposite ends of the spectrum:

  1. An unmotivated person who doesn't care all that much about your company, they're mainly focused on getting a paycheck.
  2. A highly motivated person who has invested his or her passion and energy into helping your company succeed.

The tradeoffs here are compliance vs. ideas on how to solve problems. The former can be told what to do and how to do it. They're never going to proactively seek out problems and suggest (or implement) solutions. They're never going to challenge the thinking behind a particular aspect of your product, or tell you you're hiring too fast or that the next product plan has some fatal flaws.

The latter will generally tell you what they think, after all, that's why you hired them. By asking them to care deeply about the success of your company, you're inviting them to find problems and offer solutions that will help the company succeed.

For technology people (aka: programmers), they like (a) control and (b) to fix things, and for a start-up, this is both a huge asset and potentially, a big liability.

The biggest risk factor for the startup is if you're unable to integrate these ideas in some reasonable way, then you risk disenfranchising the employee. Disenfranchised employees can lose their motivation, and their passion, for making your company the best it canb be. Clearly it's a tradeoff, and a balancing act.

Risk Factor #2: Conflict Resolution & the Marketplace of Ideas

The other risk is finding the best product and/or technology solution for whatever your company is trying to do, which involves a marketplace of ideas as your technology staff tries to quickly evaluate technologies and implement solutions.

Central to this process is conflict resolution, which implies having some sort of a framework for resolving conflict. I'm continually shocked at the number of people I've spoken with who do not understand this).

Bring a half-dozen talented, motivated, passionate engineers into a room and ask them to solve a problem, you're going to get 4 or 5 solutions, a couple [or all] of which will be mutually exclusive. How do you decide which solution to run with? More importantly, how do you decide which solution to run with without alienating the other employees?

In other words, you want key employees to feel like they have a say in the solutions to the most important problems, and yet, you can't incentivize employees by accepting all of their ideas. So it's all about conflict resolution.

One of the google founders understands this, and so in the early days of Google, they focused on conflict resolution for their early engineers, who were all extremely bright, and this allowed Google to manage their marketplace of ideas in a very efficient manner, allowing the best ideas to "win".

Here's an excerpt from an interview with a previous Google employee:

Conflict resolution between team members is very complex – the product’s manager isn’t involved day-to-day, probably doesn’t actually manage all of the peers who are trying to resolve a conflict, and likely hasn’t spent any time with their employees anyway.

Most of the startups I've been to have spent a disproportionate amount of time in the "conflict" phase of design and not enough in the "conflict resolution" phase, which overall slowed down the pace of devlelopment, and at times, nearly stopped it. Given the pace of technology progress, and the competition among startups, this can really have a profound impact on the success, or lack thereof, of a startup.

Other Reading

I have read two excellent articles that discuss the subject of Internet best practices and have a couple of thoughts on each one[3][4]. One of them goes into great detail on what makes a great hacker (you'll need a handful of these if you'd like your startup to succeed). The other details how to manage said hackers (also something you'll need to do for your startup to succeed).

Time permitting, I'll add my list of top qualities to look for in your Internet startup employees, and equally as important, what to avoid...

[0] The briefest [non-trivial] summary might look something like:

1. Controversial, reasonable. 2. Not so controversial, also reasonable.

[1] The Calacanis article began with some some money-saving tips, e.g.:

  • Don't buy a phone system
  • Rent out your extra space
  • Don't buy everyone Microsoft Office

... but soon gets into several "employee quality of life" issues like:

  • Get an expensive, automatic espresso machine
  • Buy everyone lunch four days a week
  • Allow folks to work off-hours
  • Fire people who are not workaholics don't love their work
  • Buy your hardest working folks computers for home

Overall, I thought his points were all good ones and I've seen many of them implemented at startups I've been to, though controvery ensues around the following point:

Fire people who are not workaholics don't love their work

... the only rub being (and it's a big one) that not every employee has the same skin in the game, particularly in terms of stock options, so while it's generally reasonable to expect founders and early employees to slave away, once you pass the 10-person mark, those addt'l employees will never have the same motivation to work as many hours as the founders (and early employees) of the company.

[2] The Arrington article had tips like:

  • Get a really cheap office, to start
  • Pay your employees cell phone bills
  • Pay money out as slowly as possible
  • Never miss payroll

... The 2nd point being a huge point of contention in several startups I've been to (e.g.: whose cell phone is comp'd, whose is not, and why?)

[3] The best article I've read on this subject, written by Paul Graham, is called Great Hackers, and has a bonus audio clip for those of you who won't like to read.

Here are some of the highlights:

  • Although great hackers are interested in making a lot of money (so eventually they can work on whatever they want), what's probably more important is what they work on every day.
  • What do hackers want? (besides money)
    1. Great tools: great hackers simply won't do the work if the tools are bad.
    2. The right platform: as a social choice, not as a technology choice, as the quality of your programmers is far more important than the actual language.
    3. Control: when something's wrong, they need to fix it, and so the more control they have.
    4. An office: as a place to think (not as an expression of rank), which is important, as your programmers thoughts are your product.
    5. Work for people with high standards, who insist on the right things: which means for technology choices, they need to be technical people.
    6. Working on great (hard) problems: working on tedious and buggy problems makes you stupid.
    7. Working with other great hackers.
  • Because you can't tell how good a hacker is without working with them, most hackers don't know how good they really are. People who are great at something are not so much convinced of their own greatness as they are mystified why everyone else seems to incompetent.
  • The key to being a great hacker is to work on what you like.
  • The number one quality of a hacker is being curious, particularly of how things work.
  • Great hackers are more politically incorrect... they question assumptions all of the time.
  • Follow two rules to become a great hacker: Never work on something you find boring, never do a half-assed job.

[4] Another excellent article on startups written by Phillip Greenspun, is called Managing Software Engineers.

It has some broader points on incentivizing key employees:

  • Small, immediate, certain consequences are better than large, future, uncertain ones.
  • Positive reinforcement is more effective than negative reinforcement.
  • Ownership leads to high productivity.

This article also has a lot of great info, including a section called Building and Keeping a Good Software Engineering Team, and Mr. Greenspun is in agreement with Graham on many fronts:

  • Good people like to work with other good people.
  • Traditionally the best programmers seek the most challenging problems.
  • Good programmers want to achieve and therefore removing barriers to achievement is the most important step that one can take in creating an effective working environment.
  • Your business success will depend on the extent to which programmers essentially live at your office. For this to be a common choice, your office had better be nicer than the average programmer's home.

While I agree with a lot of this article, I think he gets it wrong near the end, here:

Getting design input from leaf-node engineers is important for having a good product design. But at the end of the day nobody should be confused as to who is providing leadership. There is an irreducible amount of Engineer A imposing his or her design on Engineer B. This can lead to some harsh-sounding words and bruised feelings.
Microsoft is not the self-esteem company, at least if you believe Playboy magazine's interview with Bill Gates: "We hear you're brusque at times, that you won't hesitate to tell someone their idea is the stupidest thing you've ever heard. It's been called management by embarrassment challenging employees and even leaving some in tears."

I'm not convinced that "management through embarassment" is a good idea at any time. In the marketplace of ideas, the best idea wins, and there's really no place to embarass the employees who proferred the ideas that didn't win. The concept of Providing Leadership involves setting your ego aside long enough to let the best idea rise to the top, even when it's not yours.

I do agree with him that management by cncensus is generally harmful. At the end of the days, it's the executive staff's call on which direction the company should go from a business standpoint, and everyone has to live with that decision. If you can't do that, it may be time to find a new jobby job.