The a16z Show - a16z Podcast: Inside Apple Software Design

Episode Date: April 19, 2019

Join longtime Apple software engineer Ken Kocienda in conversation with a16z Deal and Research operating partner Frank Chen for an insider’s account of how Apple designed software in the golden age of Steve Jobs, spanning products like the first release of Safari on MacOS to the first few releases of the iPhone and iOS (very first codename: "Purple"). Ken vividly shares about the creative process, how teams were organized, what it was like demo'ing to Steve Jobs, and many other fun stories. This episode originally aired as a YouTube video, and throughout, we repeatedly probe the question: is Apple's obsession with secrecy during the product development process a feature or a bug? Stay Updated:Find a16z on YouTube: YouTubeFind a16z on XFind a16z on LinkedInListen to the a16z Show on SpotifyListen to the a16z Show on Apple PodcastsFollow our host: https://twitter.com/eriktorenberg Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Hi, welcome to the A16Z podcast. This is Frank Chen. This episode, which is called Inside the Apple's Software Factory, originally aired as a YouTube video. You can watch all of our YouTube videos at YouTube.com slash A16Z videos. Hope you enjoy. Well, welcome to the A16Z YouTube channel. I'm Frank Chen, and today I am so excited. I feel like I have won the golden ticket to Willy Wonka's chocolate factory because look if you're in Silicon Valley the one chocolate factory you want you're desperate to go visit is Apple and the reason for that is Apple has consistently over its history turned out some of the most intuitive and delightful and just plain awesome products that people use and people are dying to find out how is it that Apple makes such delightful products.

And so today, I'm here with Ken Kashenda, and I'm so excited for him to tell us all about the creative process that he used and his team used to create these products. So, Ken, thank you so much for coming. Well, thank you so much. It's great to be here with you. Well, let's get right into it.

So maybe talk a little bit about how you ended up at Apple because, like, on paper, you don't look like the typical software engineer. So go back and do the longroom. Like, where were you born? in like oh well I was I was born in New York stayed there on Long Island downstate I grew up close to beaches lived there until I went away to college I went to Yale and got a degree in history and then after I graduated from Yale I didn't do the typical thing I went to motorcycle mechanic school really mm-hmm all right Ivy League

and what motivated that like you just loved motorcycles I wanted to learn how to fix motorcycles well I when I graduated from from I wanted to do something that was as different from Ivy League college as possible. I think that qualifies? Right, right. This was dismaying to my parents, my father in particular, I can tell you. I'm sure. But yeah, so I...

At least you didn't have an Asian parent. Well, I think my dad was pretty confused about the choice. But eventually, they got behind and supported that. And so I fixed motorcycles. And then I wasn't really quite sure what I wanted to do. I had this degree in history. But I wanted to kind of keep following my nose. Find new and interesting things to do.

I also did a lot of work in photography when I was at Yale. I spent a lot of time in the Art and Architecture Library on the Yale campus, just reading books, learning books. Learning about art. Beautiful buildings on Kappa. Oh, for sure. Yeah, very interesting architecture, the art and architecture building in particular.

Well, anyway, so I became more interested in photography. I wound up getting a job at a newspaper in the New York area, Newsday. I did two years there working in their editorial library with their photo archive. But then I kind of decided that wasn't really going anywhere fast enough. So I moved to Japan. Wow. And I had a three-part plan for going to Japan. I was going to photograph myself, make a portfolio of my own work.

And I thought that it might be interesting to get some teaching experience. So I taught English. And I was chasing a girl. And not in that order, right? That was the three-part, three-part plan, right? Photograph, teach, chase a girl. I wound up catching the girl. And so we've been married for, it's going to be 25 years.

Oh, congratulations. Just a couple months here. Awesome. And so after that, I took that of the portfolio of work that I put together two years in Japan and applied to a fine arts program at the Rochester Institute of Technology for a Master of Fine Arts degree program. But it was there that I discovered the World Wide Web. And so I put my plans to be a fine art photographer or maybe a professional. professor of photography, you know, putting together the teaching experience with photography.

I just set that aside. And because I saw the web for the first time, this is probably 1994. And I thought it was the most amazing thing. So, Mosaic, when, and the professor, oddly enough, loaded up, you know, one of the few websites comparatively that was available that Yahoo, when it was text only. Right, right. And so to me, the interest was, I'm going to make folks. photos show up on this thing.

I'm taking my experience, my love of fine art and the liberal arts and figure out how to make that come alive on the web. And then just wound up getting more and more into programming. I graduated or I left RIT without graduating with any degree. But by that time I learned enough to go get a job at a web development company and wound up making websites and this startup, that startup, the next startup. I wound up at a company called EASL, where I did Linux software development making desktop Linux. Right. Every year is the year of Dextop Linux. The desktop Linux, we thought that 1999 or 2000 was going to be the year of desktop Linux, it turned out not to be.

Not to be. But you worked on the Nautilus file browser? I actually worked on the portion of Nautilus that connected to these sort of proto-cloud services. And interestingly, our cloud, interestingly for where I am here, Andreessen Harowitz, we hosted our cloud services at LoudCloud. Oh, thank you very much. Yes. Yes.

And so we went ahead with that project, but of course, that company didn't succeed. But of course, Ezel had this long-standing connection through some of its principles, Andy Hertzfeld, Mike Boyge, Bud Tribble. Yeah, the legends, right? Macromedia. And that got me an introduction to Apple. And started Apple at 2001 and started getting into making the web browser for Apple was my first project. That's fantastic.

And why don't we get into that story? Because as you tell in the book, you sort of started experimenting with the old Netscape code base, right? Right. Called Mozilla, I guess, by then. But you ultimately didn't go that way. Right. Well, you see, you know, it's sort of interesting. and maybe we'll get into this more as we talk.

The way that Apple worked in this period during the Steve Jobs era is that he would set this vision. And so his vision was Apple needs its own web browser. So at the time, when I joined in 2001, MacOS 10, the new version of the desktop operating system replacing the old classic version of MacOS that had been shipping on the computer since, the 80s.

Right. So came along with this Unix-based replacement. But that system didn't have its own web browser. It was still part of the agreement that had been made a couple of years earlier with Microsoft to provide Apple with web browser. So Internet Explorer. When Bill invested. That's right.

He brought Office to the Mac and then IE became the default browser. Correct. People don't remember this anymore. Correct. But that was the situation that Apple was in is that this, this, exciting new technology, the web, was something that wasn't under its own control. And so the vision for Apple back then and even still today is that Apple wants to be in control of what it considers to be critical technology.

It's critical to its user experience. And as all the operating system companies decided, the web browser was critical. It wasn't an optional add-on component. NetScape and Microsoft famously got into a legal battle. battle over this. So Apple arrived at the same insight. Yeah. And then interestingly, the two codebases that you consider to get Safari off the ground were Mozilla, right, the Netscape codebase, and then Conquer, which was a Linux web browser, and they were both open source. And so talk to me about what it felt like at the time to be looking at open source inside

Apple, which is a famous sort of like, we'll build it all ourselves. It was interesting that the executives, people like Avi Tavanian, who was the chief software VP at that time, and Steve, were willing to consider open source. But just to give a brief summary of our full investigation, we considered writing a browser from scratch. We also considered going out and licensing from a company like Opera. That was the company that... There were many who would license you browsers back then.

Right, right. And so, but we, we, Don Melton and I, which is the two people we joined on the same day in 2001 to begin this browser investigation. And we looked at open source because it was, we were a team of two people. And web browser is a pretty complicated thing. It's harder than it looks. It's harder than it looks. So we thought that if we could make a compelling case to use open source as a way to jump ahead in the effort, you know, stand on the shoulders of giants, right?

You know, it would get us to a point where we would have something sooner. And that was really the goal. And being open source, if we took this software from, say, another platform that neither Mozilla nor Conqueror worked on the Mac. So we were going to have this opportunity to bring this code from elsewhere and make it Apple's own and really make it look and feel like it was a native program. to the Mac. So that was, and looking at that, it really just came down to conquer was one-tenth the size

of Mozilla. And so as a two-person team, soon thereafter, a three-person team, this just was the easiest way to get from where we were to where we wanted to be. Yeah, it makes sense. I mean, people don't remember this about the early days of the browser, but when we ship Netscape, we had to do it on 20 platforms. So every build was a, all right, here's the one for Arix, here's the one for Digital Unix, Here's the one for AIX, here's the one for HPUX.

