a16z Podcast - 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?

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. 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 Kashyanda, 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 long run. Like, where were you born? Oh, well, I was born. 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? All right. Ivy League and what motivated that? I wanted to learn how to fix motorcycles. Well, when I graduated from college, 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 wish you didn't have an Asian parent. Well, I think my dad was pretty,

was pretty confused about the choice. But anyway, so, but eventually, you know, they got behind. 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, you know, 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 about art. Yeah. Beautiful buildings on campus.

Oh, for sure, yeah, very, 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, did two years there working in their editorial library in the photo, in their, 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 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 in 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 professor of photography or 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, and the professor, oddly enough, loaded up one of the few websites comparatively that was available, that Yahoo, when it was text early. And so to me, the interest was, I'm going to make photos show up on this thing. I'm going to take 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 desktop Linux. Every year for the last 30 years. We thought that 1999 or 2000 was going to be the year of desktop Linux it turned out 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 interesting, 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 longstanding 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, he brought Office to the Mac and then I.E. became the default browser. Correct. People don't remember this anymore. Correct. But that was the situation that Apple was in,

is that this exciting new technology, the web, with some. 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 future, critical to its user experience. Yep. And as all the operating system companies decided, right, the web browser was critical. It wasn't an optional add-on component.

NetScape and Microsoft famously got into a legal 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 code base, 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.

Yeah, yeah. It was interesting that the executives, people like, obviously, 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. 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, 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, right? 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. Yeah. 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 that 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. Right. 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. Right? Microsoft. That people were familiar with.

Right? And so now we're going to 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 going to convince people to make the change? And so Steve thought, well, we're going to 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're 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 idea that was really Don Melton's idea, who's 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 weeks, the months, hundreds and hundreds and hundreds of check-ins, that's what happened. The code either stayed the same where it got faster. And over time, because there was this speed priority, straight from Steve, we would look for ways to make it faster.

And eventually, Safari, when it was released, it was three times faster than MSIE at loading webpages. And the point is, again, you know, 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 sprouter 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, 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, I think the way that Steve organized the company and 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 is almost well-known. Steve was very, very clear. He could be, almost, you know, domineering, right? in pushing his vision forward, right? 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 not

to know. 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 at that point?

He would see the code, yeah, very, very often. So that's a little unusual. I compare that to sort of a typical Silicon Valley company where, like, 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 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 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 his, 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. Yeah. So it was sort of a focus thing, right?

But 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 basket 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 is 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 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 like ship 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, you know, 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 job. 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 Forstahl, 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 chain 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 portable and 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, you know, 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 as you think on the other side of it, 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. Yeah. And a lot of people go through that, oh, I didn't want to ship a team. I want to ship a product. Right. All right. So it sounds like that's what you did. You sort of went back to being.

Yeah. Well, I had a, I almost shaped to say, you know, it was like a mini, mini meltdown. I went to Scott Forstall and I say, hey, look, Scott, I don't want to do this. Yeah. I led you astray, led myself astray. I quit. I offer to resign. Yeah.

Because I know, because, and part of the thing was, is it was a feeling of responsibility that I had taken on a responsibility deleted it now I did not want to fulfill. And I felt like, well, the only thing for me, 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. And so Scott was like, whoa, whoa, whoa.

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, OK, well, just go away. He was not pleased with me.

Yeah, yeah. But like, we got to 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. 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 to, you know, that job because Scott continued to engage with me. And he said, you know, just, you know, kind of, you know, sit tight, you know, we've got something

for you. And a couple days later, it was actually my direct management. at the time said, you know, come here, and he took me into this, 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 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 gonna 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 way. as really trade secrets, something that was valuable to the company.

Right. 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.

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 were going to take the operating system kernel and some of the low-level libraries, you know, the networking stack, things like this, the graphics 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, then, I was.

invited onto the team that was going to invent the touch screen OS. So we weren't going to take any of the, naturally the mouse tracking or handling 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 UI Kit 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.S. 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 AI 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.

So, 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, 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. Yeah. You know, they're the QA engineers, right? And so, but still, that still is all encompassed in the numbers that I gave you.

And there, and in a way, I say there were no product managers, but if I, you know, I would say that we had one product manager. There's two ways that I could say. We either had one product manager, Steve. Right. Yes, the ultimate decider. Right. Or that we all were. 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, we did. 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, let's talk about this. 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 crunching down Safari, optimizing Safari so that it could fit on a smartphone. operating system and form factor. 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 progress, right? I mean, the whole thing was high risk. Right, right? We're gonna make a whole new touchscreen operating system,

