CFI Podcast: Inside Apple Software Design

Join longtime Apple software engineer Ken Kocienda in conversation with CFI 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?

Show Notes

Background prior to joining Apple [0:00] and early work designing the Safari browser [6:26]

The influence of Steve Jobs on the creative process [15:03]

Short stint in management and transfer to the iPhone design team [20:54]

How the iPhone team was structured [29:13] and technical issues building a touch keyboard [37:00]

Apple’s culture of secrecy and the difficulty of getting outside help [43:19]

What it was like to demo for Steve Jobs [54:06], and further discussion about his influence and personality [1:09:21]

Why having a liberal arts background is beneficial [1:18:07], and general advice for young people interested in tech [1:24:32]

Discussion of Apple’s culture of collaboration [1:30:30]

Transcript

Frank: Hi, welcome to the “CFI Podcast.” This is Frank Chen. This episode, which is called “Inside the Apple Software Factory,” originally aired as a YouTube video. You can watch all of our YouTube videos at youtube.com/a16zvideos. Hope you enjoy.

Well, welcome to the CFI 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 Kocienda. 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.

Ken: Well, thank you so much. It’s great to be here with you.

Frank: 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 — like where were you born and, like…

Ken: Well, I was born in New York, stayed there on Long Island, downstate. 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.

Frank: Really?

Ken: Mm-hmm.

Frank: All right. Ivy League to — and what motivated that, like, you just loved motorcycles?

Ken: I wanted to learn how to fix motorcycles. When I graduated from college, I wanted to do something that was as different from Ivy League college as possible. This…

Frank: I think that qualifies, motorcycle maintenance.

Ken: Right. This was dismaying to my parents — my father, in particular, I can tell you.

Frank: I’m sure.

Ken: But yeah so I…

Frank: At least you didn’t have an Asian parent.

Ken: Well, I think…

Frank: You would have been disowned, that’s like…

Ken: …my dad was pretty confused about the choice. But anyway, 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 I wanted to, you know — kind of, keep following my nose, finding 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.

Frank: Beautiful buildings on campus. Gothic, and…

Ken: Yeah, 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.” Did two years there working in their editorial library 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 gonna 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. So, that was the…

Frank: And not in that order, right?

Ken: That was the three-part plan, right. Photograph, teach, chase a girl. I wound up catching the girl so we’ve been married for — it’s gonna be 25 years in…

Frank: Oh, congratulations.

Ken: …a couple months.

Frank: That’s so awesome.

Ken: So, after that, I took that — 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 you know, putting together the teaching experience with photography. I just set that aside, because I saw the web for the first time. It was probably 1994, and I thought it was the most amazing thing.

I saw Mosaic and the professor, oddly enough, loaded up, you know, one of the few websites, comparatively, that was available then. Yahoo, when it was text only, right? And so to me, the interest was — I wanna make photos show up on this thing. Let me 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 I just wind up getting more and more into programming. I graduated — or, I left RIT without graduating with any degree. But by that time I’d learned enough to go get a job in a web development company and wound up making websites. And this startup, that startup, the next startup. I wound up at a company called Easel.

Frank: Oh right, of course.

Ken: I did Linux software development, making desktop Linux.

Frank: Right. Every year is the year of desktop Linux. Every year for the last…

Ken: Desktop Linux. We thought ’99 or 2000 was gonna be the year of desktop Linux, it turned out not to be, but…

Frank: Not to be. But you worked on the Nautilus file browser.

Ken: I actually worked on the portion of Nautilus that connected to these, sort of, proto-cloud services, right. And interesting…

Frank: Dropbox before it’s time.

Ken: Interestingly, for where I am here, Andreessen Horowitz — we hosted our cloud services at LoudCloud.

Frank: Wow. Thank you very much for being a customer.

Ken: And so, we went ahead with that project. But, of course, that company didn’t succeed. But of course, Easel had this long-standing connection through some of its principals. Andy Hertzfeld, Mike Boich, Bud Tribble…

Frank: Yeah, the legends, right? Macromedia and…

Ken: That got me an introduction to Apple. So I started [at] Apple in 2001, and started getting into making the web browser for Apple — was my first project.

Early projects at Apple

Frank: 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 codebase, right?

Ken: Right.

Frank: Called Mozilla, I guess, by then. But you ultimately didn’t go that way.

Ken: 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, Mac OS 10 — the new version of the desktop operating system, replacing the old classic version of Mac OS that had been chipping 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 a web browser, so Internet Explorer.

Frank: When Bill invested…

Ken: That’s right.

