#20 - Building Products People Love—Lessons from Decades at Apple and Adobe - Arno Gourdol

Episode Introduction [00:00:51]

Henry Suryawirawan: [00:00:51] Hello, everyone. Welcome to another episode of the Tech Lead Journal with me your host Henry Suryawirawan. Thanks for tuning in and spending your time with me today listening to this episode. For those of you who have participated in my recent giveaway, thank you for participating and subscribing to the show’s mailing list. In the next few days, I will pick the 5 lucky winners to win the JetBrains All Products Pack Personal licenses, and make sure that I can reach you by your email address. And once confirmed, I will announce the winners on the Tech Lead Journal social media channels on LinkedIn, Twitter, and Instagram.

Speaking of which, if you haven’t subscribed to any of those channels, please take a quick pause right now, find the links in the show notes, and click the “follow” button in order to get updates from the show. Every day, I post insightful daily quotes from the week’s episode to share some wisdom from my amazing guests, and to give you some spark of idea or insight that you can implement right away.

We are coming to the end of 2020. And this episode 20 is the last episode for the year. I’m going to take a 2-week break before continuing with the episode 21 on the 11th January 2021. I hope all of you can also spend some time to take a break and recharge your energy, especially after going through such a challenging year due to the pandemic. Maybe you can also take this time to do some retrospectives, and possibly list down your new year’s resolution in order to improve yourself and achieve new goals and habits. I, myself, will also take a look back on this podcast progress, which I started 6 months ago. And I really appreciate your continuous support for listening to me and the show. I would also like to take this opportunity to thank all my amazing guests, who willingly spent their time to share their stories, knowledge, experience, and wisdom that we all can learn and apply to make an impact in our personal work. So thank you again all of you from the bottom of my heart.

And for those of you who have found lots of inspirations from the show this year, and are thinking of making contribution back to the show, please join us as a patron by going to techleadjournal.dev/patron. And you can help me towards achieving a goal that I’m currently running on the page.

For today’s episode, I am extremely excited to share my conversation with Arno Gourdol. Arno is an inspiring tech leader who has decades of experience working in two major creative companies, Apple and Adobe. He started his career journey at Apple straight after his internship there. And he had the fortune to work closely with Steve Jobs, and experienced firsthand when Steve came back to Apple, and turned around the direction of the whole company to focus all their efforts on doing things that Apple was really good at, and discarded the others. And this, as history showed, was the key success factor that brought Apple to where it is today. The entire company had to adapt to Steve Jobs new ways of working, and had to work in an iterative fast-paced approach at the time when Agile was not yet widely known. During his time there, Arno also successfully led a complete rewrite of a 10-year old Finder code base to make it easier to maintain and evolve, and shipped it for macOS X.

After such successful career at Apple, Arno then moved to Adobe, where he spent almost 15 years of his career there, where he had the opportunities to explore different projects and established his engineering leadership skills. Arno led an audacious move when he proposed Adobe to open source XMP, the eXtensible Metadata Platform, an action that was considered bold during the time when open-sourcing wasn’t common back then. XMP eventually became an ISO standard to store metadata for images, videos, and many other digital documents, such as JPEG and PDF. There are so many interesting anecdotes and valuable lessons that I learned from Arno in this episode, including his advice on how to build products that people love, and what we should focus on in order to create successful products.

Right at the end, after his 3 Tech Lead Wisdom, Arno shared with me what made him decide to end his illustrious career, and pursue the things he is truly passionate about, which is about landscape photography and doing some passion open source projects.

I hope that you will enjoy this great episode. Please consider helping the show in the smallest possible way, by leaving me a rating and review on Apple Podcasts and other podcast apps that allow you to do so. Those ratings and reviews are one of the best ways to get this podcast to reach more listeners, and hopefully the show gets featured on the podcast platform. I’m also looking forward to hearing any comments and feedback on the social media, or you can also directly send to me at techleadjournal.dev/feedback. So let’s get the episode started right after our sponsor message.

Sponsor [00:06:05]

Henry Suryawirawan: [00:06:05] Are you looking for a new cool swag? Tech Lead Journal now offers you some swags that you can purchase online. These swags are printed on-demand based on your preference, and will be delivered safely to you all over the world where shipping is available. Check out all the cool swags available by visiting techleadjournal.dev/shop. And don’t forget to brag yourself once you receive any of those swags.

Introduction [00:06:35]

Henry Suryawirawan: [00:06:35] Hello, everyone. Welcome back to another Tech Lead Journal show. Today, I’m so excited to meet Arno Gourdol. I hope I pronounce the name correctly. I was introduced to Arno by one of my best friends. Looking at Arno’s profile is pretty stunning. Arno has a very illustrious career working at two big creative companies, I will say. The first one was Apple for around 10 years. And the other one is Adobe, which is about 14–15 years. So looking at this illustrious career, I would say Arno is pretty credible people that I can interview in this podcast. And hopefully today, Arno will be able to share lots of insights, lots of career story from his career for all of us to learn. So welcome Arno to the show.

Arno Gourdol: [00:07:16] Thank you. It’s a pleasure to be here.

Henry Suryawirawan: [00:07:18] So Arno, what are you doing now? I know that you are not currently in any career now. You’re doing your own stuff. So tell us a little bit more, what are you up to these days?

Arno Gourdol: [00:07:27] Yeah. Right now, what I’m doing is, trying to do as much travel as I can, which this year has been challenging, definitely. But I try to travel and do some landscape photography, which is one of my passions. I try to take pictures that showcase the beauty, the natural beauty that’s out there in the world, and try to share it with the world. When I’m not doing that, I’m also working on some open source projects for various things that I care about, and a lot of those that have no commercial value that I could not have worked on otherwise. But now that I don’t have that constraint anymore, I work on some of those open source projects.

Career Start [00:08:07]

Henry Suryawirawan: [00:08:07] So let’s go back to your career. Looking at your career, maybe you can share with us what are some major highlights and maybe turning points in your career that are interesting for us to hear about?

