We discussed user centric design as the fundamental tenet of new product development under Jobs. We talked about how a long-term vision, bounded by user centric design and supported by deep understanding of technology roadmaps is critical to long-term success.  We also talked about how a leader has to be engaged in R&D to make the vision of a user centric design practical.

Let us now focus on next attribute of a successful R&D manager: Building strong and driven team.  Having a vision and ability to engage in the detailed R&D goes a long way towards motivating teams.  However, Steve Jobs seems to have some more characteristics that helped him become successful. Again, I will be gleaning information from several sources to see if we can build a better picture.  Let us start off with the information from the transcript of an interview with ex-Apple CEO John Sculley and see what we can learn…

When I first saw the Macintosh — it was in the process of being created — it was basically just a series of components over what is called a bread board. It wasn’t anything, but Steve had this ability to reach out to find the absolute best, smartest people he felt were out there. He was extremely charismatic and extremely compelling in getting people to join up with him and he got people to believe in his visions even before the products existed. When I met the Mac team, which eventually got to 100 people but the time I met him it was much smaller, the average age was 22.

So, the user centric design, a vision for the future and an ability to engage in R&D (along with a charismatic personality) helped Steve Jobs attract talent.  More importantly, he kept his design team small:

The Mac team they were all in one building and they eventually got to one hundred people. Steve had a rule that there could never be more than one hundred people on the Mac team. So if you wanted to add someone you had to take someone out. And the thinking was a typical Steve Jobs observation: “I can’t remember more than a hundred first names so I only want to be around people that I know personally. So if it gets bigger than a hundred people, it will force us to go to a different organization structure where I can’t work that way. The way I like to work is where I touch everything.” Through the whole time I knew him at Apple that’s exactly how he ran his division.

So, the team size is a corollary of the level of engagement.

The other thing about Steve was that he did not respect large organizations. He felt that they were bureaucratic and ineffective. He would basically call them “bozos.” That was his term for organizations that he didn’t respect

Many people have asked me about how this level of engagement and this size of team is possible in their industry (where teams are thousand engineers strong).  Here is one answer: keep product development focused:

The organization can become bigger but not the Mac team. The Macintosh was set up as a product development division — and so Apple had a central sales organization, a central back office for all the administration, legal. It had a centralized manufacturing of that sort but the actual team that was building the product, and this is true for high tech products, it doesn’t take a lot of people to build a great product. Normally you will only see a handful of software engineers who are building an operating system. People think that it must be hundreds and hundreds working on an operating system. It really isn’t. It’s really just a small team of people.

Clearly, in larger development projects, it may not be difficult to limit the team to one hundred people.  As we will discuss below, the team developing iPhone had several hundred engineers.  Furthermore, segregating product development from manufacturing and marketing (as suggested above) may also have significant disadvantages.  But, the idea probably remains valid: One should have a core team of designers driving the process and the rest can follow.

Engineers are far more important than managers at Apple — and designers are at the top of the hierarchy. Even when you look at software, the best designers like Bill Atkinson, Andy Hertzfeld, Steve Capps, were called software designers, not software engineers because they were designing in software. It wasn’t just that their code worked. It had to be beautiful code. People would go in and admire it. It’s like a writer. People would look at someone’s style. They would look at their code writing style and they were considered just beautiful geniuses at the way they wrote code or the way they designed hardware.

The other important point is the respect for designers.  As you saw above, designers are more important at Apple compared all other disciplines.  Here is some more evidence:

An anecdotal story, a friend of mine was at meetings at Apple and Microsoft on the same day and this was in the last year, so this was recently. He went into the Apple meeting (he’s a vendor for Apple) and when he went into the meeting at Apple as soon as the designers walked in the room, everyone stopped talking because the designers are the most respected people in the organization. Everyone knows the designers speak for Steve because they have direct reporting to him. It is only at Apple where design reports directly to the CEO.

Later in the day he was at Microsoft. When he went into the Microsoft meeting, everybody was talking and then the meeting starts and no designers ever walk into the room. All the technical people are sitting there trying to add their ideas of what ought to be in the design. That’s a recipe for disaster.

I am definitely not suggesting that everyone make designers the top people just like Apple.  Apple is a design focused company, not everyone needs to be like them.  However, R&D leaders should decide on their strategy and build the necessary culture around it.  This is easy to say and hard to do.

Microsoft hires some of the smartest people in the world. They are known for their incredibly challenging test they put people through to get hired. It’s not an issue of people being smart and talented. It’s that design at Apple is at the highest level of the organization, led by Steve personally. Design at other companies is not there. It is buried down in the bureaucracy somewhere… In bureaucracies many people have the authority to say no, not the authority to say yes. So you end up with products with compromises. This goes back to Steve’s philosophy that the most important decisions are the things you decide NOT to do, not what you decide to do. It’s the minimalist thinking again.

Clearly, respecting engineers does NOT mean accepting whatever they do:

Largely because Steve would shift between being highly charismatic and motivating and getting them excited to feel like they are part of something insanely great. And on the other hand he would be almost merciless in terms of rejecting their work until he felt it had reached the level of perfection that was good enough to go into – in this case, the Macintosh.

Of course, not all Steve Jobs did was perfect.  Wired article The Untold Story: How the iPhone Blew Up the Wireless Industry gives us some more information that we can learn from:

It was a late morning in the fall of 2006. Almost a year earlier, Steve Jobs had tasked about 200 of Apple’s top engineers with creating the iPhone. Yet here, in Apple’s boardroom, it was clear that the prototype was still a disaster. It wasn’t just buggy, it flat-out didn’t work. The phone dropped calls constantly, the battery stopped charging before it was full, data and applications routinely became corrupted and unusable. The list of problems seemed endless. At the end of the demo, Jobs fixed the dozen or so people in the room with a level stare and said, “We don’t have a product yet.”

The effect was even more terrifying than one of Jobs’ trademark tantrums. When the Apple chief screamed at his staff, it was scary but familiar. This time, his relative calm was unnerving. “It was one of the few times at Apple when I got a chill,” says someone who was in the meeting.

Or this:

For those working on the iPhone, the next three months would be the most stressful of their careers. Screaming matches broke out routinely in the hallways. Engineers, frazzled from all-night coding sessions, quit, only to rejoin days later after catching up on their sleep. A product manager slammed the door to her office so hard that the handle bent and locked her in; it took colleagues more than an hour and some well-placed whacks with an aluminum bat to free her.

The stress was so high that people actually quit, but they came back!  May be that is the proof of the respect they faced.  However, respecting designers does not mean that Jobs shared all the information with them.  The desire to control actually won out:

Through it all, Jobs maintained the highest level of secrecy. Internally, the project was known as P2, short for Purple 2 (the abandoned iPod phone was called Purple 1). Teams were split up and scattered across Apple’s Cupertino, California, campus. Whenever Apple executives traveled to Cingular, they registered as employees of Infineon, the company Apple was using to make the phone’s transmitter. Even the iPhone’s hardware and software teams were kept apart: Hardware engineers worked on circuitry that was loaded with fake software, while software engineers worked off circuit boards sitting in wooden boxes. By January 2007, when Jobs announced the iPhone at Macworld, only 30 or so of the most senior people on the project had seen it.

I guess the take home message is this: If the R&D staff are respected and they are motivated (with a vision and engagement), they will put with a lot and keep delivering!