And here's, by the way, is Windows 95, Windows 98, Windows NT. Like, it was such a cross-platform exercise that, you know, the code base sort of grew and grew. Sure. And so we only had to do that once in that we took this Linux code and brought it over to the Mac. And of course, it was a challenge for us so I can only imagine what it would be to kind of keep all of these platforms going concurrently as you're trying to make improvements and add features and make things better. Yeah.

And so you ultimately decided on the Conquer Codebase is sort of your starting point. And then pretty early in the development process, you ended up building a stopwatch, the PLT. Right. And so maybe talk a little bit about why did you decide to do that and then ultimately flash forward, like when Steve announced the browser, he would say this is the fastest, like it was one of the key features. And did you know at the time that you built the stopwatch that he was going to do that?

Or did you get lucky? So, no, no, we didn't. It was not luck at all. Steve was very, very clear to us at a very early stage in our browser development process. Was that, well, of course, he wanted to deliver the best experience out to customers. That was it. He wanted to put a smile on the user's face, right? And so if you think about the challenge that we had, there was this existing browser on

the platform that people were familiar with. And so now we're gonna come along and we say, no, well, you had that other thing. Here is this new browser that we want you to use. It's Apple's own browser. And well, what is gonna convince people to make the change? And so Steve thought, well, we're gonna need

a compelling argument. And to be compelling, it needs to be simple. And so his idea, his vision, was, look, we need to make this thing perform fast. Again, thinking back to the time that, you know, the network wasn't so fast. I mean, some people were getting, you know, maybe broadband at the office,

but certainly at home, we were still doing dial-up. Right? And so anything you could do to sort of speed up the browsing experience was something that would be attractive to people. People would notice. And so he said, browser team, you need to figure out how to make this browser fast. And he told us this

a year plus ahead of time. So this PLT, the page load test, as a PLT stands for, was this performance tool that we used during our daily development so that every code check-in that we had, we would run our page-load test to see that there were no speed regressions. We had this this idea that was really Don Melton's idea, who was the manager of the team, he had this little bit of sneaky logic where he said, okay, team, if we check in code and it doesn't make

any speed regression, only two things can happen. Either the code will remain the same speed or it'll get faster, right? And again, it's just one of these simple things that just turns out to be this profound truth because as we would go over the you know the the weeks the months at hundreds and hundreds and hundreds of check-ins that's what happened either the the code either stayed the same where it got faster and over time because there was this speed

priority come straight from Steve we would look for ways to make it faster yeah and and eventually the Safari as when it was released it was three times faster than MSIE at at loading web pages yeah Yeah, that's fantastic. And the point is, again, you know, this, this, you know, Steve Jobs going out on stage, you know, he has this reputation of being this great marketer, you know, the reality distortion field, anything that Steve says, you'll believe, just because he has this, through the sheer force of his personality.

But this was more of a matter of just, of him just saying, well, we executed on this plan, we got a great result, and here it is. So I love this idea that sort of Steve set this goal early on. ship the fastest browser that you can ship, because when I launch it, like, that's what I'm going to talk about. And as I was thinking about sort of basically the software development process, you know, it's rare for a CEO of a big company. And Apple was a big company back then.

Sure. To be so intimately involved in the planning process. And sort of how important do you think that was to sort of your age of design? Yeah. Yeah, I think the way that Steve organized the company and built the teams, built the culture, was an essential part of how we did our work. And the way I like to describe it is that Apple was this wonderful combination of top-down leadership and bottom-up contributions. So Steve, the top-down part, I think.

thing is almost well known, Steve was very, very clear. He could be, almost, you know, domineering in pushing his vision forward. So when you worked at Apple in software development, you knew what the vision was. That was always very, very clearly communicated. But it still was just a vision. Now, sometimes he would get specific, but most of the time he just would tell us, I want a great browser, and it's got to be fast. And so with that, as a brief handed over to the engineering team, it was our job to figure out how to do it.

And so then that's where the bottom-up contribution comes from. He didn't say, I want you to make a performance test, and I want you to institute this policy where every check-in doesn't allow any speed regression. It's no, no, we came up with that, providing that bottom-up contribution that helped to realize the vision. And then one of these other things, and perhaps we'll get into it a little more as we go, because it is such an important part of Apple's culture,

is that there would be demos. So we would periodically, I remember quite clearly there was a 0.1, there was a 0.2 demo where we needed to demonstrate the strength and the potential of this open source idea of the conqueror source code that we had chosen, and of our porting plan and efforts before they would commit to going through to the project

to go from 0.2 to 1.0. And was Steve at the demo? He would see the code very, very often. So that's a little unusual. I compare that to sort of a typical Silicon Valley company where you're doing these demos frequently, right? And so in general, you sort of think of the CEO of a company this size not being involved in every single milestone, right? Because you're

Safari on macOS. MacOS is one of the many products that Apple was shipping at the time. And so like it's a, it seems unusual that the CEO would be involved in this many demo points. And how important do you think that is to sort of... Well, see, and I'm actually going to dispute one of the things that you said, if I may, is that certainly during the Steve Jobs era, and I still think to today here in 2019, Apple didn't ship a whole whole thing. lot of products. Back then, Steve, quite famously, when he reestablished control over the company, he came up with that product matrix, right, where we're going to have, you know, consumer product, a pro product, a desktop product, and a portable product. Right. And so we've got four products,

and it's the same operating system, right, MacOS. And so there's actually very, very few products. Now, interestingly, when I joined Apple in June of 2001, Mac OS10 had come out, and so we had that two-part product matrix that we were still working in, and that was still four months before the announcement of the iPod, which was just that beginning of Apple expanding out from being, well, Apple Computer

to being Apple Inc. Right? You get into more consumer-focused products that weren't really thought of as being computers. But because, I mean, the point of going through all that is that since there were so few products, Steve could keep tabs on what the software teams were doing, that there was this big initiative to make a web browser. So he could keep tabs on it. He could find the time on his schedule to get updates on how the software was doing. And he did.

So it was sort of a focus thing, right? By Steve saying, look, we're not going to have that many skews. We're not going to have that many products. Like, then I can put all my eggs in one back, so I get in and watch the basket very carefully. You say the word, and it is one of the best words, perhaps the best word to describe Steve's approach, which was focus. Focus on what? Great products. I mean, in those three words, focus, great products.

You get, you can distill down Steve's approach, his formula, to just a good product. a couple concepts. Yeah. So you ship Safari, awesome browser, fast, native. You get a lot of people to switch over. And then at that point in your career, after having been this individual contributor that shipped this awesome product,

you thought, like many people in your shoes, time to be an engineering manager. So maybe talk a little bit about that story of sort of how you thought about it and then how you got the job and then what the job was like when you got it as your first engineering manager. Right, right.

Well, I always try to think about, well, what's next? And I don't really have a big career vision. It's especially the tech world, it changes so fast, right? And so it always seems like you come to the end of one thing and then that's the moment to really decide what the next thing should be. And as you say, I mean, engineering management seemed to be, like this new domain that I didn't have a lot of experience in. So I thought that this would be an interesting opportunity.

And so I pushed for it. I asked for it. And it was actually Scott Forstall, the software executive, really instrumental in coming up with a lot of the interesting user interface work in the iPhone software project later, which I'm sure we'll get to. But he was the one who was in my management. who gave me this opportunity. And so I started working on the sync services software for the Mac, which at that time was really still the software that would be up in the cloud and would help two Macs sync with each other.

I mean, we didn't really have. There were no phones, no iPod. Right, right. Okay, so it's like you have a desktop computer in the office. You have a desktop computer at home or maybe you have a platform. portable in a desktop, and it was to get those systems exchanging some data, your contact, your dress book, things like that. And so I thought this was an interesting challenge, and people were going to be getting

more devices and things like that. But I found that very soon after I got into the job that I was miserable, that I hadn't really reckoned at that point in my career with what management really is. It's about people. Yeah. I was still, certainly at that point in my career, still fascinated by the software itself. That's what was attracted to me about sync. It seemed like this distributed computing problem, and I was enamored with the technology,

and you had client server and all of this. And not really, again, thinking about how the right focus was to build a team, build a team culture, support the people so that they could do the technology. And again, at that point in my career, I wasn't really ready for that. And I found myself within just a couple of months, I was miserable. Yeah. It's the lament of a lot of sort of first-time managers, which is you think on the other side of the, of course, I want a manager job. It's the way up.