Arno Gourdol: [00:08:18] Yeah, well, my career started very interestingly, unexpectedly, I would say. When my career started, I was actually going in a very different direction than where I ended up with. I was studying for an engineering degree at my university. Degree that was both in software engineering and computer human interaction. Which has always been my passion. That’s something that I’ve always been deeply interested in, and interested in the potential for technology to really help people be more creative, do more, express themselves. It’s always been something fascinating to me. And making that technology accessible is something that I’ve always really cared about. I started hacking on the Apple II back when I was in high school. And that was sort of like my opening to that whole universe. And then when the Mac got out in 1984, the first time I saw a Mac, that was a revelation. I saw that and it was like, “Okay, this is the future. This is how computers are going to be from now on. There’s no doubt in my mind.” That was the first thing I thought. And then the second thing is, I have to have one. I got to put my hands on it and do something with it. Which I ended up doing. I managed to get a Mac the first year that it came out. And I started programming on it and building applications on it. That was about the same time that I was working on my undergrad studies. And you know, it was like Intro to Computer Science, and at the time I was a little bit bored by those classes, I must admit. I figured that actually building applications at the same time was a good way to sort of distract myself. So I ended up doing that, and publishing some of those very early Mac apps back then.

And then after that, I started working on this graduate degree, that was focusing on user interaction. And we’re talking about like early 90s. But at the time, it was very ambitious, let’s say, because it was all about voice, speech recognition, gestures, how to use all of that with a computer. And the big challenge at the time is that the hardware was not really capable of doing that. And I don’t know. At one point I was like, I bet the company that could help me with this is Apple. So I’m going to get in touch with them. And I’m going to ask them, “Hey, do you guys have any hardware that I could play with that could help me with this?” And to my surprise, they actually ended up responding and saying, “Well, as it turns out, we do have a project that we’re going to get started on. And if you’re interested, we can take you on for an internship.” I was like, “Oh wow! I did not expect that positive answer. And that’s exactly what I’m looking for.” So I talked to my thesis advisor about it. And she was very supportive. She said, “Oh, this is a great opportunity.” But she told me, “You’re never coming back.” And I’m like, “What? What do you mean? Of course I’m coming back. No, this is just for the summer. And this is just for a couple of months, that’s going to help me, you know, make some progress on thesis and all that.” She’s like, “Yeah, no. I’m never gonna see you again.” I’m like, “All right, well, we’ll see.” And it turns out that she was right. After a few months at Apple, I got completely hooked. I was like, this is great. Actually working on things that millions of people are actually going to be using, and that’s a fantastic feeling to think that you’re building something that is really gonna make a difference in people’s lives. I mean, not that the academic world doesn’t have its value as well, but you know, for me that was just completely different. And so Apple ended up extending my internship a few times. And eventually just telling me, “You should just stick around. We’re going to hire you as a full-time employee and keep on going.” So that’s sort of how I got started at Apple. And that was the beginning of my career. That was a big turning point. And unexpected one, like I said.

Journey at Apple [00:11:44]

Henry Suryawirawan: [00:11:44] So it must be a dream for you. The first time you saw Mac, you got hooked by it. You think, “Oh, this is like the future of computing.” I mean, I didn’t have a chance to have the first Mac, obviously. I can understand at that point in time, Mac probably is one of the more advanced, sophisticated technology that came out. And to be able to do an intern in a company of your dream product, is something that I think is really, really amazing. So tell us, after your internship, how did you actually start? What kind of role you started at Apple? What product that you built?

Arno Gourdol: [00:12:14] Like I said, I was an intern. Really low on the totem poles. Basically I was just happy to be there. I remember, the first time I realized that I actually have access to the source code of macOS. That was just like mind blowing for me. And just being able to read that on my spare time, that was just wonderful. I did a lot of that. I would spend my nights and weekends just reading through that code, and just being fascinated by it and learning so much from it. But it turns out that Apple did have a project at the time for a pen-based Mac. So it was essentially like a Mac portable that had a touch screen on it. That was a product that Apple was working on, even hadn’t shipped yet. And that was sort of like going on at the same time that Newton was going on, if you remember that. So they have those two projects in parallel. And I worked on the Mac-based one. I wrote some of the gesture recognizers for that computer, and some of the UI that we’re building on it. Now that was interesting because that gave me access to this hardware that I was looking for, so that was wonderful. I worked on that for a little while. The project ended up being canceled, which happens a lot. And this time, especially with the Newton being going on at the same time, they decided that it didn’t make sense to sort of have both. And they bet on the Newton as being the one project.

After that, I was still part of the UI group that’s working on all the UI components of the Mac. That included the Finder, the system preferences, all the things that are visual that you interact with in the Mac, that was the team I was working on that. And so I ended up taking up some responsibility for some of those components. One of the first one was the open and save dialogs, that’s still part of the Mac to this day. I was responsible for icons as well. So everything to do with icons on the Mac, I worked on that. And it was sort of like a gradual progression. At first I was intern, then I got promoted to software engineer. So I was working on smaller components. And then things, you know, sort of started accumulating, with more components I was responsible for. And then eventually, also being part of a team. Working with people, just not on my own, but starting to work in the context of a bigger team as well. So it was like a gradual progression as time went on.

Steve Jobs Impact [00:14:17]

Henry Suryawirawan: [00:14:17] So during this time, was it with Steve Jobs inside? Or Steve Jobs was out of the company?

