What is the value of thinking forward by five or ten years? This is what we discuss in part in today's episode, the second part of my interview with Tom Icke. 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 in whatever podcasting app you use if you don't want to miss out on future episodes just like this one. My name is Jonathan Cottrell. 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. 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. We're going to get straight into the second part of the interview with Tom Icke, CTO at IDEO. That beginning stage. That beginning stage. 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, some of those initial kind of ceremonies, what do they look like? It's interesting you call them ceremonies. I mean, I think that it looks like it did as if I squinted 21 years ago and I walked in. It's basically, we're always trying to make the small changes. We're always 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 is anymore because it's so available and accessible. So really, again, it's not important. 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 whether 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. And 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. And that's a very important thing. And I think that's something that we need 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. So I think that the ceremonies at IDEO, just to 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 on the user. 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 behaviors or is it inhibiting them on the part of the user? And so, 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, right? 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 a door opened and closed on a binder bin for a steel case or whatever it was. Get that model prototyped 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. And make sure that there's compatibility there. One of the things that I always had no problem with was working with bona fide trained designers. Because I recognized that that was a path that I could have taken but didn't. Car design in 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 condition of success for teams. Is that they have to have mutual respect for each other's deep depth or discipline. That's one of the important things. When people do the eye roll about, you know, here comes user testing. I think that's when you start to get worried about where is this headed. And 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. So 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. So 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? And if we're actually going to build something, I think we've hired some really sharp creative technologists and sort of designer coder leads that really understand based on their depth of experience. Do use this framework or do use this approach or this language or this architecture. Don't use that one. That's another 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. Yeah. You mentioned something very interesting as you were discussing this. Two things that I think are 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. You 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, a way of getting ideas out, whiteboards and post-it notes. So all of these different ways of kind 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. And that refinement process is kind of the the holy grail of design. Right. It is the concept of of switching these ideas around and refining and cutting off corners. If you look at, you know, a sculpture is is that is the cutting off of all of the parts that it is not right. And so much of design is this way as well. Exactly. And it reminds me to share something. I think our founding engineer was one of the early David Kelly design employees, Jimmy Chenko, who I worked 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. And one of his specialties is injection molding machines for complex plastic molded parts. And knowing that he loves David Smith and other sculptors and sculptors, and then you look at the complexities of the injection molding process, you can realize that what Jim's 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 just find. And so I think that that kind of mindset about where we're stripping something down and then 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 your listeners. I think it's really important to realize that there's a lot of work that's going on in the industry 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. Oh, I love that. That's great. Before 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 exactness of how you do it on a screen. But what's more important is that we do it in a way that's really simple. And that's what I think is I think the meta behavior you're trying to foster or design for. And so people need to switch mediums. We have a lot of designers that are happy going from, say, 2D to 3D. And our makespaces 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 know, 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. I think understanding the behavioral science side of things is incredibly important. You've mentioned it a few times. And I think that that some of the way that our brains work, we can talk about this stuff on the show all the time, actually, some of the 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. So 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 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. Where I've seen it 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 what we've used as tools like something called the five dynamics to assess teams that were composing or that are working on a project. It really is about where are you energized and what phase of work and where you may be 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 that those sorts of tools which are simple, they're based on brain science, actually. They're just you answer a shockingly 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 at 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. So finding a partner like Duane Bray is a partner here is responsible for talent. His five dynamics is like the opposite of mine. And we work rather well together. 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. I think the other thing that, you know, I mentioned earlier about leadership needing to have an informed point of view is really important for the. 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, you know, financial service software versus, you know, sort of 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 the facile level of, you know, I know what my 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. And 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 this really kind of speaks into the idea of prediction, but not prediction for the sake of, you know, writing a book, but prediction for the sake of understanding the kind of the long tail of a given product. Right. This is something that you've 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 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 some basic kind of visual. Visuals that I found, I was able to to Google around enough to find these, but some really basic visuals, but ultimately this 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 mattered 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 99 to get it out. Yeah. It definitely is the case that the designers always think about the future and live in the future. It's a cliche to say designers. I use that term broadly 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. And so what we looked at was and we actually ran generative sessions, brainstormers and prototyping sessions around different categories of technology. Um, to get to those scenarios, they were things like what's happening with displays. And and at that time, displays were clearly going down a commodity curve. But, you know, a design lead I worked with who was a close associate said, I don't want to just talk about the watch the future. I want to talk about programmable tattoos that move on my skin. Yeah, that can 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 structural. Way there. They're building an R&D network looking at big disruptive categories of design, the blockchain, AI. Yeah, yeah. 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 to 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 had coined the term Internet of Things. But I don't know if it was coined in 99. It might have been talking about it in the concepts that we showed. Yeah, yeah. And some of these concepts were, you know, eventually they developed into at least very similar analogs. And so that that was really interesting to me to see. You know, it's always interesting to look back at what our predictions were and and see how they fit in. And it was a very interesting project. I highly recommend people go check it out. But I'd also love for people to look at these the things that Colab is doing. Yeah. I mean, 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 the 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've moved quite a ways from that. And nowadays I think we always look at the big human systems. So we wouldn't just say, oh, this is really cool to think about the the age of a team that is more than my personal digital assistant, 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 well-being, on people's health. And we did have the health buddy. Yeah. So there's a larger lens that we now bring to bear that I think it is two things. It gets us focused on solving the right problems at the right level. And it gets us out of, I think, you know, 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. And this is something I've always loved about IDEO is when we look at a given problem and the problem that IDEO is working on, you can rest assured that IDEO is 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. And it is important. I think that I'm proud that years ago working on products, again, Jim Yurchenko and a team of engineers, I think I was part of it, said, we're not going to do any chrome-plated plastic parts for any client no matter how much they want them. We basically stopped doing it. It was a 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 be 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 jaundiced view 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 some are better than others. 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 immature. 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 out 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 led to people getting crushed. Human-built systems. I'm not going to go so far as to speculate when the machines 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 evolution brings evolution and evolution brings evolution and evolution brings evolution and evolution brings evolution and evolution brings evolution evolution brings evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution 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 very large companies 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. And especially as we become more and more active in the digital space, 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 you're right. Context is key. And 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 probably... And if our room had better acoustic isolation, 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, you know, it's the powers of 10 thing. You can step back and really look at, okay, we've 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, you know, 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'd 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 is 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, I'm 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, you know, I think that there's always, you know, a larger scale. And what I'm finding about particularly 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. They're people that actually can galvanize users that can get, empower the mavens and, and deal with the resistors. I think those are the big misses that I don't get asked enough about is, is how's this working for you and your, your, your user population. I, I meet with lots of vendors of cool new tools that I like a lot. But they're drinking their own Kool-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. Yeah, absolutely. And this is, this is such an important piece of the puzzle is just communicating, getting, 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. Right. 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, um, repeat myself a little bit here from early, I would, I would build to learn and not to ship at first, I would want to build lots of things to learn. Am I asking the right questions, am I solving the right problems in the right ways, and then you can start to winnow. So that's one thing, in general, understanding the options space around how things might work, as technology is going, because, you know, if you're going to, if you're going to, if you're going to, as technology has gotten so available, as the stacks have gotten so full and so flat, could lead back toward those better outcomes like I alluded to with the car gear shift selector. It's funny. Again, I was a car mad when I was a kid in the 60s, and I remember the push-button transmissions 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 Prindle, as we call it in car design, the Prindle gear shift selector. The advantage of that, especially as I think implemented at its 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 developers 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 developers that I know. 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. It was delightful to talk to you. Thank you so much for listening to this episode of Developer Tea. I trust that you have listened to both parts of the interview with Tom. Ike, 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 Ike. 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 time. Thank you.