There is some, but not nearly as much as say what's in win32. This lack of 'crust' can be attributed to SJ's personality. He had no problems dropping something he didn't think worked. This led to headaches for 3rd parties, and is one of the primary reasons enterprise stayed away from Apple (along with no roadmaps).

How can you lead if you don't understand fully the field.

It's not so much that you need to understand every in and out of the field. What you need to understand is effort level required develop something[1], and when you're clearly getting BSed. How much technical knowledge you need to do those two things is the hard part to figure out.

[1] I once had a manager ask me why a change was going to take so long because she thought "it's just and if/then statement."

Those are not trivial things to do. Is not so rare for me to underestimate the effort required for a change in own code (but this might be because I'm not such a great programmer).

I think you may be framing the issue in the wrong way. Here's a little anecdote from my own experience: When I first studied math, I could solve isolated problems but I still had no feeling for what I was doing. One day, I stumbled upon a more theoretical book: Rudin's Principles of mathematical analysis (or Baby Rudin). The rigor, the very thought process was completely foreign to me. Sometimes I spent an entire day on retracing a few lines of proof. On the side, I read a delightful little book by Polya on How to solve problems. While the former gave me stuff to chew on, the latter gave me words to understand what I was doing when I was chewing. After much huffing and puffing, one day I "got" it. I really did. And to paraphrase SJ here, "I did it in a big way."

If I had stopped right there, I might not know about measure theoretic probability, the theory of point processes, copulas, or any other more or less specialized subjects. But once I crossed that point I always felt confident I _could_ learn whatever subject I chose to and do it quickly if called for.

Even for completely foreign topics, I may not know the details yet, the definitions, the important theorems or the lesser ones that help in establishing them or that shorten their proofs. But I now know how to read mathematical books, the difference between an important and a not so important theorem, what to look for.

Without knowing SJ personally, and only half-way through his biography, I think the above is a valid analogy for the kind of understanding SJ must have had for technology. He somehow "got" it, and that allowed him to intuit special areas quickly, select among alternatives, and perhaps be a better editor of more narrowly focused, deeper minds than any single one of them could have been on its own.

I'm not saying he was singular in this, or that his "getting" it was _the_ reason for his later success. For that, you need more, starting with certain type of self-awareness, social aptitude, luck, etc. etc. But as for his technical compass, I'm pretty sure this is all he needed. If you have this type of confidence and understanding, you can always dig into something and specialize when the problem in front of you calls for it. Or you can learn on whom to rely, whom to poll, etc.

That's the difference between a Ballmer, Lazaridis, any of the other management types with business school backgrounds, say, on one side and Jobs, Page or Zuckerberg, say, on the other.

So Jobs got "lucky" (luck favors the prepared, of course) in his finding Ali to obsess about the NS and Cocoa libraries in all dimensions, with the same kind of taste-making abilities as Jobs had at the larger whole ecosystem level.

He said that it was a mistake only taking the GUI to Apple, and he should have taken the whole Smalltalk environment. This in turn lead directly to why Next (and hence Cocoa) uses Objective-C. The fact that he would argue with Eric Schmidt in a car park about the merits of why Obj-C is a better O-O language (http://www.businessweek.com/magazine/eric-schmidt-on-steve-j...) says a lot.

  1. Build a talented team.
  2. Keep it small.
  3. Give them time.
  4. Keep them focused on the end goal not the internals of the project.
  5. Cut all non essential features.

   6. Don't tolerate crap.
   7. Turn your product announcements into theatrical performances.
   8. Have as your main goal keeping the end users happy, not the middle men.

Not so much... carry that too far and you get that recent Samsung CES thing with the kid 'Zoll' and the dancers promoting TV sets.

It is a lot easier to avoid and eliminate debt when you are ruthlessly focused on a few key features.

1) Ask smart questions to smart people. Steve seemed to be a master at this - he can sense when someone is glossing over something, and attacks it. I.E.: "What do you mean, 'for now'; will there be problems later on?". Most people don't want to hear the things you clearly omit. Steve went for the jugular.

2) Experience. Heard of the Next computer? Uneconomic - the whole automated assembly, and razor-sharp magnesium corners, and 16 different shades of black thrown out because they weren't quite right drove the costs up too much. Heard of WebObjects? Steve had his failures. He tended to salvage what he could, restart them, and finally get them working; but he still had failures. I bet he learnt a lot from them.

Which is another way of saying that if a team is small and optimally sized they can't go off and do random nonsensical reinvention of wheels.

Many times parsimony is elegance.

When I first looked into it, I was surprised at the extent to which Mac OS X was based on Unix. It seems like they reuse as much as they can, and innovate only where they need to.