Frank: …he brought Office to the Mac, and then IE became the default browser.

Ken: Correct.

Frank: People don’t remember this anymore.

Ken: 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, you know, 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 — critical to its user experience.

Frank: 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. And then, interestingly, the two codebases that you consider to get Safari off the ground were Mozilla, right — the Netscape codebase — and then Conkeror, 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.”

Ken: It was interesting that the executives — people like Avi Tevanian, who was the chief software VP at that time, and Stev — were willing to consider open source. But just to give you a brief summary of our full investigation, we considered writing a browser…

Frank: From scratch.

Ken: …from scratch. We also considered going out and licensing from a company like Opera. That was the company that…

Frank: There were many licensing browsers back then.

Ken: Right. And so, but we — but Don Melton and I, which was the two people — we joined on the same day in 2001 — to begin this browser investigation. And we looked at open source because we were a team of two people, and a web browser is a pretty complicated thing, right?

Frank: Complicated. It’s harder than it looks.

Ken: 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 the software from, say, another platform that — neither Mozilla nor Conkeror 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. So that was — and looking at that it really just came down to, Conkeror 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.

Frank: Yeah, it makes sense. I mean, people don’t remember this about the early days of the browser, but when we shipped 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 HP-UX. And here, by the way, is Windows 95, Windows 98, Windows NT. Like, it was such a cross-platform exercise, you know — the codebase, sort of, grew and grew.

Ken: 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.

Frank: And so you ultimately decided on the Conkeror codebase as, sort of, your starting point. And then pretty early in the development process, you ended up building a stopwatch, the PLT. And so, maybe talk a little bit about — why did you decide to do that — and then ultimately, flashforward. Like, when Steve announced the browser, he would say, this is the fastest — like, it was one of the key features. And did you know at the time that you built the stopwatch that he was gonna do that or, like, did you get lucky or…

Ken: So 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…

Frank: Right, Microsoft.

Ken: …that people were familiar with, right? And so now we’re gonna come along and say, no, you had that other thing — here is this new browser that we want you to use. It’s Apple’s own browser. And, well, what is gonna convince people to make the change? And so Steve thought, well, we’re gonna need a compelling argument. And to be compelling, it needs to be simple. And so his idea — his vision — was look, we need to make this thing perform fast. Again, thinking back to the time that — well, the network wasn’t so fast. I mean, some people were getting, you know, maybe broadband at the office, but certainly, at home, you’re still doing dial-up.

Frank: You’re definitely in dial-up.

Ken: Right? And so anything we could do to 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” is what 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 Milten’s idea, who was the manager of the team.

He had this little bit of sneaky logic, where he said, “Okay, team. If we check-in code and it doesn’t make any speed regression, only two things can happen. Either the code will remain the same speed, or it’ll get faster, right?” And again, it’s just one of the simple things that just turns out to be this profound truth. Because as we would go over, you know, 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 the speed priority coming 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 MS IE at loading web pages.

Frank: That’s fantastic.

Ken: And the point is, again this — Steve Jobs going out on stage, he has this reputation of being this great marketer, 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.”

Influence of Steve Jobs

Frank: 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 gonna 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?

Ken: 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, 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 gotta 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 regressions.” No, we came up with that. Providing that bottom-up contribution that helped to realize the vision.

And then one of these other things — and perhaps we’ll get into it a little more as we go, because it is such an important part of Apple’s culture — is that there would be demos. So, we would periodically — I remember quite clearly, there was a 0.1, there was a 0.2 demo — where we needed to demonstrate the strength and the potential of this open source idea — of the, sort of, the Conkeror 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. So…

Frank: It was Steve at the demo at that point?

Ken: He would see the code yeah. Very, very often very, very…

Frank: 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 Mac OS —Mac OS 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, the…

Ken: See, I’m actually gonna 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, you know, re-established control over the company, he came up with that product matrix, right? Where we’re gonna have, you know, [a] 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 —Mac OS — and so it’s actually very, very few products.

Now, interestingly, when I joined Apple in June of 2001, Mac OS 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 the 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 his — keep tabs on it. He could find the time on his schedule to get updates on how the software was doing, and he did.

Frank: So it was, sort of, a focus thing, right? By Steve saying, “Look, we’re not gonna have that many SKUs, we’re not gonna have that many products — like, then I can put all my eggs in one basket and watch that basket very carefully.

Ken: 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, there, in those three words — focus, great products — you can distill down Steve’s approach — his formula to just a couple concepts.

Frank: 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, 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?

Early work with iPhone