It's the natural hierarchy. And then you get there, and your job is about shipping a team and not a product. And a lot of people go through that, oh, I didn't want to ship a team. I want to ship a product. All right. So it sounds like that's what you did. You sort of went back to being- Yeah, well, I had a, almost ashamed to say,

it was like a mini-melt-down. I went to Scott Forstall and I say, hey, look, Scott, I don't want to do this. I led you astray, led myself astray, I quit. I offer to resign. Because I know, because, and part of the thing was, it was a feeling of responsibility that I had taken on a responsibility

that now I did not want to fulfill. And I felt like, well, the only thing, There's really just two choices. I could continue on being miserable about it, or I could just go and say, look, I'm done with this. I submit my resignation. So Scott was like, whoa, whoa, whoa, oh, just a second. Stop, right there.

I want to understand what's going on there. So I explained to him what I just explained to you about really wanting to still be in closer touch with the technology. And so he said, okay, well, just go away. He was not pleased with me. Yeah, yeah. We got you, the management job you asked for.

You said that you wanted. Yeah, yeah. Right, and now you're coming back and now a couple months later saying, saying that you want something else, what's going on. So yeah, he wasn't that happy, but he had... And at that time, you had sort of started taking calls from Google recruiters, right? Yeah, I mean, because I thought that I was resigning, so I just need to go get another job. So I actually did, and I went to Google.

Full interview cycle, right? I went and did the interview process at Google, and they offered me a job. Yeah, so you were serious. You were ready to go. I was serious. Yeah. I was serious. But I turned it down.

Turned down that job because Scott continued to engage with me. And he said, you know, just, you know, kind of sit tight. You know, maybe, you know, we've got something for you. And a couple days later, it was actually my direct manager at the time said, you know, come here. and he took me into his office, and he said, we want you to work on this new project, sign this paper,

and I kind of thought, there was just the barest little hint on the grapevine. So I just, like, reach out, I signed the paper, and he said, yeah, we're making a cell phone. Yeah. And you're now on the team. So that's fascinating, right? So this is a great part of Apple

that's sort of very different than most Silicon Valley companies, which is in most Silicon Valley companies, if you get assigned to another project, there's not this level of secrecy. You're not signing papers saying, so tell me a little bit about that. Like, what did they read you into at the time?

It was purple at the time, right? What's the code name? You know, the funny thing is that at Apple, I was already under this blanket non-disclosure agreement. You couldn't say anything about it. I mean, for the whole time that I worked there, I was under these document retention orders. I would get these periodic emails from the lawyers

saying, Do not destroy anything because of the work that I had done was then submitted in patents and perhaps there was going to be patent litigation. So this is just the whole mindset, the whole culture of what app was it. There was secret. We were doing patentable where we were trying to innovate. And we were interested in treating that work as really trade secrets, something that was valuable to the company.

And so... So already super secret culture. Already. And then you have to sign something, which is I'm going to introduce you to an even more secret culture. Even more. Inside Apple, it's kind of like the, you know, when you do the logic classes, like infinite sets can be larger than other infinite sets.

That's right. Now you're in the larger... That's right. Now you're in a bigger, deeper, darker, darker, infinity. That's right. It is a bottomless well. Truly. And so, yeah, so I had to sign this additional NDA.

And yeah, I got to introduce. to this project, it was called Purple, the code name for iPhone, and it was in development. And my job was to join the software effort, which at that point was maybe six or eight people, to do... It's a tiny little team, to do what I like to term the high-level software. The plan was that we were going to take as much of the Mac as possible and bring it over and squeeze it into one of these. you know, a tiny little, you know, smartphone form factor. And so we're going to take the operating system kernel and some of the low-level libraries,

you know, the networking stack, things like this, the graphic stack. But above the level of core graphics, which was the, you know, the low-level graphics library, above that, it was then I was invited onto the team that was going to invent the touchscreen OS. So we weren't going to take any of the, naturally, the mouse tracking or hand-es. or anything of App Kit, which was the user interface level software for the Mac, we were going to make that from scratch for the phone. So what became UIKit for people who know about the technology for what became, you know, the iPhone software, iOS, that was our job.

And so we started with it with a clean slate. And that slate was pretty well clean when I joined, again, just about six or eight people on that effort at the time. Yeah. So they tap you on the shoulder. you're on the purple team. It's like six to eight people. So tell me about the people on the team.

Like what are the roles? Are there product managers? Are there U.X designers? Right, right. So when I say six to eight people, that was software engineers. Yeah. There was also this other team of designers, which in Apple we called the human interface team, the H-I team, right, human interface.

And that was the team of designers. They would do graphic design, animation design, but they would also do concepts. They would provide the thinking behind what is going to be the experience of the person that is going to be using this product that we make. And so there was this small team, half dozen software engineers and H.I. designers and then executives, managers. So there was a fellow named Henri who was leading the software engineering team. There was a fellow named Greg Christie, who was the day-to-day manager of the H.I team. they both reported to Scott Forstahl, who was the executive, who reported to Steve. And that's it.

That was the team. Now, eventually we wound up adding, over time, more people, we probably never had more than 20 software engineers and maybe 10 designers. Those two managers and the executive and Steve, and that was it. Yeah. And so there were no product managers. No product managers. No QA engineers.

No, like until later. Until later. Yeah. Yeah. So the core of it that sort of got the whole product going is software engineers, human interface designers and executives. Yeah. We started then, we added then a program manager.

Right. So there were maybe like two people in just managing the schedule, tracking risk, yeah. You know, looking at the bugs. A couple of QA people joined. But, you know, at Apple, you know, certainly from my standpoint, I, you know, consider them engineers. They're the QA engineers.

But still, that still is all encompassed in the numbers that I gave you. And in a way, I say there were no product managers, but I would say that we had one product manager. There's two ways that I could say. We either had one product manager, Steve. Yes, the ultimate decider. Or that we all were. It was all our responsibility.

to make sure that the product was going to be great for people. We all shared commonly in that responsibility. So that's really interesting, because you sort of distribute the responsibility. Now it's everybody's responsibility, but a lot of companies would think, oh, I've got to have a throat to choke. I've got to have, like, the one person.

But of course, at Apple, that one person was Steve. Okay, well, but then another way, when you get down to the level of features, We had this notion at Apple of directly responsible individuals. Oh, yeah. So we had DRIs, right? And so when I started working, when I was invited to join the Purple effort, because of my experience on the web browser, I started working on making, crunching down Safari, optimizing Safari so that it could fit a smartphone operating system and form factor. And but then after a couple of months, we had a bit of an impasse with the software keyboard.

And we had what was really quite unusual, really unique in my experience at Apple, is that this was judged to be, that the development of the software keyboard was judged to be a sufficiently high risk and that the risk was not being matched by a commensurate practice. I mean, the whole thing was high risk. Right. We're going to make a whole new touch screen operating system, right? So the whole thing was high risk. But the thing is that we were making good incremental progress on most of those areas. Touchscreen and the UI kit and Safari and messages and calendar and all of these, you know, the phone app. But the touchscreen keyboard was lagging behind all of these other projects.

And so one day, it really, really, again, unique in my experience, Henri, who was the software engineering manager, called all of the engineers out of our offices, into the hallway. We had a group meeting, again, about two dozen people, probably even less than that, and said, okay, you all stop. Stop what you're doing. Stop working on, yeah, calendar, it's phone, app,

you know, the user interface level software, everything, stop. Starting from now, you're all keyboard engineers. Wow, that is crazy. Yeah. Like the entire team. TIEB, stop. Everybody's a keyboard engine. Because the idea was that if we don't crack this problem, we might not have a product.

Yeah. So I think we need to take people back to that era, right? Because this seems super counterintuitive that you'd put all 20 people on one project. And so take us back in time. So the most popular phone at the time was the crackberry, right? Yeah. The Rinn Blackberry and it has a physical keyboard. It's a physical keyboard.

And so this was in the fall of 2005. And again, to just give the time perspective, Steve stood up on stage and announced the iPhone in January of 2007. So again, this is just a really, really compressed time scale. So we're just a little bit more than, you know, it's less than a year and a half out from the day where we were trying to hit, you know, that target. Yeah, 18 minutes, not a lot of time. We still had really nothing to show for this effort to give a solution for our phone, which

would compete with the Blackberry. Of course, the Blackberry had this wonderful keyboard, the hardware keyboard, the little plastic keys, click, click, click, the little chicklet keys. And again, you said the word crackberry. People loved those things. Love the product. It's a great product. Right?

