

John Ousterhout on Startup Decision-Making - olivers
http://www.stanford.edu/~ouster/cgi-bin/decisions.php

======
jgrahamc
I was John's VP of Engineering at those two start-ups and there's one thing he
doesn't and can't say (but I can :-)

He truly practices what he preaches in that article: I've seen him act like
that over a period of many years. By doing that he set company culture.

Never underestimate the power of a CEO in setting culture.

------
gruseom
"The best decisions are recognized, not made."

This article is a keeper. Its clarity is reminiscent of good software design,
yet without being technical. It's also interesting that it goes against the
grain in a way that's clearly based on experience. I suspect it would be a
good idea to periodically reread this.

~~~
pasbesoin
For me at the moment, it's "too long; read later", but thanks very much for
citing that quote; it compelled me to read the first couple of paragraphs, and
I've made note to follow up with the rest as time allows.

The quote strikes me strongly because it captures, in a sentence, how
decisions were reached in the best groups I've worked with. A bunch of senior
people who know the domains and context. A frank discussion of options,
including: Personal preferences versus current requirements; Short term versus
long term; etc.

It becomes apparent to all what the correct choices are. If there are
disagreements, they are usually minor and acceptable. They are discussed with
respect, and usually kept in mind as contingencies / alternate paths in case
the choices made don't work out satisfactorily. Sometimes, a small amount of
additional work is included to keep those paths open/practical.

The choices are not locked into some doctrine that itself becomes the problem
further down the line. ("The plan becomes the project.") If/when the landscape
shifts, it's discussed and, if necessary, an alternate path chosen. People may
be a bit unhappy, but it doesn't become personal, because it was all discussed
and people know how the situation came to be, with reasonable consensus, and
that it's not the result of neglect (at least, within the team). If there's
some crunch time, it's of necessity. And if your colleague was incorrect, this
time around, they may well be the one covering your back, a few months from
now.

With regard to one team I'm thinking of, outside pressures kept wanting to
"formalize" the work. The team leader resisted this -- through a tactful
combination of attentiveness and responsiveness, a genuinely nice personality,
and benign neglect (we're too booked at this time (with things you are telling
us you REALLY want/need), but we'll keep it in mind). It helped greatly that
he was one of the brightest people in the division (I'd say, in the
organization overall) and people, including upper management, really
appreciated and needed his continued good will. He created a haven of
productivity. Ironically, our documentation was also often better than that of
other "formalized" projects: We recorded what was important, clearly, and
didn't worry about wading through a blizzard of redundant checklists,
schedules, and... Well, if you've never been there, you (speaking to the
readership rather than the parent post) may find it difficult to imagine the
inanity.

Sadly, things changed. When you find such a situation, foster it, and savor it
while it lasts.

For my part, if I'm fortunate, maybe I'll have the opportunity to help create
and maintain such an environment in the future. It's certainly my mindset, and
as I've gotten older, I'm more inclined to just act on it -- independently, if
necessary -- as best I can and let other people sort out their own ruffled
feathers. Doing so, you tend to find others of like mindset and form your own,
ad hoc groups. The caution being that if you do this independently within a
larger setting that does not share your view, politically and career-wise you
may become effectively isolated. Even the fellow I described above eventually
got pushed into a much more "management"-centric roll; it was the only way to
maintain his career. He was smart enough to perceive this and act upon it, if
not entirely happy with the outcome.

------
ramanujan
Hmmm. But there is a reason that design by committee is a curse word. To his
credit, I found it interesting that Ousterhout at least gave a hat tip to the
dictator school of thought.

I think though that there are many more examples which he omits.

Linus -- "Benevolent Dictator for Life"

Guido Van Rossum -- ditto

Just about every other open source worthy -- ditto

Larry & Sergey -- ditto

If you don't have that ruthless product genius with "taste" you just aren't
going to achieve greatness, IMHO. Open to counterexamples, but every time I've
observed consensus based decision making it has devolved into politics and
pre-meetings and vote-swapping. And this is among both tech academics and tech
startups, who one would hope would be more rational.

Actually, this Onion clip captures what happens during an open consensus based
process where everyone can see each other's votes:

<http://www.youtube.com/watch?v=uFpK_r-jEXg>

 _Real-time pandering_.

Instead what you may want to do is buttonhole people or small groups with deep
knowledge of the decision area, ask for their input, debate if you must, and
then go out with a united front.