Ken: Well, you know, I always try to think about, well, what’s next? And I don’t really have a big career vision because — 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, engineering management seemed to be, like, this new domain that I didn’t have a lot of experience in. So I thought that this would be an interesting opportunity. And so I pushed for it, I asked for it.

And it was actually Scott Forstall, the software executive — really instrumental in coming up with a lot of the, you know, 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…

Frank: There were no phones, no iPod.

Ken: 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 contacts, your address book, things like that. And so, I thought this was, you know, an interesting challenge, and you know, people were gonna 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. I was still — certainly at that point in my career, still fascinated by the software itself.

That’s what was [attractive] to me — about sync. It seemed like this distributed computing problem, and I was enamored of the technology, and you had client server, and you know, 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 can 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.

Frank: It’s the lament of a lot of, sort of, first-time managers, which is — you think, on the other side, 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. I didn’t wanna ship a team, I wanna ship a product. So it sounds like that’s what you did — you, sort of, went back to being…

Ken: Yeah. Well, I had, I’m almost ashamed to say, you know, it was like a mini-meltdown. I went to Scott Forstall and I say, “Hey, look, Scott. I don’t wanna do this. I led you astray, led myself astray. I quit. I offer to resign.” Because — and part of the thing is that 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. You know, I submit my resignation. And so Scott was like, “Whoa, whoa, whoa, just a second…”

Frank: Not quite yet.

Ken: …stop right there. I wanna understand what’s going on there.” So I explained to him what I’ve just explained to you, about really wanting to still be in closer touch with the technology. And so he said, “Oh, okay, well, just go away.” He was not pleased with me. But…

Frank: We got you the management job you asked for.

Ken: You said that you wanted [it], right? And now you’re coming back, and now a couple of months later, saying that you want something else. What’s going on? So yeah, he wasn’t that happy but he had…

Frank: And at that time, you had, sort of, started taking calls from Google recruiters, right?

Ken: Yeah, I mean, because I thought that I was resigning. So I need to go get another job. So I actually did, and went to Google.

Frank: Full interview cycle?

Ken: I went and did the interview process at Google, and they offered me a job.

Frank: So you were serious, you were ready to go.

Ken: I was serious. I was serious. But turned it down — turned down, you know, that job, because Scott continued to engage with me. And he said, “Just kind of sit tight, maybe we’ve got something for you.” And a couple of days later, it was actually my direct manager at the time — said, “Come here.” And he took me into his office and he said, “We want you to work on this new project, sign this paper.” And I kind of thought there was just the barest little hint on the grapevine. So I just, like, reach out, I signed the paper. And he said, “Yeah, we’re making a cell phone, and you’re now on the team.”

Frank: So that’s fascinating, right? So this is a great part of Apple that’s, sort of, very different than most Silicon Valley companies, which is — in most Silicon Valley companies, if you get assigned to another project, there’s not this level of secrecy. You’re not signing papers saying — so tell me a little bit about that. Like, what did they read you into at the time? It was Purple at the time, right, was the codename.

Ken: The funny thing is that at Apple, I was already under this blanket non-disclosure agreement…

Frank: You couldn’t say anything about it.

Ken: …for all the — 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 lawyer saying, “Do not destroy anything,” because of the work that I had done was then submitted in patents and, you know, perhaps there was gonna be patent litigation. So this is just the whole mindset, the whole culture of what Apple was. There was [a] secret, we were doing patentable — where we were trying to innovate. And we were, you know, interested in treating that work as a trade secret, something that was valuable, you know, to the company. And so…

Frank: So, already super-secret culture.

Ken: Already.

Frank: And then you have to sign something, which is — I’m gonna introduce you to an even more secret culture…

Ken: Even more.

Frank: …inside Apple. It’s kind of like, you know, when you do the logic classes, like — infinite sets can be larger than other infinite sets.

Ken: That’s right.

Frank: Now you’re into the larger area — like, seriously? Like, what?

Ken: Now you’re in a bigger, deeper, darker…

Frank: …there’s more secrecy?

Ken: … infinity. That’s right, it is a bottomless well, truly. So, yeah — I had to sign this additional NDA. And yeah, I got introduced to this project, it was called Purple.

Frank: Purple.

Ken: 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…

Frank: That’s a tiny team.

Ken: Tiny little team, to do what I like to term the high-level software. The plan was that we were gonna take as much of the Mac as possible and bring it over and squeeze it into one of these — you know, tiny, little, you know, smartphone form factor. So we’re gonna 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, you know, the low-level graphics library — above that, it was then — I was invited onto the team that was gonna invent the touchscreen OS.