But we were going to provide this different vision for what a smartphone would be, is that it was going to be this, that there wasn't going to be enough room for a plastic keyboard with the keys fixed. We were going to give more of the front of the display over to a screen, to software. And so the keyboard had to be in software. And the idea of an all, the sort of software-based keyboard was one of the design things that came from Steve early. Yes.

Like it was just like, look, this is non-negotiable. I'm not shipping a physical keyboard. That's right. No, his idea was that we need a keyboard some of the time, but we certainly don't need it all of the time. And so the idea of the keyboard being in software is that it could get out of the way. It could go off the screen, which would then make the rest of that screen real estate available for a customized user interface that was great. That was optimized for either the phone app or if it's the calendar, you can see. more of your appointments or see more of a month view for the calendar.

So it was absolutely essential that the keyboard could get out of the way when you weren't using it so that the device could be opened up for these other better, richer experiences in the apps that we were going to be shipping. And what problems were you running into at the time? Like were people missing keys, where the keys not big enough? Like what caused the... Yeah, okay. You know, again, I mean, it's in some ways it's hard to think back given how he's how he's history has played out.

Right. Right. That we have our phones now and, you know, maybe you've got, you know, I've got my phone here today and I'm, you know, two thumb typing and I'm hardly even looking and whatever. Back when we were working at this early stage and we were all new to interacting with touch screens, we found that we had this real sense of apprehension. Apprehension, whenever we were going to touch a target on the screen that was smaller than our fingertip, right?

That was actually a really interesting threshold. A constraint that we were dealing with when we were designing the user interface is that if the target that you were going for was larger than your finger, you could target because you could maybe move your head a little bit out of the way and you could see what you were going for. If the target was smaller than your fingertip, it's like, did I get it? I don't know. Right, right?

And so we started. We didn't have the tactile feedback of that Blackberry, right? You could feel the edges of the keys with your fingers. And of course with the touch screen, it was just this sheet of glass. And so that's the challenge with the keyboard, is that you needed enough keys to have a typing experience, right? But in order to give the number of keys necessary, the keys needed to be smaller than your fingertips.

So what do you do? And so it turns out that, you know, through investigation and a lot of the number of the keys, of demos and lots of sleepless nights, right? That the way to close that gap was to give software assistance. Yeah. And so on R-Wave the Magic Wand, everybody now is a keyboard engineer. Everybody needs to figure out how we're going to make a reliable keyboard that's delightful. And so what happened from that point?

Was it like a series of demos where people were just demo? Yeah. Yeah. We did this series of demos. We see, again, going back to Wave the Wai, the ones. way that it was on that hallway. And it was just one hallway, since it was so few people, it was 20-ish people.

And we all had our individual offices at the time. This was not open plan office, right? Everybody had their office. Mine, when I was working and thinking, I had my door closed, right? But then, okay, so I would be in my office with my door closed, and I would come up with a demo, an idea, right, that could be represented in a demo. Then I opened the door, and I go and see who else's door is open and say, here, try this. And so we would have this culture,

we were all demoing to ourselves all the time. And when we were set off on this thing, you're all keyboard engineers now, well we all just went in our own directions. Some of us had already well established, you know, collegial relationships where I would collaborate a lot with you and some other people, you know, they had maybe,

they worked by themselves, some people had a good relationship with one of the H.I. designers or whatever. So we just cobbled together our own little teams, our own little efforts, and started making demos. And again, trying to combat this problem of the keys being too small. So one idea that we experimented with was making larger keys,

with multiple letters on the keys. I started experimenting with software assistance. Maybe there could be a dictionary on the phone that the software could consult to provide suggestions that may be much like we have today, that there's this bar on top of the keyboard that is updating as you're typing keys, giving you some notion

of what the software thinks you're trying to do. Auto-correct, the author of Auto-Correct, which is now not only super useful on the phone, but probably my favorite comedy genre. So go watch the Facebook videos on Auto-Correct comedies. They're fantastic.

Yeah, well, sorry about that. So eventually, you know, the breakthrough, if you will, that made it possible for software keyboards to really work in a shippable product was a software assistance to the extent that the software may change the letters that you type. Right, right.

That it'll change it to what it thinks rather than what you did. And it's actually this phrase is really, really important. I think really, really, one of the important organizing concepts for so much that we did, to make the touchscreen operating system work is because you didn't get this tactile feedback because you couldn't feel the edges

of either keyboard keys or any button or anything in the user interface is that the software had to be there working behind the scenes to give you what you meant maybe differently than what you did. Yeah. And how did you come up with this idea?

Because this is a classic thinking outside of the box idea, right? Like if you were going to try to solve this problem, I bet you saw a lot of variations of sort of key sizes and, you know, that type of thing. But, like, consulting in the dictionary, putting up suggested words, like, where did the idea come from? It's just this iterative process. It just takes a long, long time.

You start with ideas. Maybe somebody else does a demo that does an idea. And you had your idea and you think, oh, maybe if I can combine those two ideas and make a demo that does the best of everything that I see. And it was just this collaborative soup of ideas all swirling around. And you just take the, you know, all of us were, there was a sense of friendly competition. And it was both of those. We all wanted to do the best. We all wanted to be the one.

I mean, I think we all had a sense of maybe a sense of ego that we wanted to be the one to crack this hard problem that we were given. But it's all very friendly in the end that if your idea wound up winning, proving useful, yeah, you got a little bit of sort of geek, you know, cred for that on the hallway. Everybody knew who it was that came up with the idea. I want to talk to you a little bit about this sort of secrecy, right? You got read into the Holy of Holy is it more secret than sort of other parts of Apple. And at one point, you decided, as you were refining the autocorrect algorithm, that there were actually experts outside of the Purple team that might be able to help.

But, of course, they hadn't been disclosed. And so, like, what was that like to try to go get their help and was it offered? It was tough. It required getting approval. It's like, well, I'm going to go and talk to these people. But there was no process, really, at that point, to get them disclosed. I mean, really, you know, at a certain point, Steve was still personally approving every person that was submitted to get disclosed on the project. But I did get permission to talk to them, so as long as I told them, I can't tell you why I want to know how, say, the Japanese input method works.

I was saying, you know, the way the Japanese works is that there is this input method, that there is a sophisticated way to, take the keys that a user types and turn it into the Japanese language, a text that actually reads as Japanese. And so that just won't get into the details of that, but it seemed like it was similar in a way, at least in the thought process, is that we have this, this, this real software whirring away in the background other than, you know, different than say just like a desktop keyboard, where if you type the A, you get an A. Right? And so I went and talked to them

But you know in the end it was It was just more of conceptual help than then really You know anything concrete that I could put into the into the software. It just turns out really that the problem that I was trying to solve Which is really input correction that you weren't sure what key you hit Was a class of problem that was different enough that that it really required different solutions. Yeah. Looking back at it now, which is sort of the extreme secrecy,

you couldn't really describe the problem, right? And so as a result, you got some conceptual help, but not sort of concrete design help. Would you think of this sort of tiers of secrecy inside Apple as a feature or a bug or somewhere in between? Yes. Yes. You know, the thing is I think there is a really underestimated power

in keeping your teeth. team small. The cohesion, the small unit cohesion that you have, where simple things, like it's where we're going to have a meeting, who do we invite? Everybody. Right, right. We're going to have a team meeting. Yeah, right.

Where we're going to talk about important milestones. Or we're going to call everybody out of their office. Henri could say, hey, everybody, come out of your offices, please. And within 30 seconds, everybody was standing there. Yeah. Right? So, you know, you get these, there are advantages to keeping things really, really small. And, of course, then there is the disadvantage that when you are trying to tackle difficult problems, you may not have all of the talent that you need.

And you may not have a sufficient amount of diversity. Right. Right. Right. That all the, you know, especially, you know, a company like Apple is trying to make products for everybody. Well, how do you design for everybody? Right, right.

If the design team isn't a microcosm of everybody. And so there are these really profound challenges, right? You know, back in these times we did the best that we could within the constraints. And, you know, and we tried to then really tap into the benefits that, you know, and we try to then really tap into the benefits that the smallness and the secrecy gave us as well. Yeah. Another funny thing that I learned reading in your book is the secrecy was so extreme that like you didn't even know what the product was going to be named.

And so like the word iPhone wasn't even in the dictionary. That's right. After Steve launched. That's absolutely true. So there was, we were all heading toward this, this announcement for the iPhone in January of 2007. and so if you remember how Steve introduced the product, he said, you know, give his, you know, very dramatic introduction, you know, he said that something to the effect of, well, we've got, you know, a groundbreaking product, and, you know, and you privilege to be involved in, you know, a product

