Inside Apple Software Design

Frank Chen: Welcome to the A16Z YouTube channel. I'm Frank Chen, and today I am so excited. I feel like I have won the golden ticket to Willy Wonka's Chocolate Factory. Because look, if you're in Silicon Valley, the one chocolate factory you want, you're desperate to go visit is Apple. And the reason for that is Apple has consistently over its history turned out some of the most intuitive and delightful and just plain awesome products that people use. And people are dying to find out how is it that Apple makes such delightful products.

Frank Chen: 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 Kocienda: Well, thank you so much. It's great to be here with you.

Frank Chen: Well, let's get right into it. So maybe talk a little bit about how you ended up at Apple, because on paper, you don't look like the typical software engineer. So go back and do the long run. Like, where were you born?

Ken Kocienda: 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 mechanics school.

Frank Chen: Really? Ivy League, what motivated that?

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

Frank Chen: I think that qualifies.

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

Frank Chen: At least he didn't have an Asian parent.

Ken Kocienda: Well, I think my dad was pretty confused about the choice. But eventually they got behind and supported that. And so I fixed motorcycles. And then I wasn't really quite sure what I wanted to do. I had this degree in history. But I wanted to kind of keep following my nose to find new and interesting things to do.

Ken Kocienda: 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 Chen: Beautiful buildings on campus.

Ken Kocienda: Oh, for sure, yeah. Very interesting architecture, the art and architecture building in particular. Well, anyway, so I became more interested in photography. I wound up getting a job at a newspaper in the New York area, Newsday. Did two years there working in their editorial library with their photo archive. But then I kind of decided that wasn't really going anywhere fast enough, so I moved to Japan.

Frank Chen: Wow.

Ken Kocienda: And I had a three-part plan for going to Japan. I was going to photograph myself, make a portfolio of my own work. And I thought that it might be interesting to get some teaching experience. So I taught English. And I was chasing a girl.

Frank Chen: And not in that order, right?

Ken Kocienda: That was the three-part plan, right? Photograph, teach, chase a girl. I wound up catching the girl. And so we've been married for, it's going to be 25 years.

Frank Chen: Oh, congratulations.

Ken Kocienda: Just a couple months here.

Frank Chen: That's so awesome.

Ken Kocienda: And so after that, I took 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 aside. I just set that aside because I saw the web for the first time. This was probably 1994. And I thought it was the most amazing thing.

Ken Kocienda: So Mosaic, and the professor, oddly enough, loaded up one of the few websites comparatively that was available. Then Yahoo when it was text only.

Frank Chen: Right, right.

Ken Kocienda: And so to me, the interest was, I'm going to make photos show up on this thing. I'm going to take my experience, my love of fine art and liberal arts and figure out how to make that come alive on the web. And then just wound up getting more and more into programming. I graduated, or I left RIT without graduating with any degree. But by that time, I'd learned enough to go get a job at a web development company and wound up making websites.

Ken Kocienda: And this startup, that startup, the next startup, I wound up at a company called Eazel.

Frank Chen: Oh, right, of course.

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

Frank Chen: Right. Every year is the year of desktop Linux.

Ken Kocienda: The desktop Linux, we thought that 1999 or 2000 was going to be the year of desktop Linux. It turned out not to be.

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

Ken Kocienda: I actually worked on the portion of Nautilus that connected to these sort of proto-cloud services.

Frank Chen: Right.

Ken Kocienda: And interestingly, our cloud, interestingly for where I am here, Andreessen Horowitz, we hosted our cloud services at LoudCloud.

Frank Chen: Oh, thank you very much. Yes. Yes. Very good customer. So we went ahead with that project, but of course, that company didn't succeed. But of course, Eazel had this longstanding connection through some of its principles, Andy Hertzfeld, Mike Boyd, Bud Tribble.

Frank Chen: Yeah, the legends, right?

Ken Kocienda: Macromedia. And that got me an introduction to Apple. I started Apple in 2001 and started getting into making the web browser for Apple was my first project.

Frank Chen: That's fantastic. And why don't we get into that story? Because, as you tell in the book, you sort of started experimenting with the old Netscape code base, called Mozilla, I guess, by then. But you ultimately didn't go that way.

Ken Kocienda: Right. Well, 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, on Mac OS X, the new version of the desktop operating system replacing the old classic version of Mac OS that had been shipping on the computers since the 80s. So it came along with this Unix-based replacement. But that system didn't have its own web browser. It was still part of the agreement that had been made a couple of years earlier with Microsoft to provide Apple with web browsers.

Frank Chen: So Internet Explorer. When Bill invested.

Ken Kocienda: That's right. He brought Office to the Mac and then IE became the default browser.

Frank Chen: Correct. People don't remember this anymore.

Ken Kocienda: Correct. But that was the situation that Apple was in. This exciting new technology, the web, was something that wasn't under its own control. And so the vision for Apple back then and even still today is that Apple wants to be in control of what it considers to be critical technology that gets critical to its user experience.

Frank Chen: Yep.

Ken Kocienda: And as all the operating system companies decided, the web browser was critical. It wasn't an optional add-on component.

Frank Chen: Sure. Netscape and Microsoft famously got into a legal battle over this. So Apple arrived at the same insight.

Ken Kocienda: Yeah. And then interestingly, the two code bases that you considered to get Safari off the ground were Mozilla, the Netscape code base, and then Konqueror, which was a Linux web browser. They were both open source. So talk to me about what it felt like at the time to be looking at open source inside Apple, which is famous for "we'll build it all ourselves."

Ken Kocienda: It was interesting that the executives, people like Avi Tevanian, who was the chief software VP at that time, and Steve, were willing to consider open source. But just to give a brief summary of our full investigation, we considered writing a browser from scratch. We also considered going out and licensing from a company like Opera. There were many who would license you browsers back then.

Frank Chen: Right, right.

Ken Kocienda: But Don Melton and I, the two people who joined on the same day in 2001 to begin this browser investigation, we looked at open source because we were a team of two people. And a web browser is a pretty complicated thing. It's harder than it looks.

Frank Chen: It's harder than it looks.

Ken Kocienda: So we thought that if we could make a compelling case to use open source as a way to jump ahead in the effort, stand on the shoulders of giants, it would get us to a point where we would have something sooner. And that was really the goal. And being open source, if we took this software from, say, another platform, neither Mozilla nor Konqueror worked on the Mac. So we were going to have this opportunity to bring this code from elsewhere and make it Apple's own and really make it look and feel like it was a native program to the Mac.