So, we weren’t gonna take any of — naturally, the mouse tracking or handling, or anything of app kit, which was the, you know, the user interface level software for the Mac. We were gonna make that from scratch for the phone. So what became UIKit, for people who know about, you know, the technology for what became —  you know, iPhone software iOS — that was our job. And so we started 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.

The iPhone design team

Frank: 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 UX designers?

Ken: Right. So when I say six or eight people, that was software engineers. There was also this other team of designers, which in Apple we call the human interface team — the HI 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 gonna be using this product that we make? And so there was the small team, half dozen software engineers, and HI 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…

Frank: HI.

Ken: …of the HI team. They both reported to Scott Forstall, who was the executive who reported to Steve. And that’s it.

Frank: And that was it.

Ken: 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. And so…

Frank: Super interesting, no product managers

Ken: There were no product managers.

Frank: No product managers, no QA engineers, like, until later.

Ken: Until later.

Frank: So the core that, sort of, got the whole product going is software engineers, human interface designers, and executives. And that’s it.

Ken: Yeah, then we added, then, a program manager. So there were maybe, like, two people in just managing the schedule, tracking risk — you know, looking at the bugs. A couple of QA people joined. You know, at Apple — you know, certainly from my standpoint, you know, I consider them engineers. You know, they’re the QA engineers, right. But still, that still is all-encompassed in the numbers that I gave you. And, in a way — I say there were no product managers, but I would say that we had one product manager. There’s two ways that I could say it. We either had one product manager, Steve.

Frank: Yes, the ultimate decider.

Ken: Right? Or that we all were. We all were, it was all…

Frank: So that’s really interesting.

Ken: …our responsibility to make sure that the product was going to be great for people. We all shared commonly in that responsibility.

Frank: So that’s really interesting, because you, sort of, distribute the responsibility. Now it’s everybody’s responsibility. But, you know, a lot of companies would think, ooh — I’ve gotta have a throat to choke. I’ve gotta have, like, the one person. But of course, at Apple…

Ken: So we did.

Frank: Right. The one person was Steve.

Ken: And then another way, when you get down to the level of features, we had this notion at Apple of directly responsible individuals…

Frank: Oh yeah. Let’s talk about this.

Ken: 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 — the development of the software keyboard was judged to be sufficiently high risk, and that the risk was not being matched by commensurate progress, right? I mean, the whole thing was high risk, right —we’re gonna make it a whole new touchscreen operating system, right? So the whole thing was high risk.

But the thing is that we were making good incremental progress on most of those areas — touchscreen, and the UI kit, and Safari, and messages, and calendar, and you know, all of these — you know, the phone app. But the touchscreen keyboard was lagging behind all of these other projects. And so, one day — 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, and 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 your calendar, phone app —you know, the user interface level software. Everything, stop. Starting from now, you’re all keyboard engineers.”

Frank: Wow, that is crazy. Like, the entire team…

Ken: Entire team, stop.

Frank: …everybody is a keyboard engineer.

Ken: Because the idea was that if we don’t crack this problem, we might not have a product.

Frank: 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 — the RIM BlackBerry, and it has a physical keyboard.

Ken: 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 timescale. So, 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.

Frank: Eighteen months, not a lot of time.

Ken: And 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 chiclet keys. And again, you said the word CrackBerry — people loved…

Frank: Loved those things.

Ken: …loved the products, it’s a great product, right? But we were gonna provide this different vision for what a smartphone would be. Is that it was gonna 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…

Frank: And that was…

Ken: …had to be in software.

Frank: And the idea of an all — for, sort of, software-based keyboard was one of the design things that came from Steve early like it was…

Ken: Yes.

Frank: ….just like, look, this is not negotiable. I’m not shipping a physical keyboard.

Ken: That’s right. 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 gonna be shipping.

Frank: And what problems were you running into at the time? Like, were people missing keys, were the keys not big enough? Like what caused the…?

Ken: You know, again, I mean — in some ways, it’s hard to think back, given how history has played out, 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 two-thumb typing, and I’m hardly even looking, or whatever. Back when we were working at this early stage, and we were all new to interacting with touchscreens, we found that we had this real sense of apprehension. Apprehension, whenever we were gonna 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 hand a little bit out of the way, and you could see what you were going for. If the target was smaller than your fingertip, like, did I get it? I don’t know, right? And so we started…

Frank: You don’t have tactile feedback.

