John Ousterhout on Startup Decision-Making(stanford.edu)
stanford.edu
John Ousterhout on Startup Decision-Making
http://www.stanford.edu/~ouster/cgi-bin/decisions.php
3 comments
"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.
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.
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.
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.
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.
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.
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.