right, so the whole thing was high risk. But the thing is, is that we were making good incremental progress on most of those areas. Touchscreen and the UI Kid 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, you have a 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. Like the entire team. 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? The rim blackberry and it has a physical keyboard. Has 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 a really, really compressed time scale.

So where just a little bit more than, less than a year and a half out from the day where we were trying to hit that target. Yeah, 18 months. 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, right? And of course, the Blackberry had this wonderful keyboard, the hardware keyboard, the little

plastic keys, click, click, click, click, the little chicklet keys. And again, you said the word crackberry, people loved, love the product. It's a great product, right? But we were going to provide this different vision for what a smart phone. phone 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. 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. Again, I mean, it's, in some ways, it's hard to think back, given how 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 fingertip. So what do you do?

And so it turns out that, you know, through investigation and lots of demos and lots of sleepless nights, right, that the way to close that gap was to give software assistance. Yeah. And so on re-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...

Yeah, we did this series of demos. We see, again, going back to the 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.

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 open the door and I go to see who else's door is open and say here try this right and so we would have this 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 that well we all just went in our own directions some of us you know 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, you know, 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, you know, 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 letter. that you type, 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. It does demo that does an idea and you had your idea and you think oh maybe if I can combine

those two ideas and and make a demo that 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's 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. Right, yeah. 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's secret, 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, 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 the Japanese input method works. I'm saying you know the way the Japanese works is that there there is this input method That there is a sophisticated way to take the keys that that a user types and turn it into the Japanese language The text that that that actually reads as Japanese and so that you know just won't get into the details of that but it seemed like it was similar in a way. I mean it at least in the thought process,

is that we have this, this, this, this, this real software worrying 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, so I went and talked to them, but, you know, in the end, it was, it was just more of conceptual help than really, you know, anything concrete

that I could put into the, into the software where 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 it really required different solutions. 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 as 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 team small. The cohesion, the small unit cohesion that you have, where simple things, like we're going to have a meeting, who do we invite? Well, everybody. Right, right, we're going to have a team meeting, 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, 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. 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 we tried 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 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 announcement for the iPhone in January of 2007. And so if you remember how Steve introduced the product, he said, you know, give his very dramatic introduction. You know, as we said that something to the effect of, well, we've got, you know, a groundbreaking product. And, you know, you're privileged to be involved in, you know, a product like this maybe once in your career.

But Steve, he had been involved with the, you know, the Mac 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, he'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, and 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. Well, you just, I mean, again, the secret, you know, I have to admit that it was just a moment where it's just like, wait, wait a second, is there something that I don't know? No, it can't be. But, but yeah, it was, that was just the culture and the times and the way Steve liked to run things. Yeah. 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 talking 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, you know, we got 20 people in the room, and Henri is up at the, you know, up at the front of the room, and he's got, you know, a keynote slide deck, and he's saying, okay, big challenges, well, keyboard, of course, you know, and then whatever other challenge there may have been, and those challenges came and went, but keyboard was just a constant throughout the whole, you know, 18-month development cycle.

And so we knew that we wanted cut, copy, paste, but we knew that there was simply not gonna 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 way, the insertion point, you know, the little cursor would, 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 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. And so I want to get right into this because, 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, 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 A-B 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 A-B-tested. But Apple made sort of, like, what I would argue, is a pretty courageous call. 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 to 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? And now there's 40 people who can't. 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, it's 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, most, the most amazing product that we've ever made. And so that was, and Steve just was, you know, in his mind, was, was, was, he believed that the things that we did do were good enough to counterbalance for the things that we, we couldn't do. Yeah. 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 so everybody wants to know this right it's probably the scariest room in silicon valley it was it was it was pretty it was pretty scary steve could be uh could be intimidating there is there is absolutely no doubt about it uh but the you know to get back to this this point i mentioned before of the top down and the bottom up uh yeah as i mentioned except for this very brief uh 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? and go ask a person who is the DRI, 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.