Ken Kocienda: So looking at that, it really just came down to Konqueror was one-tenth the size of Mozilla. And so as a two-person team, soon thereafter a three-person team, this was the easiest way to get from where we were to where we wanted to be.

Frank Chen: 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 AIX, here's the one for Digital Unix, here's the one for AIX, here's the one for HP-UX, and here's, by the way, is Windows 95, Windows 98, Windows NT." It was such a cross-platform exercise. The code base sort of grew and grew.

Ken Kocienda: Sure. And so we only had to do that once. 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 keep all of these platforms going concurrently as you're trying to make improvements and add features and make things better.

Frank Chen: Yeah. And so you ultimately decided on the Konqueror code base as your starting point. And then pretty early in the development process, you ended up building a stopwatch, the PLT.

Ken Kocienda: Right.

Frank Chen: So maybe talk a little bit about why you decided to do that. And then ultimately, flash forward, when Steve announced the browser, he would say, "This is the fastest." It was one of the key features. Did you know at the time that you built the stopwatch that he was going to do that? Or did you get lucky?

Ken Kocienda: No, no, it was not luck at all. Steve was very, very clear to us at a very early stage in our browser development process. 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. And so if you think about the challenge that we had, there was this existing browser on the platform, Internet Explorer, that people were familiar with. And so now we're going to 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 what is going to convince people to make the change?

Ken Kocienda: And so Steve thought, "Well, we're going to need a compelling argument. And to be compelling, it needs to be simple." So his idea, his vision was, "Look, we need to make this thing perform fast." Thinking back to the time, the network wasn't so fast. Some people were getting maybe broadband at the office, but certainly at home, you're still doing dial-up.

Frank Chen: Right.

Ken Kocienda: And so anything you 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.

Ken Kocienda: So this PLT, the Page Load Test, was this performance tool that we used during our daily development so that every code check-in that we had, we would run our page load test to see that there were no speed regressions. We had this idea that was really Don Melton's idea, who was the manager of the team. He had this little bit of sneaky logic where he said, "Okay team, if we check in code and it doesn't make any speed regression, only two things can happen. Either the code will remain the same speed or it'll get faster."

Frank Chen: Right.

Ken Kocienda: And again, it's just one of these simple things that turns out to be this profound truth. Because as we would go over the weeks, the months, hundreds and hundreds and hundreds of check-ins, that's what happened. The code either stayed the same or it got faster. And over time, because there was this speed priority straight from Steve, we would look for ways to make it faster. And eventually, Safari, when it was released, it was three times faster than IE at loading web pages.

Frank Chen: Yeah, that's fantastic. And the point is, again, 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 sheer force of his personality. But this was more of a matter of him just saying, "Well, we executed on this plan, we got a great result, and here it is."

Frank Chen: So I love this idea that Steve set this goal early on: "Ship the fastest browser that you can ship, because when I launch it, that's what I'm going to talk about." And as I was thinking about the software development process, 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. How important do you think that was to your age of design?

Ken Kocienda: Yeah, I think the way that Steve organized the company and built the teams, built the culture, was an essential part of how we did our work. And the way I like to describe it is that Apple was this wonderful combination of top-down leadership and bottom-up contributions. So Steve, the top-down part, I think is almost well-known. Steve was very, very clear. He could be domineering in pushing his vision forward. So when you worked at Apple in software development, you knew what the vision was. That was always very, very clearly communicated. But it still was just a vision.

Ken Kocienda: Now, sometimes he would get specific, but most of the time he would just tell us, "I want a great browser and it's got to be fast." And so with that as a brief handed over to the engineering team, it was our job to figure out how to do it. And so then that's where the bottom-up contribution comes from. He didn't say, "I want you to make a performance test and I want you to institute this policy where every check-in doesn't allow any speed regression." We came up with that, providing that bottom-up contribution that helped to realize the vision.

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

Frank Chen: And was Steve at the demo at that point?

Ken Kocienda: He would see the code very, very often.

Frank Chen: So that's a little unusual. Compare that to a typical Silicon Valley company where you're doing these demos frequently. In general, you think of the CEO of a company this size not being involved in every single milestone. Because you're Safari on Mac OS. Mac OS is one of the many products that Apple was shipping at the time. So it seems unusual that the CEO would be involved in this many demo points. How important do you think that is to the...?

Ken Kocienda: Well, see, and I'm actually going to dispute one of the things that you said, if I may. Certainly during the Steve Jobs era, and I still think to today here in 2019, Apple didn't ship a whole lot of products. Back then, Steve quite famously, when he reestablished control over the company, he came up with that product matrix. We're going to have a consumer product, a pro product, a desktop product, and a portable product. And so we've got four products. And it's the same operating system, macOS. And so there's actually very, very few products.

Ken Kocienda: Now, interestingly, when I joined Apple in June of 2001, macOS 10 had come out. And so we had that two-part product matrix that we were still working in. And that was still four months before the announcement of the iPod, which was just the beginning of Apple expanding out from being Apple Computer to being Apple Inc. You get into more consumer-focused products that weren't really thought of as being computers. But because there were so few products, Steve could keep tabs on what the software teams were doing. There was this big initiative to make a web browser, so he could find the time on his schedule to get updates on how the software was doing, and he did.

Frank Chen: Yeah, so it was a focus thing. Steve saying, "Look, we're not going to have that many SKUs, we're not going to have that many products. Then I can put all my eggs in one basket and watch that basket very carefully."

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

Frank Chen: So you ship Safari. It's an awesome browser. Fast, native. You get a lot of people to switch over. And then at that point in your career, after having been this individual contributor that shipped this awesome product, you thought, like many people in your shoes, "Time to be an engineering manager." So maybe talk a little bit about that story of how you thought about it, how you got the job, and what the job was like when you got it as your first engineering manager job.

Ken Kocienda: I always try to think about what's next, and I don't really have a big career vision. Especially the tech world, it changes so fast. 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 this new domain that I didn't have a lot of experience in. And so I thought that this would be an interesting opportunity. And so I pushed for it. I asked for it. And it was actually Scott Forstall, the software executive, really instrumental in coming up with a lot of the interesting user interface work in the iPhone software project later, which I'm sure we'll get to. But he was the one who was in my management chain who gave me this opportunity.

Ken Kocienda: 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. There were no phones, no iPod.

Frank Chen: Right, right. Okay, so it's like you have a desktop computer in the office, you have a desktop computer at home, or maybe you have a portable and a desktop. And it was to get those systems exchanging some data, your contacts, your address book, things like that.

