The a16z Show - Inside Apple Software Design

Episode Date: April 28, 2022

In this wide-ranging conversation from April 2019, a16z’s Frank Chen sits down with Ken Kocienda, a longtime software engineer and designer at Apple from 2001 to 2017, who wrote a book about his career there, called Creative Selection.They discuss Ken’s unconventional path from freelance photographer to software engineer at Apple, his work on many core products from Safari web browser to iPhone, iPad, and Apple Watch and features like Autocorrect, what it was like to demo new products for Steve Jobs, and more. 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.

What was it like to build and demo new things for Steve Jobs? How did Apple develop the software components of iconic hardware products like iPhone, iPad, and more? And what can we learn from these stories? In this wide-ranging conversation from April 2019, A16Z's Frank Chen sits down with Ken Kossienda, a longtime software engineer and designer at Apple, who was there from 2001 to 2017, who also wrote a book about his career called Creative Selection. They discuss Ken's unconventional path from freelance photographer to software engineer at Apple, his work on mini-core products from Safari web browser to iPhone, iPad, Apple Watch, and features like AutoCorrect,

and what it was like to demo new products for steep jobs and more. 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 video. 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 Kashienda 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 on paper you don't look like the typical software engineer. So go back and do the long run. Like where were you born in? 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 mechanics school. Really? All right. Ivy League to, and what motivated that? Like, you just loved motorcycles? I wanted to learn how

to fix motorcycles. Well, when I, 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. At least you didn't have an Asian parent. Well, I think my wife, my dad was pretty pretty

confused about the choice. But anyway, so, but eventually, you know, 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

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, reading books, learning about art. Yeah.

Beautiful buildings on campus. 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. Ha ha ha ha ha. So that was the three-part three-part plan, right.

Photograph, teach 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. Fine Arts, a 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 a mosaic. when and the professor, oddly enough, loaded up one of the few websites comparatively that was available then Yahoo, when it was text only.

Right, right. And so to me, the interest was, I'm gonna make photos show up on this thing. I'm gonna experience, my love of fine art and 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, oh, I left RIT without graduating with any degree. But by that time, I learned enough to go get a job at web development company and wound up making websites and this startup, that startup, the next startup. I wound up at a company called EASL. Oh, right, of course. 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, for where I am here, Andreessen Harowitz, we hosted our cloud services at LoudCloud. Oh, thank you very much.

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. That got me an introduction to Apple.

Yeah. 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. But the,

called Mozilla, I guess, right, 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 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 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. Sure. 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 Mosella, 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. It was interesting that the executives, people like Avi Tavanihanian, 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. And so, but 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 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? 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 in Mozilla nor Conqueror worked on the Mac. So we were gonna 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. And looking at that, it really just came down to Conqueror 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 Eric's, 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. 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. 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 like, 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. 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? 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, I was just, you know, 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 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. things can happen. Either the code will remain the same speed or it'll get faster. 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. Either the code either stayed the same or it got faster. And over time, because there was this speed priority coming straight from Steve, we would look for a way. is to make it faster. Yeah.

And eventually, Safari, when it was released, it was three times faster than MSIE at loading web pages. Yeah, that's fantastic. 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 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. 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 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 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 at a 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. Yeah.

So that's a little unusual. Like 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... 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, MacOS 10 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? By Steve saying, look, we're not going to have that many scus. We're not going to have that many products. Then I can put all my eggs in one back, so I can 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, there, in those three words, Focus, great products. You get, you can distill down Steve's approach, his formula, to just a couple concepts. 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, 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. 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 that's the moment to really decide what the next thing should be. And as you say, engineering management seemed to be like this new domain that I 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 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, is it's about people yeah I I was still at certainly at that point in my my career still fascinated by the software itself that's what was attracted to me

about sync it seemed like this this distributed computing problem and I was enamored with the technology and and you had client server and you know and all of this and and not really again thinking about how the right focus was to build a team build a team 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 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. And a lot of people go through that, oh, I didn't want to ship a team. I want to ship a product. Right. So it sounds like that's what you did. You sort of went back to being... Yeah.

Well, I had a almost shaped to say, it was like a mini meltdown. 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. 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 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. So Scott was like, whoa, whoa, whoa, whoa, just a second. Stop right there. I want to understand what's going on. 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. But 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. Full interview cycle, right? I went and did the interview process at Google, and they offered me a job. So you were serious. You were ready to go. I was serious.

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 kind of sit tight, 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 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'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. 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, you know, perhaps there was going to be patent litigation or not. 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 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 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 do. 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 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 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 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, you know, 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 or 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. 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. There were no product managers. No product managers, no QA engineers,