like this maybe once in your career, but Steve, he had been involved with, you know, the Mac and and then the iPod. And he said, we're going to have three new products of this class today. And I'm saying like, wait, there were two other secret projects that I didn't know about. I mean, truly for a moment. Yeah. I didn't get. And it's like, oh, no, no, no.

It's just how he's going to tell the story. It's my product he's talking about. That's going to be, you know, the phone. And it's, you know, going to be the, you know, the touchscreen music player and then, you know, the internet communicator. Yeah. And that how, no, this is actually all just one product. then we call it iPhone. And when he said that, that's when I knew that I was going to have to go back the next day and add iPhone to the Auto Correction Dictionary. That's awesome that he fooled you,

too, because he fooled me. Like, like, you were working on it, so I don't feel quite as bad. What, you just, I mean, again, the secret, you know, I have to admit that it was just a moment or it was just like, wait, wait a second, is there something that I don't know? It's like, no, it can't be. But yeah, it was just the culture and the times and the way Steve liked to run things. Now, a feature we all take for granted now actually didn't appear in iOS until several releases later, and that's copy and paste. So I wonder, at the time, did you guys talk about that? And did you make an explicit decision to sort of like, yep, let's ship without copy and paste? And was that contentious?

Because on the surface it seemed like that's contentious? Yes, yes, it was. But one of the other things that we were really expert at, to bring back the word that we talked about earlier, was focus. In that we were very, very good, really very, very early in the development process to say what was in and what was out. Physical keyboard out. That was super early. That's right. Very, very early.

And that it was clear that this was that getting the text entry system working at all was going to be one of the real challenges. I mean, I got used to being in the team meetings where Enri, team engineering meetings, again, everybody's in the room. So we've got 20 people in the room, and Henri is up at the front of the room, and he's got a keynote slide deck. and he's saying, okay, big challenges, well, keyboard, of course, and then whatever other challenge there may have been, and those challenges came and went, but keyboard was just a constant throughout the whole 18-month development cycle. And so we knew that we wanted cut, copy, paste,

but we knew that there was simply not going to be time for it. So we didn't spend any real development effort on it. The one thing that I did implement for the first iPhone was the loop. So you press and hold, and it would give that little magnifying glass above your finger that would show. And the whole idea of that

is that we wanted your finger to be right where the insertion point, the little cursor, would move. And so then we needed to show you what, and so this was an idea that I came up with. But then there was no time to capitalize that, then expand on that, to do cut, copy, paste. And it even got delayed an extra year.

That's right. Because in the second year, after we did the initial release of the iPhone, and then we had that six-month delay before we did the first customer shipments, and then that whole next year was taken up by making third-party APIs. Yep. So two releases before you had copy and paste. That's right. That's right.

And so I want to get right into this. So look, Apple was famous for having. exquisite taste around the design tradeoffs. And a feature like copy and face kind of feels like, wait, you're arguing against copy and paste? Like, that's not a great user experience. And so, like, how did the argument evolve? And sort of the big setup is, look, there's taste,

taste making hard decisions like this. And then there's sort of another style of decision making, which sort of Google made super popular, which is just relentlessly AB testing everything. Right. Right. And so, like, maybe the way, Google would have come at this challenge is, all right, let's give people tasks.

This one has copy and paste. This one doesn't have copy and paste. Let's say be tested. But Apple made sort of like what I would argue is a pretty courageous call, right, that seems to fly against the user intuition to exclude it. Yeah, well, it was simply a matter of setting the constraints and keeping them. Again, maybe if we had doubled the size of the team, we could have gotten some other things done, but maybe not at the same level of quality.

And again, once you start adding people, other things begin to break down, right? You can't invite everybody to the team meetings. You can't find a conference room big enough, right? Right. And now there's 40 people who can break the build. That's right. That's right.

I mean, how you start to have problems like this. And so we just decided that, well, you know, and like a Steve way of maybe communicating this was, look, this is the greatest product ever, right? It's a touchscreen, iPod, It's the greatest iPod that we've ever shipped. It's got all these great feeds. It's a phone.

You've got web browsing that you can take anywhere with you now. And there's no copy paste. Well, who cares? Well, we'll get to it. Right? I mean, in the meantime, you've got this, you know, the most amazing product that we've ever made. And so that was, and Steve just was, you know, in his mind,

was, he believed that the things that we did do were good enough to counterbalance for the things that we couldn't do. So that's great. Great segue to sort of the next segment. I'd love to sort of take us into what it was like to demo first, Steve. Like, what was the room like? Who's in there? Like, what's the emotion of it?

Everybody wants to know this, right? It's probably the scariest room in Silicon Valley. It was pretty scary. Steve could be intimidating. There is absolutely no doubt about it. But to get back to this point I mentioned before of the top down and the bottom up, as I mentioned, except for this very brief interlude where I was a manager, throughout my whole Apple career, over 15 years, almost 16 years, I was an individual contributor. And yet I got the opportunity to demo to Steve some of the latest work that I did at various points in my career. because he wanted to see from the person who did the work.

And because when he would ask questions, well, go and ask the expert, right? Go ask a person who is the DRI, right? The directly responsible individual, the person who is, at least according to plan, the person who when they lose sleep, they are losing sleep over that thing that they're going to be demoing to me.

So that's what he wanted to do. These demos were very, very small affairs. Now, interestingly, the demo room for Steve, the software demo room, was this really shabby little room. That's not what you would expect for Steve Jobs' command performance, right? This pristine room that it's like an air, you know, air filter, the air is clean,

or you know, or you know, like the scent of redwoods or something like that piped in it, no. No, it was this, shabby little room with this mangy old couch and just standard issue office furniture. And that's, that's what there was. I don't know why he didn't want better. But the only reason that I can say is that again, as a matter of focus, he was focused on looking at the software and not worried about the decor. Yeah. All right. So take us in the room. It's a mangy couch. Who's in the room? Let's do the version where you're trading off sort of the keyboard with the big keys of the keyboard with the little keys.

So now, so skipping ahead a couple of years after the original iPhone when we were then doing the original iPad. So this is now 2009, as I recall. So a couple of years later. And so this is actually an original iPad right here. It's actually a really good one, which is actually autographed by Steve Jobs. So this was the iPad that I got at the end of the iPad development process. But back at the beginning of the iPad process, you know, I would have a prototype that looked pretty much like this. And so we were thinking of, well, what's the typing experience going to be like?

And so here's an original iPhone or an original iPad. Well, we've obviously got a bigger screen. A lot of pixels now. Right? So now what are we going to do to make great use of these additional pixels that we have? And one thing that I also noticed was if you turn the iPad to landscape, that screen distance is actually just about the same as the distance between the Q key and the P key on a laptop keyboard. So I was thinking, hey, like, wait a minute, we could maybe fit a full size, something that is a full-size keyboard on a landscape iPad. Now, it turns out that right around at the same time, one of the H.I. designers, one of my favorite

H.I. Designers that I really loved working with, and who I had also collaborated with on the iPhone keyboard, Basa Ording, he was starting to think about iPad keyboards as well. And so he had come up with this demo where he had all of these variations, all of these ideas. And so he gave me a demo where he went through, he showed me 10, 20 different ideas, but one of them really made, really struck me, which was he had a design that showed pretty much just a shrunk-down laptop keyboard to fit in this space. And so what that meant is that I had two ideas, is that maybe I could use this larger screen real estate to make a version of the keyboard that had big keys that was almost

the same size as a laptop keyboard. But then one that also gave you like the number row and all of the punctuation keys, exactly where you would expect to find them on a laptop keyboard. And so I figured, well, you know, and I started talking with Boss and we came up with this demo where we would have a special key, we called the Zoom key, that would take you from this keyboard that had the small keys keys that would zoom up to the larger keys and then back down to the smaller keys as a kind of a complement to the gloom key that changes the keyboard language. So we would have this other key, this kind of complementary key, that would change the keyboard

layout. We thought this was a great idea. And again, the idea of what are we going to do with this larger screen real estate for the iPad? Software key. The idea was give the user choice. I have these pixels. Give the user choice.

Give the user choice. Use these new pixels that are available on this new platform, this new form factor. And have that be the pitch that we make to people. And so before, of course, you can make the pitch to people. You need to make the pitch to Steve. To the man. That's right. And so I got to demo this for Steve.