Ken Kocienda: And so I thought this was an interesting challenge, and people were going to be getting more devices and things like that. But I found that very soon after I got into the job that I was miserable. I hadn't really reckoned at that point in my career with what management really is. It's about people. I was still, at that point in my career, still fascinated by the software itself. That's what attracted me to Sync. It seemed like this distributed computing problem, and I was enamored with the technology. You had client server, and all of this. And not really thinking about how the right focus was to build a team, build a team culture, support the people so that they could do the technology. And 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 Chen: Yeah, it's the lament of a lot of first-time managers. You think on the other side of it, "Of course I want to manage a job. It's the way up. It's the natural hierarchy." And then you get there, and your job is about shipping a team and not a product. And a lot of people go through that: "Oh, I didn't want to ship a team. I want to ship a product."

Ken Kocienda: Right.

Frank Chen: So it sounds like that's what you did. You sort of went back to being...

Ken Kocienda: Yeah. Well, I had a... I'm almost ashamed to say, it was like a mini meltdown. And I went to Scott Forstall and I said, "Hey, look, Scott, I don't want to do this. I led you astray, led myself astray. I quit. I offer to resign." Because a part of 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 the only thing for me was really just two choices. I could continue on being miserable about it, or I could just go and say, "Look, I'm done with this. I submit my resignation."

Ken Kocienda: So Scott was like, "Whoa, whoa, whoa. Just a second. Stop right there. I want to understand what's going on." So I explained to him what I just explained to you about really wanting to still be in closer touch with the technology. And so he said, "Okay, well, just go away." He was not pleased with me.

Frank Chen: Yeah.

Ken Kocienda: "We got you the management job you asked for. You said that you wanted. And now you're coming back a couple months later saying that you want something else. What's going on?" So, yeah, he wasn't that happy.

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

Ken Kocienda: Yeah, I mean, because I thought that I was resigning. So I just need to go get another job. So I actually did. I went to Google. Full interview cycle. I went and did the interview process at Google, and they offered me a job.

Frank Chen: So you were serious. You were ready to go.

Ken Kocienda: I was serious. Yeah. I was serious. But I turned it down. I turned down 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 days later, it was actually my direct manager at the time who 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 reached out, I signed the paper, and he said, "Yeah, we're making a cell phone."

Frank Chen: Yeah.

Ken Kocienda: And you're now on the team.

Frank Chen: So that's fascinating. This is a great part of Apple that's very different than most Silicon Valley companies. In most Silicon Valley companies, if you get assigned to another project, there's not this level of secrecy. You're not signing papers. So tell me a little bit about that. What did they read you into at the time? It was Purple at the time, right? What's the code name?

Ken Kocienda: The funny thing is that at Apple, I was already under this blanket non-disclosure agreement. You couldn't say anything about it. For the whole time that I worked there, I was under these document retention orders. I would get these periodic emails from the lawyers saying, "Do not destroy anything" because of the work that I had done was then submitted in patents, and perhaps there was going to be patent litigation. So this is the whole mindset, the whole culture of what Apple was. There was secret. We were doing patentable work. We were trying to innovate, and we were interested in treating that work as trade secrets, something that was valuable to the company.

Frank Chen: So already super secret culture.

Ken Kocienda: Already. And then you have to sign something which is, "I'm going to introduce you to an even more secret culture."

Frank Chen: Even more. Inside Apple, it's kind of like when you do the logic classes, infinite sets can be larger than other infinite sets.

Ken Kocienda: That's right. Now you're in the larger.

Frank Chen: That's right. Now you're in a bigger, deeper, darker infinity.

Ken Kocienda: That's right. It is a bottomless well, truly. And so, yeah, I had to sign this additional NDA. And I got introduced to this project. It was called Purple. The code name for iPhone, and it was in development. And my job was to join the software effort, which at that point was maybe six or eight people.

Frank Chen: That's a tiny team.

Ken Kocienda: It's a tiny little team to do what I like to term the high-level software. The plan was that we were going to take as much of the Mac as possible and bring it over and squeeze it into one of these tiny little smartphone form factors. And so we were going to take the operating system kernel and some of the low-level libraries, the networking stack, things like this, the graphics stack. But above the level of Core Graphics, which was the low-level graphics library, above that, I was invited onto the team that was going to invent the touchscreen OS. So we weren't going to take any of the mouse tracking or handling or anything of AppKit, which was the user interface level software for the Mac. We were going to make that from scratch for the phone.

Ken Kocienda: So what became UIKit, for people who know about the technology for what became the iPhone software, iOS, that was our job. And so we started with a clean slate, and that slate was pretty well cleaned when I joined, again, just about six or eight people on that effort at the time.

Frank Chen: 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. What are the roles? Are there product managers? Are there UX designers?

Ken Kocienda: Right, 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 called the Human Interface team, the HI team. And that was the team of designers. They would do graphic design, animation design, but they would also do concepts. They would provide the thinking behind what is going to be the experience of the person that is going to be using this product that we make.

Ken Kocienda: And so there was this small team: half a 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 of the HI team. They both reported to Scott Forstall, who was the executive, who reported to Steve. And that's it. That was the team. Now, eventually, we wound up adding more people over time. 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.

Frank Chen: Yeah, super interesting. There were no product managers.

Ken Kocienda: No product managers, no QA engineers, until later.

Frank Chen: Until later, yeah. So the core of it that got the whole product going is software engineers, human interface designers, and executives.

Ken Kocienda: Yeah, we added then a program manager. So there were maybe like two people just managing the schedule, tracking risk, looking at the bugs. A couple of QA people joined. But at Apple, certainly from my standpoint, I consider them engineers. They're the QA engineers. But still, that still is all encompassed in the numbers that I gave you. And in a way, I say there were no product managers. But I would say that we had one product manager.

Frank Chen: There's two ways that I could say it. We either had one product manager, Steve.

Ken Kocienda: Right. Yes, the ultimate decider. Right?

Frank Chen: Or that we all were. We all were. It was all our responsibility to make sure that the product was going to be great for people. We all shared commonly in that responsibility. So that's really interesting because you sort of distribute the responsibility. Now it's everybody's responsibility, but a lot of companies would think, "Oh, I've got to have a throat to choke. I've got to have the one person." But of course at Apple, one person was Steve.

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

Frank Chen: Oh, yeah. Let's talk about this.

