In today's episode, I had the opportunity to speak with Tom Eich, CTO at Whiteboard. Tom shares valuable insights in both parts of this interview, so be sure to subscribe in your podcasting application of choice!
In today's episode, I had the opportunity to speak with Tom Eich, CTO at IDEO.
Tom shares valuable insights in both parts of this interview, so be sure to subscribe in your podcasting application of choice!
Imagine if you were born maybe a hundred years ago or even as short as 50 years ago. What kind of job would you hold? Or a better way of asking that is, as a developer, the way that you think and the things that you're interested in, what could you imagine applying the same kinds of interests to before software development was really even a thing. Before we had computers, before we had all of the languages and things that we used today, how would you have interacted in the world? What kind of job would you hold? The truth of software development is that it has a lot of roots in both mechanical engineering or just engineering in general, as well as design. In today's episode, I'm interviewing Tom Eich. Tom is the CTO of IDEO. If you've never heard of IDEO, a quick Google search, we'll tell you about all of the things that IDEO has been involved in, perhaps most famously in the early days of IDEO, the development of Apple's mouse. This is something that IDEO is relatively well known for. IDEO has been leading in the conversation about design thinking for basically their entire existence. Tom has so much to share about the connection between testing and design and engineering, engineering, thinking, human factors thinking. These are all things that IDEO is really well known for. These are all things that we talk about in today's episode and continuing into the next episode, part two of this same interview. Thank you again to Tom for joining me on the show and thank you for listening. Now, let's get straight into the interview with Tom Eich, CTO of IDEO. Tom, welcome to the show. Thank you. Nice to be here. I'm related to have you on and admittedly, quite honestly, a little bit nervous. I've been following IDEO's work for a long time, been inspired by a lot of the processes at IDEO, but before we jump into talking about IDEO, I'd love to kind of get a sense of your backgrounds and where you came from to end up at IDEO in the position that you're in. Oh, great. I'm happy to say more and you can ask me more questions about it. I am an engineer by education, mechanical engineering. When I was little, so I started at the beginning, I was mad for cars in the 1960s as a really small boy. Also, it was the space age and I'm positive that I thought I'd be living in a space station or on another planet by now. And there's still time. All that really just made me into an avid builder of models and drawer of comic book art and all sorts of things, cars like you wouldn't believe I did so many styling concepts that I should have gone into car design, but I think cars got very sad and silly in the 1970s. And that made me interested in other things like buildings and architecture and how things work. So the thread throughout my childhood and with two brothers, they're essentially the same age, all interested in science and how things work was to figure it out and to do that, I think an engineering degree is a prerequisite. It's one of the best ways to understand how things work. And so I'm always curious about how things work regardless of whether it's hardware or software or natural mechanisms. I just am a curious person of why things are the way they are and how they work. And by the time I got out of high school in Palo Alto in the late 70s, the economy was in a terrible situation. And I really didn't have the portfolio together to say go get into architecture school. So I went in with no stated undergraduate degree for almost two and a half years at Santa Claire University and I declared mechanical engineering because it just made sense as like the thing that brought tangibility and engineering together. I wasn't as interested at that point in software, which was as you can imagine, nothing like it is today. And electrical engineering, I was pretty good at it, especially electric machines, but machines were my thing just going back to cars and I really was interested in mechanical engineering. So from there, I went out into the workforce and I really wanted to work from the age of 21, which I did and I'd had a summer internship at NASA Ames Research Center doing helicopter flow field modeling codes, which was not what I wanted to do. Oh wow. I really knew that I wanted to go to work at a company that was making products and my first job was actually programming five-axis CNC machines to make complex parts for large districts and this is how I am those were big and not very dense districts. There's totally absolutely within a few years. But it was a good way again to learn how to make things. I hadn't designed the parts I was responsible for making. I had to work on the fixtures, select the tooling program machines to make them and I could learn by seeing how easy or hard they were to make and not feel that I was responsible for the design at that point I could be more objective standing back and looking at what was flawed in the design or what was good in the design that made it easier or harder to make. That's where I continued out there fast through my next couple of jobs where again as a young engineer I think it's really helpful to be given the chance to break things and make them fail and understand how and why they fail. So my next job was at a company called Roam, which was a real slow convali success story back in the 70s and 80s. It's the first one that built the big lavish campuses with swimming pools and courts and rec center and the original startup culture. Yeah, it was really nice. But my job was actually to do environmental qualification testing on airborne and other ruggedized data general computing equipment. And those were not my designs again. So I could take them to the shake table or the drop test or the shock impact test or the humidity test, which was the worst. And I could force them to fail here. And I remember vividly watching the design engineer partly cry because the thing was breaking apart. But I was more objectively scrutinizing it because my job was to do the analysis some way to fail. And again that really gave me a good grounding in how things work. And so without having my own designs at stake, I think I was able to look much more dispassionately about the laws of physics and why I think enable success or failure and mechanical engineering and hardware design. That fast forward a bit. I think I ran the circuit of Silicon Valley small companies that were building the hardware and writing the software that ran on the hardware. And by the time I got to about 10 or 12 years into my career, I really was losing faith that a lot of these companies were going to produce what was soon to become the broadband future. We knew that we were working with digital micro-euroid radio and the formats were all going to go commercial. But a lot of these companies were not that interested or not poised to take that on like Broadcom eventually did. And meanwhile I started to hire firms like I do and I even talked to I do about doing project work for programs I was running at a well-funded startup that was clearly not going to go anywhere. I turned the tables on IDEO and had a couple other companies and said you know, at the point in my career where I'd like to work on lots of different things, technology is getting very flat and 2D. This is the V90s. And what you guys be interested in hiring me. And interestingly enough, after a fairly protracted three or four rounds of job interviews, I did get offers and I do hire me. I agreed to go work there. And I think that might have been also because I happened to know a hot parametric 3D CAD modeling software to a lot of the time that they wanted to get more people to know about that in the door. But I think they also liked me which was great because I thought it might be a good place for me to work. To be honest, I didn't want to go into software project management. So many people I knew even with mechanical engineering degrees were going to do that because the valley was full of those kinds of jobs. And as I say, I think hardware was getting fairly flat and 2D and sort of less interesting for a moment. This is the era when that's capable of starting up and all that activity. So I recognized from talking to people at IDEO in my interviews actually that they were working with all kinds of clients across different categories of industry. And in particular, they were doing a lot of work with SteelCase which brought me full circle to my passion for architecture and design. And so that was really why I went to IDEO initially. I wanted to work on things that maybe didn't have a plug-out on them as a product that maybe had wheels and rolled around and you sat in them. And I got into the terrific. And the whole reason IDEO is working with SteelCase, of course, was to grapple with technology in the workplace. But it was through a different lens and it was a great introduction to IDEO, to design and thinking to humans that are designed and how we grapple with technology and people in the workspace always through a lens of what's desirable for people, not what technology might do for them in their jobs. So that was my point of entry and a good first round at IDEO. And from there, it just went because I think at some point I wasn't a kid anymore and you're running different chunks of the business either for content or maybe for client or I've ultimately for the whole time to the business that you're responsible for. And soon enough after the dot com bubble collapsed, I was working on technology clients again and I was happy to because what I'd learned through being an idea then four or five years was that I could find satisfaction like I thought I could with cars or buildings with almost any problem because of the way that we were approaching the problem and unpacking the opportunities for design to have impact. And that was always with very broad multidisciplinary teams where I as an engineer or a project manager got to go on the research journey, got to go do user interviews or observations and run the full cycle from that through to the delivery of the detailed design. And we were also working on design at a higher level where it wasn't just about one thing it was about many things maybe it was about the space that the client was going to deliver the service and product in but also the service and the product and ultimately the whole strategy for that client. So it was really a good progression from going to work on products and working on big scale things for clients like steel case to then going back to technology but not at the level of the box guy which I was when I was in Silicon Valley. When I was in Silicon Valley working for those companies it was the era when the VLSI circuit designer was Lord God king of the engineering pyramid and the box guy was way down on the bottom of the pyramid worrying about how to do things cool and maybe break when they were dropped and so on and so forth. So coming back full circle to technology and looking at the future with clients like Intel and Hewlett Packard with IDEO and the way we were engaging was really actually exciting and fun and I had no problems embracing technology again. Yeah. Yeah. Fantastic history and such an interesting thing to watch because most of the listeners who are listening to this show are primary introduction to engineering has all been through a screen and instead of through mechanics and hearing that difference as well as some of the similarities that we have as new developers, new technologists is really quite interesting. I'd love to know if you could go back now and identify what you think would be kind of the field of study that best correlates to today's technology, that kind of sphere. If you could go back and redefine some of that education period of your life, what do you think you would study if you were to go back in the school today? You know that's a great question I thought about a little while. I actually don't know that I would change it very much because now with the flattening out and sort of democratization of the tool sets, mechanical engineers get to work with code and with technology devices and prototyping that were very hard to do when I was going through that. So it would be interesting experience just to go through it again. I will say some of the smartest people I know in technology just had a general sort of physics education, which again is a deep deep understanding of how things work and why they work the way they do. And if you look at the analogy to coding and software, physics and the modeling of behaviors in physical reality is quite helpful for understanding how to program. And so I think it's a really good background. I think I worry a little bit about people that only have screen-based experience in their education because it may make it harder for them to understand that analogy and to also benefit from the increasing, I think, penetration of software and technology into physical products. So you really have to understand there's some need to have a step back that only having worked with physical, tangible prototypes and models can really give you. I don't know that I'd change anything, you know, it's with you, Jonathan. I think it's really interesting that I'm now responsible for technology at IDEO as a mechanical engineer. And I think it's because I always understood that tools and systems are really a means to an end and that the ways to achieve those ends are diverse and varied as well. Many different ways with just software alone that you can solve a problem. So what's really always the interesting, inspiring and sometimes maddening challenge is actually finding what's right for the humans that are engaged with the problem, whether they're stakeholders, or they're delivering, whether they're receiving that has me where I am now. I said to my colleague, I don't get too emotional about tools because they're just tools. They're not depending on or people that you're looking to for help. And so if something doesn't work, I use the old German expression, a good worker, never blames his tools quite a bit. And you blame the tool if something didn't work. If it broke, sure. If you were misusing it, no. And just didn't do what you hoped it would do, but it did what it was supposed to do, then probably not there either. So that's why I'm in the job of him now, I think, which definitely has been one of the more challenging jobs that have taken out of the idea. Yeah, that's so that kind of gets at the idea that these tools that we're using are really abstractions on other ideas and everything that we've done in technology for as long as technology has been a thing, which really has been since the beginning of humankind. All of our technology is just one level or another of abstraction. So from mechanical to digital, really, it's just another abstraction. That's right. And I think that to your point about the abstractions that are in the world now, especially around coding, it's just amazing to me to see how full of stacks are. I'm watching a team prototype with Amazon landers now. I'm thinking, wow, this has gotten so rich. And of course, all the other bigs have competitors for those. And yet, I think you still need to have people like I am hiring that are really able to understand beyond all those abstraction layers. What is the way in which we want the system to work and what outcomes do we want? And that's still a person that's probably got more depth in computer science than I have. But it is important to always balance that against what I framed up as tools or just means to an end. So you've got to be very aligned and really defined and work on the goal and the process. And yes, then you can apply tooling. And job tooling can be refractory to that process so you can make it better by understanding what the tool can do, especially if it's a complex tool and find your way to the best implementation. But you've really got to know what the problem you're trying to solve is first. And that's where I think another thing that I really learned at the idea from the beginning, that actually was probably set up for in my life, well, by just making all those models as a kid is prototyping. And I'm really pleased to see, I took Scram Master training like everybody does. And I'm really pleased to see the focus on build and delivery and shipping something to test it and get feedback. I think that going back to my early career or I mentioned I was breaking other people's designs, well, at IDEO, of course I had to break my own designs. And now, I'm at the point where I'm responsible for almost the whole company's tool set in some ways. And I can't afford to break a production system. But I definitely want to break it when it's in test environment or test instance or a sandbox so that we can understand how to avoid it breaking in production. And so all that training and experience that said, build and test and break your prototypes and be willing to work on them together with others is really solid background for me. And also I thought was reinforced by the training I took that indexed on an agile team working together to build and ship products. Yeah, absolutely. It's kind of all of that experience realized in a modern framework or a modern way of doing things. I'd love to talk a little bit more with you about that concept of breaking the prototype. Can you explain a little bit more about what it means to break a prototype and how that's different from just stressing or perhaps finding bugs? How is breaking the prototype a different thing than just finding bugs in the prototype? Yeah, I think there's three ways we looked at this for years in prototyping. There's prototyping for inspiration, which I think is really the front end that every designer does whether they plan or not, they start sketching, they start building little models, you switch media. If you're stuck, you might go make a video or something. And that's prototyping just to inspire yourself and others on your team. I think that's a very necessary part of the creative process. It's always been true even going back to my times in Silicon Valley. I think that nobody who really designs anything avoids that step. Then of course there's prototyping to validate. But first I think we always do something that we call prototype to evaluate. And so the evaluation isn't about bug fixing, right? That's about saying this way or that way. Is this going to make users happier or less happy? Or is this going to present some problems we didn't foresee? So it's more of a gross filter on our, we heading in the right direction. And being willing to build lots of different prototypes if it's called for or to iterate more than expected is part of what we do. And it can be challenging because you have to deal with ambiguity through the process of design and prototyping. And that's where I think something that's intrinsic to design thinking in our process at the end of the idea is really valuable, which is another layer of abstraction around. What are the principles that we can deduce or synthesize from the problem we're facing, the research we can do around it, the inspiration we find in going to new solutions. And those guiding principles can hold a team together when they're dealing with not just ambiguity around, are we building the right solutions and are they panning out? But really, are we solving the right problems? Which increasingly when you're in a job like ID is often in, it's not just, hey, go do the new thing here. It's what is the new thing? What is the next thing? And so you really have to, with the client, of course, hold together to some strong principles that can guide you through a mind field of ambiguity and maybe, you know, that's where breaking prototypes can be uncomfortable, it can be as simple as when I was an engineer working on projects at IDEO. I'd say, okay, we're ready to take this chair part into the test lab and put it through the 600 pound repeating arm load test and you'd be saying it shouldn't break, it shouldn't break. But if it broke, you want to know it then so you can go do something about it and not after it's gone to market and people are hurting themselves on it. So I think it's that level of sort of clarity that give you, in the software world, my experience is it's much more nuanced and generally nobody's putting something up and just plain doesn't work. I mean, we all come point to failures in some software or website that do not work. But in general, it's more, does this work the way that would be best for the outcome that it's seeking and using it? And I think that's a lot more nuanced and people I think tend to get very fixated on visual design, but I find the most challenging area in software for us as a company and as a buyer of lots of software now that I'm responsible for across IDEO is behavioral, not visual. Yeah, that's a fantastic segue because that's where I was headed next anyway. This concept of design, you know, a lot of especially young developers, young designers, we have this very clear line, seemingly very clear line that we've drawn between visual design and the actual implementation or the backend developer. We hear these terms all the time and they may be useful for a hiring process, but a lot of this could really be summed up by re-configuring our understanding of the position of design and what design actually is. And you know, this debate is ongoing. It's one that a lot of people have had, but I think IDEO really kind of embodies this concept that design is the whole process. Not that every person is a designer, certainly not that every person is a visual designer, but rather that we're engaging in a design process from the moment that we are attempting to define the problem all the way through multiple iterations down the road, version two, version three, version 500. And so I'd love for you to speak to kind of how IDEO views this concept from really what I believe to be one of the defining companies in the world on the term design. How does IDEO view this in light of how design compares or works with technology? Right. I mean, I think it's easy to say in the age of Google that answers are easy to find, but asking the right question is the real hard thing. And that's where design helps us find the right questions to ask and answer. And I think that we've all been on projects where we feel like because of decisions taken fairly early in the project, and I'm sure your listeners can resonate with this, we're a bit trapped at the end of the project or toward the end of the project in a place we don't want to be. And I think the ability to look down the road, not necessarily to see that trap exactly as it might transpire, but to understand what are the markers of good or bad along the way that could lead you astray and to have the ability to iterate your way away from those and sort of, if you're in the fog in the front end of a project, not sure, are we describing the problem correctly? Are we building the right solutions? Are we testing them in the right ways? Just really having a drum beat around putting things out and getting feedback can be the way to have a much more confident way forward to production and market. And what I find when you look at the trade-offs that people make, especially with digital products, is often bound by this very full stack. So as you say, there's a lot of things that will happen in delivering that service or standing that digital product up that are based upon the backend, they're based upon infrastructure, they're based upon things that the design team working on, the actual design can't really be responsible for. You need, I think, the kind of design judgment to exist and the digital or technological fluency to exist in the leadership of the team and the company that's leading that development team to be able to steer in the right ways. It isn't just about the teams on their own, they're going to solve everything and make it as good as it could be. It has to be leadership. There has to be, at some level, a really good, I'm going to use the word again that I love, but in a different sense. There's a really good architect who's looking at the options across all these different capabilities that you can bring to bear and understanding this way, not that, to get the best outcome that the firm can deliver. And again, I think this has gotten to an area where the prototyping, like I mentioned Amazon, landed us all these sort of serverless environments that you can spin up, is very rich and powerful now, but it still is just a tool. So you have to be really sharp on what you're planning to wield it toward what end and with what design principles is what we would call them. Thank you again to Tom Eig for joining me on Developer Tea. On the next part of this interview, we're going to keep on talking about prototyping and the value of learning and lots of other fantastic insights that Tom has for you as a developer. Thank you so much for listening to Developer Tea. Make sure you don't miss out on the next part of this interview. Go and subscribe to Developer Tea. Whatever podcasting app you use, of course, were in iTunes and every other major outlet. Thank you again for listening and until next time, enjoy your tea.