Arno Gourdol: [00:14:23] That was before Steve came back. So that was interesting. That was a very interesting time to sort of be at Apple at the time. It was a challenging time for Apple as well. Apple wasn’t always doing that well back then. One of the bigger challenges was that Apple was trying to build a new Operating System from scratch, that was supposed to be the successor to the Mac Operating System from 1984. And it was a big endeavor. It was a huge project. And that project was not going very well. Apple was making some progress, but there were lots of problems with it as well. It wasn’t moving as quickly as everyone was hoping. My team, the UI team, we had lots of ideas for what we wanted to do, and build on top of this new Operating System. And, we felt a little bit constrained, because we’re like, “Okay, come on guys. We need to ship. If we don’t have the OS, we can’t ship.” And, after a while, I ended up being so frustrated with the progress. I ended up making a recommendation. I said, “I don’t think we can pull it off. I don’t think given the complexity of what we’re trying to build, I don’t think we’re set up in terms of process, and know-how to do a project this size. And I think we would be better off just buying an OS from somewhere else. And then build on top of that. Make it our own. But give us a head start by just buying something.” And at the time, actually the recommendation I made was we should buy BeOS. I don’t know if you remember BeOS. It was small operating system that had been started by Jean-Louis Gassée. He used to be at Apple, and left Apple and started this company to build this desktop Operating System, that was very advanced for the time. It had multi-threading, full multitasking, was very high performance, which has all the things that we were kind of living for in the new Operating System. And it was already there. It was built. It was working. It was shipping. Be themselves wasn’t doing very well, because it’s really hard to do something like that from scratch and be successful commercially. I was like, “You know, that would make sense. Buy them and then build on top of that. And that could become the next version of macOS.” And to my surprise, people were like, “Yeah, I guess that makes sense. We should definitely look at that.” And then they get a investigation started. And then the discussions were fairly advanced. There was an offer that was made. But people were like, “We should look at what the other options are as well. And make sure that this is really the best for us. Maybe Be seems to be asking for a lot of money for what they have. Maybe we can find something less expensive. Or is the price really justified? And so on.” And that’s how it was decided to actually look at NeXT as another option. NeXT, which was the company founded by Steve when he left Apple the first time. That also had a great Operating System that could be a foundation as well. And they were not for sale or anything. They were not trying to get themselves sold. But they were a good comparative to what we’re looking to BeOS. And then Steve being such a good salesman, he ended up actually convincing everyone else at Apple that, that was the right thing to do. The thing that made sense was for Apple to actually buy NeXT, and for Steve to come back at Apple. So that’s what ended up happening. Yeah, really interesting time when this whole transition happened.

Henry Suryawirawan: [00:17:27] It must be one of the best moments in your career, I must say, that looking back, you were around when Steve was not around. And when he came back as the CEO, what was the first thing you remember in your mind? What change that he made?

Arno Gourdol: [00:17:40] So there was actually a transition as well, because Steve came back, but at first he was not CEO. He was sort of like advisor to the current CEO at the time. And it’s sort of like over time that he ended up taking more responsibility, and eventually becoming interim CEO, and then full -fledged CEO. But when he got this title of interim CEO, and he was more like in charge, the first thing he did, which was a bit of a shock to the system, to be fair for everyone at Apple, was canceling projects left and right. At first, we were like, “Oh my God, what is he doing? We’re going down the drain. He’s canceling everything. The company is over. What’s happening?” It was all very disorienting. But Steve’s idea was that Apple was just doing too many things. We had lots of different projects going on, both on the hardware side and on the software side. It was just too much. We were just stretched too thin. In order for Apple to really be successful, it was important to focus on fewer things. To just decide what are the things that are really important. Those things we’re going to do. And the things that are, maybe good ideas that would be nice projects to do, we’re just going to have to cancel, so that we can focus all our efforts, all our energy on those critical projects. And so that’s what happened. That’s when Newton got canceled. There were some great other projects, OpenDoc and Cyberdog at the time, which got canceled as well. Lots of hardware projects that got canceled. But it was all I think the right thing to do. And certainly, history has proved that by focusing on fewer things, we were able to produce higher quality work.

Apple’s Key Success Factor [00:19:08]

Henry Suryawirawan: [00:19:08] I know it must be a very tough decisions, looking at so many projects, and then canceling one by one. But what was the principles behind it? What made it such a success at the end of the day?

Arno Gourdol: [00:19:18] I think it was really focusing on those things that Apple could do, that was difficult for other companies to do. When you step back and you think about, “Well, what is special about Apple?” At the time back then, but it’s true to this day, was the fact that Apple was really one of the very few companies that really looked at building a product as a complete thing. Meaning both the hardware and the software that goes with it. Apple wasn’t a hardware company that got its software from somewhere else, and then try to make it run on top of it. Or a software company that ran onto whatever hardware others were producing. Apple was unique in that it was a company that was building a product that had a hardware component and a software component, but those two were built to really work together. And that was exemplified with the iMac, which was the first product that Steve really worked on when he came back at Apple, by saying, we’re going to be building this new kind of hardware that is custom fit to work with the software that’s going to be running on it as well. And the two are going to be running really closely together. So that you can have this machine that makes it like really easy to connect with the internet. That was the whole idea of the iMac. That was the " i" in iMac, is to make it a machine that was really easy to connect on the internet. And for that to work, you have to have both the hardware and the software work together. And so that was the key idea that was sort of driving which project made sense for Apple and which ones didn’t.

Working in Agile Manner [00:20:40]

Henry Suryawirawan: [00:20:41] So you mentioned as well during our introduction, that during this time, you were working in such a incredible pace. Changes seems to be a norm. And we were kind of like discussing, this is like pre-Agile. But you worked in an Agile manner anyway. So could you tell us, what was it like building products and introducing a lot of changes throughout the process?

Arno Gourdol: [00:21:01] Yeah, that was really interesting, because at the time, Apple was pretty large company. And the way it approached building products was relatively conservative, I would say. The whole approach to product design, so many on the hardware side, because when you build hardware, it’s different than when you work on software projects. Hardware side, you have physical constraints. When you make a prototype, it takes time to build that prototype, and it’s very difficult to make changes to that prototype. You have to retool things. And that takes time as well and so on. So the whole approach on the hardware side is very methodical for how you build your product. But some of that approach had leached through on the software side as well. So the software projects also were very conservative. It had waterfall type of methodology. You wrote specs before you wrote the first line of code. And then you checked that after you’ve written the whole software, you’ve made sure that the software actually matched the spec. So it was a different approach from what we’re using today, like more Agile methodologies.