Ken Kocienda: So we had DRIs. 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 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. We had what was really quite unusual, really unique in my experience at Apple: the development of the software keyboard was judged to be a sufficiently high risk, and the risk was not being matched by commensurate progress. The whole thing was high risk — we're going to make a whole new touchscreen operating system. But we were making good incremental progress on most areas: touchscreen, UI kit, Safari, messages, calendar, the phone app. The touchscreen keyboard was lagging behind all of these other projects.

One day, unique in my experience, Henri, who was the software engineering manager, called all of the engineers out of our offices into the hallway. We had a group meeting — about two dozen people, probably even less — and he said, "Okay, you all stop. Stop what you're doing. Stop working on calendars, phone, app, the user interface level software, everything. Starting from now, you're all keyboard engineers."

Frank Chen: Wow, that is crazy.

Ken Kocienda: Yeah. Entire team. Everybody's a keyboard engineer. The idea was that if we don't crack this problem, we might not have a product.

Frank Chen: I think we need to take people back to that era. This seems super counterintuitive, putting all 20 people on one project. Take us back in time. The most popular phone at the time was the Crackberry, right? The RIM Blackberry. It has a physical keyboard.

Ken Kocienda: It has a physical keyboard. This was in the fall of 2005. To give the time perspective, Steve stood up on stage and announced the iPhone in January of 2007. This is a really compressed timescale — less than a year and a half out from that target.

Frank Chen: 18 months, not a lot of time.

Ken Kocienda: We still had really nothing to show for this effort to provide a solution for our phone, which would compete with the BlackBerry. The BlackBerry had this wonderful hardware keyboard, the little plastic keys, click, click, click, click. You said the word CrackBerry — people loved that product. But we were going to provide a different vision for what a smartphone would be. There wasn't going to be enough room for a plastic keyboard with fixed keys. We were going to give more of the front of the display over to a screen, to software. The keyboard had to be in software.

Frank Chen: The idea of an all software-based keyboard was one of the design things that came from Steve early. Like it was non-negotiable. "I'm not shipping a physical keyboard."

Ken Kocienda: 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. The keyboard being in software meant it could get out of the way, go off the screen, which would make the rest of that screen real estate available for a customized user interface optimized for the phone app or the calendar. It was absolutely essential that the keyboard could get out of the way when you weren't using it.

Frank Chen: What problems were you running into at the time? Were people missing keys? Were the keys not big enough?

Ken Kocienda: In some ways it's hard to think back given how history has played out. We have our phones now and I'm two-thumb typing hardly even looking. Back when we were working at this early stage, we were all new to interacting with touchscreens. We found that we had this real sense of apprehension whenever we were going to touch a target on the screen that was smaller than our fingertip. That was a really interesting threshold. If the target was larger than your finger, you could target it because you could move your head a little bit out of the way and see what you were going for. If the target was smaller than your fingertip, it's like, "Did I get it? I don't know."

We didn't have the tactile feedback of that Blackberry. You could feel the edges of the keys with your fingers. With the touchscreen, it was just this sheet of glass. The challenge with the keyboard is that you needed enough keys to have a typing experience, but to give the number of keys necessary, the keys needed to be smaller than your fingertips. So what do you do? Through investigation and lots of demos and lots of sleepless nights, the way to close that gap was to give software assistance.

Frank Chen: So wave the magic wand, everybody is now a keyboard engineer. Everybody needs to figure out how to make a reliable keyboard that's delightful. What happened from that point? Was it a series of demos?

Ken Kocienda: We did a series of demos. Going back to the way it was on that hallway — just one hallway, since it was so few people, 20-ish people. We all had our individual offices. This was not an open plan office. Everybody had their office. I would be in my office with my door closed, come up with a demo, an idea that could be represented in a demo. Then I open the door, go see who else's door is open, and say, "Here, try this." We had this culture of demoing to ourselves all the time.

When we were set off on this — "You're all keyboard engineers now" — we all went in our own directions. Some of us had well-established collegial relationships where I would collaborate a lot with you. Some people worked by themselves. Some people had a good relationship with one of the HI designers. We cobbled together our own little teams, our own little efforts, and started making demos, trying to combat this problem of the keys being too small.

One idea 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. Much like we have today, there's a bar on top of the keyboard that updates as you're typing, giving you some notion of what the software thinks you're trying to do. Auto-correct — the author of auto-correct, which is now not only super useful on the phone, but probably my favorite comedy genre. Go watch the Facebook videos on auto-correct comedies. They're fantastic.

Frank Chen: Well, sorry about that.

Ken Kocienda: Eventually, the breakthrough that made it possible for software keyboards to really work in a shippable product was software assistance to the extent that the software may change the letters that you type. It'll change it to what it thinks rather than what you did. This phrase is really important — one of the important organizing concepts for so much that we did to make the touchscreen operating system work. Because you didn't get tactile feedback, you couldn't feel the edges of keyboard keys or any button in the user interface. The software had to be there working behind the scenes to give you what you meant, maybe differently than what you did.

Frank Chen: How did you come up with this idea? This is classic thinking outside of the box. If you were trying to solve this problem, I bet you saw a lot of variations of key sizes. But consulting the dictionary, putting up suggested words — where did the idea come from?

Ken Kocienda: It's just this iterative process. It takes a long time. You start with ideas. Maybe somebody else does a demo with an idea, and you think, "Maybe I can combine those two ideas and make a demo that does the best of everything I see." It was this collaborative soup of ideas all swirling around. All of us had a sense of friendly competition. We all wanted to do the best. We all wanted to be the one to crack this hard problem. But it was all very friendly. If your idea wound up winning, proving useful, you got a little bit of geek cred for that on the hallway. Everybody knew who it was that came up with the idea.

Frank Chen: I want to talk about this sort of secrecy. You got read into the holy of holies. It's more secret than other parts of Apple. 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 they hadn't been disclosed. What was that like to try to go get their help? Was it offered?

Ken Kocienda: It was tough. It required getting approval. There was no process at that point to get them disclosed. Steve was still personally approving every person submitted to get disclosed on the project. But I did get permission to talk to them, as long as I told them, "I can't tell you why I want to know how the Japanese input method works." The way Japanese works is that there is a sophisticated way to take the keys a user types and turn it into Japanese text. It seemed similar in thought process — we have this real software whirring away in the background, different from a desktop keyboard where if you type the A, you get an A. I went and talked to them, but in the end, it was more conceptual help than anything concrete I could put into the software. The problem I was trying to solve — input correction, not being sure what key you hit — was a class of problem different enough that it required different solutions.

Frank Chen: Looking back, with the extreme secrecy, you couldn't really describe the problem. You got conceptual help but not concrete design help. Would you think of these tiers of secrecy inside Apple as a feature or a bug, or somewhere in between?