Ken: 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 touchscreen, it was just this sheet of glass. And so that’s the challenge with the keyboard, is that you needed enough keys to have a typing experience, right? But in order to give the number of keys necessary, the keys needed to be smaller than your fingertips. So what do you do? And so, it turns out that, you know — through investigation and lots of demos and lots of sleepless nights, right, that the way to close that gap was to give software assistance.

Frank: And so Henri waved 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…?

Ken: Yeah. We did this series of demos. See, again, going back to the way that it was in that hallway — and it was just one hallway, since it was so few people, sort of, 20-ish people. And we all had our individual offices at the time. This was not [an] 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 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 culture, we were all demoing to ourselves all the time.

And when we were set off on this thing, you’re all keyboard engineers — 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 work by themselves. Some people had a good relationship with one of the HI 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 maybe, 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.

Frank: Autocorrect. The author of autocorrect, which is now not only super useful on the phone, but probably my favorite comedy genre. You know, go watch the Facebook videos. Autocorrect comedies, they’re fantastic.

Ken: Well, sorry about that. So eventually, you know — the breakthrough, if you will, that made it possible for software keyboards to really work, you know, in a shippable product was software assistance — to the extent that the software may change the letters that you type. That it’ll change it to what it thinks, rather than what you did. And 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.

Frank: 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 you know, that type of thing. But like consulting the dictionary putting up suggestive words, like where did the idea come from?

Ken: It’s just this iterative process. It just takes, you know, a long, long time. You start with ideas, maybe somebody else does a demo — does an idea, and you had your idea, and you think, “Oh, maybe if I can combine those two ideas and make a demo of 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 was 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 cred for that on the hallway. Everybody knew who it was that came up with the idea.

Secrecy at Apple

Frank: I wanna talk to you a little bit about this, sort of, secrecy, right? You got led into the Holy of Holies — it’s 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?

Ken: It was tough — it required getting approval. It’s like, well, I’m gonna 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. You know, the way the Japanese works is that there is this input method — that there is a sophisticated way to take the keys that a user types and turn it into the Japanese language. A text that actually reads as Japanese.

And so that — and I just won’t get into the details of that. But it seemed like it was similar, in a way, I mean, 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 you know, in the end, it was just more of conceptual help than really, you know, anything concrete that I could put 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.

Frank: 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 the, sort of, tiers of secrecy inside Apple as a feature or a bug, or somewhere in between?

Ken: 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 gonna have a meeting. Who do we invite? Everybody. We’re gonna have a team meeting, right, where we’re gonna talk about important milestones. We’re gonna call everybody out of their office. Henri could say, “Hey, everybody, come out of your offices, please.” And within 30 seconds, everybody was…

Frank: Everybody is there.

Ken: …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? 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, 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, you know — and we tried to then really tap into the benefits that the smallness and the secrecy gave us as well.

Frank: 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 gonna be named. And so, like, the word iPhone wasn’t even in the dictionary…

Ken: That’s right.

Frank: …like after Steve launched.

Ken: That’s absolutely true. So there was — we were all heading toward this announcement for the iPhone in January of 2007. So if you remember how Steve introduced the product, he said — you know, he gave his very dramatic introduction, you know. So he said something to the effect of, well, we’ve got you know, a groundbreaking product — you know, and 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, 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 I didn’t get — and it’s like, oh, no, no, no, it’s just how he’s gonna tell the story.

Frank: It’s my product he’s talking about.

Ken: That’s right it’s gonna be…

Frank: That’s awesome.

Ken: …you know, the phone, and it’s, you know, gonna be you know, the touchscreen music player. And then, you know, the internet communicator. And 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 gonna have to go back the next day and add iPhone to the autocorrection dictionary.

Frank: That’s awesome that he fooled you too, because he fooled me, like, I — and like you were working on it, so I don’t feel quite as bad.

Ken: Again, the secrecy. 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 yeah, that was just the culture and the times and the way Steve liked to run things.

Frank: 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 would seem like that’s contentious.

Ken: Yes, it was. But one of the other things that we were really expert at, to bring back the word that we had 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.

Frank: Physical keyboard out, super early.

Ken: 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 got used to being in the team meetings where Henri, team engineering meetings — again, everybody is in the room. So we got 20 people in the room and Henri is, 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 [the] keyboard was just a constant throughout the whole, you know, 18-month development cycle. And so, we knew that we wanted 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…

Frank: The magnifier.

Ken: …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, you know, 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 and expand on that to do cut copy, paste. And it even got delayed an extra year, 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.

Frank: So, two releases before you run copy and paste.

Ken: That’s right.

Frank: And so I wanna get right into this because, sort of — look, Apple was famous for having exquisite taste around the design trade-offs. And a feature like copy and phase 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, 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? 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 test it. 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.

