What is the value of thinking forward by five or ten years? This is what we discuss in part and today's episode. The second part of my interview with Tom Eich. We continue our discussion on prototyping as well. Tons of great stuff. In the first part of this interview, make sure you go back and listen to it. You can find it at spec.fm. Of course, on iTunes and every other major outlet for podcasts. Thank you so much for listening to today's episode of Developer Tea. While you're listening, make sure you subscribe and whatever podcasting app you use. If you don't want to miss out on future episodes just like this one. My name is Jonathan Cutrell. Of course, my job on this show is to help you become a better developer. We do that by creating conversations and encouraging hard questions being asked. We talk to people like Tom. My goal is that you will listen to an episode and start seeing things in a different way. Start seeing something maybe from a different angle in a clarified way, maybe an inspired way. Whatever it is that will change your thinking for the better. That's my hope on this show. So we're going to get straight into the second part of the interview with Tom Eich, CTO at IDEO. So that beginning stage, that asking the questions, understanding the problem from its core level. I'd love to know, get some insight from you, how you are actually practicing this at IDEO. On a day-to-day level, what does that, there's some of those initial kind of ceremonies, what do they look like? It's interesting you've called them ceremonies. I mean, I think that it looks like it did as I went to 21 years ago and I walked in. It's basically, we're always trying to make the smallest team work that can get the job done. It's always very multidisciplinary so it doesn't require everyone to have coding skills. But as you probably know, Jonathan, we hire from a lot of art schools and designers have been coding for years coming out of school. I think the software, purists in Silicon Valley might have been shocked a while ago about it and about maybe the way that they were being trained. But nobody has any more because it's so available and accessible. Again, it's not important to say in the early stages of development, hey, don't use that framework or don't use that language because we don't know it will be right or wrong. If it's right for the prototype, we can stand something up. We just have to have the right mindset around. We're building a prototype, not a product, and the prototype is only serving as long as it can to help us learn something. Going back to my comment about breaking it, breaking it at that level more likely means just showing that it isn't as effective as we'd hoped or isn't as effective as another set of prototypes we built to be able to keep moving forward in a way that is giving us confidence we're going to end up where we want to go. I think that the ceremonies at IDEO just answer your question specifically are things like building prototypes and testing them on ourselves, testing them with users, sharing them with each other within the team, having lots of targeted moments of critique that are focused not just on, say, coding style or something as specific as, let's pick an attribute as specific as availability or response time loading time. Those things aren't important when you're building a prototype, it's much more about does this look and feel the way we want it to? Is this engendering the right behavior, sort of inhibiting them on the part of the user? Again, it's back to the behavioral layer. I think even when I was working purely on physical product in my early days here, I learned very quickly to do something I was quite comfortable with, which is take away the visual layer altogether. Who cares? It doesn't matter at some level at first. What matters is the wireframe or the behavioral model, if it was a mechanism I was building or the way I door opened the closed on a binder bin for steel case or whatever it was, get that model prototype in many different ways, go down an iteration path towards some level of resolution and then at the same time bring in the visual language, which was already being developed in parallel, make sure there's compatibility there. One of the things that I always had no problem with was working with bonafide trained designers because I recognized that that was a path I could have taken but didn't car design my early childhood architecture in my teenage years and that everybody has to have, I think, mutual respect for each other's disciplines. If you asked what, to me, is a successful condition of success for teams is that they have to have mutual respect for each other's depth or discipline. That's one of the things that I think is important. When people do the eye roll about, here comes user testing, I think that's when you start to get worried about where is this headed. Very poisonous. Even if you want to disagree with the way that they're conducting or setting up the tests, I think you have an obligation now to help contribute to a better way forward. One of the things that I think we do here is we do the right, I think, tempo of designer view of user testing and it's very bespoke for each project. Again, we're solving problems that aren't just about building a new digital product. Typically, it's in the scale of a much larger problem like develop a new school system for a South American country and everything from the financial and business model to the space design, to the curriculum and so on. You can see digital is in everything as we all know, technology is in everything and you have to understand where is it valuable to put our efforts into designing something new, where should we leverage something existing. If we're actually going to build something, I think we've hired some really sharp creative technologists and sort of designer code or leads that really understand, based on their depth of experience, do use this framework or do use this approach or this language and this architecture. Don't use that one. That's no thing that I think is just added to the mix of design disciplines here. We actually call it software designers or software engineering like anybody else would, but it's treated as if it's the same level of discipline as industrial design or mechanical engineering. You mentioned something very interesting as you were discussing those two things that I think were really particularly interesting. One was the idea of designing through multiple different shapes or formats. You have a wireframe, you have different language that you're using. Potentially, I assume you probably have probably a stack of notebooks that you're drawing in on a regular basis or some kind of sketching way of getting ideas out whiteboards and post it notes. All of these different ways of extracting stuff out of your minds and onto something you can share, something a medium, whatever it is, digital or not, doesn't really make a difference, but something to transfer between two people. That refinement process is kind of the holy grail of design. The concept of switching these ideas around and refining and cutting off corners, if you look at a sculpture is the cutting off of all of the parts that it is not. So much of design is this way as well. It reminds me to share something I think our founding engineer was one of the early David Kelly design employees Jimi Orchenko, who I work with quite a number of years and he still works with us. Is a master's in fine art and sculpture from Stanford? He's not an engineer by education, but he's the most capable and smart practical engineer I've ever worked with. One of his specialties is injection molding machines for complex plastic molded parts and knowing that he loves David Smith and other sculptors and then you look at the complexities of the injection molding process, you can realize that what Jim is doing is he's been designing complex kinetic sculpture for a lot of his career. It just happens to be their industrial equipment to make parts that we designed. So I think that that kind of mindset about we're stripping something down and we're going to figure out how the best way to realize it can work for anything that you're designing. You also said something that I think would be interesting for listeners that is about being willing to just change mediums if you're stuck. I think everybody stays too much in their screen. We've had teams literally go and take improv classes or actually work things out at the skit level to illustrate them. Oh, I love that. That's great. Or they ever put something on a screen and I think we encourage that because you get trapped into one way of doing something even if there's a huge number of variations in the exact mess of how you do it on a screen. But what's more important is I think the meta behavior you're trying to foster or design for. So people need to switch mediums. We have a lot of designers that are happy going from say 2D 3D and our makes faces are full of now, you know, form labs, equipment and laser cams and things like that. So they can go in a number of directions or just go make a video or take some stop motion and you can do the same thing with obviously pencil and paper and a post it pad becomes a great stop motion mechanism if you're in a pinch. It's just really important to challenge yourself and your team to not get stuck in a very narrow way of making that can really only lead to a few well-known outcomes when you really want to come to something new that nobody's done before. Yeah, that's fantastic advice. So I think understanding the behavioral science side of things is incredibly important. You've mentioned it a few times. And I think that some of the way that our brains work, we can, you know, talk about this stuff on the show all the time actually. Some of the things that our brains do, if we understood those things better than perhaps we could work it better, right? We could operate our brain a little bit better. So, you know, maybe understanding the way that we take shortcuts by nature. That's something that our brain does. We're lazy. We have lazy brains. Exactly. And understanding how each of us works the one thing I've been interested in learning about quite a bit since I was responsible for the New York office before I moved into the technology role here is how teams work together and how each of us is wired differently. But as long as we understand each other and how we work, how we think, how we react to different modes of work, I think we can actually work well as a team. What I've seen to break down is when the team itself doesn't understand where each member is coming from and why they're thinking about something the way they are. And what's been really gratifying at IDEO, even from before I started grappling with that question just being on teams, is to see how open the culture here is and encouraging of, you know, everybody bringing forth their own point of view. What we've used is tools like something called the five dynamics to assess teams that work on posing or that are working on a project. It really is about where you energize and what phase of work and where you maybe stretched or stressed and having the right composition of the team to have people that are energized in those moments when you might be stressed or stretched. And those sorts of tools, which are simple, they're based on brain science, actually, they're just, you answer a shop and leave short list of questions and you get a profile. And again, there's no judgment in that profile. But mine's not surprising. It says, I'm off the charts, it examining things and I'm pretty off the charts at executing and I love exploring. I'm good there. And I get stressed out when I have to get too many other people excited about something because I just want to go and examine and execute it. So finding a partner like Dwayne Bray, the partner here is responsible for talent. His five dynamics is like the opposite of mine. And we work rather well together because of the policy. And I think if you look at how teams work, especially when it's maybe all of them working on a software product, that is still a fact that not everybody is going to be at the same energy level through the same modes of work and it's really important to understand. It doesn't, again, put you in a box. It's just to help optimize for the outcome of the team. That's one thing I've learned a lot about it. I think the other thing that I mentioned earlier about leadership needing to have an informed point of view is really important for the leadership to make good decisions. We can't have people that are responsible for the investments the company is making going to market, not be concerned whether they were making financial service software versus a consumer product that they would see in the app store. I think that you really have to understand the business you're in. What is the stakeholder landscape for the entire delivery and that may include the app store. But really, I think that the most successful leaders have to have fluency with technology that's beyond a fast-sell level of, you know, I know what my platform is and I know what we're doing today. You have to be able to say what's happening next year and the year after. That's something that, again, the teams might have the best, most up to the minute insights around, but it has to not just inform leadership, it has to be in the leadership to lead effectively. This really kind of speaks into the idea of prediction, but not prediction for the sake of writing a book, but prediction for the sake of understanding the kind of the long tale of a given product, right? This is something that you've done at IDEO, you've done some predictive kind of projects. One that I have in my notes, I think, that I sent over was about this project that you worked on back in 2000. You did a project that was predicting kind of what life might look like in the year 2010. And without, you know, going into extreme detail, there's some basic kind of visuals that I found, I was able to Google around enough to find these, but some really basic visuals. But ultimately, this isn't intending to create a product as much as it is intending to create direction. Would you agree with this? Yes, absolutely. None of those battered as individual products. It was trying to convey something about different experiences that people might have a decade on. Actually, it's probably 11 years. I know we worked on that in late 1999 to get it out. It definitely is the case that designers always think about the future and live in the future. It's a cliche to say designers, I use that to probably live in the future because you're always thinking about the next thing. And I think that in that case, and in many other cases that I've worked on, you really have to do a bit of design around it. You have to actually say, well, we know these are trends in technology or in science. And we know these are trends in society and these are trends in business. But we have to put some shape to what they might mean and that's where design comes in. All those trends can tell you is that something might be important in one of those categories. But what's important in the context of that holistic future vision is it's only achieved through designing an experience. So what we looked at was, and we actually ran a generative sessions, brainstormers, and prototyping sessions around. Different categories of technology. To get to those scenarios, they were things like what's happening with displays and at that time displays were clearly going down a commodity curve. But you know, a design lead I worked with who was close associate. So I don't want to just talk about the watch of the future. I want to talk about programmable tattoos that move on my skin. I've got only come from design. I'll flash forward a little bit Jonathan. I'm really pleased that there's something called IDEO COLAB, which is really doing this in a much more structured way. They're building an R&D network looking at big disruptive categories of design, the blockchain, AI, AR and VR. And the whole point is exactly what we did that product of 2010 for, which is look for the blind spots, build the learn, and look for the real opportunities that will deliver a better experience for people. And so it didn't matter if we showed a particular individual product concept there. I think we could have been more explicit if we were a little more futuristic, but we're not futurists if we coined the term in a way of things. But I don't know if it was coined in 1999. It might have been. But we were talking about it in the concepts that we showed. Yeah. And some of these concepts were eventually they developed into at least very similar analogs. And so that was really interesting to me to see. It's always interesting to look back at what our predictions were and see how they fit in. And it was a very interesting project. It highly recommended people go check it out. But I'd also love for people to look at the things that COLAB is doing. Yeah. I would say what's shifted for us, and this is true, not just for COLAB, but for the whole firm, and definitely it's something I have to worry about in that I'm responsible for global technology and infrastructure and services as well as helping those software leads with the right amount of support for our designer coders and people that actually build with software. And that is to look at the impact on the human systems. This is really where I think we probably weren't as mature as a firm in fall of 99 when I was working with that team on products of 2010. We were still a little bit, you know, product focused. We moved quite a ways from that and nowadays I think we always look at the big human system. So we wouldn't just say, oh, this is really cool to think about the agent that is more than my personal digital system but can talk to what became the Internet of Things. But really think about the impact of that on financial services, on people's financial wellbeing, on people's health and we didn't have the health buddy. So there's a larger lens that we now bring to bear that I think it does two things. It gets us focused on solving the right problems, the right level, and it gets us out of I think gear lust or sort of eye candy traps that can be fun. But probably don't mean very much if they don't solve the bigger problems. Sure. Yeah. So something I've always loved about IDEOs when we look at a given problem and the problem that IDEO is working on, you can rest assured that IDEOs going to ask questions that are way rewound back away from what the actual realization of the solution is. It's going to be way back into the human form, right? And how is this going to affect our generations to come, for example? Right. It is important, I think that I'm proud that years ago working on products, again, Jim Yurtenko and a team of engineers, I think, go as part of it said, we are not going to do any chrome plated plastic parts for any client no matter how much they want them. Basically, we're doing it. We're doing the horrible thing. And you just, you know, you have to take that mindset at a much higher level toward, is what we're doing really helpful in terms of business and society or is it really potentially going to do something we don't like? And I think a lot of people worry about, you know, the singularities coming and we're designing our human obsolescence. I actually have a much more job just for you because I have to deal with all those smart home assistants I actually experiment with them because I think it's part of my job now. And I somewhere better than those, believe me, the one that comes from a big retailer is the best one I've dealt with so far. But the space is very mature, it is still entirely dependent on humans. And I'm very humbled by things like the, you know, DDoS attack last fall and how that took up major service providers or about the things I'll tell you another example. This is where engineering has to intersect design. How quickly in that screen based upbringing we've dropped the value of haptic and kinetic and kinematic feedback. So whether it's cars and a number of manufacturers have sort of hidden the park button. So there's no mechanical signaling that I've got the car in park or I don't. And this is literally that if people get crushed human built systems, I'm not going to go so far to speculate when the machine start building their own systems. But for me, the thing that I think is always going to be important about design and engineering is that we're still responsible for how things work, even if we delegate some part of that to artificial intelligence from machines. And until we get to the point where the machine turns smarter than us, which again, I would forecast anytime soon, we have to really be, I think, mindful about where design can really help us to do a better job for people. That's a really fantastic reminder for developers who you may have had the experience of designing something kind of in a black box or working on a project that was not really thinking about very simple things like human factors. The physical nature of what we do, a lot of the work that I did in my master's program at Georgia Tech was relying on the physical space that you're in when you use a digital product. How that changes how you perceive it. The light in the room. These are things that a very large company, certainly, are thinking about, but a lot of the time, the small boutique app designer is not typically going to think about that kind of thing. And it becomes more and more important as we have more and more choices of what to use so many micro products that are available. Anybody can create and release something that is shaping our world. So it's incredibly important to keep this stuff in mind, especially as we become more and more agile and able to create things faster, create products that are still well-suited for the market in less time as our tools become more capable of creating those things or co-creating those things with us. Right. And I think your right context is key. So you have to not just model it, you have to at some level build your designs within that context. So we can have the best system for recording this conversation, for example, but there are sirens screaming down Broadway right now so you can help. And if our room had better acoustic isolation of the doors and windows, we would probably not be bothered as much by that. The thing that I think that design can always bring is sort of the ability to step back and it's the powers of 10 thing. You can step back and really look at, okay, we solved the right problem in a narrow sense technically, but what are we doing in the bigger sense in the context of the office or the city or the planet? So I think that it's very important to always check yourself against the scale that you want the impact to arrive at in what you're building. And I don't think anybody thinks that you're just building for the finite functions of the app or whatever it is you're building, you're definitely building as part of an ecosystem or a system of systems. And that really can, I think, lead to the right outcomes not only for the individual product design, product being designed, but it can lead to a better business outcome for your company. Absolutely. I have two more questions. I know we have to wrap up very soon here. I have two very quick questions for you that I like to ask all the guests who come on the show. The first question is, if you could choose one topic for people to ask you about more often, what would it be? That's a great question. I think I would wish people would ask more often, how was that thing that we're using together working for you? We just tend to dive in and start using things. And I think these are thinking of technology tools, but many tools. And we don't check ourselves on it. Are we using this in the right way? I made the comment earlier that I think that there's always a larger scale. And what I'm finding about particularly on technology tools is that you really need a sort of user community leader and a content leader. If there's content flowing through that tool or being manipulated by it. And those are not really technology or engineering roles. Those are actually quite human. There are people that actually can galvanize users that can get empowered of the mavens and deal with your resistors. I think those are the big misses that I don't get asked enough about. Is how is this working for you and your user population? I mean, with lots of vendors of cool new tools that I like a lot. But they're drinking their own cool aid and telling me why what they have is so great and not asking how is it going to work because it's not so dependent on their great features and their functionality and their SLA and their uptime. It's based upon how people are actually using it. Yeah, absolutely. And this is such an important piece of the puzzle is just communicating, getting words in front of another person and getting their opinion before you get halfway down the road. Figure out if you're going down the right road to begin with. Very good. The second question I like to ask everyone who comes on the show is if you had 30 seconds to give advice to all developers regardless of their background, what would you tell them? Well, let's see. I think I would repeat myself a little bit here from earlier. I would build to learn and not to ship at first. I would want to build lots of things to learn in my asking the right questions and my solving the right problems and the right ways. And then you can start to winnow. So that's one thing. I think in general, understanding the option space around how things might work as technology is gotten so available as the stacks have gotten so full and so flat, could lead back toward those better outcomes like I added it to with the car gear shift selector. It's funny. Again, I went to Carmay when I was a kid in the 60s and I remember the push button transmission that were before I was even born and how they actually broke a paradigm that came out of manual transmissions but led to the classic PR and the printless we call it car design. The printless gear shift selector that manages that, especially as I think it implemented it's best is that it has a visual cue, it has a mechanical feedback, it has all kinds of ways that it's giving the user information and situational awareness. Now with all the mechatronics that are getting flat, miniaturized and getting ready to be really small scale, mezzo scale, not nano, I think I would like all Developer To think more than just bits and coding. I think they should think about physical things that can be achieved with those bits and with that code. Fantastic advice for all Developer That I know and hopefully this is hitting home with the listeners of the show and I'm certain it will be. Thank you so much Tom for coming on the show. You're most welcome and it was delightful to talk to you. Thank you so much for listening to this episode of Developer Tea and I trust that you have listened to both parts of the interview with Tom Eich, I was of course very impressed but also very thankful for Tom's time and really the big takeaway that you can write down from this episode and really this whole interview is that the technology will always be kind of subject to your learning. In other words, regardless of what technology you're using, if you aren't able to continue investing in learning then eventually the technology will be obsolete. It won't really matter all that much. If you can continue learning the technology may be able to enhance that learning but if you stop that process, if you stop learning then you're going to end up in a dead end position. Beyond that, learning is not just about learning your tech. It's about learning about people, it's about learning about how your product is sitting with people, how people interact with it. It's about learning about how you work with other people. Refining your knowledge over and over and over, trying new things, trying old things in new ways, this is how we continue to learn, we continue to invest in that learning process. Thank you again to Tom Eich, thank you to IDEO as well for allowing Tom to share his knowledge and wisdom with us and his experience. Thank you so much for listening to Developer Tea, I hope you'll subscribe so you don't miss out on future episodes. And until next time, enjoy your tea.