And so the way that this worked is that there was a very small team that was like the the chief demo review team, the small group of people that Steve wanted around him as he was reviewing demos. And this was Scott Forstahl, Greg Christie, Henri, people that I've mentioned. So the chief managers for iOS. And then a couple of H.I. Designers. It's like Boss Ording, the fellow that I collaborated with on this keyboard, was almost always in this meeting. Another fellow, Steve Lemay, was another H.I. designer was often in the meetings. But as I recall, he wasn't in this particular one

where I was demoing the keyboard. So half a dozen people ish? Half a dozen people in the room, yeah. And so then what would happen is that people like me who had individual demos, and so it's like there were circles inside of circles. So I was in the circle of people who could demo to Steve. But then there was this circle inside of that

who would stay for all the demos. And so my role would be that, or my, you know, how I would figure is that I would go in give my demo, and then leave. And so, you know, think of that beforehand, is that, you know, I'm sitting there with my iPhone, you know, out, you know, down the hallway, waiting for Henri to text me. Waiting for my turn. That's right. Say, you know, and so he sends me a text.

Go stand outside the door. And then, you know, and then the door is going to open. I'm going to get invited in. So I get the text. I go stand outside the door. And, you know, now I'm waiting and I'm waiting and I'm waiting. And it just seemed like, well, he just texted me. Why did he text me?

And so then the door opens. I get invited to, I figure I'm on. I'm going to go do this iPad keyboard demo, and I come around the corner and turn into the room, and Steve is over there, and he's like this. He's like, he's on the phone. He's on the phone, staring at the ceiling, like, you know, going back and forth in his office chair.

And I'm like, gulp. I was like, what do I do? Like, now I'm eavesdropping on Steve on his phone call. Yeah. Right? And so, you know, it's pretty uncomfortable. Yeah. And I think I actually do, I actually do think that he was talking to Bob Iger, the head of Disney.

Right? And so he's like, yeah, yeah, Bob, yeah, yeah, that sounds great. Yeah, yeah, I'll call you next week. Yeah, great talking to you. Right. So then he hangs up. Yeah. And so then he does this thing.

He takes his iPhone. He puts his, you know, his phone back through his pocket. And then he does this. Right. It's like, you know, I mean, out of you know, like the eye of Sauron, right? The Lord of the Rings, right? You know, the great eye turns to focus on you, and that's what it feels like. And so it's very, very interesting than how the demos go from that point in that he didn't want a lot of words.

He didn't want a lot of, you know, use car salesman pitches, right? All he really wanted to know was what was next. And so what happened is he hung up the phone, he turns towards me, And then Scott Forstow was the one who then stepped up. He goes and the iPad was already in the room. And so he goes and wakes it up and brings my demo up and says, Steve, we're going to be looking at iPad keyboard options. Now, Ken, he did work on the iPhone keyboard, and now he's got ideas for the iPad keyboard. So Ken?

And so I said, yes, Steve, go and look at the demo. It's on the screen now. Try the Zoom button. And that's it. That's it. That was the intro. And so then Steve goes, he slides his office chair over, and he starts like looking at the iPad screen.

And what was up was one of the two keyboards, let's say it was the big key keyboard, the one that was more like suitable for touch typing. And he's looking at it, he took a long time to look at it. It's like he even did this little thing where he was like turning his head to see what it looked like, Like in his peripheral vision, it's like he's just incredible to see what does Steve do when

he evaluates a product. Okay, so this is what, and that's what he did. And so he hadn't even touched it yet. He's just looking at it. Yeah. And this is going on for a long time. It's like one of those things where it was probably maybe 20 or 30 seconds that's felt like 20 minutes.

Right? But he took a long time to study and then eventually he goes out and touches the Zoom button and this zoom button to change between the two keyboards in this case shrinking the keys down to be the more laptop-like keyboard layout the animation that boss ording had designed was one of the most beautiful things I'd ever seen I mean it really looked like they were like the keys were just like morphing it was absolutely beautiful yeah but Steve just was like no reaction he does the zoom and then he does this study again he's like Like looking at all the keys, looking at how the screen changed, then he does the zoom again, and it goes back to the state

that it was in the beginning. And then he studied a little bit more and tapped the zoom button again to see that it's like, okay, there are just two states that we're going here between, right? We've got two keyboards, I see the animation, go between one, then the other, back to the first one. He satisfies himself that he's seen what there is to see. And so then he turns to me and he says, we only need one of these things,

right? And you're like, I'm on the hot seat. I guess so. And then he says, I mean, this is, this is again the interesting part. He asks me, which one do you think we should use? He asks me. Yeah. He doesn't ask, you know, Scott Forstall, who is, you know, he knows much better. He doesn't ask, you know, any of the other people in there. He asks me, the individual contributor. You're the DRI. You're just coming in, but I'm the DRI. You see, that's the thing. He wanted the answer from me.

Now, the thing was, I had to give an answer. Yeah. You know, if I didn't give a good answer, maybe I would never be invited back again. And not the DRI anymore. That answer. See, but, you know, and I had no idea that this was what he was going to ask.

But in that moment, I came up with an answer. Because I thought about my experience with these two keyboards, and I thought that, you know, the one with the bigger keys, I found more comfortable. I was getting to be, you know, that may be with, you know, like four or five fingers that I could touch type. And auto correction was helping.

So that's why I said to Steve. I said, well, I like the bigger one. You know, the auto correction is kind of helping. And I'm starting to get a feel for touch typing. And he says, okay, we'll go with that one. Wow. Demo over. Yeah.

And, you know, the interesting thing is that then that's the keyboard that chipped on the product with the slight modification of taking away the zoom. which was now no longer needed. Right. Right. And so Steve had this amazing ability to simplify and to rely on his people to have a good enough idea about what they were doing and to be involved enough in the work that even when you get asked difficult questions about it that you've been thinking about it. You have this, this background.

of just context of having been thinking about the problem for for weeks and weeks, that that experience was then something he was interested in tapping into to provide a way forward for the product. What was going through your head when you were just watching him sort of head tilt in silence? Were you like tempted to like explain things? Yeah, well, you just know that you, that's not where you're not supposed to do that. Yeah. Yeah.

I mean, I would imagine that if he had, done so he would have been in no uncertain terms he's like let me look at the thing yeah because now he's like you know what was he doing he was in my in my view I don't know what's going on inside his head but just having seen him do that having at least you know enough experience with him and his approach to to evaluating work is that he was putting himself in the position of a customer he had he was envisioning himself that being in an Apple store.

As a customer, walking up to a table, seeing this new iPad thing for the first time, what's going to be my impression of it? So he pictured himself as customer number one. And so, you know, I don't want anybody. I don't want the engineers. The engineers aren't going to be there to be whispering in the ear of the person in the Apple store.

Sure, they can maybe get the help of, you know, one of the nice people, you know, working in the Apple store. But, gosh, wouldn't it be better? if I can figure this thing out for myself and decide for myself and see the evidence of the care that the engineers and designers

had put into the work that I can decide for myself, yeah, this is the thing I want to take home with me, right? Yeah. So obviously, if you have a leader like Steve, that's that into being able to emulate the user who has great taste, like you want to make this person benevolent design dictator for life, right? Now, the downside of that, you know, Silicon Valley is getting a lot of criticism for these sort of super charismatic reality distortion field generating CEOs where, like, you might not agree with them, right? And, you know, in the sort of ultimate downside case, there's sort of just too much worship, hero worship of CEOs. Like, do you think that ever became part of the Apple culture, right? Sort of the blind obedience to the fearless leader?

Yeah, I think the Steve's reputation and his success causes people to draw the wrong conclusions, to take away the wrong lessons. I think that if you go back and look at on YouTube of old videos with Steve, maybe on stage with Walt Mossberg and Karas Swisher at their, at their, you know, all things, D conference. or I just had a reason to go back and look at the antenna gate. Oh, right? I forgot about that. Because I, and the reason that I did this is because this, you know, it's current now that there was a bug in group FaceTime. And Apple issued an apology. Say, we're sorry that we had this problem and we're going to be fixing it and whatever.

And so I wanted to go back and say, well, what did Steve say about Antenegate, you know, which was the issue with the iPhone 4 where you're holding it wrong and the signal strength would go down. And I wanted to see what he said. And it was, it's really interesting. This is on YouTube. You can go and look at it. And Steve held a little press event. And, you know, he was just very, very clear, very, very up front saying, our goal is to make our customers happy. And so that's the kind of lesson that people should be taking away. It's not that he was domineering, not that he was this. this absolute monarch, you know, 21st century absolute monarch now in a company rather than a government, you know, all that, you know, that he had this, yeah, reality distortion