But the thing that changed that was when Steve actually came back. Because he was so involved in the creation of the products themselves. It was obviously relying on the very talented team of engineers and designers and so on. So it’s not like he was designing all the product himself from scratch. But he had a very good vision and understanding for what customers were looking for and what customers wanted. Sometimes better than the customers themselves would know if you asked them. Steve could sort of like intuit that, what people were actually looking for. He was invaluable in giving feedback to direct the product in the right direction. But what he couldn’t do, he couldn’t at the beginning of the project tell you, “Okay, well, this is exactly what we’re going to build. This is exactly what it’s going to look like. Now go do it.” It was very much a reactive experience, where you build a prototype, and you would bring it to him, and try something out, and that would spark an idea or a feedback. He would say, “Oh yeah, this is really good. Oh yeah, no. That doesn’t really work.” That would lead things in different directions. So by nature, it was very iterative. I had a weekly design review meeting with Steve, where we would bring in basically the latest state of the system, and he would actually just play with it, and try it out, and discuss things, and look at different options, see which one felt were more promising. And that was sort of like the feedback cycle that we use for the next iteration.

That was a very different approach from what the software engineering team at Apple had done. When I realized that, “Okay, this is how we are going to work now.” One of the big challenges for me was like, “Okay, I have to explain to my team, which was the UI team, that this is what’s going to happen.” Because they would come to me and say, “Okay, so what are we building? What are we supposed to build?” And like, we don’t know yet. There’s no spec. And there’s never going to be a spec. So we had to approach how we’re building software differently. And I would tell them, “We have to think more of building components that are inherently flexible so we can rearrange them in different ways. As we try things, as we find that some things work or don’t work, so we can make those changes constantly.” One metaphor that I used to explain that was it’s like building Lego pieces, where we’re going to be making like this huge sculpture. We don’t know exactly what it’s gonna look like yet, but we know that we’ll need those smaller pieces. So let’s start by building those, putting them together, see what pieces we need that we don’t have, build those until we have something complete. That was again, a big change from what we were used to, but eventually, the team got into it. And it worked out pretty well, because that’s how the first version of macOS X eventually came out.

Building Without Clear Direction [00:24:38]

Henry Suryawirawan: [00:24:38] I’m sure this is a good learning for all of us here as well. As we all know startups are booming these days. A lot of people want to start a startup, but they don’t necessarily know what kind of product they want to build. Not exactly, for sure. But they have a direction, maybe they have a vision. So in your view, as a technical leader at that time, not knowing what to build, what would be a good tips from you to give technical leaders these days, that if you don’t know what to build exactly, what kind of tips that they should know in mind in order to be able to still come up with a good engineering product and good engineering design, and which probably will lead to a good product and good success for the company as well?

Arno Gourdol: [00:25:15] I would say that one of the key things was not to be overly ambitious when you get started. Not starting to make assumptions that may end up being invalidated later. Starting small. That’s definitely something that worked very well. Trying to do small things. And not trying to do something that’s too broad either. So to give you an example, when we started working on the Aqua, which was the macOS X user interface, that was actually the first meeting that I had with Steve. He came prepared. He had no idea what the UI actually was going to be like. All of that. But what he told us is we’re going to be working on buttons, windows, and menus. Those are sort of like the basic building blocks. We have to figure out what those things are. And then, once we have that, the rest will follow. But rather than trying to do everything at once, all components and elements that you’re going to have in the UI, and try to figure that all out at the same time. Let’s try to figure out like one button. But you can’t have something simpler than a button. So let’s figure out, how do we want the button to work in this UI? And once we have that, then we’ll move on to windows, and then menus, because those are the building blocks, and then we’ll do the rest. Again, that goes back to this idea of focus. Both in terms of at the product level, but also in how you’re building a product, and then saying, “When you build a UI, that’s something that’s really complicated. How do you simplify it? How do you make it so that you can focus on fewer things? Do those things really well. Not get distracted by all the possible different directions that you could go to. All the different problems that are up there. But try to make a solid foundation that you can build on and develop from.”

Tips When Revamping Product [00:26:53]

Henry Suryawirawan: [00:26:53] So I think the last project from your profile I saw, is to revamp the Mac Finder, if that is right. And looking at the history as well, Mac Finder has been around since maybe, I don’t know, like early version of macOS. And then for you to be able to revamp from scratch, rewrite the whole thing, and plus introducing a new way of interactions for people to use Finder. I foresee that there are a lot of challenges as well, especially new interactions, maybe new styling, new placement of things. So what will be the best tips for you for people who want to embark this kind of a journey, maybe rewrite the whole thing, revamp, restyle, the whole thing, in order to get it right, so that the users are not to the opposite of what you want right there, they are angry, they are mad, in terms of building the end product.

Arno Gourdol: [00:27:37] That is a great question. And, that was certainly something that caused us a lot of anxiety when we started the project. The old Finder, I would say the Finder that was running on macOS system seven and versions previous to macOS X, it was a beast. It was a gigantic piece of software, way more complicated than you would think, from just playing with it. It was also actually, interestingly, as far as I know, one of the first large scale C++ apps. It had started to be written just at the time that C++ came out. There was like no framework or anything at the time. So the Finder sort of had its own system of doing things. Its own way that had been invented by the team back then as they needed. Because the code base was so large and so old, it had become really difficult to make changes to it. Going back to what we’re talking earlier about getting to make all those changes and introduce all those new interactions and so on. At first, we were like, “Okay, well, maybe we can sort of like retrofit that in the existing code base and get it to work.” But I became convinced that just wasn’t gonna work. That we were gonna be fighting so much, the code base, to get it to do what we wanted, that we’d waste so much time, that we would be better off if we’re writing it from scratch. Usually, when you have an engineer that comes along and says, “We have to rewrite everything.” The reaction is, “Okay. Yeah, you’re crazy. We’re not doing that.” Especially when you went out with a product that has such history. Cause like you said, there were a lot of subtle user interactions that users were used to it and expecting that could be difficult to reproduce. And I made that pitch. I said, “I think that’s the only way. I’m convinced that if we rewrite it from scratch, we’ll be able to go faster. We’ll be able to do more. We’ll be able to catch up to where the code base currently is. And then, move further wherever you want to go, better than if we just stay with the current code base.”