Ken Kocienda: Yes. I think there is a really underestimated power in keeping your team small. The cohesion, the small unit cohesion where simple things like having a meeting — who do we invite? Everybody. We're going to have a team meeting. Henri could say, "Hey, everybody, come out of your offices, please," and within 30 seconds, everybody was standing there. There are advantages to keeping things really small. Then there is the disadvantage that when you're trying to tackle difficult problems, you may not have all the talent you need, or a sufficient amount of diversity. A company like Apple is trying to make products for everybody. How do you design for everybody if the design team is a microcosm of everybody? There are profound challenges. Back in these times, we did the best we could within the constraints, and we tried to tap into the benefits that the smallness and the secrecy gave us.

Frank Chen: Another funny thing I learned reading your book — the secrecy was so extreme that you didn't even know what the product was going to be named. The word iPhone wasn't even in the dictionary after Steve launched.

Ken Kocienda: That's absolutely true. We were all heading toward this announcement for the iPhone in January of 2007. If you remember how Steve introduced the product, he gave his very dramatic introduction. He said something to the effect of, "We've got a groundbreaking product. You're privileged to be involved in a product like this maybe once in your career." But Steve had been involved with the Mac and then the iPod. He said, "We're going to have three new products of this class today." I'm thinking, "Wait, there were two other secret projects that I didn't know about?" Truly for a moment, I didn't get it. Then I realized — no, no, no. It's just how he's going to tell the story. It's my product he's talking about.

Frank Chen: That's awesome.

Ken Kocienda: It's going to be the phone, the touchscreen music player, and the internet communicator. And that's all just one product, and we'll call it iPhone. When he said that, that's when I knew I was going to have to go back the next day and add iPhone to the auto-correction dictionary.

Frank Chen: That's awesome that he fooled you too, because he fooled me. You were working on it, so I don't feel quite as bad.

Ken Kocienda: I have to admit it was just a moment where it's like, "Wait, wait a second. Is there something that I don't know? No, it can't be." That was just the culture and the times and the way Steve liked to run things.

Frank Chen: A feature we all take for granted now actually didn't appear in iOS until several releases later — copy and paste. Did you guys talk about that at the time? Did you make an explicit decision to ship without copy and paste? Was that contentious? On the surface, it would seem like that's contentious.

Ken Kocienda: Yes, it was. But one of the other things we were really expert at, to bring back the word we talked about earlier, was focus. We were very good, very early in the development process, at saying what was in and what was out. Physical keyboard out — that was super early. It was clear 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, the software engineering manager, would be up at the front of the room with a keynote slide deck saying, "Big challenges — well, keyboard, of course." Other challenges came and went, but keyboard was a constant throughout the entire 18-month development cycle.

We knew we wanted cut, copy, paste, but we knew there was simply not going to be time for it. We didn't spend any real development effort on it. The one thing I did implement for the first iPhone was the loupe. You press and hold, and it would give that little magnifying glass above your finger. The idea was that we wanted your finger to be right where the insertion point, the little cursor, would move. We needed to show you what was under your finger. That was an idea I came up with. But there was no time to capitalize on that and expand it to do cut, copy, paste. It even got delayed an extra year because after the initial release of the iPhone, we had that six-month delay before the first customer shipments, and then that whole next year was taken up by making third-party APIs.

Frank Chen: So two releases before you had copy and paste.

Ken Kocienda: That's right.

Frank Chen: I want to get right into this. Apple was famous for having exquisite taste around design tradeoffs. A feature like copy and paste kind of feels like, "Wait, you're arguing against copy and paste? That's not a great user experience." How did the argument evolve? There's taste, taste-making, making hard decisions like this. Then there's another style of decision-making that Google made super popular — relentlessly A/B testing everything. Maybe Google would have come at this challenge by giving people tasks — this one has copy and paste, this one doesn't — and A/B testing it. But Apple made a pretty courageous call that seems to fly against user intuition to exclude it.

Ken Kocienda: It was simply a matter of setting the constraints and keeping them. 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. Once you start adding people, other things begin to break down. You can't invite everybody to the team meetings. You can't find a conference room big enough. Now there are 40 people who can break the build. We just decided that — Steve's way of communicating this was, "Look, this is the greatest product ever. It's a touchscreen iPod. It's the greatest iPod we've ever shipped. It's got all these great features. It's a phone. You've got web browsing you can take anywhere. And there's no copy-paste. Well, who cares? We'll get to it." In the meantime, you've got this most amazing product we've ever made. Steve believed that the things we did do were good enough to counterbalance the things we couldn't do.

Frank Chen: Great segue to the next segment. I'd love to take us into what it was like to demo for Steve. What was the room like? Who's in there? What's the emotion of it? Everybody wants to know this. It's probably the scariest room in Silicon Valley.

Ken Kocienda: It was pretty scary. Steve could be intimidating, no doubt about it. But to get back to this point about top-down and bottom-up — except for this brief interlude where I was a manager, throughout my whole Apple career, over 15 years, almost 16 years, I was an individual contributor. Yet I got the opportunity to demo to Steve some of the latest work I did at various points in my career. He wanted to see from the person who did the work. When he would ask questions, he'd say, "Go ask the expert. Go ask the person who is the DRI — the directly responsible individual. The person who, when they lose sleep, they are losing sleep over that thing they're going to be demoing to me." That's what he wanted.

These demos were very small affairs. Interestingly, the demo room for Steve, the software demo room, was this really shabby little room. Not what you would expect for Steve Jobs' command performance. You wouldn't think it would be this pristine room with beautiful blonde wood and clean air and the scent of redwoods piped in. No, it was this shabby little room with a mangy old couch and standard-issue office furniture. I don't know why he didn't want better. The only reason I can say is that it was a matter of focus. He was focused on looking at the software, not worried about the decor.

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

Ken Kocienda: Skipping ahead a couple of years after the original iPhone, when we were doing the original iPad. This is now 2009, as I recall. This is actually an original iPad right here — a really good one, autographed by Steve Jobs. This was the iPad I got at the end of the iPad development process. Back at the beginning of the iPad process, I would have a prototype that looked pretty much like this. We were thinking, "What's the typing experience going to be like?" We've obviously got a bigger screen, a lot of pixels. What are we going to do to make great use of these additional pixels?