field personality, is that he had this focus on doing great work and making customers happy. That's really what he cared about. Yeah. And then sort of how did the organization morph itself to sort of reflect that you had this, you know, great tastemaker who wanted to make these decisions that is sort of a very granular level in the design. So there was an example where you were designing in an animation, I think it was sort of the scrunch zooming demo, and you got to the point where like Steve and Scott Forstall actually disagreed. Right. So maybe tell us a little bit about that.

Yeah. And so this was, this was for iOS 5. So this was, you know, maybe the second version, second or third version of iPad software. And we wanted to come up with multitasking gestures, is what we called them, so that you would have some way of interacting with your whole hand on the screen. Well, obviously from the beginning, even though multi-touch was something that shipped even in the first Apple product, there was no way that you could have sophisticated gestures, multifinger gestures on a screen that size. But with the iPad, we thought that you could.

And so you had this idea of, well, what if you've got the home button that way? You still maybe want some gestures to interact with the device to control going between app to app. I came up with this idea of using this five-finger gesture, like you take a sheet of paper and crumple it up and throw it away to go from an app back to the home screen. There was then this other interaction where you would swipe side to side to just go between one app directly to some other app.

So you launch mail and then you launch Safari, well then I can just swipe to go from Safari back to mail. So that the system would keep track of the history of apps that you launched. So now here's the part that Scott didn't like. So let's say you start up your iPad from nothing, right? You take it out of the box and you bring it home. And yeah, you launch mail and you launch Safari.

You only ever launched two apps. So you swipe to go from Safari back to mail. Well, what happens if you continue swiping in that direction? Right, there's no other apps. End of list. End of list. And so what I came up with was this, sort of morphing, stretching, rubbery distortion of the app to show you that you were at the end

of the list. And it would kind of do this bloop, bloop, bloop sort of animation when you let your fingers up off the screen. And Scott Forstall hated it. He hated it. And his argument went like this. He said, you know, that's not fair to the designers of the apps because they really didn't design for what their apps would look like when you stretch them.

Oh, that's super interesting. They didn't have a say in what it's going to look like. That's right. You've taken away their taste. And it's an interesting aspect to what happens as you evolve a product. They would then, for the subsequent version, but we would be shipping a version that added a new feature multitasking gestures, and it would have to work with all the apps that were already in the world.

Of course, there was a huge ecosystem by that point. So this was Scott's argument, is that the designers, you've done something to the the designers that they couldn't really have accounted for in the design of their apps. Okay, so I got the chance to demo this to Steve, too. And I remember that Steve, what he did was he had the iPad in his lap. So he was sitting like this and doing the gestures, trying them side to side and whatever. And when he just discovered by himself this rubbery animation, end of list animation, he did it. He did it again, and he didn't look up.

He said, this is Apple. Awesome. So it was a pretty good moment for me. Had to stop yourself doing the victory lap. He thought that it was, you know, sort of tapping into the little sort of whimsical aspect that went all the way back to sort of like the happy Mac on the original Macintosh, right,

that it was this whimsical little animation that showed that the system has this playful character to it and that was an aspect that he really loved. And so, and it also just goes to show that there could be disputes, even up at the highest level. Scott knew that I was very excited about this feature and wanted to show Steve, so he let me. And Steve was the one who had the final vote

and he sided with me in that instance. And do you feel like that slowed decision-making down at all in the org where basically we're just going to wait for Steve to decide? So, like, why bother making a decision? See, but again, the DRIs were responsible. You needed to bring him proposals. Yeah. Right? You know, you might think of that keyboard demo example was, well, we were bringing him two keyboards and we wanted him to pick which one.

No, that wasn't it. We were presenting him with a design. We wanted to ship in the product. The design was going to have these two keyboards. He was the one who unpacked it, and to say we only wanted one of these. So no. And the point is that if you brought him shoddy work

that was like the equivalent of a shoulder shrug, Steve, we've got five things. We don't really know which one we think we like. that was a way to Never get invited back to a demo, right? It's a way to get invited back to the demo. And that was the way that Scott Forstall then would have gotten blowback from Steve offline

to say, Scott, why aren't you presenting me with solid designs? I'm not here wasting my time. I want to see the full result of that bottom-up process so that he could then give his top-down approval, disapproval, no, send this back for more work with specific feedback on what to change. That was the outcome of every demo with Steve. Approved, not approved, bring me something different

next time. Or not approved, give me these specific changes. It was one of those three things. So Steve himself is sort of legendary for sort of fusing liberal arts and engineering thinking, right? And if you think about the classic Silicon Valley stereotype, companies are a lot more about the pedigreed computer science engineer, right? Like that's the stereotype of like that's what we're looking for now. But your own background and other people at Apple who've sort of had the valued liberal arts and engineering degree, talk about like what are the advantages of sort of melding the traditions?

What's an example of a decision that got made that was a better decision? Well, I mean, it's all the, the, the, the, the process of designing experiences for people that are useful and meaningful, right? And I think that how do we define what's useful and meaningful? Well, we look to literature, right? We look to philosophy, right? We look to art, we look to the creative media, right?

To decide what's useful and meaningful. And so, you know, I think, and, you know, I don't know, I didn't know Steve well enough to, to know what he thought. But the culture that he helped to create and that I found my place in that culture was the part of the approach was that these devices are part of people's lives, right?

More and more now, to the extent that now, right, we think that there's a problem with the number of amount of time that we're spending looking at these screens, right? That we need apps and features on the phone to help us track. Right? Too much screen time.

Right? And so if we're going to have this, this object, this device, these experiences that are that are so important to us, so deeply ingrained, well then they, they, it requires, I think, the care and attention and the thought about it's not just a technology artifact, it's a social artifact, right? It's a human artifact, right? And so that's where liberal arts. comes in. Yes, you do need to have the technological background to come up with the

hardware and the software and the networking and the services to get everything packed together so that a product like this is possible. But if you're going to ask, well, what is it good for? You know, why do we do this feature rather than that feature? I think that, yeah, that's a liberal arts process. Tell the story, if you would, of how you guys arrived at the home screen app icon size. There's a fun liberal arts twist to this. Yeah, so, okay. So now, you know, going back to a phone

that looks more like this, is my original iPhone that I still have. So, you know, this is the screen size that we were dealing with. Now, one of the, you know, again, now jumping back all the way to 2005, 18 months out from the, you know, the product announcement,

we were still in the early stages of trying to figure out, well, what is the home screen of apps going to look like and how is it going to work? And one of the fundamental questions that we had was, well, how big should the icons be? And again, I mentioned before this apprehension of touching targets that were smaller than your finger. And we were still in the phase where we didn't know how big on-screen objects should be. And so we had some experiments, but this was still, we didn't have a good handle on it. And so one of the engineers on the hallway had an idea. And his name was Scott Hurs.

He was doing work on Springboard, the icon launching program himself. And so he had this idea, is that I'm going to make a game. It's the first ever iPhone game. Truly, because this is the point where we didn't even have all of our units still needed to be tethered to a Mac. We didn't have standalone enclosures yet. So we were still at this phase where we had touch screens that still needed to have a wire tether to it. But still we were trying to figure out, well, what the ideal size is.

And the game was the solution. And the game went like this. You would launch the game, and there was a minimal user interface. All it was was a rectangle on the screen. That was a random size and a random position. And the game was tap the rectangle. And as soon as you did, it didn't tell you if you succeeded or failed. because the idea was just go tap the rectangle as quickly as possible.

You tap the rectangle, the next one would show up at some other random size and some other random position on the screen. And the idea was to just go as quickly as possible without, again, being sort of weighed down by the feedback of whether you were succeeding or failing. And you would get then 20 of them, and then it would give you your score.

Right? And so it was fun, right? Before Angry Birds? Before Angry Birds? There was random rectangles. There was random rectangles. Angry rectangles, going around.

Now, naturally, what he was doing, he also wrote the software so that he was tracking rectangle by rectangle whether people were succeeding or failing and also based on where the rectangle showed up on the screen. And within a couple of games,

of course, the game was actually fun, right? I finally got 20 out of 20, right? We determined that if you made a, a rectangle that was 57 pixels square that pretty much everybody could tap it 100% of the time no matter where it was again since you were going quickly you could tap it comfortably and that number he just then since he was working