So I didn’t win that argument upright. I think my management was rightfully skeptical. And I convinced them enough that they were like, “Okay. We’re going to give it a try. But we’re going to keep our options open. So we’re going to have sort of a classic code base. We’re going to try to move it forward. And then, you and a few engineers. You go ahead and prove to us that you can actually rebuild it and do it faster.” And so that’s what we ended up doing. And it did work the way I was hoping. Which is that the new code base ended up being so much easier to work with, so much more flexible that we were able to like really quickly catch up to the capabilities that the old Finder had, but in a much more flexible and better organized and architected component based on everything that we had learned from the old Finder, that we were able to catch up and go much further. But it was a very controversial decision. We had sort of like those parallel efforts for a while. Eventually, people were like, “Okay, we’re convinced. We’re abandoning the old code base. We’re going to bet on this new code base.” But it took some convincing by actually building things and demonstrating that it was possible and it could work.

How to Decide a Technical Rewrite [00:30:36]

Henry Suryawirawan: [00:30:37] This is a classic kind of a problem for every engineer. “Oh, you look at the piece of code.” I mean, old enough. Maybe even two or three years is old enough for an engineer. And they decide, “Oh, you have to rewrite and rebuild this.” But I think most of the times it’s not a valid argument for sure. So in your case, what do you think in this modern era for people who come up, “Okay, I need to rewrite something.” What will be some of the criteria for them to actually judge whether the effort is worth it or not?

Arno Gourdol: [00:31:03] In my landscape photography hobby, there is a little bit something similar, which has to do with your equipment, with your gear. People often ask me, “What camera should I buy? What camera do you use? What lenses? All of that.” When I tell people, I say, “You should not buy a new lens, or a new body, or new camera, if you can’t explain what is it you’re going to be able to do with this new camera, this new lens, that you can’t do right now.” Because the new camera, the new lens, they’re not magically gonna make better images. If you don’t understand what are the limitations of what you’re working with right now, then there’s no point. You’re just wasting money. And I think it’s the same thing when you’re looking at rewriting software, rearchitecting it and so on. I mean, sometimes I totally get that. Sometimes you’d venting. You’re like, “Oh my God, this thing is like terrible. And it could be so much better.” But if you can’t answer the question, in what ways is it going to be better? What is it going to allow you to do this new architecture that you can’t do right now? Then, it’s probably not worth it. So I would definitely not recommend to just rewrite things just for the sake of it. Sometimes, piece of code that’s old and cranky, but it works. That’s good enough. Don’t touch it. In this case, I knew that the code base that we had, we just could not move it in the direction that we wanted. And that’s what justified me doing this rewrite. I mean, I was not enthusiastic about this rewrite either. But I really saw that as like the only way to do what we wanted, with the risks that were associated with it.

Henry Suryawirawan: [00:32:30] Wow! Nice analogy. I like the photography analogy. Not buying lenses, if you don’t know what you’re doing. And then, I mean, it’s pretty insightful for us, not to just judge, “Oh, there’s a new technology, like maybe Kubernetes or whatever it is, let’s just rewrite everything to just adopt that technology.” I think your message is pretty spot on. Know what you want. What kind of limitations that you currently have that you cannot avoid? And then before you actually embark the journey to rewrite or rearchitect or re-platform your system.

Journey at Adobe [00:33:00]

Henry Suryawirawan: [00:33:00] This is like 10 years journey of Apple, before you move to Adobe, which you spent about 15 years. So tell us more about Adobe’s experience. Maybe some highlights, maybe its turning points?

Arno Gourdol: [00:33:11] Yeah. So that was definitely a interesting career as well at Adobe. The reason why I ended up transitioning to Adobe, well first, the two companies have always been very close, both in terms of the people who work there. You have people going back and forth between Apple and Adobe, like all the time. But also in terms of how they approach the products that they build and the customers they build it for. There’s obviously a lot of intersection between the people that buy Apple products and Adobe products. One thing that I had gotten more interested over time, while working at Apple, which was about managing people and providing leadership to engineering teams. That’s something that I found increasingly interesting. When I was at Apple, I was managing some people back then, but it wasn’t the focus of what I was doing. And I just wanted to do more of that. And learn more about how do you become a good manager? What is a good manager in the engineering field? And so that’s what I started doing at Adobe. Again, that was a great career progression. I got extremely lucky.

One of the wonderful things about Adobe is that the company is large enough that there are so many different projects that you can get the opportunity to work on. And new projects all the time as well. You basically never get bored. I mean, unless you want to. And some people at Adobe, like you know specialize, and you have some people that have been working on Photoshop since the beginning of Photoshop , and they love it, and that’s the only thing they want to do, and they do that, and they’re great at it, and that’s wonderful. But for me, I wanted to also try different things. And I really love working with new products as well. That’s always been a passion of mine, and something that I always found interesting and challenging. And Adobe offered plenty of opportunities for that. I got to work on tons of great products for creative. From Photoshop, which was the first product I worked on when I joined Adobe. To some new product. I worked on the XMP metadata initiative. Which was very interesting because it started something like extremely mundane, I would say. It was all about how can you represent metadata. The location that something was created, and the author of something and so on, across all sorts of different media, because the people who use Adobe products, they create photos. They make magazine layouts. They create illustrations. And all sort of those different things. But they all have this need to have metadata to represent that information and attach it with all those documents. So how do you do that across all those different type of documents? And so there was this proposal to have this new format to do it. I was like, “Yeah, that’s kind of interesting.” But that’s never going to work if that’s the new Adobe format. It has to be something, for it to really work, to be universal so that anybody can use it. No matter what products they’re using, whether they’re using Adobe products or not. That has to be possible to use that.

And so I end up making again, which at the time was sort of like a crazy pitch, which was, “We should open source this.” And it was like in the early 2000s. At the time, open source wasn’t what it is today. So the first thing I often had to do was start by explaining what open source was. And then, you know, I would have people look at me funny. “What are you talking about? We’re going to be building all this and we’re going to be giving it away?” “Yes! Yes, we are. Because that’s the only way that it can succeed. And we’ll get the benefit from it. If everybody uses it, that will be great for the whole ecosystem. But we can’t do that if we just keep it to ourselves.” Again, I got lucky. I got the support for it. And we ended up doing this project, which was called XMP. And that ended up becoming like an ISO standard. And that ended up being adopted by literally everyone. I mean, I remember visiting Canon, the camera makers in Japan, where they were like, “We’re going to put XMP in our camera.” I’m like, “Oh, wow!” I did not anticipate that. I did not expect that, but that’s really cool. A lot of cameras, now you can push a little star button to rate your images. That’s XMP actually, behind the scenes that makes all of that possible. That was really exciting to be working on that. And that was an opportunity also for me to get started also, getting involved on the standard side of things, and a world that I did not really know. But that was interesting to discover as well, to see how all of that works. And then later on I would do more of that also while at Adobe.