until later. Until later. 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 so there were maybe like two people in just managing the schedule, tracking risk, looking at the bugs, a couple of QA people joined. But at Apple, certainly from my standpoint, I 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 to, 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, 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. 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. 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. 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 commensurate progress. I mean, the whole thing was high risk. Right. We're gonna make a whole new touchscreen operating system, right? 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 kid and Safari and messages and calendar and all of these, you know, the phone app and 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 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. Tire T, stop. Everybody's a keyboard engineer.

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. 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, you know, it's 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. And we still had really nothing to show for this effort

to give a solution for our phone which would compete with the Blackberry. 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 those things. Love, the product'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 gonna 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. 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 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 at 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 tactile feedback. 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 through investigation and lots of demos and lots of sleepless nights, that the way to close that gap was to give software assistance. Yeah. And so on Rave 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 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, 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, right? 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 key, 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. Autocorrect, the author of AutoCorrect, which is now not only super useful on the phone, but probably my favorite comedy genre. So go watch the Facebook videos on autocorrect 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. 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 gonna try to solve this problem, I bet you saw a lot of variations of sort of key sizes and that type of thing, but like consulting 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, he 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. 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, 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. 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, you know, just won't get into the details of that,

but it seemed like it was similar in a way, In a way, at least in the thought process, is that we have 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 in the end, it was just more of conceptual help

than really anything concrete that I could put into 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 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 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. 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's there. Everybody's 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,

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 microcosmous 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 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, he said that something to the effect of, well, he said, you We've got 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 the you know the Mac and then the iPod and He said we're gonna 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 I didn't get and it's like oh no no no it's just how he's gonna tell the story I 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 then we call it iPhone and when he said that that's when I knew that I was gonna 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 headline I got and like you were working on it so I don't feel quite as bad what you just I mean again this is this the secret

You know, I have to admit that it was just a moment where it was just like, wait, wait a second, is there something that I don't know? No, it can't be. 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 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. 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

and 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. And so I want to get right into this. So, look, Apple was famous for having XI. exquisite taste around the design trade-offs. 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 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, you know, maybe if we had double the size of the team, we could have gone.

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? Right. And now there's 40 people who can break the bill. 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, inside 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,

did do were good enough to counterbalance for the things that 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?

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, like the scent of redwoods or something like that piped in. No, no, it was this shrew.

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, it was a matter of focus. He was focused on looking at the software and not worried about the decor. 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. Okay, 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 AI designers that I really loved working with, and who I had 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 10, 20 different ideas. But one of them 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 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? A software key. 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. 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 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 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 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, 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 he sends me a text, go stand outside the door,

and then, you know, and then the door is going to open, and 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 why 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 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. And so then he does this thing. He takes his iPhone, he puts his, you know, a phone back to 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 Forstold 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 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 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 was 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 seems, 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 key

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 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. does to 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, 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 the room. 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. 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. Not the DRI anymore. That answer, yeah.

See, but you know, and I had no idea that this was what he was going to ask, and 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 maybe 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 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, you know, 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, 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 enough experience with him and his approach to evaluating work, is that he was putting himself in the position of a customer. He was envisioning himself being in an Apple store. As a customer walking up to a table,

seeing this new iPad thing for the first time, what's gonna 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 gonna be there to be whispering in the ear of the person in the Apple store. Sure, they can maybe get the help

of 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? I can decide for myself. Yeah, this is a 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, 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. They were sorry that we had this problem and that 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? 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's 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, very upfront 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, yeah, reality distortion field personality. It's 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 him? 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 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 for iOS 5. So this was 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. 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 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 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 stretched them. Oh, that's super interesting. They didn't have a say in what it's gonna 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 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 pretty good moment for me. And did you stop yourself in doing the victory lap? Look! He thought that it was

you know, 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 gonna 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 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, you know, the equivalent of a shoddy work, shoulder shrug, yeah, 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 like 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 because Well, I mean, it's all 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 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. at these screens, right?

That we need now 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 object, this device, these experiences that are so important to us, so deeply ingrained, well then 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 gonna 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. 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 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 object 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 a point where we didn't even have all of our units still need to 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 tethered 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. 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 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? 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 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 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 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. 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 and it'd 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.

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 your program in Python or whatever as opposed to what's good. Okay. And really, 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 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. Yeah. 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. 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 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, 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 to 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 a sort of 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. He 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. 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 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. 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, part of being a DRI is recognizing strong ideas that are coming from other people and including them in the work. And so 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 the famously secretive Apple Corporation. 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, passing into history. And again, I was one of the few people who had this perspective, 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 thought that it was really more of a personal story. And so no, I didn't, I was imagining that maybe I would ask 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 and your own software development lifecycle. So see you next episode.