on springboard and it was his game it was his app he put that number into the app he made the pixel 57 pixel square and since that was a good number we never changed it and so that's what wound up shipping on the iPhone. Yeah, I love that story, that it was sort of a game that led to it as opposed to, all right, we're just going to do every possible pixel variation,

we're going to bring people into tested, and we'll see what works. Yeah, no, it was, again, he was the DRI for Springboard. It was his job to figure out how big the pixels should be, and he came up with a good solution, so we didn't change it. Yeah. So let's switch gears a little bit

and talk about sort of your advice for young people who are thinking about getting into the computer industry, sort of liberal arts degree, computer science degree, what set of life experiences? Like, what's your general advice for people who want to join a tech company? Yeah, I think it needs to be a mix. I think if you're going to be a programmer, yeah, go write programs. I mean, the only way to get better at things is to do them.

And one of the wonderful things we mentioned open source a bit earlier, the best. the barriers now have never been lower to get involved. I knew that when I was a young person in college, I actually started in college in 1984, I couldn't afford a Mac. Right? I wanted one.

Yeah, they were thousands of dollars. Thousands of dollars. There was no way. There was no way that I could afford one. And so now the barrier to entry is much lower. So if you're interested in making projects, well, just go out and join a community and start making them. Or maybe you don't even, you can even lurk in the community. You can download the software and try to make something of it yourself.

So I think that, you know, again, if you want to do something, just start doing it. So that's one piece of advice. And then the other piece of advice is, yeah, you do need to look at more. than technology. Again, for the reason that I said a few minutes ago, which is these technological artifacts that we're making now have become so important to people that if you don't know anything about people, right, I don't think that it's, you're going to be successful in the long term. And so, yeah, read books. Read books. Study, philosophy. Go to art museums. learn about what's beautiful and meaningful to you.

Answer those questions for yourself. I don't think, you know, if you can't answer those questions for yourself, it would be then hard as say a product designer to then take on the responsibility of answering those questions for other people. Because that's what you do when you're a technologist and say a product company like Apple, you're gonna be making decisions on products

and it's then going to go out in the world are going to be affecting other people. Other people are going to be putting those things and bringing them into their lives. And so how do you know? What's good? And so that's a question that you should be prepared to answer for yourself.

What do you like? And why? What are your goals? Why do you make a choice to make the product turn like this rather than that? And so it's this combination of learning about the technology so that you can actually implement your ideas. But then you've got to actually have good ideas.

Right. And again, it's the liberal arts that provides the grounding for that. Huh. Super. And that's counterintuitive in Silicon Valley, right? The suite of interview questions you typically encounter when you're interviewing for jobs are about linked lists and do you know TensorFlow and can you program in Python or whatever as opposed to what's good.

Okay. What's beautiful? And really, you know, it's unfortunate that there are so many questions like that. Well, obviously linked lists we're still going to have need for those as we go into the future. But, you know, the work that I, much of the work that I did in my life, there was no way that I could have predicted, right? When we, I was handed, you know, a piece of hardware like this and it's like making a touchscreen operating system for a smartphone, well, there were precious few examples that we could have looked at. And so how do you have experience in that thing? So, again, I think getting a flexibility, being able to answer the sort of more general

questions about what you like and what's good and and and and and and and what your higher level goals are because technology is going to change yeah yeah and then um sort of thinking about a company like how important do you think it is if you're thinking about joining a company that there be a figure like a steve jobs who has a trusted due tenant like a scott forestall like is the absence of those ingredients like uh like i'm not going to join that company or right how universal is the Apple experience is another way of asking this question, versus how specific to a set of characters and a time in history?

Yeah, it's a hard question. I mean, Steve was unique, right? And unfortunately, he's not around anymore. And so I think it's kind of a fool's errand to go out and find who is the direct successor to Steve Jobs. It's just, you know, it's just like the questions are always changing. And so I think it's a matter of finding a place where you feel comfortable, where you feel some sort of connection to what the organization is trying to accomplish and that you like the people and that you feel that you're bringing something. You know, it's again this kind of this interesting contrast of both fitting in, but then also, I think, providing more diversity.

I mean, that's an ongoing challenge for high-tech companies, is that, again, as the products become more and more important for our culture, I think the people who are making the products need to be a better reflection of the world as it is, right? That it's not just a bunch of computer geeks who went to maybe just a few high-powered schools that have good computer science departments. Right. In your book, there's sort of a couple key ingredients that you would sort of distilled the Apple experience down to. Like this is basically in reflection. This is what made the iPhone team so productive. And you talk about things like collaboration and taste and decisiveness. So we'll pick up sort of a few of these things on the, as we sort of finish up the segment. So collaboration, right? Every company says we have a collaborative culture. What do you think made Apple's use? Yeah, well, it's interesting that we were very, very good at combining complementary strengths. Right? So we had this human interface design team, and I worked very, very closely over time with a couple of the folks in there. Of course, there were only a few folks in there in total.

And what we would do is, let's say the example of me working with boss ordering on the iPhone keyboard. And so I was coming from the project primarily from an engineering direction. He was coming from the project primarily from a design direction, but boss was pretty good at writing code. And I would fire up Photoshop and Illustrator. And so we would come up with these ideas and we would complement each other. And to the extent, and again, whatever you think of software patents, we got them for the work that we did in Apple. And one of the constraints that you have when you apply for patents is that you need to list the inventors. You actually need to be honest

about who contributed to the specific invention. And so they would ask us, well, which one of you two came up with this specific idea so that we can write it into the claim language? And maybe if we're going to take that claim and move it to a separate patent, we have to know who to put as the inventor.

And we would, Boss and I would look at each other and we would go, I don't know, we both came up with it. And so that's the sign of collaboration, is that where the collaboration is so good that you don't know where it begins and where it ends. You're complimenting each other so well that we did it.

And there was no other way to describe it. And part of, you know, as sort of a concrete piece of advice or maybe a way of describing that more at Apple is that we didn't have a lot of politics. You know, when Boss came up with an idea, I came with an idea, it just didn't matter. It wasn't a strong attribution culture, right? Oh, that's his idea and like, how dare you explain.

And I can't work on that, and now my manager is going to get involved because now I'm not going to get the credit for it and whatever. It just wasn't like that. Yeah. But you still had to have strong DRIs, right? Yeah. But that is also one of the ways that just made it clear about, you know, if I was collaborating with someone like boss or just some other engineer on the iOS

engineering hallway, if I was the DRI for the keyboard, well, I was the one making the calls. And as long as I kept making good calls, right, I mean, if somebody else had an idea that they really, really thought, they were going to go to the mat and they're going to say, no, I think Ken made the wrong call on this, yeah, they could buck that up, the management hierarchy, but that was relatively unusual because, again, I mean, part of being a DRI is recognizing strong ideas that are coming from other people and including them in the work. And so that was, that helps to describe some of the character of the collaboration that we had. Well, Ken, it's been a fascinating conversation. Thanks so much for taking us inside the chocolate

factory. Look, the chocolate factory did not have very many people. So I feel really blessed that, you know, one of those people made it out and is willing to lead the tour. and talk to us. And maybe that'll be the last question I asked you, which is the famously secretive Apple Corporation, right? Did you have to get their approval to actually write the book and tell the stories?

Well, no, I didn't. I don't know if I was supposed to, but I didn't. And I took a certain approach to it, which is that it's a positive take on Apple. I loved my career at Apple. So I didn't throw anybody under the butt, because I did there was there was nobody that I thought that I thought deserved it. And I I limited myself to the Steve Jobs era, which is now, you know, sadly, or for good or for

bad, passing into history. And again, I was one of the few people who had this, this perspective, this, this opportunity to be there during the time that some of these products were getting made. And so, you know, again, with my background being in here, history and being in the liberal arts, I thought that it would be good if I collected these recollections while I still do remember them well and tell the story. And so I thought that it was really more of a personal story. And so no, I didn't, I was imagining that maybe I would ask for forgiveness if somehow they didn't really approve. But I thought that I wouldn't really run into trouble.

Yeah. Well, that's great. Thank you for taking the time here and for putting the stories down so they don't fade into the mists of history. It's been great having you. Thanks so much. I've had a great time. Thank you.

Great. So for those in the YouTube audience, if you liked what you saw, go ahead and subscribe. And then in the comments thread on this video, let's talk about things that you might want to try in your own culture. Now having listened to sort of can describe what it was at. Apple, what Apple did, sort of what would work in your environment and what wouldn't work in your environment? We'd love to have a conversation about how would you implement some of the ideas that

we talked about and your own software development lifecycle. So see you next episode.