Contributing to Open Source [00:37:18]

Henry Suryawirawan: [00:37:18] So this is very interesting story, coming from a traditional, or maybe during that time, not many companies are into the open source yet. I could even remember during my time when I was early in my career, open source was really not deemed as secure. There are a lot of scrutiny. Why are we using an open source software? You should just buy from vendor. Have support. And then, be more secure rather than open source. Although now times have changed, definitely. But for some companies who just use open source software, but rather than building open source libraries or software back to the community, why do you think it’s important for every company to do this initiative?

Arno Gourdol: [00:37:52] So in the case of XMP, that was a good example where if you wanted to benefit from better ecosystem, essentially, you had to contribute to this ecosystem in a way that was giving, making improvements that everybody could benefit from. Not just something that would be better for your products. I think that’s more and more true, because software nowadays interoperates. I mean, it’s not like your customers are using just your software and nothing else. So being able to have something that works with lots of different things is important. Now it’s a difficult pitch for a commercial company, right? You say, we’re going to be building something. We’re going to be investing time and resources into building something. And then we’re just going to be giving it away. But I think that you can make that argument. I mean, it doesn’t make sense for everything obviously. But I think it does make sense for a lot of things when by the contribution that you make, you’re going to be improving the overall ecosystem, so that you can benefit from that better ecosystem, and others can as well. And you’re going to be competing with your competitors, who can provide the best solution for the ecosystem. But if the ecosystem doesn’t exist, if it’s not there, nobody wins. There’s just no product that can be built at all.

The other thing, which I believe as well, and that’s a little bit more controversial. And I get it that not everybody buys into that, but I think that when you’re a company of some size, like Adobe is certainly, you benefit from the work that others in the open source community are doing. Whether it’s directly, when you reuse some piece of an open source software, because it does what you need. Or because others have contributed to this enrichment of this ecosystem in one way or the other. It’s great. You benefit from it. That’s fine. That’s fair. That’s the way it works. But I think you sort of have a moral obligation to contribute back as well. You take some, but you should give back. I think that’s only fair. Now I understand that not every company can do it. If you’re a small startup that is strapped for resources, and just doesn’t have the time and the funding, you may not be able to do that. But I think if you reach a certain level of success, which again, that success very often would have been built on the contribution of others that have contributed to the open source community. When you can, I think you should give back and contribute something back. So those are sort of like the two arguments. I strongly believe in both of them. But like I said, I know that the second one is definitely a bit more controversial. And not everyone agrees with that.

Henry Suryawirawan: [00:40:06] So the way I see it, I think it’s kind of fair as well. Like these days, I mean, as a developer, especially the new one, if they want to build any kind of software, you could easily just start by typing few commands. And then you can download the whole bunch of dependencies. It could be hundreds even. And then they can start building something. I think at some point in time, it’s kind of like fair if you know that something you can contribute back, either like small fixes to the dependencies that you use, I think it’s fair for you to contribute back. It doesn’t have to be necessarily like a big open source project.

Dealing with Canceled Projects [00:40:33]

Henry Suryawirawan: [00:40:33] In your Adobe experience as well, right? You work on few different products. And not necessarily products that are long lasting. Some of them like Adobe Air and Adobe Flash, now pretty much not existent anymore. I wanted to ask this question, like for some people, of course they are sometimes unfortunate as well, working in a product that probably got killed or something like that. So what will be your learnings throughout this experience, working on a project, a big product, then suddenly got killed?

Arno Gourdol: [00:41:02] I think the most important thing is not to get attached. Not to lose perspective about why you’re doing what you’re doing. Because then you can get stuck in a direction that may not be the right direction, and get terribly disappointed and crushed when your product or project or whatever ends up getting canceled and so on. I mean, it’s good to be passionate about what you’re doing. I think that’s really important. But you have to sort of examine why is it important? What is it really that you’re trying to accomplish? And oftentimes, it’s not about the specific of the product, but there’s a bigger idea behind it. For example, Flash, that’s a great example. The reason why I thought that Flash was so interesting, and I enjoyed working on it despite all of its challenges. But I think it was great about it is what people were doing with it. It’s the creativity that it enabled others to express, whether it was building games or incredible experiences on the web. At the time, the web was just not very capable, and Flash enabled those developers to build those amazing experiences. And that, that’s something that was very powerful. The thing that I was really interested in wasn’t Flash in itself. It was being able to build those experiences. When I was working on the Flash runtime, and I was leading that effort, I came to realize, given that how things were evolving, and that’s when mobile devices started to come on the scene. And of course the iPhone, which, you know, famously, with Steve refusing to have Flash on the iPhone, and all that. I started thinking and realize, if you look at the trajectory, if you say 5 years or 10 years from now, or maybe 15 years from now, it ended up being less than 15 years actually. Is Flash going to still be around? Probably not. But people will still want to build those great experiences. How can we help people build those great experiences? And that’s when I realized that the right thing to do was for Adobe to actually invest in web standards. Because that was the future. That was what was going to enable people to build those great experiences. Even if the technology that they used to do it changed, but the fundamental need that people had wasn’t going to change. And so I made that argument again. I keep putting myself in the situation where you have to make those pitches, but things that seems right to me, but I often go against the conventional wisdom. I mean, if you can imagine, I was at Adobe, and I was making the pitch that we should kill Flash and invest in web standards. And I was in charge of Flash. So you can imagine how that went. So same thing, there was a lot of skepticism when I met that pitch. But you know, again, I’ve managed to convince people enough that there was an agreement that, okay, maybe we should try to make some investment in web standards and see how that goes. And so we ended up doing that. And I started getting more involved with the W3C, the CSS working group in particular, and making some proposals there, that were about making the web better, and sort of filling in some of the gaps that the web had, so that we could have better platform to allow people to express themselves.