Ken: Well, it was simply a matter of setting the constraints and keeping them. You know, again, you know, 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?

Frank: Right. And now, there’s 40 people who can break the build.

Ken: That’s right. I mean, [it’s] 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. The touchscreen iPod, it’s the greatest iPod that we’ve ever shipped. It’s got all these great features. It’s a phone, it’s got web browsing that you can take anywhere with you now. And there’s no copy-paste — well, who cares? 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, he believed that the things that we did do, were good enough to counterbalance for the things that we couldn’t do.

Demoing for Steve Jobs

Frank: 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 for Steve. Like, what was the room like, who’s in there? Like, what’s the emotion of it? Everybody wants to know this, right?

Ken: It’s pretty…

Frank: It’s probably the scariest room in Silicon Valley.

Ken: It was pretty scary. Steve could be intimidating, there is absolutely no doubt about it. But you know, 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 the 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’re losing sleep over that thing, that they’re gonna 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.

Frank: That’s not what you would expect for Steve Jobs…

Ken: You wouldn’t think you think…

Frank: …coming out of performance, right?

Ken: …would be this pristine room …

Frank: Exactly, [a] beautiful blonde woman.

Ken: Like 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 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.

Frank: 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, or the keyboard with the little keys.

Ken: Okay, 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…

Frank: Lovely.

Ken: …and it’s actually a good one, which is 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 gonna be like? And so here’s an original iPhone, an original iPad — well, we’ve obviously got a bigger screen.

Frank: A lot of pixels now.

Ken: Right. So now what are we gonna 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 HI designers — one of my favorite HI designers that I really loved working with, and who I’d also collaborated with on the iPhone keyboard, Bas 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 made — really struck me, which was — he had a design that showed pretty much just a shrunk-down laptop keyboard to fit in this space. And so, what that meant is that I had two ideas — it’s 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 first started talking with Bas, 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 globe 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 to, you know — and again, the idea of, what are we gonna do with this larger screen real estate for the iPad, right? A software key.

Frank: The idea was, give the user choice.

Ken: Give the user choice.

Frank: I have these pixels.

Ken: Give the user choice.

Frank: I have the real estate.

Ken: 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.

Frank: To the man.

Ken: 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 Forestall, Greg Christie, Henri — people that I’ve mentioned — so, you know, the chief managers for iOS. And then a couple of HI designers, like Bas Ording, the fellow that I collaborated with on this keyboard, was, you know, almost always in this meeting. Another fellow, Steve Lemay — another HI designer — was often in the meeting. But as I recall, he wasn’t in this particular one where I was demoing the keyboard.

Frank: So half a dozen people-ish.

Ken: Half a dozen people in the room, yeah. And so then what would happen is that people like me who had individual demos — 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 — or my — you know, how I would figure is, 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.

Frank: Waiting for my turn.

Ken: That’s right. You know, and so he sends me a text, “Go stand outside the door,” and then, you know, the door is gonna open, I’m gonna get invited in. So I get the text, I go stand outside the door. And you know, 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. I’m gonna 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…

Frank: He’s on the phone.

Ken: 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, right? And so you know, it’s pretty uncomfortable. And I think — I actually do think that he was talking to Bob Iger, the head of Disney.

Frank: Disney.

Ken: Disney, right. And so he’s like, “Yeah, Bob, yeah, that sounds great. Yeah, I’ll call you next week. Yeah, great talking to you.” So then you know, he hangs up. And then he does this thing, he takes his iPhone — he puts, you know, his phone back to his pocket. And then he does this, right? It’s like, I don’t know if you know — it’s 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, then, 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, used 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 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 gonna 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.” So I said, “Yes, Steve, go and look at the demo it’s on the screen now. Try the zoom button.”

Frank: And that’s it.

Ken: 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, turning his head to see what it looked like, like in his peripheral vision. It’s like he’s just — it’s just incredible to see — what does Steve do when he evaluates product? Okay, so this is what — and it’s what he did. And he hadn’t even touched it yet, he was just looking at it.

Frank: And this is going on for a long time.

Ken: You know, it seems — it’s like one of those things where it was probably maybe 20 or 30 seconds that felt like 20 minutes, right? But he took a long time to study, and then, eventually, he goes out and touches the zoom button. And this zoom button to change between the two keyboards — in this case, shrinking the keys down to be the more laptop-like keyboard layout. The animation that Bas 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?”

Frank: You’re like, I’m on the hot seat.