One thing I noticed: if you turn the iPad to landscape, that screen distance is just about the same as the distance between the Q key and the P key on a laptop keyboard. I thought, "We could maybe fit a full-size keyboard on a landscape iPad." Around the same time, one of my favorite HI designers, Bas Ording — who I collaborated with on the iPhone keyboard — was starting to think about iPad keyboards as well. He came up with a demo with all these variations, all these ideas. He showed me 10, 20 different ideas. One really struck me: a design that showed pretty much a shrunk-down laptop keyboard to fit in this space.

I had two ideas. Maybe I could use this larger screen real estate to make a version of the keyboard with big keys almost the same size as a laptop keyboard, but also give you the number row and all the punctuation keys exactly where you would expect to find them on a laptop keyboard. I started talking with Bas, and we came up with a demo where we would have a special key we called the zoom key. It would take you from this keyboard with small keys that would zoom up to the larger keys, then back down to the smaller keys — a complement to the globe key that changes the keyboard language. We thought this was a great idea. The idea for what to do with this larger screen real estate for the iPad was: give the user choice. Use these new pixels available on this new platform, this new form factor, and have that be the pitch we make to people.

But before you can make the pitch to people, you need to make the pitch to Steve.

Frank Chen: To the man.

Ken Kocienda: That's right. I got to demo this for Steve. There was a very small team that was the chief demo review team — the small group of people Steve wanted around him as he was reviewing demos. Scott Forstall, Greg Christie, Henri — the chief managers for iOS. A couple of HI designers. Bas Orting, the fellow I collaborated with on this keyboard, was almost always in this meeting. Another fellow, Steve LeMay, was often in the meetings, but as I recall, he wasn't in this particular one. Half a dozen people in the room.

People like me who had individual demos — there were circles inside of circles. I was in the circle of people who could demo to Steve. But there was a circle inside that who would stay for all the demos. My role would be to go in, give my demo, and then leave. I'm sitting there with my iPhone down the hallway waiting for Henri to text me, waiting for my turn. He sends me a text: "Go stand outside the door." The door is going to open and I'm going to get invited in. I get the text. I go stand outside the door. I'm waiting and waiting and waiting. It seemed like, "Well, he just texted me. Why did he text me?"

Then the door opens. I get invited in. I figure I'm on. I'm going to go do this iPad keyboard demo. I come around the corner and turn into the room. Steve is over there like this — he's on the phone, staring at the ceiling, going back and forth in his office chair. I'm like, "Gulp. What do I do? Now I'm eavesdropping on Steve on his phone call." It was pretty uncomfortable. I think he was talking to Bob Iger, the head of Disney. He's like, "Yeah, yeah, Bob. Yeah, that sounds great. Yeah, I'll call you next week. Great talking to you."

Then he hangs up. He does this thing — he takes his iPhone, puts it back in his pocket, and then he does this [gestures]. I don't know if you know the Eye of Sauron from Lord of the Rings? The great eye turns to focus on you. That's what it feels like. It's very interesting how the demos go from that point. He didn't want a lot of words. He didn't want a used car salesman pitch. All he really wanted to know was what was next.

He hung up the phone, turned towards me. Scott Forstall stepped up. The iPad was already in the room. He goes and wakes it up, brings my demo up, and says, "Steve, we're going to be looking at iPad keyboard options. Ken, he did work on the iPhone keyboard, and now he's got ideas for the iPad keyboard. So, Ken?" I said, "Yes, Steve, go and look at the demo. It's on the screen now. Try the Zoom button." And that's it?

Ken Kocienda: That's it. That was the intro. And so then Steve goes, he slides his office chair over, and he starts looking at the iPad screen. What was up was one of the two keyboards. Let's say it was the big key keyboard, the one that was more suitable for touch typing. And he's looking at it. He took a long time to look at it. He even did this little thing where he was turning his head to see what it looked like in his peripheral vision. It's just incredible to see what Steve does when he evaluates a product.

Frank Chen: So this is what he did. He hadn't even touched it yet. He's just looking at it.

Ken Kocienda: Yeah, and this is going on for a long time. It was probably maybe 20 or 30 seconds that felt like 20 minutes. But he took a long time to study, and then eventually he reaches out and touches the zoom button. 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. It really looked like the keys were just morphing. It was absolutely beautiful. But Steve just had no reaction. He does the zoom and then he does this study again. He's looking at all the keys, looking at how the screen changed. Then he does the zoom again, and it goes back to the state it was in the beginning. Then he studied a little bit more and tapped the zoom button again to see that there are just two states here. 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. So then he turns to me and he says, "We only need one of these things, right?" And you're like, oh, I'm on the hot seat. Yeah. I guess so. Then he asks me, "Which one do you think we should use?" He asks me. He doesn't ask Scott Forstall, who he knows much better. He doesn't ask any of the other people in the room. He asks me, the individual contributor. You're the DRI. Just coming in, but I'm the DRI. That's the thing. He wanted the answer from me. Now, I had to give an answer. If I didn't give a good answer, maybe I would never be invited back again. Not the DRI anymore. 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. I thought that the one with the bigger keys I found more comfortable. I was starting to touch type with four or five fingers, and auto correction was helping. So I said to Steve, "Well, I like the bigger one. 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. The interesting thing is that 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. Steve had this amazing ability to simplify and to rely on his people to have a good enough idea about what they were doing. He wanted you to be involved enough in the work that even when you get asked difficult questions about it, you've been thinking about it. You have this background of context, of having been thinking about the problem for weeks and weeks, and that experience was something he was interested in tapping into to provide a way forward for the product.

Frank Chen: What was going through your head when you were just watching him sort of head tilt in silence? Were you tempted to explain things?

Ken Kocienda: Yeah, you just know that you're not supposed to do that. I would imagine that if I had done so, he would have told me in no uncertain terms. He's like, "Let me look at the thing." In my view, I don't know what's going on inside his head, but having seen him do that, having enough experience with his approach to evaluating work, 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 going to be my impression of it? So he pictured himself as customer number one. I don't want the engineers whispering in the ear of the person in the Apple store. Sure, they can maybe get the help of one of the nice people working in the Apple store, but 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? Then I can decide, "Yes, this is the thing I want to take home with me."

Frank Chen: Obviously, if you have a leader like Steve that's that into being able to emulate the user who has great taste, you want to make this person benevolent design dictator for life. Now, the downside of that — Silicon Valley is getting a lot of criticism for these sort of super charismatic reality distortion field generating CEOs where you might not agree with them. In the ultimate downside case, there's too much hero worship of CEOs. Do you think that ever became part of the Apple culture? The blind obedience to the fearless leader?