Director of Products [00:43:56]

Henry Suryawirawan: [00:43:56] I think the last position that you have at Adobe is Senior Director of a suite of products. So at this level, especially when you’re working on different products, I could imagine that it’s pretty difficult to probably manage all of them. But what will be the key success factor from your experience or your view, when you are in this position, having to manage multiple different products, not necessarily working together, but some could. But what are the critical things at this position as the Director of product?

Arno Gourdol: [00:44:22] Yeah. One of the most important things is to trust your teams. Because you’re right. As you progress in your career and your portfolio becomes larger and larger, there’s only so much that you can get directly involved in. You’re still ultimately responsible for the success or failure, more likely of your other products. Meaning, you know, if everything goes well, it’s because your team did a great job. If things don’t go well, it’s because you didn’t do your job. That’s how it is really. So you have to trust your teams, that they are going to be doing a great job. And what your team needs from you is clarity of purpose. You ended up spending so much time communicating. That’s the most important thing. And you end up, maybe sometime you feel like you’re just repeating yourself, but really what you’re doing is you’re providing clarity to your teams in helping them understand, what is important? What is the goal? What is it that we’re trying to achieve? And why is it important? Why is it worth doing? Your teams can figure out how are we going to do that. If you have great teams, they will build a great product. But you have to help them understand why this product is important, and what is behind what they’re trying to build. That’s the most important thing. And that’s definitely worth spending a lot of time on.

Building Products People Love [00:45:36]

Henry Suryawirawan: [00:45:36] Looking at your illustrious career again, having worked at Adobe and Apple. These two are the giants, in terms of building products that people love, that people use, either for their creative work. Or it’s just like fanaticism. When you talk about Apple users, they’re fanatic about it. And even some Adobe users as well, like Photoshop, I think is still one of the best product available for manipulating images. In your view again, what will be some tips for building products that delight people first of all, in terms of UX and UI experience, and also giving people a lot of values, fanaticism, so that they are attached to your product, your brand and your company together?

Arno Gourdol: [00:46:13] Yeah. When Steve came back at Apple, I guess Apple wasn’t doing very well financially. And there were a lot of people at Apple, me included, that were wondering, you know, “Hey, should we stick around? Should we maybe go join a startup somewhere? Is Apple going to be around next month?” And, I actually ended up asking Steve about that. I said, “Steve, what’s going on? Is the stock going to turnaround? I mean, are our options gonna be worth something someday?” And Steve had this great answer. He said, “Don’t worry about all that. Don’t worry about the financial rewards or what the stock is going to do. Don’t worry about even pleasing your customers. All of those things are not what’s important. All of those things are the things that happen if you’ve built something that’s great.” So the most important thing we can do, in order to get whatever success we want, whether it’s financial rewards, or like you said, you have the customers that are really passionate about your products that really love them. Build the best product you can. Invest all your energy in making the product absolutely best that you can think of. Don’t worry about what your competitors are doing. Don’t worry about what criticism you may get from maybe your current customers that are not happy about something or other. All of those things are distractions, really. If you really focus on building an absolutely best product possible, everything else will follow. You’ll have happy customers. They’ll be happy to give you money to buy your products. And investors will be happy to buy stock in your company, because they want to be part of the journey as well.

3 Tech Lead Wisdom [00:47:42]

Henry Suryawirawan: [00:47:42] I know that this is such a great conversation so far. But I would like to ask the last questions that I have, in this show normally, which is the technical leadership wisdom. So do you have any wisdom from your journey, throughout these 25 years of career, what are the most important things for us technical leaders to know about?

Arno Gourdol: [00:48:02] Well, one of the first things that I learnt, which was a surprise, was the importance of stepping up. I found myself so many times in situations where, you know, I’d look around me: “Someone should be doing something about this.” And realizing that nobody was doing anything about this. I was like, well, maybe I should be the one doing something about it. We’ve talked about some of those opportunities where I made some crazy proposals. Things for me that were like, “I think that’s the right thing.” Nobody else maybe is speaking up and saying it. But that’s what I think is the right thing. That is something that has served me so well so many times. That has helped me really progress in my career in ways that I couldn’t have otherwise. It’s very easy to be in a situation where you’re like, “Well, things are just the way they’re supposed to be. What can I do about it?” And then you realize that in fact you can do a lot about it. You’d be surprised. But you just have to be willing to step up, and say, “Hey, I know how to fix this. Or I have an idea. Or I think we’re doing something wrong.” And oftentimes that will open up opportunities for you to do more than you thought possible. So I would definitely encourage anybody, especially someone that’s early in their career, to not hesitate to speak up. I mean, you have to do it in a respectful way obviously. But more often than not, I think you realize that people will value a different perspective. And you may have an idea that nobody else had that is worth contributing. So don’t hesitate to speak up and contribute. Now, don’t think that you always have the answers either. And oftentimes, I was the last one to think that I was right. And I was like, “I don’t know what I’m talking about. That saying, “That sounds right to me, but you know, if anybody thinks differently or think I’m wrong, speak up. Let me know.” So you have to be very humble in how you approach this. But, yeah definitely, speaking or stepping up and be willing to contribute and take responsibility that nobody else is willing to step up for. So that’s one thing.