Ken: And I’m like, “I guess so.” And then he says — I mean, this is again the interesting part. He asked 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 the room. He asks me, the individual contributor. You know, he’s coming in…

Frank: You’re the DRI.

Ken: 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.

Frank: Not the DRI anymore, with that answer.

Ken: And I had no idea that this was what he was going to ask. But in that moment, I came up with an answer, because I thought about my experience with these two keyboards. And I thought that, you know, the one with the bigger keys, I found more comfortable. I was getting to be, you know — that maybe with, you know, like four or five fingers, that I could touch type. And auto-correction was helping. So that’s what 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.” Demo over. And you know, the interesting thing is that, then, that’s the keyboard that shipped on the product — with the slight modification of taking away the zoom button, which was now no longer needed, 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 experience was then something he was interested in tapping into to provide a way forward for the product.

Frank: 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? Were you like…

Ken: Yeah, well, you just know that that’s not…

Frank: That you’re not supposed to do that.

Ken: That you’re not supposed to do that. I would imagine that if [I] 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 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 engineer, 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, you know, one of the nice people, you know, working in the Apple Store. But gosh, wouldn’t it be better if I can figure this thing out for myself, and decide for myself? And see the evidence of the care that the engineers and designers had put into the work. I can decide for myself — yeah, this is a thing I wanna take home with me, right?

Steve Jobs’ lasting influence

Frank: 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 wanna 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 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?

Ken: Yeah, I think 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 on YouTube of old videos with Steve — maybe, you know, on stage with Walt Mossberg and Kara Swisher at their, you know, AllThingsD Conference. Or, I just had a reason to go back and look at the Antennagate….

Frank: Oh, I forgot about that.

Ken: …because — and the reason I did this is because, you know, it’s current now that there was a bug in group FaceTime. And Apple issued an apology saying, “We’re sorry that we had this problem, and we’re gonna be fixing it,” whatever. And so I wanted to go back and see well, what did Steve say about Antennagate — 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’s really interesting — this is on YouTube, you can go and look at it. And Steve held a little press event. And you know, he was just very, very clear — very, very 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, you know, absolute monarch, you know —  21st-century absolute monarch now in a company rather than a government. Or, you know, all of 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.

Frank: And then, sort of, how did the organization morph itself to, sort of, reflect that you had this, you know, great tastemaker — who wanted to make these decisions that are, sort of — very granular level in the design? So there was an example where you were designing an animation. I think it’s, sort of, the scrunched zooming demo. And you got to the point where, like, Steve and Scott Forstall actually disagreed. So maybe tell us a little bit about that and…

Ken: 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 we 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 know, 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. You know, you take it out of the box and you bring it home. And yeah, you launch Mail and you launch Safari, you’ve 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.

Frank: End of list.

Ken: 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.”

Frank: That’s super interesting. They didn’t have a say in what it’s gonna look like.

Ken: That’s right.

Frank: You’ve taken away their taste.

Ken: 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…

Frank: End of list.

Ken: …end of list animation, he did it, he did it again, and he didn’t look up. He said, “This is Apple.”

Frank: Awesome.

Ken: So it’s a pretty good moment for me.

Frank: How did you stop yourself from like, doing the victory lap? Woo-hoo.

Ken: He thought that it was — you know, sort of, tapping into the — excuse me, the little, sort of, whimsical aspect that went all the way back to, sort of, like the happy Mac on the original Macintosh, right? That it was this whimsical little animation that showed that the system has this playful character to it. And that was an aspect that he really loved. And so — and it also just goes to show that there could be disputes, even up at the highest level. Scott knew that I was very excited about this feature and wanted to show Steve, so he let me. And Steve was the one who had the final vote, and he sided with me in that instance.

Frank: 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?

Ken: But again, 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, is that if you brought him shoddy work that was, like, you know, 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…

Frank: Never get invited back to a demo, right?

Ken: It’s a way to 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 wanna 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.

Benefits of a blended background

Frank: 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 you’re sort of…

Ken: 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 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 — the part of the approach was that these devices are a part of people’s lives, righ? More and more now, to the extent that now, right, we think that there’s a problem with the amount of time that we’re spending looking at the screens, right, that we need to have apps and features on the phone to help us track, right?

Frank: Too much screen time.

Ken: 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, 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 — you know, you’re gonna ask well, what is it good for? You know, why do we do this feature rather than that feature? I think that yeah, that’s a liberal arts process.

Frank: Tell the story, if you would, of how you guys arrived at the home screen app icon size, right? It was a fun liberal arts twist to this, right?