Ken Kocienda: Yeah, I think Steve's reputation and his success causes people to draw the wrong conclusions, to take away the wrong lessons. If you go back and look on YouTube of old videos with Steve, maybe on stage with Walt Mossberg and Kara Swisher at their All Things D conference, or the AntennaGate controversy — I forgot about that. The reason I did this is because it's current now that there was a bug in group FaceTime and Apple issued an apology. I wanted to go back and see what Steve said about AntennaGate, the issue with the iPhone 4 where you're holding it wrong and the signal strength would go down. It's really interesting. Steve held a little press event. He was very clear, very upfront, saying, "Our goal is to make our customers happy." That's the kind of lesson people should be taking away. It's not that he was domineering. Not that he was this absolute monarch. Not that he had this 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 Chen: How did the organization morph itself to reflect that you had this great tastemaker who wanted to make these decisions at a very granular level in the design? There was an example where you were designing an animation, the scrunch zooming demo, and you got to the point where Steve and Scott Forstall actually disagreed. Tell us a little bit about that.

Ken Kocienda: This was for iOS 5, maybe the second or third version of iPad software. We wanted to come up with multitasking gestures so that you would have some way of interacting with your whole hand on the screen. Even though multi-touch was something that shipped in the first Apple product, there was no way you could have sophisticated multi-finger gestures on a screen that size. But with the iPad, we thought you could. So I came up with this idea of using a 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 another interaction where you would swipe side to side to go between one app directly to another. You launch Mail and then you launch Safari. Then you can just swipe to go from Safari back to Mail. The system would keep track of the history of apps that you launched. Now here's the part that Scott didn't like. Let's say you start up your iPad from nothing. You take it out of the box and you bring it home. You launch Mail and you launch Safari. You only ever launch two apps. So you swipe to go from Safari back to Mail. What happens if you continue swiping in that direction? There's no other apps. End of list. So what I came up with was this morphing, stretching, rubbery distortion of the app to show you that you were at the end of the list. It would do this bloop, bloop, bloop animation when you let your fingers up off the screen. Scott Forstall hated it. His argument was, "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 Chen: That's super interesting. They didn't have a say in what it's going to look like.

Ken Kocienda: That's right. You've taken away their taste. It's an interesting aspect to what happens as you evolve a product. 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. There was a huge ecosystem by that point. So this was Scott's argument: the designers, you've done something to them that they couldn't really have accounted for in the design of their apps. I got the chance to demo this to Steve, too. Steve had the iPad in his lap. He was sitting like this and doing the gestures, trying them side to side. When he discovered by himself this rubbery animation, the end of list animation, he did it. He did it again. He didn't look up. He said, "This is Apple."

Frank Chen: Awesome. How did you stop yourself from doing the victory lap?

Ken Kocienda: He thought that it was tapping into the whimsical aspect that went all the way back to the Happy Mac on the original Macintosh. It was this whimsical little animation that showed the system has this playful character to it, and that was an aspect he really loved. It also 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. Steve was the one who had the final vote, and he sided with me in that instance.

Frank Chen: Do you feel like that slowed decision-making down at all in the org? Basically, "We're just going to wait for Steve to decide, so why bother making a decision?"

Ken Kocienda: The DRIs were responsible. You needed to bring him proposals. You might think of that keyboard demo example as, "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 said we only wanted one of these. If you brought him shoddy work that was the equivalent of a shoulder shrug — "Yeah Steve, we've got five things, we don't really know which one we think we like" — that was a way to never get invited back to a demo. That was the way Scott Forstall would have gotten blowback from Steve offline: "Scott, why aren't you presenting me with solid designs? I'm not here to waste my time. I want to see the full result of that bottom-up process so that he could then give his top-down approval or disapproval." That was the outcome of every demo with Steve. Approved, not approved with specific feedback on what to change, or not approved, bring me something different next time. It was one of those three things.

Frank Chen: Steve himself is legendary for fusing liberal arts and engineering thinking. If you think about the classic Silicon Valley stereotype, companies are a lot more about the pedigreed computer science engineer. Your own background and other people at Apple who have valued the liberal arts and engineering degree — talk about the advantages of melding the traditions. What's an example of a decision that was better because of that?

Ken Kocienda: It's all the process of designing experiences for people that are useful and meaningful. How do we define what's useful and meaningful? We look to literature, to philosophy, to art, to the creative media. I didn't know Steve well enough to know what he thought, but the culture he helped create — the part of the approach was that these devices are a part of people's lives. More and more now, to the extent that we think there's a problem with the amount of time we're spending looking at these screens, we need apps and features on the phone to help us track too much screen time. If we're going to have this object, these experiences that are so important to us, so deeply ingrained, then it requires care and attention and thought. It's not just a technology artifact, it's a social artifact, a human artifact. That's where liberal arts comes in. Yes, you need the technological background to come up with the hardware, software, networking, and services to get everything packed together so a product like this is possible. But if you're going to ask, "What is it good for? Why do we do this feature rather than that feature?" — that's a liberal arts process.

Frank Chen: Tell the story of how you guys arrived at the home screen app icon size. There's a fun liberal arts twist to this.

Ken Kocienda: Going back to a phone that looks more like this. [Holds up original iPhone] This is the screen size we were dealing with. Jumping back to 2005, 18 months out from the product announcement, we were still in the early stages of trying to figure out what the home screen of apps would look like and how it would work. One of the fundamental questions was, how big should the icons be? I mentioned before this apprehension of touching targets that were smaller than your finger. We were still in the phase where we didn't know how big on-screen objects should be. We had some experiments, but we didn't have a good handle on it. One of the engineers on the hallway had an idea. His name was Scott Hurst. He was doing work on Springboard, the icon launching program. He had this idea: "I'm going to make a game." It was the first ever iPhone game. Truly. At this point, we didn't even have all of our units — they still needed to be tethered to a Mac. We didn't have standalone enclosures yet. We were still at this phase where we had touchscreens that needed a wire tethered to it. But we were trying to figure out the ideal size. The game was the solution. You would launch the game and there was a minimal user interface. All it was was a rectangle on the screen that was a random size and a random position. The game was: tap the rectangle. As soon as you did, it didn't tell you if you succeeded or failed. The idea was just go tap the rectangle as quickly as possible. You tap the rectangle, the next one would show up at some other random size and some other random position on the screen. You would go as quickly as possible without being weighed down by feedback. You would get 20 of them, and then it would give you your score. It was fun. Before Angry Birds, we had the little angry rectangles. Naturally, he was also writing the software so that he was tracking rectangle by rectangle whether people were succeeding or failing, and based on where the rectangle showed up on the screen. Within a couple of games — the game was actually fun — I finally got 20 out of 20. We determined that if you made a rectangle that was 57 pixels square, pretty much everybody could tap it 100% of the time, no matter where it was, since you were going quickly, you could tap it comfortably. He just then, since he was working on Springboard and it was his game, he put that number into the app. He made the icons 57 pixels square. Since that was a good number, we never changed it. That's what wound up shipping on the iPhone.