Another thing is the importance of teamwork as well. You can do a lot by yourself. You may be very talented and able to do a lot of work on your own. But you can do so much more when you’re in a team of other talented people that can contribute and help out. Now, one key thing is, not everybody’s alike. Not everybody has the same talent. Nobody is talented at everything either. Some people are better at some things than others. One of the key things is first recognizing that. I’ve seen many instances of people that would get frustrated, because their teammate would not do something. And they’d be like, “But you know, why isn’t he doing this? He should do this. He’s supposed to do this.” As the manager, I would have to explain: “Well, yeah, but they’re not very good at it. Do you want them to try to do a terrible job at something that you’re really good at? No. You’re really good at this thing. You should be the one doing it. They’re not really good at it. Let them do the things that they’re really good at.” And that’s important to recognize that people are good at different things and to give them a job that’s basically in line with that. Don’t ask them to do things that they’re not passionate about, that they’re not going to be doing a great job of. Make sure that those things they are really good at, that they can really blossom into and really flourish. And if you think of the whole team as a whole, you need the team to have all sorts of different talents. And sometimes you have gaps, right? You have, “Wow. We’re a fantastic team of architects. And we design like some great software, but we suck at managing our schedule. We never ship on time. It’s always disorganized.” Don’t say, “Okay, you, from now on, you’re in charge of the schedule.” And you ask an architect to do that. Because they’re going to be doing a terrible job of it. What that means is you may need to bring somebody in on the team that has those particular skills that you lack. So that’s really important to think of the team as a whole and make sure that the team as a whole has all the right skills. But don’t ask people to do things that they’re really not the most talented at. And if you do that, then you can create a great team that can really do some amazing work. And then you can be so much more productive than you could be if you try to do everything yourself. Which is sometimes a temptation as well for engineers, right? When you’re like, “We don’t like this. And it’s just not done right. I know how to do it. I’m just going to fix it.” Sometimes it’s so much better to actually help somebody to learn how to do it right than to fix it yourself.

And then finally, I would say, again, it goes back to some things that we talked about earlier. Choose to only do your best work. And choose what you work on. We all only have so much time on this Earth. So it’s very important to choose how are you going to be spending your time. What are you going to be working on? Are you working on something that’s worth it? That’s gonna make a difference. If you do that, you end up happier. Certainly, when you do something that you feel matters to you, and is important to you. That’s also when you tend to do your best work. It’s very difficult to do some really great work when you’re working on something that you’re not that interested in, or that passionate about, or you think is kind of a waste of time. Being selective in what you choose to work on is really important.

Why Arno Decided to Pursue His Passion [00:53:09]

Henry Suryawirawan: [00:53:09] This is just a guess. Could that be the reason why you chose to end your career and do the photography?

Arno Gourdol: [00:53:15] It actually is! You’re exactly right. You’re absolutely right. I really enjoyed my career. Both at Apple and at Adobe. It was very rewarding. It was really something that I’ve got a lot of satisfaction out of. And I really enjoyed doing for a long time. But yeah, I had reached that point where I ended up asking my question. And the answer was what would I rather do? Would I run a work on this new project, which seems sort of interesting, but this is also something that I’ve kind of done before. Or is there something else that I would rather sort of explore and learn and do? And the answer for me was, yeah, landscape photography. Which is something that I had been interested in for a very long time. But it was definitely sort of like a background hobby that I did not have a lot of time to spend on. And I came to the realization that if I really wanted to get better at it, I have to spend some time on it. Like everything else, you only get better at it if you spend the time practicing. I decided that, that was the right time for me to do that. Now, it was one of those things that were…, I had a little bit of anxiety about it as well. I wasn’t sure it was a right thing. I remember having a conversation with my boss at the time. And, you know, I shared with him where I was and what I was thinking about. I was seeking his advice and his wise counsel. He told me something that hadn’t occurred to me, but that made perfect sense, “Well, you know, this is something that you feel strongly about. You should try it. Worst case scenario, let’s say in a year from now or two years or whatever, you want to come back in the tech industry. You can come back, you’ll find something else to work on. We’ll take you back. Don’t worry about that.” I was like, “Oh well, I guess if you put it that way, that’s actually a fairly low risk proposition then. Yeah. I should try it.” And so that’s what I ended up doing. And I’ve been spending my time on the both landscape photography, which has been fantastic for me to be sort of like on the other side, after having worked on all those creative products for so many years to actually get to use those products to explore my creative vision.

And then, as I mentioned, working also on some open source projects, that are also on some passions of mine, including some things that are very obscure, I would say, or that have very small audience, or that are non-commercial products. Nobody would buy. But there are things that I feel passionate about and enjoy working. So to give you an example, one of the projects is a very geeky thing. But it’s actually a software that allows you to transcribe English into the writings of the “Lord of the Rings” from Tolkien. Tolkien was a brilliant linguist who has invented all this beautiful writing systems, but it turns out they’re actually really difficult to do manually. When the question is someone should do this. I was like, well, maybe I’m the one who should. And so I ended up writing this website called a Tecendil that does just that. And it’s been very fun. It’s been a very interesting way to get connected actually with this whole community of Tolkien enthusiasts. So that’s one thing.

And then another, which is another passion of mine from ages ago, which is math typography. Again, that’s a little bit geeky. It’s very obscure as well. But, it all started with a question that I had, which was, I wonder if it would be possible to essentially implement the TeX layout algorithms in JavaScript. Is it even possible? I don’t know. And I ended up exploring that a little bit. And I ended up writing an interactive editor for math equations that implement the TeX layout algorithms, which sort of like the reference for how you do beautiful layout of mathematics. But all interactive, all in JavaScript so that it works in the browser. And so that people that need to input math in the browser can do it in a way that looks as good as if they were writing it on the blackboard, or hopefully it looks even better than what they can do on a blackboard. And that’s been a really interesting journey as well. Again, it’s all open source on GitHub. The website is mathlive.io. And there’s a bunch of companies, mostly in the education space, that are using it to build software for interacting with students so on. And that’s been great. Lots of different fun things that scratch an itch for me, you know, for something that I’m like, I wonder if that’s possible. Or that sounds kind of like interesting. And that I get to sort of explore and have fun with.

Henry Suryawirawan: [00:57:25] So definitely sounds like cool projects, open source projects, and some of these creative projects that you have. I’ll make sure to put that in the show notes. You can share with me the links later. I’ll make sure that the audience here can also follow if they’re interested, especially the Tolkien fans or the math fans. And I must say, I’ve seen your photography as well. They look stunning, very beautiful, all these landscape pictures, and also the night photography, right. They look surreal to me. I don’t know much about photography. When I see something is beautiful. I just know that okay, it’s beautiful. But I know that it takes a lot of effort to produce such a picture.

Arno, it’s been a pleasure talking to you. Thanks so much for sharing your journey, your career, and all the lessons that you have. I wish you good luck in all the things that you do. Your photography. Your open source projects. And, maybe one day we’ll meet again.

Arno Gourdol: [00:58:11] That would be wonderful. Thank you so much, Henry. It’s been a pleasure as well for me. Thanks again.

– End –