Ken: Okay. So now, you know, going back to a phone that looks more like this, 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, 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 gonna 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 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 Herz. He was doing work on SpringBoard, the icon launching program himself. And so, he had this idea, is that — I’m gonna make a game. It’s the first-ever iPhone game.

Frank: iPhone game.

Ken: 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 standalone enclosures yet. So we were still at this phase where we had touchscreens that still needed to have a wire tethered to it. But still, we were trying to figure out 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 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 in some other random position on the screen. And the idea was to just go as quickly as possible, without, again, being, sort of, weighed down by the feedback of whether you were succeeding or failing. And you would get, then, 20 of them — and then it would give you your score, right? And so it was fun, right?

Frank: Before “Angry Birds…”

Ken: Before “Angry Birds,” we had the little…

Frank: …was random rectangles.

Ken: …rectangle going around. Now actually, what he was doing — he also wrote the software so that he was tracking, rectangle by rectangle, whether people were succeeding or failing. And also based on where the rectangle showed up on the screen. And within a couple — of 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 pixels square. And since that was a good number, we never changed it. And so that’s what wound up shipping on the iPhone.

Frank: Yeah, I love that story, that it was, sort of, a game that led to it — as opposed to, “All right, we’re gonna do every possible pixel variation. We’re gonna bring people in to test it and we’ll see what works.”

Ken: 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.

Advice for getting into tech

Frank: 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?

Ken: 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. You know, and one of the wonderful things we mentioned, open source, you know, 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.

Frank: They were thousands of dollars…

Ken: Thousands of dollars, there was no way…

Frank: …back in 1984 dollars.

Ken: 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 — you know, again, if you want to do something, just start doing it. So that’s one piece of advice.

And then the other piece of advice is, yeah, you do need to look at more than technology. Again, for the reason that I said a few minutes ago, which is — these technological artifacts that we’re making now have become so important to people, that if you don’t know anything about people, right? I don’t think that 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.

You know, if you can answer those questions for yourself, it would be, then, hard as 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 in, say, a product company like Apple. You’re gonna be making decisions on products that are then gonna go out in the world and are gonna be affecting other people. Other people are gonna 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 gotta actually have good ideas. And again, it’s the liberal arts that provides the grounding for that.

Frank: Super. And it’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, what’s beautiful?

Ken: And really, you know, it’s unfortunate that there are so many questions like that. Well, obviously, linked lists — we’re still going to have need for those as we go into the future. But you know, the work that — much of the work that I did in my life, there was no way that I could have predicted, right? When I was handed, you know, a piece of hardware like this, and said, “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 flexibility and 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 the technology is gonna change.

Frank: 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 Scott Forstall? Like, is the absence of those ingredients — like, I’m not gonna join that company. Or, 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?

Ken: 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. 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 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.

Apple’s culture of collaboration

Frank: In your book, there’s, sort of, a couple key ingredients that you, sort of, distilled the Apple experience down to. Like, 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?

Ken: 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 Bas Ording 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 Bas 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 you know, to the extent — again, you know, 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 could write it into the claim language? And maybe if we’re gonna take that claim and move it to a separate patent, we have to know who to put as the inventor.” And Bas 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 complementing 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 Bas came up with an idea, or I came with an idea, it didn’t matter.

Frank: It wasn’t a strong attribution culture, right? Oh, that’s his idea, and like, how dare you claim that that was your idea?

Ken: And I can’t work on that. And now my manager is gonna get involved because now I’m not gonna get the credit for it and whatever. It just wasn’t like that.

Frank: But you still had to have strong DRIs, right?

Ken: Yeah. But that is also one of the ways that just made it clear about — you know, if I was collaborating with someone like Bas, or just some other engineer, 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 gonna go to the mat, and they’re gonna say, no, I think Ken made, you know, 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.

Frank: Well, Ken, it’s been a fascinating conversation. Thanks so much for taking us inside the chocolate factory. Like, the chocolate factory did not have very many people. So I feel really blessed that, you know, one of those people made it out and is willing to lead the tour and talk to us. And maybe that’ll be the last question I ask you, which is — you know, the famously secretive Apple Corporation, right. Did you have to get their approval to actually write the book and tell the stories?

Ken: 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 I think 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, 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 for forgiveness if somehow they didn’t really approve. But I thought that I wouldn’t really run into trouble.

Frank: 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, thank you so much.

Ken: I’ve had a great time. Thank you.

Frank: 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 wanna try in your own culture, now having listened to, sort of, Ken describe what it was Apple — what Apple did, sort of, what would work in your environment and what wouldn’t work in your environment? Would 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.