Frank Chen: I love that story. It was a game that led to it, as opposed to "We're just going to do every possible pixel variation and bring people in to test it."

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

Frank Chen: Let's switch gears and talk about your advice for young people thinking about getting into the computer industry. Liberal arts degree, computer science degree, what set of life experiences? What's your general advice for people who want to join a tech company?

Ken Kocienda: I think it needs to be a mix. If you're going to be a programmer, go write programs. The only way to get better at things is to do them. One of the wonderful things we mentioned about open source — the barriers have never been lower to get involved. I started in college in 1984. I couldn't afford a Mac. They were thousands of dollars. There was no way I could afford one. Now the barrier to entry is much lower. If you're interested in making projects, go out and join a community and start making them. Or you can even lurk in the community. You can download the software and try to make something of it yourself. If you want to do something, just start doing it. The other piece of advice is, you do need to look at more than technology. These technological artifacts that we're making now have become so important to people that if you don't know anything about people, I don't think you're going to be successful in the long term. Read books. Study philosophy. Go to art museums. Learn about what's beautiful and meaningful to you. Answer those questions for yourself. If you can't answer those questions for yourself, it would be hard as a product designer to take on the responsibility of answering those questions for other people. That's what you do when you're a technologist at a product company like Apple. You're going to be making decisions on products that are going to go out in the world and affect other people. Other people are going to bring those things into their lives. How do you know what's good? That's a question 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? It's this combination of learning about the technology so you can actually implement your ideas, but then you've got to actually have good ideas. It's the liberal arts that provides the grounding for that.

Frank Chen: That's counterintuitive in Silicon Valley. The suite of interview questions you typically encounter are about linked lists and TensorFlow and Python, as opposed to "What's good? What's beautiful?"

Ken Kocienda: Obviously, linked lists are still going to have need for those. But much of the work I did in my life, there was no way I could have predicted. When I was handed a piece of hardware like this and told, "Make a touchscreen operating system for a smartphone," there were precious few examples we could have looked at. How do you have experience in that thing? Getting a flexibility, being able to answer the more general questions about what you like and what's good and what your higher level goals are — because technology is going to change.

Frank Chen: How important do you think it is, if you're thinking about joining a company, that there be a figure like a Steve Jobs who has a trusted lieutenant like a Scott Forstall? Is the absence of those ingredients a reason not to join that company? How universal is the Apple experience versus how specific to a set of characters and a time in history?

Ken Kocienda: It's a hard question. Steve was unique. Unfortunately, he's not around anymore. I think it's a fool's errand to go out and find who is the direct successor to Steve Jobs. The questions are always changing. 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. That you like the people. That you feel you're bringing something. It's this interesting contrast of both fitting in, but then also providing more diversity. That's an ongoing challenge for high-tech companies. As the products become more and more important for our culture, the people who are making the products need to be a better reflection of the world as it is. It's not just a bunch of computer geeks who went to maybe a few high-powered schools with good computer science departments.

Frank Chen: In your book, you distilled the Apple experience down to a few key ingredients. This is what made the iPhone team so productive. You talk about things like collaboration, taste, and decisiveness. Let's pick up on collaboration. Every company says they have a collaborative culture. What made Apple's unique?

Ken Kocienda: We were very good at combining complementary strengths. We had this human interface design team, and I worked very closely over time with a couple of the folks in there. There were only a few folks in there in total. For example, me working with Bas Ording on the iPhone keyboard. 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. We would come up with these ideas and we would complement each other. Whatever you think of software patents, we got them for the work we did at Apple. One of the constraints when you apply for patents is that you need to list the inventors. You need to be honest about who contributed to the specific invention. They would ask us, "Which one of you came up with this specific idea so we can write it into the claim language?" Bas and I would look at each other and go, "I don't know, we both came up with it." That's the sign of collaboration — 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 there was no other way to describe it. As a concrete piece of advice, at Apple we didn't have a lot of politics. When Bas came up with an idea, I came up with an idea, it just didn't matter. It wasn't a strong attribution culture. "Oh, that's his idea. How dare you? I can't work on that. Now my manager is going to get involved because I'm not going to get the credit." It just wasn't like that. But you still had to have strong DRIs. That was one of the ways that made it clear. If I was the DRI for the keyboard, I was the one making the calls. As long as I kept making good calls — if somebody else had an idea that they really thought they were going to go to the mat and say, "I think Ken made the wrong call on this," they could buck that up the management hierarchy. But that was relatively unusual because part of being a DRI is recognizing strong ideas that are coming from other people and including them in the work. That helps to describe the character of the collaboration we had.

Frank Chen: Ken, it's been a fascinating conversation. Thanks so much for taking us inside the chocolate factory.

Ken Kocienda: The chocolate factory did not have very many people. I feel really blessed that one of those people made it out and is willing to lead the tour and talk to us.

Frank Chen: Maybe that'll be the last question. Famously secretive Apple Corporation. Did you have to get their approval to write the book and tell the stories?

Ken Kocienda: No, I didn't. I don't know if I was supposed to, but I didn't. I took a certain approach to it. I think it's a positive take on Apple. I loved my career at Apple. I didn't throw anybody under the bus because there was nobody that I thought deserved it. I limited myself to the Steve Jobs era, which is now, sadly, passing into history. I was one of the few people who had this perspective, this opportunity to be there during the time some of these products were getting made. With my background being in history and in the liberal arts, I thought it would be good if I collected these recollections while I still remember them well and tell the story. It was really more of a personal story. I was imagining that maybe I would ask for forgiveness if somehow they didn't really approve. But I thought I wouldn't really run into trouble.

Frank Chen: 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.

Ken Kocienda: I've had a great time. Thank you.

Frank Chen: For those in the YouTube audience, if you liked what you saw, go ahead and subscribe. In the comments thread on this video, let's talk about things that you might want to try in your own culture. Having listened to Ken describe what Apple did, what would work in your environment and what wouldn't? We'd love to have a conversation about how you would implement some of the ideas we talked about in your own software development lifecycle. See you next episode.