And 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 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 manger couch. Who's in the room? Let's do the version where you're trading off sort of the keyboard with the big keys or 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. And 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'd also collaborated with on the iPhone keyboard, Boss 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, you know, 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 eyes. 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 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? Right? So the idea was give the user choice. 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. Man. That's right. Yeah. 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 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, you know, the chief managers for iOS. And then a couple of 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 the 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 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, down the hallway, waiting for Henri to text me. Waiting for my turn. That's right. So, you know, and so he sends me a text,

go stand outside the door. And then, you know, and then the door is gonna open, I'm going to get invited in. So I get the text, I go stand outside the door. And 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, and I figure I'm on. 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 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, yeah, Bob, yeah, yeah, that sounds great.

Yeah, yeah, I'll call you next week. Yeah, great talking to you. Right. So then he, you know, he hangs up. And so then he does this thing. takes his iPhone, he puts his, you know, his phone back to his pocket, and then he does this. Right. It's like, you know, I mean, not if 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 Forstall was the one who then stepped up. He goes and he, 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 to. 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, you know, slides his office chair over. Yeah. 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 like turning his head to see what it looked like in his peripheral vision it's like he's just it's just incredible to see what what does Steve do when he evaluates a product okay so this is what then that's what he did and see 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 a You know, it seems, it's like one of those things where it was probably maybe 20 or 30 seconds that's felt like, 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. But Steve just was like no reaction. He does the Zoom and then he does this study again. He's 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. 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 know, 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. You know, if I didn't give a good answer, maybe I would never be invited back again. Not the DRI anymore. That answer.

See, but you know, and I had no idea that this is 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.

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 button, 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 background of just context of having been thinking about the problem 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're not supposed to do that.

You're not supposed to do that. 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. Because now it's like, what was he doing? he was 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 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 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. And see the evidence

of the care that the engineers and designers had put into the work, 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 controversy. 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. They were 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 really interesting. This is on YouTube. You can go and look at it. And Steve held a little press event, and he was just very, very clear, 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 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 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 at a sort of very granular level in the design. So there was an example where you were designing in an animation, I think it's 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 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, multi-finger 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. So 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, right? So you launch mail and then you launch Safari, well, then I can just swipe to go from Safari back to mail, right?

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 launch 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 stretched them. That's super interesting.

They didn't have a say in what it's going to look like. That's right. 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 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 list. 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 pretty good moment for me. And did you stop yourself in like doing the victory laugh. Look, yeah, yeah, yeah. He thought that it was, you know, sort of tapping into the, excuse me, the little sort of whimsical, 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, and then 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, 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 not 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 like the pedigreed computer science engineer, right? Like that's the stereotype of like that's what. 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 process of designing experiences for people that are useful and meaningful. 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 know what he thought, but the culture that he helped to create and that I found my place in that culture was, you know, 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 now apps and features on the phone to help us track. Too much screen time, right? And so if we're going to have this, this, this object, this device, these experiences 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? 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. right there's a fun liberal arts twist to this yeah so okay so now you know going back to 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 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 Hurst. 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 we didn't even have all of our units still needed to be tethered to a Mac. We didn't have a standalone enclosures yet. So we were still at this phase where we had touchscreens 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 did, if 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. Yeah, right? Before Angry Birds? Before Angry Birds. We had the little 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 rectangles 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 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 pixels 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, you know, 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 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's 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, 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. 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, Right. Because that's what you do. When you're a technologist and say a product company like Apple, you're going to be making decisions on products and it is then going to go out in the world. They're 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,

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. 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, and really, you know, it's unfortunate that there are so many questions like that. Well, obviously, linked lists were 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, when I was handed, you know, a piece of hardware like this and say, make 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 what your higher level goals are. Because technology is going to change. Yeah. And then 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 lieutenant, like a Scott Forstall.

Like, is the absence of those ingredients, 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 sort of 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. 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 in decisiveness. So we'll pick up sort of a few of these things 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 unique? Yeah, well, it's interesting that we were very, very good at combining complementary strengths. 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 know we have to. 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 is 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, and 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 claim? 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, right. 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, you know, on the iOS engineering hallway, if I was the DRI for the keyboard, well, I was the one making the calls. You know, 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 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, you know, 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 bus because there was nobody that I thought deserved it. And I limited myself to the Steve Jobs era, which is now, you know, sadly, or for good or for bad, has him to history. And again, I was one of the few people who had 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 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... 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. 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.

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, sort of can describe 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 in your own software development lifecycle. So, see you next episode.