Podcast appearances and mentions of jeff sussna

In observance of the winter holidays, this episode doesn't feature a guest interview. Instead, I reflect on five themes that emerged in the diverse conversations we hosted on the podcast during 2021. I wish you and yours happy holidays! Cover photo by Waldemar Brandt on Unsplash. If you're enjoying the show, please rate or review it in Apple's Podcasts directory: https://podcasts.apple.com/us/podcast/the-informed-life/id1450117117?itsct=podcast_box&itscg=30200 Show notes The Informed Life episode 53: Jason Ulaszek on Healing Social Rifts The Informed Life episode 54: Kourosh Dini on DEVONthink The Informed Life episode 55: Hà Phan on Product Leadership The Informed Life episode 56: Margot Bloomstein on Trust The Informed Life episode 57: Ben Mosior on Wardley Maps The Informed Life episode 58: Jesse James Garrett on Leadership and IA The Informed Life episode 59: Matt LeMay on One Page / One Hour The Informed Life episode 60: Kat Vellos on Friendship The Informed Life episode 61: Jeff Sussna on Customer Value Charting The Informed Life episode 63: Sophia Prater on Object Oriented UX The Informed Life episode 64: Sarah Barrett on Architectural Scale The Informed Life episode 66: Jim Kalbach on Jobs to Be Done The Informed Life episode 68: Mags Hanley on Career Architecture The Informed Life episode 69: Karl Fast on Interactionism, part 1 The Informed Life episode 70: Karl Fast on Interactionism, part 2 The Informed Life episode 71: Sunni Brown on Deep Self Design The Informed Life episode 73: Patrick Tanguay on Newsletter Curation The Informed Life episode 74: Annie Murphy Paul on The Extended Mind The Informed Life episode 75: Hans Krueger on the Cycle of Emotions The Informed Life episode 76: Dan Brown on IA Lenses Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the transcript Jorge: Welcome to the informed life. In each episode of this show, we find out how people organize information to get things done. I am your host horsehair angle. Today, I don't have a guest on the show. Instead, I'm going to try something a little different. Rather than a conversation with a single guest, I'm going to do a review of some of the things that I heard during the course of the year. So, you'll be hearing from several of the folks who graciously agreed to be on the show. And the reason why I'm doing this is because I listen to a lot of interview-based podcasts. And while I find myself getting totally engrossed in each individual conversation, I often lose track of what I've heard before in prior conversations, and I have a hard time making sense of patterns that may be emerging. So, I thought that during this quiet time of year I might take some time out to do just that, to see if there are any themes or patterns that have stood out during the interviews i've done in the past 12 months. Of course, the guests on the show, didn't speak with each other. I don't want to imply that they're somehow in conversation or responding to each other's points. In fact, the only point that any of these conversations have in common was that I was a part of all of them. I'm also aware that when you take snippets of interviews out of context, It may change their meaning, especially when put next to other snippets from other conversations. And that's definitely not my intent. I'm not going to present these in the order in which they were recorded. In fact, I'm going to talk about these in no particular order. So, in this episode, I'm just going to edit these together and see if I can highlight some of these themes that seemed to have come up in more than one conversation. If you want to check out the full conversations, which I encourage you to do, I will include links to each episode in the show notes. Hopefully, this will prove useful to you if you choose to revisit the conversations we've had over the last year. So, now onto the themes. We recorded 25 conversations during 2021. And in revisiting them now, I've grouped them into five high-level themes. There are other ideas that have come up and there are different arrangements you could make, but these are five themes that stood out to me. The first theme, I'm calling, aligning our values with our actions. The second is about using intentional structures for self-development. The third is about practicing information architecture at scale. The fourth is highlighting tools and methods for visualizing systemic intent. And the fifth is about thinking beyond the brain. I'll unpack what these are about one by one and hopefully draw connections between them to try to bring some coherence to the conversations that we've been having throughout the year. Because I do think that there are things that connect them. Aligning our values with our actions Jorge: So now, let's dive into the first of these themes, which has to do with aligning our values with our actions. And this is one that came in this year, particularly strongly and with intent on my part because I was appalled by the January 6th insurrection in Washington, DC. This horrible event brought to life the degree to which there are deep social rifts in the U.S. And I I've been thinking about what designers can do so what can I do through my work to help make these things better. So I wanted to talk with folks who have been explicitly thinking about this stuff. And this led me to reach out to Jason Ulaszek, who has used design to help heal Rwandan society in the wake of the Rwandan genocide, which I think is obviously a much more extreme situation than the one that we're facing here in the U.S. Now, Jason is not originally from Rwanda, he's from the U.S., so I asked him if there's anything that we could learn from his experience that might help us in our society to start healing the rifts that divide us. And I was very intrigued by his answer; he talked about re-engaging with cultural values. And this is what he had to say: Jason Ulaszek: What was part of the Rwandans cultural value system well before the genocide against the Tutsi, and is now swung fully back -- and they're working hard to ensure that that's the case -- is a really strong sense of cultural values. What they've really tapped into -- and I think this is where it gets into design a bit -- is that they've tapped into ways to embody these cultural values inside of the experiences people have within education. Jorge: So there's an explicit attempt there to create structures — in that case, within the educational system — that help highlight the common social values that bind a people together. And in part the way that I understood it, at least the part of the idea there is to try to rebuild a sense of trust among parties. And we had another episode this year where we talked explicitly about building trust. And this was in episode 56, where I had a conversation with Margot Bloomstein about her book on the subject, which came out this year, called Trustworthy. And, as Margot put it in our conversation, a big part of building trust has to do with authenticity: with having our actions be grounded in a clear set of values and having them be aligned with those values. This is how Margot put it: Margot Bloomstein: You used the term "authenticity." And I think that that's a term that we throw around a lot; that's a term marketers love to throw around. Who wouldn't want to be authentic? And I always wonder, authentic to what? Do you know who you are? Know thy self first, and then you can determine, well, how do we align our actions with our values? Because that's how we measure authenticity: it's the distance between our actions and our words, all of that external stuff and our values. And I think for many organizations, they can jump into kind of the national conversation, into the international conversation, around many of those social issues and say, "Here's what we're doing. Here's why we support this. Here's what we're doing internally. And here's what we're doing externally to make this better for everyone." To put a stake in the ground. And they can do it building on that long-term, authentic investment in their values. Jorge: I love this idea of being more intentional about aligning our values and our actions as we seek to be more authentic. And of course Margot was talking here about doing that at the level of organizations, but it's also possible to do it at an individual level. And in my conversation with author Kat Vellos, we dug into that specifically in the context of her work. In nurturing friendships. And I asked Kat about how we might be more authentic in looking to create the structures that allow us to nurture friendships as we get older. And she highlighted the importance of being present. This is what she had to say about it. Kat Vellos: The more you immerse yourself in what is actually happening in that time that you're connecting with the other person, the more likely you are to feel the benefit. You know, when you're spending time sharing stories with a friend say, focus on their story, focus on them. Get curious. Ask followup questions and have that be the focus of your attention, rather than halfway listening and halfway being in your own head. Like, "do I feel less lonely right now? Do I feel less awkward right now?" Get out of that mental evaluation mode and get real immersed and real curious and interested in the other person. And that's actually when somebody feels heard. That's actually when somebody feels more connected is when you're really present and holding space with each other. Intentional structures for self-development Jorge: This idea of being more present was also an important part of our second theme, which has to do with creating intentional structures for self-development. I like to think of this almost as kind of an information architecture of the self. So, while it might seem on the surface like some of these conversations run a bit further a field from the subject of the show, I see them as being quite aligned in that we are creating conceptual structures that help us affect some kind of change. And in this second theme, the change has to do with internal transformation. We delved into this in a few conversations during the year. The first I will highlight is episode 71, where I interviewed Sunni Brown about her work in Deep Self Design, which is a practice rooted in Zen Buddhism and design thinking. And during this conversation, Sunni chastised me for allowing myself to let my devices keep me from being more present during a camping trip with my family. And I loved how Sunni talked about being more present. This is what she had to say: Sunni Brown: Camping, when it's like safe and beautiful... the point of it is to actually get you into a different state. To get your regulatory system in a different state so that you can enjoy your life and be present with your family and look at the sky and realize that you're part of... you are the sky, there's no difference between you and the sky, you just project that there is. And like, you know what I mean? So, you have to understand that that space is essential for your humanity and and make it a priority. And you can tell people, I mean, there's ways to approach it that are gentle on other people. So you can let people know, "I'm going to go dark for 72 hours. You should know that," Or, "I'm going to go dark, and then I'm going to have one hour where I look at stuff," you know? You have to design it for your life and what's actually available for you. Sometimes people have sick parents at home or sick kids or whatever, but you have to start to understand the benefit of it. Because I think most people think it's just like something they would lose. Like, they wouldn't get... something taken away from them. And I'm like, "no! It's something you're giving yourself that is priceless." And you get amazing ideas. Like your productivity goes up. So, I call it going slow to go fast. Actually I read this interesting Nietzsche quote, which I don't read Nietzsche a lot or anything, but like he said like great ideas are found when you're walking. And Steve Jobs was... Also, I'mnot obsessed with Steve Jobs, but he did a lot of walking meetings. So, If you are a productivity junkie, going slow helps you go fast. And it actually frees up a lot of stuck tension in the body and stuck ideas that you can't get through and it gives you solutions and ahas and insights. So there's huge rewards in it anyway, if you need it to be aligned with productivity. But it's like, dude, we're gonna die one day, Jorge. Like all of us! And the last thing I want to do is be like, "I spent my whole life on my iPhone!" That is like the worst thing that could happen. Jorge: So, we need to be more aware about what is going on with our systems, with our bodies — and we need to be present. And this was not the only conversation that I had that delved on similar subjects. In episode 75, I talked with my friend, Hans Krueger, who has also been influenced by Buddhism, on what he calls the cycle of emotions, which is a conceptual structure — a way of thinking about emotions and how emotions affect our behavior. Here's Hans: Hans Krueger: What surprisingly few people realize is that there is like a real system behind this thing, this whole emotional complex. How they work, how they interact with each other, what leads to what, what you can do to actually cultivate your own emotional state. A state that allows you to perceive as clearly as possible what is real, versus what you imagine is real. Jorge: There's an emerging theme here in the power of visualizing, might be one way to think about it, but at the very least naming these conceptual distinctions, becoming more aware of what is happening internally. And again, this might come across to some folks as not being relevant to information architecture at all. But I do think of these as conceptual structures where there are distinctions that we label and we establish relationships between those distinctions. And the structure helps us understand what we're doing so that we can act more skillfully, more mindfully. And at least one guest during the year talked about using such conceptual models, not just to help us personally, but to help us in our careers. In episode 68, Mags Hanley shared with us her work on career architecture, which is also the subject of her book, which was published after we talked. And Mags made the connection between the methods, processes and tools that we use as information architects and how we develop our careers. Mags Hanley: Career architecture is about how we can use the methods that we think about and we use as information architects or as UX professionals and apply that in a very systematic way into how we think about our careers. Practicing information architecture at scale Jorge: I like this idea of using information, architecture and user experience methods, practices, and tools for our own personal development. But we can also use them to develop our teams and to work at a different level of impact. I think of this as information architecture at scale, which is the next theme that emerged in the conversations that we had on the podcast over the year. Two that immediately come to mind, but I'm not going to highlight as much here, are the conversation with Jim Kalbach on jobs to be done, which, in addition to Jim's book, helped me clarify my own understanding of what jobs to be done are. And this is an important subject, one that designers and product managers need to be aware of. So, if you have heard the phrase, but are not entirely clear on what it means, I encourage you to check out my conversation with Jim. Another one is the conversation that I had recently with Dan Brown on information architecture lenses. And as that explained in that episode, the lenses are a set of cards, and now podcasts and YouTube videos, that aim to serve as a tool to help designers deal with architectural conundrums. So again, if you are into information architecture, and you haven't done so already. I encourage you to check out the conversation with Dan Brown. That said, there are a few episodes that I do want to call out here and bring to your attention. One is the conversation I had on episode 63 with Sophia Prater about her object oriented user experience framework. I see this as a way of formalizing conceptual models so they can be shared and discussed with other team members. This is how sophia described it during our conversation: Sophia Prater: OOUX is all about saying, "okay. If we know that our users think in objects and just human beings think in objects - not not just our developers - human beings think in objects, and to be able to gain understanding, you need to understand what the objects are in that system. And to understand what the objects are we need a certain level of consistency and recognizability to our objects." So as the designers of these environments, if we don't get really super clear on what our objects are, there's no way. There's just absolutely no way in hell that we're going to be able to translate that to our end users. We're just not! If we can't get it straight on our team and we can't get it straight among ourselves, then 1) that's going to create a lot of communication problems internally which is a problem that I hear all the time. We've got everybody on the team coming together. And some people, depending on what department you're in or what your role is, you've got the same object, the same thing being called two or three different things and different objects being called the same thing. And you're trying to design complex software. So just getting on the same page internally is going to be absolutely intrinsic to making sure that it's clear to your end users. Jorge: Another conversation that had to do with considering design at a different level of abstraction was in episode 64, where Sarah Barrett shared with us considerations about the architectural scale of the systems we design. I was particularly drawn to the way Sarah described how we should approach the intended effects of our work: Sarah Barrett: Occasionally, I get comments or people worrying that our information architecture isn't innovative enough that we're not doing anything surprising or introducing anything brand new. And I feel very strongly that your architecture is not the place to surprise people. Like, there are actual architects out there building very innovative homes that no one wants to live in. And I have no interest in doing that. I really want us to use the oldest, most standard, most expected way of doing things. I think the example of the grocery store is another great way here. There's a lot of benefit to not innovating in the layout of a grocery store. There probably is some benefit in innovating a little bit around the edges or in some details, but you gain a lot from making it legible and making it expected for people. And so, that one is really about... okay, given these things that we expect to have: we expect to have global navigation, we expect to have metadata on content, we expect to have titles and breadcrumbs... how do we unpack what each of those things is doing for us and make sure that between the suite of those elements we are using? Because you never use just one, you use lots of them together. Between all of those elements, we are presenting a coherent, complete view of the wayfinding people need. Jorge: It's one thing to create a coherent and complete system that allows people to find and understand things, and it's another to create the conditions that allow that system to evolve over time gracefully as conditions change but to retain that cohesiveness. And doing this requires that we understand that the things that we are designing are in fact systems and they are systems that will require stewardship over time. This implies that we need leadership. And that was the subject of episode 58, where I had a conversation with Jesse James Garrett about leadership and information architecture. This is part of what jesse said during that show. Jesse James Garrett: The way that I talk to folks about design leadership, who have come from a design background -that is to say they've been doing design work - is that leadership is just another design problem. And you're working with different materials and you're working toward different outcomes and you're having to follow different principles, but the task is the same task. It is a creative problem-solving task. It is a systems-thinking task, as a leader. So looking at the ways that you're already doing that systems-thinking, the ways in which you already doing that architecture for yourself in the work that you're already doing, and those will be your strengths. And those will be the pillars that you can lean on that are going to support your work as a leader going forward. They will evolve and they will not look like what they looked like when you were doing content inventories or task flows or whatever other artifacts you might've been working on as a designer. But the skill set that you're building is the same skill set. Jorge: The relationship between design and leadership, and how designers can use our tools, methods, practices, et cetera, to take on leadership roles, was also the subject of episode 55, which featured a conversation with hop-on about her own trajectory from design to product leadership. Hà Phan: I think the difficulty was between the role I have now, or the delta between the role I have now versus being a UX designer is that, you know, it's really a leadership role to basically provide the path to clarity. So when you have a vision, even as a seasoned UX designer, you're going to present forth this vision. And usually there's a thousand questions and a thousand steps before you get there, right? And usually you don't get there entirely. You know, you don't get to the vision entirely the way you had envisioned it. You're going to take turns, right? And I think in this role, what I get to do is that I get to enable the team to find that path to clarity, and to provide the milestones or the mission for each of the goals along the way. Jorge: This idea that leaders provide clarity and vision is very important. And it's one of the reasons why designers can make good leaders, because part of what designers do is clarify and help visualize abstract ideas. I keep saying that design is about making possibilities tangible: we take these vague notions, requirements, constraints, ill defined contexts, and we make things. And these things that we make can be validated somehow. We can put them in context and have them be used by the people that we intend to serve, to see whether things are working or not. And we create feedback loops where we make them incrementally better, better suited to meeting the needs of the people they serve. Visualizing systemic intent Jorge: And this idea of leadership as a role that clarifies and articulates a vision, brings us to the fourth theme that I noticed in going back over this year's episodes, which has to do with highlighting tools and methods for visualizing systemic intent. And by that, I mean different ways of mapping systems and making systems more tangible. Again, this idea of making the abstract more relatable. And we had several conversations along those lines. The first I'm going to highlight here is episode 59, in which Matt LeMay may shared with us One Page / One Hour, an approach he's developed to help teams articulate what they're making by working fast and iterating. So, rather than creating some kind of polished deck, the idea here is to articulate a vision really quickly so that you can spend less time upfront creating polished artifacts and spend more time iterating with stakeholders and other team members. Here's Matt describing how he came up with One Page / One Hour. Matt LeMay: I wrote up this pledge to my business partners saying I'm willing to forego the sense of individual accomplishment that comes from presenting finished and polished deliverables to my colleagues. I promise that I will spend no more than one page and one hour working on any deliverable - any document - before I bring it to the team. In other words, if I show up with five beautifully formatted pages or a one-page that took me 10 hours to create, I want you to hold me accountable to that. I want you to say, "man, why did you do this? We made a deal. We made a commitment to each other! We all know that if we actually want to deliver value, if we want to do valuable work, we need to collaborate earlier on. You can't go off onto your own and create this big thing, and then just want us to tell you how great it is!" Jorge: One Page / One Hour is about trying to articulate very quickly what we have in mind and sharing it so that we can start iterating on it. A few of the other conversations that we had during the year around visualizing systems and visualizing intent were about artifacts that are a little more elaborate. An example of this is Customer Value Charting, which Jeff Sussna shared with us in episode 61. Customer Value Charting, as Jeff explained, it is a tool to balance strategy and agility. And the purpose of creating that balance is to drive customer benefits, which are related to but not the same as business benefits. Jeff illustrated this by means of an example using a common service. Jeff Sussna: The benefit of the dry cleaner is that I can get my tuxedo cleaned in time to go to the formal event. It's not fundamentally about a cash register or a counter or even cleaning chemicals. And I mention that because a lot of the conversation I see around outcomes over outputs tends to actually talk about business outcomes. You know, revenue growth and customer retention, and time on site and business outcomes are great. I don't have any problem with them, but people tend to skip this step. We have a hypothesis that this feature will cause this change in customer behavior, which will lead to this business outcome or business impact. But it leaves open the question of, well, why is the customer changing their behavior? What is the benefit to them? Jorge: These are complex questions to take on for designers or for anyone, frankly. And it's helpful to hear about how folks are going about it. Customer Value Charting is one way of doing it. Another way of visualizing systems and visualizing things like customer needs in a systemic way was shared with us by Ben Mosiure in our conversation, which focused on Wardley maps. Ben Mosior: Wardley mapping is a visual way of representing systems: its users, its needs, its capabilities, its relationships between all those three things. And then it's also positioning those things in a way that helps their qualities become more apparent. So there's this thing that Simon Research called "Evolution." It's basically how do things evolve and get better or die under the pressures of supply demand competition, and what you get is like things start out new, uncertain, high risk, high failure, but with a high potential for future value. But then as they evolve, they get better. You know, someone's always like looking at these weird ideas and trying to make them better because capitalism basically suggest there's money to be made. So someone out there is going to try to make it better. And over time, if the idea is worth investing in, it will continue to get better, more known, more boring, more predictable, and the value of it will be more concrete. And eventually, if it evolves to a certain extent, it becomes an invisible part of our everyday lives. And so, Simon says, look, you want to represent the systems that we're a part of both in terms of their parts and relationships, but also in terms of how evolved each of those parts are. Because what that does is it sets you up to understand the implications of those qualities. New stuff is going to be high failure, old stuff that everybody understands, that's just part of everyday reality like power in the wall. It is going to be less surprising, it's going to be less failure. And so that means that depending on the context, depending on the part of the system we're looking at, we need to have a different way of approaching it. And I think that's the entire point. By making visual artifacts -- by talking about our systems visually -- we can come together, look at a specific part of it, appreciate its qualities, and then together determine what our collective intent is about that part of the system. Jorge: That's a great description of this idea that we can take these complex abstract ideas and make them tangible, make them manifest in the world, and as a result, make it possible for us to have conversations about them, to somehow change the state of things, to make things better. Thinking beyond the brain Jorge: And that brings us to the fifth and final theme that emerged over the year and that I want to emphasize here, which has to do with using tools and our environment to extend our cognitive system. So, in some way, when we are putting up stickies or diagrams or anything up on the wall, we are making it possible for us to share a cognitive space of sorts. And this is true, whether we're doing it with a note-taking app or stickies on a whiteboard. In taking stuff out of our heads and putting them out into the world, we can somehow extend our minds. And that's why I'm calling this fifth theme "thinking beyond the brain." Conversations about this theme came in two different flavors. On the one hand, we had folks who shared with us their thinking processes and tools. And on the other hand, we had a few conversations that were about thinking in this way itself and I'll say a little bit more about both of those. So, first with the thinking processes and tools. In episode 75, Patrick Tanguay shared with us, how he uses a combination of tools to write one of my favorite newsletters, Sentiers. And it's a setup that mirrors somewhat closely my own setup. Another great conversation about a particular tool was in episode 54, where Kourosh Dini told us about how he's using DEVONthink for building a personal knowledge management system. I was very excited to talk with Kourosh because he wrote a book that helped me use DEVONthink better. If you're unfamiliar with this tool and you are someone who needs to manage a lot of information, let's say if you're teaching or writing, it behooves you to give episode 54 a listen. As I mentioned, I also hosted a few discussions which were not about tools in particular, but a little more meta about how the mind itself works beyond the brain. I'll be frank with you, these were some of my favorite conversations during the year. One was with Annie Murphy Paul about her book, The Extended Mind. Annie's book is the clearest explanation I've read on the science behind the field of embodied cognition. It was one of my favorite reads of the year because it does a really good job at dispelling erroneous notions about how the brain works. And I think that this is a very important subject for designers to understand. Here's Annie. Annie Murphy Paul: I always like to say we're more like animals than we are like machines. You know, the brain is a biological organ. I mean, I know this is obvious, but we really can get very entranced in a way by this metaphor of "brain as computer." The brain is a biological organ that evolved to carry out tasks that are often very different from the tasks that we expect it to execute today. And so, our misunderstanding of what the brain is leads us, as you were saying, Jorge, to create these structures in society. In education and in the workplace, in our everyday lives, that really don't suit the reality of what the brain is. I mean, I'm thinking about how, for example, we expect ourselves to be productive. Whether that's in the workplace, or what we expect our students to do in school. You know, we often expect ourselves to sit still, don't move around, don't change the space where you're in. Don't talk to other people. Just sit there and kind of work until it's done. And that's how we expect ourselves to get serious thinking done. And that makes sense, if the brain is a computer, you know? You feed it information and it processes the information, then it spits out the answer in this very linear fashion. But that's not at all how the brain works. Because the brain is so exquisitely sensitive to context, and that context can be the way our bodies are feeling and how they're moving, that context can be literally where we are situated and what we see and what we experience around us, and that context can be the social context: whether we're with other people, whether we're talking to them, how those conversations are unfolding -- all those things have an incredibly powerful impact on how we think. And so, when we expect the brain to function like a computer, whether that's in the office or in the classroom, we're really underselling its actual powers -- its actual genius -- and we're cutting ourselves off from the wellsprings of our own intelligence, which is the fact that we are embodied creatures embedded in an environment and set in this network of relationships. So, it really... we're really kind of leaving a lot of potential intelligence on the table when we limit our idea of what the brain is in that way. Jorge: While this may seem like we are venturing a little far from the ostensible subject of the show, which is about how people organize information to get things done, there's two reasons why I think it's important for us to delve into this subject. One reason is that, if we are to properly organize information so that we can find things, understand things and so on, we have to understand how our minds work, because ultimately what we're doing is we are designing for minds. And the second reason is that in so doing — in organizing information, in creating these information environments — we are creating contexts of the sort that Annie was talking about there. Even if they are not physical contexts, they are contexts that influence how we understand things. The second conversation I had this year on this subject and which I want to highlight here is the conversation I had with my friend, Karl Fast over episodes 69 and 70. And as you might know, if you've been listening to the show for a while, that's the first time I've ever done a double header. In other words, that I've split a conversation between two episodes. And it's just because we had so much to talk about. And I don't think I can do that conversation justice by extracting just any one clip. But again, I do believe that this is an important subject for you to know about, so I encourage you to check out the whole thing. Closing Jorge: So there you have it, that's a very high level overview of some of the conversations that have stood out to me in the podcast over the last year. Now, obviously there were many more — I told you that we recorded 25 episodes — I don't want to in any way suggest that the other ones weren't as interesting. I just wanted to highlight the ones that I thought manifested some of these themes. And to recap them, the five themes are: aligning our values with our actions, using intentional structures for self-development, practicing information architecture at scale, tools and methods for visualizing systemic intent and then finally, thinking beyond the brain. These are subjects that I care about. And it's no accident that we end up having conversations about these things on the show. One of the interesting things about revisiting them now at the end of the year, is that I can start seeing threads that run through several of the themes. For example, the idea that we need to visualize abstract and complex systems, and that doing so allows us to have better conversations about them. That seems to be a thread that's running through various of these themes. It's true, whether we are talking about our own internal values or our career development, or whether we're talking about a service that we are looking to develop for our clients. And like I've said before, I think that designers — and particularly structurally- and systemically-minded designers, such as information architects — are particularly well-suited to visualize systems in this way. The other thread that I see running through all of this is the importance of considering the context that we are working with and working on, and not just the content of what we're designing. The things that we make are going to be experienced in some kind of environment, whether it's a physical environment or some kind of information environment. And the environment makes a big difference. We understand things in context. And part of what we do as information architects is establish those contexts. That's one of the reasons why I've been emphasizing these conversations about embodied cognition and the extended mind. Because science is making it increasingly clear that thinking happens, not just in our nervous systems, but in our bodies. And more to the point here, it happens out in the world. It happens in our environments and it happens in the tools that we interact with. And again, it's a system that is comprised by ourselves as actors, agents, but also the environments in which we're operating. And we can configure those environments in various ways to help us think better. And I think that this is an important frontier, so to speak, an important area of development for people who design structures of information, who create contexts through language and signs. I've loved the conversations that we've had on the show this year. And that is mostly due to the fact that the guests have been great. I am very grateful to everyone who has agreed to be on the show to have me interview them, to share their ideas, their work, their research, their experience with us. I also want to thank Sarah Clarkson, who I have not acknowledged in the show before. And I'm long overdue in doing that, but Sarah helps me edit the podcast. And her help has been invaluable in getting these shows out to you on time. And of course, I'm very grateful for you; for the fact that you are listening to this, that you have decided to make the show a part of your podcast listening. I would love to know whether there's anything that we can do to make things better. So, please drop by the informed.life, and leave us a note. But for now, I'll just tell you that I am planning to keep the show going. I have guests already lined up for next year. I'm excited about these conversations: having them and also being able to share them with you. So again, thank you. I wish you and yours happy holidays and I look forward to sharing more with you next year.

Jeff Sussna is a consultant and author specialized in helping organizations deliver software more effectively. This is Jeff's second appearance on the show. In this conversation, he tells us about Customer Value Charting, a visual tool that helps teams balance strategy and agility. Listen to the show Download episode 61 Show notes Sussna Associates Designing Delivery: Rethinking IT in the Digital Service Economy by Jeff Sussna The Informed Life episode 15: Jeff Sussna on Cybernetics Customer Value Charting: A Visual Tool for Customer-Centered Discovery & Delivery by Jeff Sussna Software as a service Salesforce Slack's new DM feature can be used to send abuse and harassment with just an invite (The Verge) Promise theory Mark Burgess Wardley map Impact mapping User Story mapping ServiceNow JIRA Read the transcript Jorge: Jeff welcome to the show. Jeff: Thanks for having me. It's great to be on and great to talk to you again. Jorge: Yeah, I should have said welcome again to the show, because this is not your first time here. So, thank you for joining us again. Now, some folks might not have listened to our first conversation, so for their benefit, would you mind, please, reintroducing yourself? About Jeff Jeff: I'm Jeff Sussna. I live in Minneapolis and I run a software delivery consulting firm there. And our clients are companies that typically are doing some form of Agile and/or DevOps, and they're struggling with it. And what we typically find is that they face a conflict between agility and autonomy on the one hand, and strategy and alignment on the other. And Agile and DevOps by themselves... they're very much about breaking things down into smaller pieces. Smaller teams, smaller systems, smaller units of work, as a way of making change and adaptation easier. But they don't really have much to say about how you put the pieces back together. I like to say that customers don't want to buy microservices, they want to buy service. And so, there's this kind of big missing piece in the discourse around where are we trying to go and what are we trying to do? And so, our focus is partly on helping organizations do Agile and DevOps more effectively, but what that really ends up being is helping them overcome this conflict between, "this is what I'm doing today," and "this is where we're trying to go this year." What customers want Jorge: And this is the reason why I wanted to speak with you again, because this idea of striking a balance.... I'm going to frame it as striking a balance between agility and strategy — or you called that a strategy/alignment — is something that I think plays out in many fields, not just DevOps. This notion that the best way for us to make progress, let's say, is by working step by step and making small adjustments. But those small adjustments need to be in service to something, right? And... anyways, you shared a link to a post on your website about a tool called Customer Value Charting, which seems to get at this idea of striking a balance between agility and strategy, and I was hoping you would tell us about it. Jeff: Sure. But we need to start by taking a little bit of a step back. One of the things that we've learned working with our clients who typically are making the transition from software products to software services and cloud delivery, is that the cloud completely transforms the relationship between the customer and the software provider. I had an epiphany a number of years ago. I was looking at a marketing website for an early software as a service company; might even have been Salesforce. And right on their homepage, they were talking about things like multiple data centers, and offsite backup, and advanced security practices. And I realized that they were spending marketing dollars on IT operations. And then I read a sentence that really opened my eyes. It said, "we update the software so you don't have to." And the epiphany was the recognition that the cloud transfers the cost of change from the customer to the software provider. So, it used to be when software was a product that the feedback from the customer was things like, "well, we have to go through a three-month change management process before we can install the new version." Or "the new version requires an OS upgrade, and we're not scheduled to do that until next year." And with the cloud, the conversation is completely different. It's, "why is it taking you so long to deliver this feature upgrade, or this bug fix, or this stability improvement?" So, customers start to expect this continuous increase in value. And on the one hand, they become impatient with delay. No matter how good your feature is, if it takes too long to deliver, you start to lose customers. But at the same time, what they want is not just this continuous spray of random features. What they want is improved value. And what value is... I think of it in terms of three dimensions. The first is usefulness. Does it help me accomplish something that I'm trying to do? The second is usability in its largest meaning. Can I understand it? Can I adopt and onboard it? Can I administer it? Can I get help with it? Can I integrate it? And finally, dependability, which is everything from scalability to performance, to resilience, to security, to compliance, to trust. If you look at what happened with Slack this week, when they released this new global DM feature and then pulled it because it turned out to be this opportunity for a huge abuse. They violated people's trust. And so, they had to pull a feature. The missing piece in Agile and DevOps Jorge: I see dependability and usability as perhaps table stakes. And when you speak of creating value, that is where the usefulness dimension comes in. Is that a fair reading of that? Jeff: I think we could have a lengthy debate about whether dependability is table stakes. I mean, yes. Ultimately, what you're after is usefulness, right? The reason I need a dry cleaner is because it isn't feasible for me to clean my tuxedo at home. So, I need someone to do it for me and you're right, that ultimately, that's what I want: is to get my tuxedo clean. But I also need to get my tuxedo clean in time for tonight's formal event. So, things like speed may be important. I need to be able to easily get to and from the dry cleaner, so usability in terms of access to roads and shopping malls and whatever, may be important. The reason that I put these three together is... again, the shift from product to service involves this inclusion of operations. And that's something that often falls short. Product management tends to think of itself as being in the feature business. I do a lot of work with what I call cloud native product management, which is working with organizations and helping them understand that product managers need to be accountable for these usability and dependability metrics, as much as they are accountable for number of features delivered, or customer growth, or revenue, or anything like that. In any case, what customers are expecting is a continual evolution. So, across these dimensions that the service is getting continually better, not just sort of a random spray of things. And so, the challenge is how do you become more continuous and how do you have some strategic direction? And again, this is kind of a missing piece in the Agile and DevOps discourse, and I think that's why there's this kind of impedance mismatch intention and a certain frustration between Agile teams and designers or Agile teams and product managers or Agile teams and executives. And in thinking about how to resolve it, it occurred to me that the answer is simply to approach your work, both at the strategic and the tactical level, in terms of the outcomes as opposed to outputs. And what I mean by outcomes is customer outcomes. Customer benefit is maybe a better word. You know, the benefit of the dry cleaner is that I can get my tuxedo cleaned in time to go to the formal event. It's not fundamentally about a cash register or a counter or even cleaning chemicals. And I mention that because a lot of the conversation I see around outcomes over outputs tends to actually talk about business outcomes. You know, revenue growth and customer retention, and time on site and business outcomes are great. I don't have any problem with them, but people tend to skip this step. We have a hypothesis that this feature will cause this change in customer behavior, which will lead to this business outcome or business impact. But it leaves open the question of, well, why is the customer changing their behavior? What is the benefit to them? So, I started thinking about both strategy and direction and context, and also tactical work in terms of customer outcomes. We have an epic, or we have a roadmap, or we have a strategy, or we have a user story. Why are we doing that? Who cares? How does it help? And I started working with teams in helping them figure out, well, how do we start to put those two together? And a couple of things happened. One is that for a long time, I've been using some work in something called Promise Theory, which was developed by Mark Burgess, which is a way of thinking about how large-scale complex distributed systems can work well. Where a distributed system could be anything from a large-scale software system to a company, to a city, to an economy. And it's based on the idea that parts of the system make promises to each other. Where a promise is simply an intention to do something of benefit. So, we can think about Slack as promising the ability to get work done together across boundaries, right? Why do you need Slack? If everybody's in the same office, at the same time and they work for the same manager, you don't need Slack. You just talk to each other. It's when you're separated by space and time, and you're working across an organization, or across multiple organizations that you need help in order to get that done. And you can think about all of the features that Slack contains as working in service to that promise. And you can think of those features also as making promises of their own. You know, in order to work together across boundaries, you need to be able to have real-time and non-real-time conversations. You need to be able to find and start conversations and dip into them and out of them. None of that says anything in particular about a feature. We haven't said anything yet about a channel, or a thread, or an emoji. We're talking about what it is that Slack helps a user do and what the user can accomplish by doing that. So, I started working with teams in terms of thinking about what promises we would make. And these could be promises to end users, or they could be promises to other parts of the organization. I do a lot of work with platform teams and their customers are internal development teams. And what happens if you look at particularly traditional IT, there tends to be this approach of: if you want us to do something, file a ticket and we'll do it. It's very requirements-driven. It's very outside-in. We try and do what we're told to do and often we fail, for various reasons, most of which aren't our fault. They have to do with the way that the organization is structured and the way the work is structured. And this is really about turning it inside-out out and thinking about a platform or whatever the team is in the organization, as a service provider that is making and hopefully fulfilling promises to its internal customers. So, I work with them to understand, well, what promises are you making? How well do you fulfill them? And how can you both do a better job of fulfilling your promises and also think about more useful ones to make, which is where innovation really starts to happen. Promises The other interesting thing about a promise — and I should probably talk about this a little more — why this word promise? Why not contract or guarantee or requirement? A promise represents an intention that may or may not actually come to pass. I might promise to take out the trash, and then I might forget. So sometimes we break our promises. And counterintuitively, that's actually a really good thing. I had a conversation with a very thoughtful person once; we were talking about promises and then she sent me this email and she said, "I really don't understand why you would ever make a promise that you don't intend to actually fulfill." And I said, "well, you never would, but you can't guarantee things." So, the word "promise" forces you to think about the possibility of failure, which on the one hand helps you do a better job of not failing, but it also gives you an opportunity to think about improvement and repair. You could think of a promise as a bundle that brings together this idea of service, and customer jobs, and commitments to actually deliver service and continuous improvement. We can create this process where we think about our work at every level, from the tactical all the way to the strategic, in terms of how are we promising to help? How effectively are we fulfilling our promises? And how can we improve our ability to make and fulfill promises that are useful? The next step was to start developing a visual way of representing this. And in particular, a visual way of connecting tactical to strategic outcomes or promises. Customer Value Charting For a while I was working with something called Wardley Maps, which is a very powerful visual mechanism for identifying value chains all the way from the strategic, down to the very, very tactical and devolving that value. And the only problem I found is that when I was working with people who weren't sort of math or graphing nerds, if you will, they tended to find Wardley Maps kind of hard to look at. They're very much built around kind of graph theory and cartesian coordinates and that kind of thing. And people seem to get somewhat confused just by the visual representation. So, I was casting around for another way to present it. I started looking at Impact Maps and User Story Maps, which were very appealing, but what I found in practice was that they tended to kind of fall back into representing features, right? Here's this big feature we want to build and we'll make a User Story Map to represent the parts, and then we'll create slices and say, "we're going to create this set of sub features first." And I really wanted something that focused on this idea of outcomes and promises. And that's what led to Customer Value Charting. You could think of it as a riff on Promise Theory meets Wardley Maps meets User Story Maps. And it's a very simple visual representation, which is basically a grid of three rows and four columns. When you look at it from the top down, the top row is, "why is your help needed?" What is it that your customer or a potential customer is trying to do that they can't do on their own? So, if we continue with our Slack example, it's getting work done together across boundaries. If you look at the middle row, this is, "how do you help?" What promises do you make in support of that higher need? So, again, Slack promises things like the ability to have structured conversations that are both real time and non-real time so you and I can just chat and then one of us can go off to lunch and come back and continue the conversation. The ability to dip into and out of conversation. So, if I join a new team, I can find out what conversations have been happening. I can see what happened last night or yesterday. The ability to dynamically create and find conversation. And the bottom row is, "what help do you need in order to fulfill your own promises?" If you're on the Slack application team and you're building an application, you need things like elastic infrastructure, because it's a very dynamic system and users come and go. It needs to be able to scale up and down very easily. You also need help from the customer support organization, because you need visibility into how are customers using the application and how are they struggling with it so we understand where it needs to be improved. Once you do that, you have a nice visual representation of your value proposition all the way from the top to the bottom of what business are we in and how do we help and who do we help. Then, if you look at it from the left to the right, you basically lay out your promises in terms of how effectively do we fulfill them. So, at the left, you have promises that you don't make. This isn't part of our business. If you want to manage some very structured workflow like procurement or ITIL or something like that, you don't do that in Slack and do that in something like ServiceNow. Now, that's helpful because it bounds your scope. It allows you to say things like, "nope! We shouldn't be working on this because we don't do it. It's not our business. We don't make any promises about that." But it's also a great place to find opportunities for innovation by identifying underserved customer needs. This is a promise we don't make, but maybe we should. The second column is, "things that you're exploring." You're just dipping your toe in the water, you know? Maybe you're not sure if there's a market or a real need for it yet. You only did it in order to win a customer deal. For whatever reason you haven't fully invested. The third column is your bread and butter. This is the heart of our product. It more or less works the way it's supposed to and more or less does what people need. And the furthest column to the right is this is where our competitive advantage is. This is where customer delight happens. This is where we know people won't switch to a competitor because they really love or are hooked on this one particular feature. So now you have in one place, your value proposition and your operational reality of this is how we actually execute on our value proposition. And then the exercise becomes a matter of identifying areas where you want to move something from the left to the right. Where you want to become more effective at. This is an iterative process. You don't start with something that you don't do at all and try and make it highly effective or compelling in one shot. You start by exploring it. Let's dip our toes in the water and find out. And the final step is you start attaching actual work to it in terms of what is the next step we're going to take. An example of CVC Let's take the example of Slack where Slack doesn't do structured workflow. But a lot of times what happens is people are debugging together in a Slack channel and they find some infrastructure problem and they have to go over to ServiceNow in order to file a ticket. Wouldn't it be nice if you actually had the ability to integrate ITIL directly into Slack because there's a use for it. So, that's an area we want to invest in. We want to explore. And the first thing we're going to do is we're just going to build a very simple connector that allows you to create a simplistic incident ticket directly from a Slack chat. What you have now done is you have identified a simple small piece of work that you were going to use to validate and explore a larger, more strategic direction. And you use this as an iterative management and conversation technique so that you do some work and then you come back and you ask yourself, "well, how far did that get us along the path that we're trying to get?" maybe it was harder than we thought, and there's not really as much market need as we thought, and we should just stop. Or maybe we learn something from it, and we discover that the next thing we should do along that path is to build Y instead of X. And again, this entire process is happening in terms of promises of outcomes, not really in terms of locking down features. So, it gives you this ability to explore in an agile fashion, but to give everybody a sense of what direction we're moving in. What is it that we're trying to make better? You know, so often when I work with Agile teams, they do stand-ups and they drew retros and they define their sprint goals and things like that in terms of work and quantity and velocity. Our sprint goal is to finish these 24 stories, and we finished 23 so we're going to declare our sprint a success. Well, what did you actually deliver? What got better as a result, you know? Or what we need to do in this iteration is we need to add three database indexes. Well, what is the promise that we're delivering on? The promise is to make search 15% faster. And whether you do three database indexes or seven or one, isn't the essential point. The essential point is to make search 15% faster. So, if you connect your work to that promise, you give yourself the flexibility of how to actually go about doing it. But you have a goal that everybody understands and everybody can communicate to each other, to management, to your customers. And so, it brings together this idea of flexibility and agility with having some kind of direction that you're trying to go in that has value in everyone. A better roadmap Jorge: It sounds to me like a tool to help visualize in a more tangible way, the question, "what is this in service to and where might we be missing something?" And, in that way, it strikes me as a kind of more useful version of a roadmap, perhaps? Is that a fair read? Jeff: That is an excellent read. Yes! It is all about identifying value and evolving value. And it's funny, I'm glad you mentioned the word roadmap. If you think about a map, right? Like a real roadmap. And remember... you and I are probably both old enough to remember the days when you actually had one of those foldout paper maps. A map showed you how you could get from point A to point B. It doesn't tell you how to get there, right? You get to make decisions about, well, we're going to take highway or we're not going to take the highway, or we're going to go this way so we can stop here for lunch. It presents opportunities. And the problem I have with traditional product roadmaps is they cause, I think, unnecessary pain and frustration. You know, the underlying insight that Agile had is that when you're building something large and complex and novel — something that's a little different from what you've built before — it is extremely hard to perfectly predict exactly how you should build it, or even exactly what it should be. And if you look at a roadmap... and it's funny, I keep coming back to this idea of AgileFall, where people use Agile to do Waterfall. And there's a lot of grief and a lot of condescension... "Well, if you're doing AgileFall, you're doing it wrong. You're bad. You're bad at Agile." I think what that misses is that AgileFall represents this tension that hasn't been resolved around, "well, we need something more than just what we're going to accomplish in the next two weeks." And so, what happens is people trying to lock down the big picture. There's a presentation where somebody stood up and they presented this completely Waterfall 12-month roadmap that said, "this is what we're going to do in Q1, Q2, Q3, Q4." And then they said, "but because we're Agile, we might change the dates." In other words, this roadmap is a work of fiction. And its primary purpose is to frustrate you because we are explicitly telling you that we're making promises, right? We promise to deliver this feature on this date. And we're going to break those promises. And I think that people do that because again, we all need a sense of direction and a sense of context. We need it for ourselves, our stakeholders need it, our executives need it, our customers need it. Where are we going? And we don't know how to communicate that other than in terms of work. But if we can communicate it in terms of value, right? So, if you think about Slack, the ability to find conversations is actually somewhat crude. You kind of have to know what you're looking for, right? You're looking for a particular name, which could be somewhat arcane. So, you couldn't actually really say that the ability to find conversations in Slack is as effective as it should be. If you tell your customers, "we are going to make the ability to find conversations more effective and more powerful and more flexible." — "Oh! That sounds good, because yeah, it really needs to be better. We're really excited about that!" You haven't locked yourself into a particular date or a particular implementation. You can explore and discover that as you go and you can tell your customers, "well, here's this thing that we're delivering this week that will make conversation-finding a little bit better in this particular way." And then, "oh! We can do that again. Well, next week, here's this thing that we're delivering that will make it even a little bit better." So, it allows you to plan, and it allows you to communicate without kind of forcing yourself into a model that doesn't actually work when you're building complex software systems. Jorge: It strikes me that the traditional roadmap is a forecast of what's going to happen that is, by definition, made at a time when your knowledge of the entire situation is imperfect. And the actual process is more like... it's stochastic, right? Every step that you take changes what happens next. If that's a fair read, then this artifact that you're describing is organic in the sense that it needs to be a living document that is revisited often. And a) I'm wondering if that's a fair read and, b) if that's the case, then who is responsible for being the steward of this chart? Jeff: It is a fair read. And I'm going to struggle with the answer to who is responsible. I think there are two answers. One is the product owner and the product manager. But two is the team. Because... you're absolutely right. Its intention is as a conversation and planning tool, not actually as a document. I don't care what it looked like last month. The point is to continuously have a conversation around, "are we getting where we want to go? What's the next step to go there? And do we still even want to go in that direction?" And so, it's simply a tool for that kind of conversation. The reason I hesitate is about who owns it or who shepherds it, is the team needs to be having the conversation. And it's less important to me who runs the session or who... you know, in the good old days, many, many moons ago, before pandemic, I would say: "create a three by four grid on a whiteboard and get stickies and put them up on the wall and move the stickies around." It's funny, because a couple of years ago I worked with a team and they were part of an organization that was very, very JIRA driven. And for whatever reason, they decided to just put stuff up on a whiteboard. And it worked perfectly.So, the mechanism is less important than the process. A high functioning team ought to be able to just have this conversation. Now, I think where it becomes interesting to think about product owners and product managers is the connection with the larger business context, right? Of why are we going in this particular direction? And how do we provide feedback to the rest of the organization about the success of going in that direction? That's really where I think that sort of... I think what you're talking about in terms of stewardship comes in is: this isn't just for teams, it's a way for teams to communicate with other parts of the organization. Or "well, you want to know what we're doing? Well, what we're doing is we're making conversation-finding better, and here's why, and here's how. Here's what we're doing next to move in that direction." And we can have conversations at a higher management level of, "is conversation-finding something that we want to be investing in?" The nice thing about that is that you stop having conversations about, "well, why didn't you deliver the feature that you said you were going to deliver on this date? Your team is not performing." Right? It makes your stakeholder and management-level conversation much richer and more productive, in my opinion. Closing Jorge: Well, this sounds like a tool that is much needed. And I'm grateful that you are writing and speaking about it. Where can folks go to find out more? Jeff: Well, they can go to the sussna-associates.com website, is the best place. There's various information about it there. This is something that I have primarily been using in working with actual clients, so I'm just starting the process of exposing it more generally and starting to talk and write about it more generally. So, I wrote a book, that was really about some of the theoretical underpinnings behind this several years ago. I've been toying with the idea of writing another one, much more practical, down to earth about how to use promises and how to use Customer Value Charts in order to run an Agile organization. So, it's very much of a work in progress. And thanks to you for helping me start to talk about this in a broader context. Jorge: Well, I'm very excited to see where it goes, and, looking forward to having you again in the show sometime, Jeff! I always enjoy our conversations a great deal. Jeff: As do I! Thanks for having me, and hopefully it'll be sooner than another 18 months when we do it again.

Lou and Jeff Sussna, author of Designing Delivery: Rethinking IT in the Digital Service Economy, examine the relationships between Design and Operations, DevOps and DesignOps, and DevOps and Agile before wending their way to promise theory, which looks at the “promise” made between a product and its user. Color Lou convinced on the promise of product promises! • Watch Jeff’s presentation at the 2017 DesignOps Summit: https://youtu.be/uWZxsul8Rek • Read Jeff’s book, Designing Delivery: https://www.oreilly.com/library/view/designing-delivery/9781491903742/ • Listen to Jeff on a previous episode of the Rosenfeld Review, DesignOps in a Post-Industrial World: Crash-Coursing Complex Systems: https://rosenfeldmedia.com/designops-community/archive/designops-jeff-sussna/ • Jeff recommends: Mark Burgess’ Thinking In Promises: http://markburgess.org/TIpromises.html Jeff is Founder and CEO of Sussna Associates, a Minneapolis consulting firm. Sussna Associates helps software teams and executives meet the demand for continuous service delivery. More about Jeff: https://www.sussna-associates.com/about#jeff Twitter: @jeffsussna LinkedIn: https://www.linkedin.com/in/jeffsussna/

In this episode, Jeff Sussna, author of Designing Delivery (O'Reilly), joins Matt and Mike to share his experiences helping organizations implement best practices for digital service delivery. He discusses promise theory, value charting, and the role APIs play in the digital ecosystem.

Enjoy our content? Support This is HCD by becoming a Premium Member Power of Ten is a podcast about design operating at many levels - zooming out from thoughtful detail through to organisational transformation, and on to changes in society and the world, hosted by Andy Polaine. In this epsiode, Jeff Sussana, known for introducing the global DevOps community to the importance of empathy and author of Designing Delivery: Rethinking IT in the Digital Service Economy, talks about the importance of systems and design thinking and services as a "chain of promises." Show Links Sussna Associates Jeff's book, Designing Delivery Jeff on Twitter Jeff on LinkedIn Jeff's writings on Medium Andy on Twitter Andy's website and newsletter Support This is HCD by becoming a Premium Member This is HCD Podcast Network EthnoPod with Jay Hasbrouck Bringing Design Closer with Gerry Scullion ProdPod with Adrienne Tan Getting Started in Design with Gerry Scullion Power of Ten with Andy Polaine NEW: The Big Remote with Gerry Scullion and Andy Polaine NEW: Moments of Change with Melanie Rayment Talking Shop with Andy Polaine and Gerry Scullion Decoding Culture with Dr. John Curran NEW: World Wide Waste with Gerry McGovern NEW: Global Jams Podcast with Adam Lawrence and Markus Hormess Connect with This is HCD Follow This is HCD us on Twitter Follow This is HCD on Instagram Sign up for our newsletter (we have lots of design giveaways!) Join the practitioner community on This is HCD Slack Channel Read articles on our This is HCD Network on Medium Support the show.

Enjoy our content? Support This is HCD by becoming a Premium Member Power of Ten is a podcast about design operating at many levels - zooming out from thoughtful detail through to organisational transformation, and on to changes in society and the world, hosted by Andy Polaine. In this epsiode, Jeff Sussana, known for introducing the global DevOps community to the importance of empathy and author of Designing Delivery: Rethinking IT in the Digital Service Economy, talks about the importance of systems and design thinking and services as a "chain of promises." Show Links Sussna Associates Jeff's book, Designing Delivery Jeff on Twitter Jeff on LinkedIn Jeff's writings on Medium Andy on Twitter Andy's website and newsletter Support This is HCD by becoming a Premium Member This is HCD Podcast Network EthnoPod with Jay Hasbrouck Bringing Design Closer with Gerry Scullion ProdPod with Adrienne Tan Getting Started in Design with Gerry Scullion Power of Ten with Andy Polaine NEW: The Big Remote with Gerry Scullion and Andy Polaine NEW: Moments of Change with Melanie Rayment Talking Shop with Andy Polaine and Gerry Scullion Decoding Culture with Dr. John Curran NEW: World Wide Waste with Gerry McGovern NEW: Global Jams Podcast with Adam Lawrence and Markus Hormess Connect with This is HCD Follow This is HCD us on Twitter Follow This is HCD on Instagram Sign up for our newsletter (we have lots of design giveaways!) Join the practitioner community on This is HCD Slack Channel Read articles on our This is HCD Network on Medium Support the show.

Jeff Sussna is an IT coach and design thinking practitioner, writer, speaker and teacher. He talks about the importance of breaking down silos and how to accomplish goals. Organizations – large or small – face similar problems when trying to release more often. Breaking down to smaller silos but also efficient and collaborative communication within and between teams make the real difference in DevOps. Stephan Lange from Accenture | SolutionsIQ hosted this episode at the DevOpsCon in Berlin in 2019. #BusinessAgility #AgileAmped #BreakingDownSilos #DevOpsCon #JeffSussna #StephanLange

My guest today is Andrew Hinton. Andrew has worked in the digital design field for two decades. He's one of the founders of the Information Architecture Institute and author of the book Understanding Context. In this conversation, you'll learn about the foundations of information architecture and why Andrew thinks of himself as a “radical information architect.” Listen to the full conversation https://theinformeddotlife.files.wordpress.com/2020/01/the-informed-life-episode-26-andrew-hinton.mp3   Show notes Andrew Hinton Helix (database) Understanding Context: Environment, Language, and Information Architecture by Andrew Hinton The Information Architecture Institute The Information Architecture Conference The Informed Life Episode 21: Vanessa Foss on Event Planning Shared Information Environment: let's unpack that, shall we? by Andrew Hinton MUD Interactive fiction (e.g. text adventure games) World of Warcraft O'Reilly Media Peter Morville Ecological psychology James J. Gibson & Eleanor J. Gibson Phlogiston The Copernican Revolution Cartesianism Play-Doh Contextual inquiry Service design Ecosystem Map Bodystorming Attention deficit hyperactivity disorder (ADHD) The Informed Life Episode 15: Jeff Sussna on Cybernetics Norbert Wiener Claude Shannon Due app Apple's Reminders app Steve Jobs: “Computers are like a bicycle for our minds” The Mother of All Demos Doug Englebart Read the full transcript Jorge: So, Andrew, welcome to the show. Andrew: Great. Hey, Jorge, thanks. Very glad to be here. Jorge: So, you and I have been friends for a long time, but for folks who might not be familiar with you, would you please tell us about yourself? Andrew: Yeah, sure. I'm Andrew Hinton. I have been in the design community, in doing digital oriented design things for probably 25 years now, if we count things I was doing before I was being paid full time for it. But definitely 20 years solid now for actually this being my “job” job. And information architecture is kind of my, I don't know, I consider that sort of my home turf. My origin story in all of this really, I think is, is information architecture story. The first community I really kind of bonded with and got connected with was the early IA community, back in the late nineties. Since I started doing this, I've worked roughly half and half, as an internal in large organizations as well as an external consultant, or agency style person. but even then, typically it's very large like… Early on, it was manufacturing in the Southeast. That was like most of our clients in the company I was with then. So, I've worked with a lot of different, big companies and IT organizations and things like that. Nonprofits, profits. But before I got to doing all this, I was more of a humanities person and I still am, I think, at heart. Was a philosophy major, went to seminary briefly as a way to get a theology and philosophy graduate education, but then left because the seminary started getting weird. And then I went into literature and got a masters in that and then ended up with a Master of Fine Arts and poetry. Mostly all of this was just a avoid the real world until I was about 30. But then I had to get like a real job, and it turned out that this fixation I had on the internet, was something that people would pay for more than poems. So, I got into that at that point. But before then, I had really done odd jobs and things where I think a really early formative thing for me was early nineties working in a doctor's office while I was in grad school and all they had was a typewriter and a phone. And I had seen a demo and a Mac user group of something called Double-Helix, I don't know if you remember that. It was later called Helix. But it was just a sort of a drag and drop style way to make a relational database. And I was like, “Ah, we need a database for all of these clients, you know, all these patients, and their accounts and things.” So, they let me do that. And I had to teach it to other people who work in the office and kind of figure out how the interface would work. And really it was sort of this crucible for figuring out how to make things on screens that people could use. And I sort of went from there. Yeah, that's in a nutshell. I ended up writing a book, which just turned five just a couple of days ago, called Understanding Context. and I've been involved in the IA community for a good while, was one of the co-starters of the erstwhile Information Architecture Institute. And I'm looking forward to hopefully being in New Orleans, with my, the IA community, which I really think of like a family reunion for me, honestly. Jorge: I recently had Vanessa Foss on the show; she is one of the people who runs the IA Conference. And that notion of that event as a family reunion came up. It definitely feels like that to me as well. Andrew: Well, and it feels like a family is growing too, which is great. Like I used to worry that it was just a bunch of, you know, old hands getting together. But every year I see these new faces and voices who are stepping in and doing things, you know, and loving the community too. So, in spite of some of the ups and downs, with organizations and whatnot, I'm very optimistic about the community's health. Jorge: And the community is a community in part because of your work. Thank you for the efforts that you've put into the information architecture community over the years. You said that you had studied fine arts and poetry as a way to avoid the real world. And I will say this, you entered the real-world with a bang. I remember myself entering the information architecture community and being influenced by your writings. I remember one piece in particular about the centrality of hyperlinks and how that was different about this work. And then the book that you brought up, Understanding Context, which I consider an important book in the information architecture field. And I was hoping you would tell us a little bit more about that. Andrew: Sure. The challenge is that… A little bit of a qualifier: it's always hard to know where to start. But, really, I think where it came from was really, I think, very early on in my involvement in the IA field, as it was starting to get going as well in the web IA community, I guess I should say. I had already been online, doing things on the internet since right out of college. And I was fascinated with how something like — if our listeners are not familiar, there were these things called — and there are — these things called MUDs, multi-user domains, or multi-user dungeons, because some of the earlier ones are really more like online D&D games, like text-based adventure games, but made in a way where multiple players can be in the same place at the same time. And a precursor to things like World of Warcraft and stuff like that. But there were bunches of these, with different code bases. And it was just one example of where it felt like you were in a real place with people. Like there were emotions involved, there were social interactions and meaning being created. I mean, it really, it mattered. It wasn't virtual in the sense of somehow non-corporeal. It was real. People had bodies who were interacting with one another in this environment. It was just mediated through language, but it felt different than just a conversation. Right? It felt like you were in a place because there were structures, and those structures felt like they affected those interactions, and they mattered. So anyway, that and some other things just had me thinking for a long, long time about what is it that makes this feel this way and work this way? I didn't have this way of saying it then, but now, how is it that language can be environment in that way? So that's always been in the back of my mind. One reason why information architecture was so fascinating to me is because to me, it's never really been especially a metaphor. It's really been just a different way of making structures that people live together in. So, from that, I also was curious, “Okay, we were doing this thing called information architecture. What is it that we're making? Like what do we mean by that?” So, the architecture part is, you know, it's sort of clear, but then the information part is not so clear. I just really wanted to go deep on understanding; what is my material if I'm an information architect? And if we're going to have this discipline, then we need some kind of grounding. Don't we need to really understand what it is we're doing, at a very fundamental level? And I had this hunch that something about digital technology was changing the way human experience worked in terms of how context worked, because anything as simple as just accidentally hitting “reply all”, a button that looks exactly like the “reply” button, except for some minor differences, having a wildly outsized effect, compared to the actual action you're taking. As opposed to in physical life, right? If you want to talk to 10,000 people or whatever, instead of just one person, there's a massive physical difference in what you need to do. All you have to work with is just physical stuff, right? Nothing technological. All the way up to the way Facebook was, clearly, essentially, you know, even early on, basically almost phishing people to get at their information and to trick them into connecting to more people and inviting more people in ways that were manipulative. These were all really preoccupying to me. But also, I really cared about the IA community and what we were doing. And I thought, we need to understand what it is we're saying when we say this information architecture thing. Because I was willing to let go of the label entirely if it turned out it really didn't mean anything different that was important. But I was just so convinced — and still am — that there is a thing that we need, and we need it to be good that other phrases about things like interaction design or user experience and these other labels, they don't quite get at. So, all of those things together. I went on this, I thought, “Hey, I'm going to write this little book about context. I'm just going to… I've got some thoughts. I'm going to put them down.” Somehow, I talked to O'Reilly about doing this with me, and thankful to Peter Morville for helping me make that connection. And it just morphed. And I'll end with this bit that — and you've heard me say this before — I think I wrote 100, 150 pages of just all of these ideas and thoughts I've had from talks and writing, some things I've already done. And then I just got into this part where I was like, “Okay, well I need to address what information is.” And I just didn't know, having some [inaudible] academic background, I was like, “I need to make sure I'm really researching these things and being clear.” So, I asked around, and I asked some of people we know, who teach in universities, about information. And I asked them, and I could not get a straight answer. And I thought, well, that's interesting. And, anyway. Ended up finding out about this whole other way of thinking about information that comes from ecological psychology, the work of James J. Gibson and his wife, and how that was influencing embodied cognition as a theoretical approach. And it just kind of went from there and it blew everything up and I had to kind of start over. And then I ended up writing a much bigger book than I believed. But that was sort of the story behind like why I even got into it. And what it's done is it's really rewired the way I think about the way people interact with their environment. Even just me saying it that way is an artifact of that rewiring, right? I tend to talk about environments rather than just individual devices or things or websites and whatnot. Anyway, it just really changed the way I think about what I do, that I'm still really coming to understand. Jorge: You said that a part of your pursuit for writing the book was coming to an understanding of what the material is that we're working with when we are working on an information architecture. Can you speak more to what that material is or where you've landed on that? Andrew: The material, it turns out to be material. And what I mean by that is, I think early on I thought… So, I use this analogy sometimes. You know how early science and alchemists would use this term — “phlogiston” — to talk about some substance or thing that they knew must be there because they could see the effects of what was going on? They treated it as if it was a thing, even though it isn't really a thing. It was multiple things and processes and whatnot, that we now have names for. But to me, that's kind of how I was using that word “material” early on. It feels like we were using information in a material way, but I really couldn't explain what that meant. Now, after going through all this, I've come to realize, well, actually it isn't material like it's, it's stuff. It's our bodies — and our brains are part of our bodies, so I just say our bodies — are interacting with the environment around us. And the environment around us has stuff. You know, it's objects and surfaces and all of that. And that's where information comes from, and everything else is really sort of this linguistic construct that we've created, or in a human sphere of language-meaning. But all of that is ultimately grounded in our bodies and the way our bodies interact with the world, the physical world around us. So, it's really more of a continuum for me now between something like knocking on the table I'm sitting at right now — that's physical — to, if you go all the way to the other end of the spectrum and saying the word “table” and all the meanings that that can have. But ultimately, the only reason that those meanings can be there is because in some way, whether it's three or four or 10 degrees of separation, it's connected to that kind of meaning. So, to me it's about the relationship between the creature, of the human, interacting with that material world. And then when you add language to that, then you get this really interesting material that can be very slippery and hard to pin down because language is like that. But it's in that interplay between our bodies and our environments and the way we talk about our experience and communicate with one another. That's the material. Jorge: One of the challenges that many of us face — many of us who think of ourselves as information architects, primarily — is that the stuff that you're speaking about is stuff that we take for granted in our day-to-day lives. I think that it's in your work that I read about this analogy with fish and this old trope about fish not being aware of the water they're swimming in and somehow, we are swimming in language. And because we are dealing with architecting structures of language that change how people perceive the environment they're operating in — that's a fairly abstract notion. And I'm wondering, for you who have worked, like you said, part of your career internally in large organizations and also as a consultant, how does one make this palatable or actionable to the folks who need this perspective as part of their work? Andrew: So, one of the real challenges of trying to write about this and teach this is that very thing. And part of the challenge of that is, there's a sort of a Copernican shift that you almost need to be able to make, to see it differently. Meaning, you know, the Copernican revolution /[that was/] basically a complete reframing, right? Where it's like, no, everything doesn't revolve around the earth, all these planets revolve around the sun. And it changed… It simplified astrophysics, astronomy. But it was a really hard shift to make because people's just ingrained idea of their experience, where it was not that. And this is really coming from this undoing of Cartesian thinking around body-mind separation and things like that that's sort of been an increasing part of the conversation in the sciences over the last 20 some years, I guess. People are so… It's so ingrained to think about, especially the West, I guess it's, it's so ingrained to think about things in a certain way you know, this idea that you could take your brain and put it into a vat and it'd still be you. But, well, no… Your brain only knows what it knows because of your body and vice versa. That part it feels like it's, to really get a lot of this, you have to get to that, but I'm realizing too that like, well, I can't sit people down and get him there every time. So, the way I've been teaching the workshop, for example, it has been just starting off with just grounding people in a substance or an object and building up from there. Just getting them grounded in, “I have a body,” and so I use Play-Doh in the workshop. So, everybody gets their own Play-Doh and you have to hold the Plato and you have to write down things about like how your body's interacting with it. You put it back in the container, you cover it. You have to think about right now, okay, what is your body experiencing with the Play-Doh now? Well, you can't see it. You can't touch it, but you can see and touch this container. And these all sound like very simplistic, primitive questions. But that's the whole point, to ground people back in simplistic, primitive way of thinking about how bodies and environments interact with one another. Because ultimately what we're trying to get to is all of this abstraction we've created around ourselves, all this information-sphere, all these other things, our bodies want those things to be as straightforward as being able to squish some Play-Doh in my hand or to pick up a hammer and hit a nail. And so that's kind of how I've been framing it is, is getting rid of some of the theory at first, and just grounding people in, “Okay, you've got a body, you're experiencing things,” and then gradually trying to get to the point where we're talking about now, how does language function on top of that? And in what ways does language complicate that simplicity. And then when we add digital, there's a whole other realm of complication or complexity. But it's building up to the abstract, I think helps. It's what I'm ultimately trying to do, is to get at the root. That's why lately I've been calling myself a “radical information architect.” I felt silly that I didn't know this until just recently, that, that radical — the root — really, the root of the word “radical” is the word “root” or the same root. But basically, radical's meaning really comes from this idea that you're changing something at the foundations, right? You're rewiring what's underneath. And I feel like that's what I'm trying to do with this. So if I get people to get out of abstract-head and out of information-head, the way that we typically think of information and start with, how do we understand our physical environment and interact with it in the same way lizards and spiders interact with their environment. The principles are basically the same. And then build from there. That's how I can teach this. Now, if I'm working with just colleagues on the fly in the middle of a project, or I'm talking to my colleagues here at work, I don't go into all that. I mean, I've been here six months and I have yet to go into all that. But what I do is try to slip in this grounding and kind of draw on the whiteboard. Here's a person. Here's some things that they're interacting with. Here's how that might change over time. I'm always trying to locate it into like, you've got a human in an environment doing stuff. Because ultimately that's what user experience brings to the table. There's a human being, and we have to make all this other stuff we're making compatible with that human being. So we're creating new parts of their environment that we want them to use and understand, right? So, in my day-to-day that's just how I started and it's been helpful that we have methodologies like contextual inquiry and service design and things like that where you have some tools, with things like ecosystem mapping and whatnot, that if you really put some pressure on them to make sure you're staying very grounded with a human, with a body doing a thing, that really helps to get people there with you. Things like bodystorming can help too, but it's hard to get engineers to do bodystorming or others. So that's not as common for me. Jorge: You said that this line of thinking has changed how you work, and I feel like we're getting a little bit into that with this conversation, in your interactions with your team. I'm wondering how, if any, it has also influenced the way that you manage your own information and get things done? Andrew: Yeah. I kind of inadvertently learned a lot about myself and the way that I interact with my own environment. You know, another thing about me is, it wasn't until I was in grad school that I was diagnosed with ADHD. And that's something that plagued… I was going to say plagued. That's maybe not the best way to put it. But until I knew what was going on, it was — and you'll hear this from a lot of people who were diagnosed as adults — I really had a lot of challenges that, that really got to the core of myself as a person from that, because I really couldn't trust myself to behave in ways that I wanted to behave in the world and things done and understand things and to keep track of things and all of that. And in fact, just writing a book with one of the scariest things I could even consider. That's one of the reasons I felt like I had to do it, was because it's just very, very hard to marshal… People talk about a train of thought. And for years I've made this joke that I've really got this sort of a Beijing-full of rickshaws of thought. Like, I don't have a train, just these things bouncing around. Understanding this more has helped me to understand so much better that I have to design my environment around me so that it can supplement and help me. Right? And you mentioned earlier before we started recording, you talked about how in one of your podcasts you talked to Jeff Sussna about cybernetics. And honestly, that's a topic I wish I had gone deeper in when I was writing the book, although then I would've had to make it even longer. So, I don't know. But Norbert Wiener and the people who were working in cybernetics, they were really getting at something that the more abstracted Shannon information science, in-theory world, wasn't quite getting at, which was this very ground, that idea of how our bodies and our environments are, are very symbiotic. But it's taken a long time for mainstream thinking to catch up with us. But now I have no shame in creating crutches for myself. So, for example, I use an app called Due on my phone. And good Lord, if this developer ever stops making or updating this, I'm going to be in terrible shape because it works just the way it needed to, which is any little thing that I go, “That feels like something I'm not going to remember.” I put it in there and then it bugs me until I do something about it. Right? So, it allows me to snooze it in a way where I can snooze it in small increments of time or big increments of time of time. For me, it's much more successful than Apple's Reminders, for example, which are too calm for me. And in fact, I think it's the thing where it's like, if it comes up more than a certain number of times, it goes away. I've yet to even figure out what the rules are around Reminders; I find them untrustworthy. Whereas Due, I have this love hate relationship with, because it just nags the hell out of me. But it does it because I told it to. So that's for things in the moment or things I need to remember this at this time. One thing that I really love about Reminders on the iPhone is the location-based thing. So, I take the train to work, which in Atlanta is sort of like winning the lottery to be able to take the train to work. And there are things that I know I need to do as soon as I get to the station near my house, but I know I'm going to forget them because — and it turns out there's research about this, and I write about this in the book — that changing physical environment, affects what you're able to remember. The thoughts that you're having on one room can just disappear when you go to the next room and things like that. And it's not some magical problem. The problem is that your body, your whole cognitive system, is using your environment as a partner in the way that it is making thoughts and thinking through things and remembering things. So, anyway, I can set it so that it's going to remind me of something as soon as I get to the train station. And sure enough, every damn time, it turns out I have forgotten the thing. And I'm thankful that I had told my phone to remind me when I got to the train station. But that's helpful because it's variable. I never know exactly when I'm going to get there when I set the reminder. So, there's things like that I have to do, and I'm in it and it still feels like I'm treading water most of the time, but at least I'm not drowning. And I have other things I do too, but that's just an example of one of those things I've had to do. Other things like routines, where I put my keys, where I put my wallet, where I put my badge for work, I have to do it exactly the same way every day, and if I don't, or if I do this thing where — and again, this is an embodied cognition thing that I understand better now because of that way of thinking — if for some reason, I have some other object in my hand on the way out the door — and this is probably true for a lot of people — like if I've got a letter, I'm trying to mail or something, or especially if it's in any way the shape of another object that I always carry, I'll often forget the thing that I'm always carrying because my body is just sort of halfway paying attention and just assume it's like, “Oh, I've got everything.” Right? So, there's leaks that can happen, but I'm always trying to plug them. Jorge: One of the benefits that we've gained from having these digital things in our lives is that they can augment that relationship between the person and the environment in ways that give us perhaps a little more control and that make it possible for us to suit it better to our needs. Would that be fair? Andrew: Yeah, absolutely. And it's that augmentation again, the thinking around cybernetics, the original work was very much about, right? Which was, let's not create this whole separate alien thing. Like this is all environment, it's all human. So, let's use it to supplement. And even in AI circles, that's one of the big — I don't want to say tension points, but one of the big dichotomies — I guess is it's sort of the school of thought of, well, let's replace certain kinds of human labor using AI or certain human activities or behaviors or whatever versus let's use it to supplement humans and humans supplement it in this more symbiotic kind of a relationship. So, I think, I think that theme, that augmentation theme, I mean, even Steve jobs, right? The bicycle for the mind. I mean, this was, and I think he borrowed a lot of this thinking from… Sorry, his name is escaping me, but the mother of all demos, you know? Jorge: Doug Englebart? Andrew: Yeah. So, this idea of augmenting human needs with technology in this way, it's got a long tradition. But the devil's in the details, right? It's as to how, how do we arrange those things? How do we make them really good for us? You know, rather than things that somehow turn against us, or other people can turn against us. Jorge: Well, thank you. I want to thank you for your work and for helping us be more aware of those relationships. And thank you for being on the show. Where can folks follow up with you? Andrew: I'm online; andrewhinton.com is just sort of my home site and it's got the ways to ping me. There's a contact form, all that stuff, and links to my book, which people are still apparently buying it, because I still get a little check every now and then. So, I'm super happy to know that. I'm starting to feel self-conscious about, about some of the content cause it's getting a little old. But I feel that hopefully the principles are still stable. So contextbook.com is the home site for that. So, you can find me either one of those ways. Jorge: Fantastic, and I will include both of those in the show notes. Thank you so much for being on the show, Andrew. Andrew: Thanks, Jorge. This is great. It was great to catch up and an honor to be on your show.

My guest today is Chris Chandler. Chris is a partner at Philosophie, a strategic software design and development studio. He's also a self-described “agilista,” and in this episode we discuss how designers — especially those working in agile environments — can embrace an ethical approach to their work. Listen to the full conversation https://theinformeddotlife.files.wordpress.com/2019/10/the-informed-life-episode-20-chris-chandler.mp3   Show notes Chris Chandler on Twitter UCLA Department of Information Studies Information Architecture for the World Wide Web by Louis Rosenfeld and Peter Morville Marcia Bates Walt Disney Parks and Resorts Magic Bands at Walt Disney World Kevin Cheng OK/Cancel Philosophie The Informed Life Episode 15: Jeff Sussna on Cybernetics DevOps Ruined by Design: How Designers Destroyed the World and What We Can Do to Fix It by Mike Monteiro Future Ethics by Cennydd Bowles Arturo Perez Bridges the Gap Between UX Design and Metaphysics Friedrich Nietzsche Jacques Derrida Jean Baudrillard Stephen Colbert Existentialism The Ethics of Ambiguity by Simone de Beauvoir The Second Sex by Simone de Beauvoir Jean-Paul Sartre Peter Singer Amazon scraps secret AI recruiting tool that showed bias against women Read the full transcript Jorge: Chris, welcome to the show. Chris: Thanks Jorge. Great to be here. Jorge: Well, I'm very happy to have you here. For folks who don't know you, tell us about yourself. Chris: Sure. Let's see. My career path is gone something like this. I started out, you know, my academic background was more in the social sciences and anthropology. I'm from the Gold Rush generation of internet people coming up in the in the in the mid to late 90s. Fell into web design. I thought for a while I was a webmaster, I built pages for the group I worked at UCLA and then found the information architecture polar bear book, met Marcia Bates at UCLA — I was working in the Library School of information Studies. And I realized that I cared a lot more about the structuring and the conversations about what we should be doing and who were presenting it for than I did about writing code. So, I began a transformation in my life to become a designer. And I'll tell you it took me a very long time to sort of own that self-definition. I didn't think of myself that way. I'm not a visual thinker; I'm a thinker in words. And so, I worked I got a job in the early 2000s — 2003 — at Walt Disney Parks and Resorts Online, and I was there for 10 years. And I think in many ways that that was pretty foundational to my thought process and sort of approach to online experiences. It was tremendous — and you and I have talked about this many many times — in the sense that it's an amazing organization that is very, very user-, customer-, guest-centric. And it was also at the same time a very large corporation that was you know, very much wanting to be a global capitalist enterprise. So, the highs and the lows in terms of the experience, but really amazing to work there. And I got to work on some gigantic projects. I spent the last three years at Disney working on the Magic Band experience at Disney World. And during that process, I joked at the time that the only thing I really designed was workflow. Right? There was a lot of teams and a lot of different groups and a lot of information and I slowly realized that I was spending more of my time with the product management group because the way I looked at it is I had such a strong perspective about being guest-centric, that I always had an opinion about priority. And you know, product managers in a big organization are supposed to set priority, but they typically — unless they've got a very strong metric that they're aiming for, a clear goal — they tend to react to the loudest voice in the room. So, you know the fact that I could help them and give them a guest-centric [inaudible] just realized I was spending more time thinking about planning and priorities and I slowly began to realize that I think maybe I was a product person, more than a designer. In fact, Kevin Cheng — the OK/Cancel writer — UX designer, also a product person. He changed my life and in one sentence he said to me, “Well, I feel like designers are about making things perfect and product people are about good enough.” And with that simple sentence, I realized that I was a good-enough person. And it dovetailed with what I sometimes call a religious conversion to the agile world. So, the post-Disney arc of my career has been to move into product and to become a dedicated “agilista.” The big realization for me, the moment for me, was to think that all of the value of the design that I worked on, it didn't get realized until code hit production. And so that fundamental thought has really reoriented my entire practice around, “What am I doing to make more better code hit production.” And anything I'm doing that doesn't result in more and better code hitting production, I really need to look at and evaluate as to whether it's waste or not, wasteful in the process. So, I went from Disney to Fandango, the online movie ticket sales company, and then after a couple of years there I left to become a full-fledged product strategist and a full-fledged agile person at a software development consulting company called Philosophie. So I've been at Philosophie for four years. I head the product strategy practice here. And I am… Yeah, I am now a proud product person. Jorge: You've surfaced a distinction that I hear coming up in the design twittersphere, which is a distinction between design and agile. And I'm wondering if you can elaborate a bit on that, because I'm always very wary of it, of that distinction. I think it might be a false duality. Chris: Yeah, I agree with that. I feel like… I think this might be a little bit of a theme for me, Jorge, is the difference between the ideal and the real. Right? I think that the critiques of the agile method to design strike me as a little bit of what's… Strawman? In the sense that I think if you think about the greatest designers, and there's definitely, you know, as I said, the distinction before about design being about perfection. Right? I think there's a part of design practices that is like “more time equals higher quality,” right? The ability to get all the little details right, the ability to be consistent across platforms, to think through design systems. I definitely think that there is truth to that from a from a design perspective. But if I think about the real and the way that most of my work went, right? It's not like anybody was ever given all the time in the world to do the design anyway. And when I worked in the more traditional waterfall fashion, I wouldn't describe that as a method for getting the best design. So there's a false distinction there between the methodology of software development versus the demands of the discipline. I suffered more in the waterfall method, right? I felt like we did a lot of work to get the design right but a lot of that had to be changed or compromised in order to get the first version done as the designers worked on their design and then gave it to the developers to do. Just a very quick down and dirty example. When we were working on that Disney World project I mentioned before, we went to a lot of trouble to design custom UI components for the search field and for the dropdowns in the global navigation. And they were heavily branded and they had nice micro animations and they sailed through our creative reviews and got approved. Well, it wasn't until almost a year and a half later, when I realized that the development team was spending an inordinate amount of time to try to make these custom UI components work across browsers in their world of how things went. And it struck me right like, “Hey, what is the value of this incredible design if it can't be realized?” So, when people complain that agile doesn't give designers enough time, my first caveat is, “Well, does waterfall give designers enough time?” I don't think you can answer that in the affirmative, to your point. Recently I read a quote from Jeff Bezos about, “Hey, in this business, if you're waiting till you have a hundred percent of the information, you've waited too long.” Right? Like, you probably should be moving forward at about 70 percent certainty or knowledge. And I think that's the kind of balance. Another version of saying this, which is that when we look at what it takes to build a digital product, we have the design, we have the experience. Then we have the technical aspects, the functional aspect, and then we also have the business aspects. Right? And so, I think the question should always be, how are those three things being balanced in order to produce a product at the end of the line. So, you know, I do sometimes call myself a design traitor, a UX traitor, Jorge, because I feel like I've shifted the emphasis in my thinking. But to balance out those three things, I think of as a design project. I mean that now is my framing, right? I think of design thinking like, how do I balance these three forces because it's not possible to optimize for all three. There's a lot of hard thinking and contingent choices that goes into that balance and it's constantly changing. Jorge: So, it's not that you don't have an ideal that you're moving towards in agile, it's that you haven't over-optimized for that ideal before you have all the information needed to actually do so. Is that a fair statement? Chris: I think that's terrific. Yeah, I agree with that. Jorge: We actually had a previous guest on the show, Jeff Sussna, who spoke about cybernetics, and he was making a similar point. And the way that he articulated it is, he says that what he's aiming to do is to move fast without breaking things. There's this notion that you can move forward towards a destination a way that isn't overly rigid and overly specified, that lets you make it responsive to conditions in the real world. Chris: Yeah, I think that a sort of connection to talk about this — and something I'd recommend people who are interested read more about — is… I'm sort of fascinated by the movement of DevOps. So, this is sort of, again, thinking about code getting into production and working backwards. Right? Lots of teams have got very convoluted processes for how this happens. And to me, the interesting insight from the world of DevOps is that if you can work the kinks, if you can remove bottlenecks and create a process where the code flows from the developers into the production environment on a much more reliable and consistent and fast basis, in a way it gives you that ability to move fast and not break things or to not break things so seriously that you can't recover from them also quickly. So in the world of software we went from companies doing giant software releases, where they might do a release a quarter, or — that's actually, could have been fast for my Disney experience, right? — maybe a release twice a year or three times a year, to companies now that push code into production multiple to hundreds of times a day. And a lot of that is about automating those processes and pipelines to make sure that you're not breaking things. Right? A lot of that impetus for that movement comes from the automation of the QA processes. Right? Like, I want to make sure that when the code hits production all of my tests are automated, so I know right away if something is breaking. So I think you know to me — and this is something I'm always, honestly just to connect to another conversation in our field — I feel like doesn't necessarily get enough emphasis in the DesignOps conversation, which is you need to think about this as a continuous process that starts in ideas and ends up in code and how is the team optimized to deliver designs in production and be able to react quickly to changes? Jorge: How do you bake into that values and an ethical approach to design? Chris: I think this is obviously a current topic and an important topic to discuss. And you know, one of the things I know you and I have connected over the years about… You know, the fact of a personal philosophy and how that influences the work that you do. So, on the one hand, I'm very excited and positive and supportive of the idea that ethics and philosophy should be part and parcel of what we do. Sometimes I say that theory without practice is useless, but sometimes I'll say that practice without theory is expensive. So, if we don't know why we're doing something then it's awfully hard to make improvements and understand why something didn't go the way that it wanted to go. And you know, that's from a practical point. But I think when we talk about “expensive,” the expense of breaking things is more — and this is why it's become such a such a watchword, right? The Facebook motto — it's not just breaking software, right? Like we're talking now about maybe breaking democracy. So that can have really big consequences. That being said, I started, I was challenged by a good friend and designer here in the Los Angeles area, Arturo Perez, who did a series of presentations starting a couple years ago about philosophy and design. And as we started talking about how we could bring that together, it put me into a little bit of a journey to try… I realized that while I had a lot of thoughts and I'd studied philosophy in school, I hadn't really answered some fundamental questions for myself. So, let me talk about that for a second. One issue that we have, that comes up, that is frustrating to me… And I was wondering, when I hear Mike Monteiro speak, or when I read Cennydd Bowles's books, you know, they always felt like there were some missing elements, and I really wanted to try to identify them for myself, what I thought was going on there. One of one of the things that's missing is the idea that in order to make ethical decisions, you have to have a framework that you use to evaluate whether those decisions are ethical or not. And you know, in Cennydd's book in particular, he does a great job of laying out several different frameworks that you could use to decide whether an action was ethical, right? Like you could say — and I'm not going to use the technical philosophical terms here — but you could say that one way to evaluate whether an action is ethical is based on what happens, right? The consequences of that action. You can say, but that's sort of a post-hoc analysis, right? Like I know that this action was unethical because it ended up harming people. Another framework that you can use is to say, well if we have an agreed-upon set of rules, then we can judge actions based on those agreed-upon set of rules. And that is very helpful, but it points to the problem, which is that there are very few agreed-upon sets of rules. And so, to jump back and talk a little bit about this from a philosophical sense, I could say in some ways this is a problem that was announced by Nietzsche when he said God is dead. Right? And so, what I think he was getting at with that proclamation was the fact that for many centuries in the West, our agreed-upon set of rules were based on this Judeo-Christian ethic. Right? Based on the rules that we got from the Bible. And so we can debate all we want about how that practically worked out, but there wasn't a lot of disagreement among people about how would we judge the ethics of actions if we all were coming from a similar spiritual religious meta-narrative, if you will, about what was really important in the world. And this is a crucial, crucial issue for people in the modern world, and this is what Nietzsche was trying to say. Now that that is gone, or put a different way, now that that is no longer as compelling a narrative to as many people, now I can no longer rely on the fact that you and I, working together, might have that common set of values. It undermines exactly how we're going to go about agreeing about what is ethical and what is not ethical. Certainly, people with a religious background and adherence often challenged those of us without such a commitment to try to understand how can we tell what is good if we don't have something like that to refer to. And honestly this problem has only been exacerbated as we've gone along, through the 20th century, right? I think the idea of what is agreed upon has been very much undermined by the postmodernist movement, right? If I think about, in particular, Derrida and deconstruction, to me, what I take away from that — many things, but in this context, which is that there's no such thing as a text that is neutral. And so even when we are talking about the ethical frameworks, how to decide what is ethical, and to decide what the framework is, we no longer can talk about that in an objective way. We have to ask ourselves, “Well, who does this framework serve and who does it not serve? Right? Who are the winners and the losers? Who's above and who's below in that context?” And when I think about what we're living through in the modern world, I think another postmodernist, Baudrillard, pointed out, theorized about another very very very modern, postmodern problem that we all are living through which is that we no longer have an ability to distinguish between reality and simulated reality. And you know, we can argue about whether that was really true at the moment when he wrote it, but we're in this moment living through this extreme crisis, where deep fakes and fake news and pizza gate… You know, the very foundations of what we think of as truth, or as Stephen Colbert used to say, “truthiness,” has been undermined, those underpinnings. So that's a very long-winded discussion, Jorge. But I think the personal journey for me was, “Okay, if I do not have a religious… An appeal to a greater narrative beyond this life, what exactly am I basing my ethics on?” Jorge: I'm wondering as you're describing this, how this line of thinking can help designers — in particular designers that are working within agile environments — to make more ethical decisions, to work towards not breaking things. Chris: So, then I started searching for anybody who had answers to that question. Because, like I said that was… Philosophically, I was like, I feel like we know the frameworks — and again, Cennydd does a great job of doing the frameworks, Mike Monteiro does a great job of explaining our own complicit nature as designers in the world that we're going through. And I found solace and comfort and firm footing in a what I thought was an odd place, which is in existentialism, the philosophical school of existentialism. And in particular, there's a book by Simone de Beauvoir called The Ethics of Ambiguity. And I think she's most well-known for her book The Second Sex, which is a foundational text for the modern feminism movement. Really, she laid out her main thesis in that book, is that people become women. They're not born women, they become women. And it really emphasizes the social roles. I recommend it highly to anyone, because I think it explains a lot of the critique and ongoing discussions around gender roles in society. But Jean-Paul Sartre, he said a couple of things and he wrote many many things. And so, this is… By no means am I an expert or am I trying to be faithful to everything that he said, but just in the snapshot, one of the things that an existentialist believes is, he said, is that man is condemned to be free. So, pardon the gender-specific language there, but humans are condemned to be free, which is really… Fundamentally, our life and what we make of our life is based on the choices that we make, and we cannot choose not to choose. Or to put a different way not choosing is a choice in itself. So, this is a very fundamental principle, and it in some ways it, you know goes to a conclusion that you know, existentialism and existentialists say that the ultimate choice might be whether to live or not live. And even if your choices are constrained — and I think there's a lot of talk about that, especially if we want to talk about privileges and how society is structured — but I think the existentialist response is, you know, you can always choose not to continue living. So, it's a little bit… It's a dark philosophy. So, Simone de Beauvoir took it upon herself, she said, you know, this is all great, but there's no way for anyone to try to figure out how to live their life based on what you just said. So, in The Ethics of Ambiguity, she takes up the question of given this existential reality, how on Earth are we supposed to decide how to live? And the fundamental insight that that she really emphasizes is that we have to understand that we have our subjective experiences, right? We are subjective entities, right? Nobody else can know what my experience has been. And we all are alone in that; we are subjects to ourselves. And then it's very easy to think of the other people that we deal with as objects. But Simone de Beauvoir wants to push on that a little bit — a lot — and say that really much of our lives are not based solely on our subjectivity, but on concepts of intersubjectivity. Right? Like the things that give us meaning, the things that tell us whether we're succeeding or failing are actually things that other subjects, other human beings are involved in. So, this is like just completely at breakneck speed to talk about, but what she says is that as an existentialist in the existentialism philosophy, your highest value should be to work towards your own personal freedom — what you might say, to self-actualization, to own the fact that you are making these choices and to own the consequences of those choices and to be deliberate about those choices — and to work towards freedom. And what Simone de Beauvoir on The Ethics of Ambiguity lays out is, that could be generalized if you think outside of just your subjective experience and you think that actually, you depend on other human beings. And we all live in an intersubjective world that can now be generalized to say that the highest ethical action is to work towards the freedom of yourself and other people. So, this is the aha moment for me where I can say, I now know that I can judge potential actions, potential designs, my participation in the process in the world, by whether I believe it is increasing the freedom of myself and other people. Again, we can argue about that that limitation of the word “people” I think about Peter Singer and the ability to think about the rest of the natural world and animals as part of that, I think about the conversation about how we're going to deal with artificial intelligences. But to limit it to what Simone de Beauvoir wrote, which is we want to judge our actions based on creating more freedom for people. Jorge: One of the things about design — especially in the world in which we're living, in which a digital product can impact the lives of many millions of people, it's not limited to the constraints that designers working in the world of atoms face. So, you're definitely looking after your own soul, but in some ways, you're also concerned with the souls of others, to put it into kind of religious imagery there. Chris: Yeah, I think that's definitely true. I mean, I think there's even in the world of atoms right like I think certainly when we talk about architecture, right? I think there's definitely the same impact on humans. So, we've sort of been contrasting these two writers in the two books and I want to continue that a little bit. So Cennydd does a great job in his book of sort of laying out and helping you understand what are all the issues involved. And he goes into detail with examples and it's a terrific book about the ways that you should think about those second-order effects and how the impacts of your work are going to go. But I think without understanding where you're really going, though, it's difficult to pick and choose. And so, to use an example from the AI ethics, the Amazon machine learning tool that evaluated resumes, right? And they said we're going to look at all this data of what makes a great Amazon employee and then we're going to use that to screen candidates coming into our pipeline. And of course, as we all know, that algorithm was very biased and tended to produce, you know, elevate white male candidates into their funnel. So again, it's easy for us to say that that is the wrong result. But my challenge, and the question I want to ask people is — and this is why I think you need to think fundamentally about what you really mean — is to ask yourself, well, what is the correct result? How would I know that the algorithm was producing the correct result? So, when we talk about diversity of candidates, when we talk about outcomes, I mean, you might say that it's supposed to be completely neutral. But I don't know that anybody believes in that anymore. So, you I think you have to make a positive statement. The one thing I want to implore people, as we talk about ethics, I want to talk about a human flaw that's built into us, which is: it's very important that we appear ethical to other people and to ourselves. And so that whenever we have a conversation about ethics, I've noticed that we all start acting as if we are very ethical. And I think there's a little bit of a danger in that. Because the truth is most of us can think of something less than ethical that we've done in the last 24 hours. And this is again back to the existentialism: we're making choices constantly and we don't always live up to the ethical ideals that we have. And in fact, we rarely live up to the ethical ideals that we have. So, I'm not trying to be critical of us. I'm trying to say that this is something we need to accept, right? That ethics are ideals and we're going to fall short of our ideals. And this is where I want to bring in Mike Monteiro's book where he does a great job of explaining how complicit designers are in all of these problems. But it's a little bit different to say that we should all stop working and refuse clients and turn down work and quit our jobs to be ethical. So, there's a certain… I sort of want to give us the freedom to acknowledge that we live in a contingent world where we make compromises and we fail to live up to our ethical ideals, because I think it's important that that we're allowed to be vulnerable with each other in order to have better conversations. And then the one additional point that I want to make is that when we talk about ethics of artificial intelligences, I just like to propose that to set the bar at human ethical standards would be a bit of a tragedy. Humans, we don't have a great track record on ethics and I hope — we all better hope — that the artificial intelligences, should we ever get to a generalized artificial intelligence, I think we should all hope that that intelligence would be more ethical than human beings, not as ethical as human beings are. Jorge: That's a very provocative statement and also inspiring. And I think it's a good place for us to wrap up the conversation. I feel like we could keep talking about this stuff for a long time. So, Chris where can folks follow up with you? Chris: Oh great. Well, you can find me on Twitter, Chris Chandler, or you can email me Chris Dot Chandler at gmail.com. Jorge: Fantastic, thank you for being on the show, Chris. Chris: Thanks Jorge! Really enjoyed our conversation, as always.

My guest today is IT consultant and author Jeff Sussna. Jeff's liberal arts background has given him a unique perspective on digital transformation. In this episode, we explore the relevance of cybernetics to today's complex design and DevOps challenges. Listen to the full conversation https://theinformeddotlife.files.wordpress.com/2019/08/the-informed-life-episode-15-jeff-sussna.mp3 Show notes Sussna Associates @jeffsussna on Twitter Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation by Tim Brown Norbert Wiener Dark Hero of the Information Age: In Search of Norbert Wiener, The Father of Cybernetics by Flo Conway and Jim Siegelman Cybernetics: or Control and Communication in the Animal and the Machine by Norbert Wiener The Human Use of Human Beings: Cybernetics and Society by Norbert Wiener Lean startup Agile software development Mutual Causality in Buddhism and General Systems Theory: The Dharma of Natural Systems, by Joanna Macy Claude Shannon The Net of Indra Ranulph Glanville Designing Delivery: Rethinking IT in the Digital Service Economy by Jeff Sussna Read the full transcript Jorge: So Jeff, welcome to the show. Jeff: Thanks for having me. It's great to be here. Jorge: For folks who are not familiar with you and your work, how do you describe what you do? Jeff: Well on a basic mechanical level, I founded and lead a consulting agency in Minneapolis. Our focus is helping organizations learn how to move fast without breaking things, and we do that through the entire digital product lifecycle from design through product management all the way to development and operations. It's about bringing together agile and devops and design thinking. We do coaching. We do workshops. A lot of it is about helping people understand: what are we really trying to accomplish when we do things like agile? I go into a lot of organizations where they do scrum for example, and they may do it reasonably well, and they have a bunch of agile activities going on but they're not necessarily really getting where they want to go. And typically that's because they don't fully understand where are they supposed to be going and how is agile supposed to actually help them get there. And it's interesting because the way I got there was actually a somewhat unusual path and I think that that path and how it's gone along really informs my work and my approach to my work. Jorge: I am not familiar with your backstory, so you've said that and now I'm completely curious. Jeff: That was intentional. I figured I'd give you a chance rather than just rambling on for 20 minutes give you a chance to say, “Now would you like to ramble on for 20 minutes and tell us about your background?” Sure, so my background is actually liberal arts. I studied visual arts, anthropology, and political science in college and one day my advisor suggested that I should take a class that had absolutely nothing to do with what I was studying. And so I took an artificial intelligence programming class. This was back in the early 80s, the sort of first or maybe second golden age of AI. And I became captivated both by that but more so programming and and system programming. And I graduated from college and managed to worm my way into the software industry. I've been there for the last 30 years. I've built systems. I've led organizations across the entire development, QA, and operation spectrum. But I always had this background of being in artsy liberal arts person. And I found myself thinking about things a little bit differently and I can never put my finger on it until I read Tim Brown's Change by Design book, which is a popular introduction to design thinking and went, “Oh, that's it! That's me. That's how I naturally think about things.” At the same time, cloud computing was starting to come about. And when I put those two things together what I realized is that service — because we were talking about it as a service and software as a service and things like that — service and the human-centered design that's part of service is really at the heart of everything we do. And so that's really been behind my approach to my work ever since then. And one of the things that happened when I was in college and I was reading about artificial intelligence and playing with it was I read someone, some little paragraph somewhere, about some guy named Norbert Wiener who back in the '40s had invented something called control theory that was peripherally related to AI. And I kind of went okay, that's interesting and didn't make much of it and went about my business. And then about five or six years ago, I happened to be in the library one day and I saw a book called Dark Hero of the Information Age, which was a biography of Norbert Wiener. I thought, “Oh, I remember that guy, you know, I should check that out. I should find out more about him.” So I read it and I was instantly captivated. And I was introduced to this world of cybernetics, which was the thing that he was really responsible for. And cybernetics is really interesting because it was a very big deal in the '40s, '50s, and into the '60s. Wiener wrote a book about cybernetics, which is about 50% post grad level math, you literally can't read it unless you're unless you're a math major. But from what I've read apparently in the '50s every single college student in America was walking around with a copy of that book under their arm. So it was a very big deal and then for a variety of reasons it fell out of favor and disappeared and was completely forgotten. The irony is that anytime that you say a word that begins with cyber — you know cyber-terrorism, cyber-security, cyberspace — the cyber comes from cybernetics. And cybernetics is really at the heart and the origin of computing and actually the heart in the origin of information. When we talk about information architecture, information theory, we have to talk about cybernetics. And it gives kind of a different flavor to what information is and how we work with it. So what is cybernetics? Cybernetics is the idea that in complex systems — particularly the kinds of systems we find in the natural world and in the social world, whether it be cities or economies or companies or markets — that control has to be adaptive. It has to be based on listening and responding as well as just telling people or things what to do. If you think about the most basic cybernetic device, it's a thermostat. A thermostat doesn't actually control the temperature of the air in the room directly. What it does is it, you could say that it listens: it detects what the temperature is, and it detects the fact that the temperature isn't what it's supposed to be, and then it tells the furnace to do something about it. And so the furnace pumps warm air into the room the room warms up, the second law of thermodynamics kicks in the room starts to cool down again. The stat goes. “Uh oh, things aren't as they're supposed to be! We better do something about it.” So you could say that the thermostat in the furnace have actually no control whatsoever over the temperature of the air in the room. Only the second law of thermodynamics does that. But they're continually having a relationship where they're adjusting things. And the way that works is based on a principle that Wiener developed or identified called feedback. And we use that word all the time. But feedback has a very specific meaning which is information about the gap between actual and expected. So if the thermostat is set to 72 degrees and the temperature in the room is actually 71 degrees the thermostat gets some information that says well, it's one degree colder than its supposed to be. So we have a tendency to think about information as the thing, right? We architect it, we store it in databases, we pass it back and forth. But from a cybernetic perspective, information doesn't have any real meaning aside from the context in which it's happening. And its purpose is not just to be a thing its purpose is to help you understand what it is you need to do. One of the things that I learned from studying art and also to some degree from my own just kind of life is that mistakes happen. Things don't always go the way we expect them to. And that's perfectly fine. That doesn't prevent us from getting to a good place if we can have kind of a dance, and to some degree give up the idea that we're fully in control, and instead have a relationship with our world of, “What is it that you're telling me and what do I need to do based on that?” So it's much more relational. I think that companies are beginning to discover that. The reason they're reaching out for things like agile is that they're realizing that they can't control the markets anymore the way they used to, so they have to have the ability to understand and respond to situations — environments — over which they have less and less control and ability to predict. Jorge: You talked about Wiener's book and how fifty percent of it is college level math, and that brings to mind the the idea that some of this stuff can be complicated for folks. And hearing you describe it in this way, it sounds more accessible than other introductions I've heard before to the subject — and more relevant. I'm hearing you say that and thinking, “Yeah, definitely.” I mean that maps to my experience of reality; the fact that if you're going to act you have to get a read on your surroundings and then you must have some kind of model where there's an objective that you're going towards and you need to somehow compute at some level the difference between where you are and where you want to be and adjust your direction. So the question is, when presented at that level it is kind of obvious. Why do you think it fell out of favor? Jeff: Well, part of it was Wiener's fault. He was a very eccentric person. And well, let me take a step back first and say that that Wiener's first book was called Cybernetics: Communication and Control in the Machine and the Animal. That's the one that's full of math. He wrote another book called The Human Use of Humans, which is much more accessible and it presents the concepts of cybernetics in a much less technical way. The amazing thing about it is it also predicts many of the trends that we're seeing now in terms of the dangers of computer-centric society. It's quite an amazing book given that it was written something like 60 years ago. But aside from that, I think the reason it fell out of favor was to some degree because it's too simple and too elegant on a very simple level. I think that part of it is that basically what it's talking about is circular causality. If you really kind of go beyond the surface of just well, we have a thermostat, we want to control the air if we talked about your example of I have an objective and I need to make sure I get to my objective, the real implication of cybernetics is that you're also adjusting your objective. Right? If you look at things like Lean Startup and the whole idea of a pivot, right? Step one of Lean Startup is let's make sure that we're accurately getting where we want to go. But Step 2 of Lean Startup is let's make sure we're trying to get to the right place. That is not exactly a 20th century Western approach to thinking about things. There's been interesting things written about the relationship between cybernetics and systems thinking and more kind of Eastern philosophical approaches. So I think, to be honest to some degree, it just blew people's minds and the world wasn't ready for it. And what I'm seeing now is that maybe the world is starting to get ready for it. It is beginning to be sort of culturally resuscitated again and people are starting to become interested in it again and going, “Oh, maybe there's actually something here.” Jorge: I am very intrigued by this notion of the relationship between systems thinking and Eastern philosophy. You have written very compellingly about this, and I'm wondering if you can delve a bit more on that connection. Jeff: Well, that's a big one. Well, there's… I'll actually refer to a very interesting book by Joanna Macy called General Systems Theory. Now I'm not remembering the name; it's something like Buddhism and General Systems Theory. And she is a system thinking practitioner. She's also a Buddhist teacher and practitioner. And she talks a lot about the Buddhist view of interdependence, which on one level means that the reason that you and I are here now is because of a whole set of things that happen that brought us to this place. You know if if Wiener hadn't thought about feedback systems and if Claude Shannon hadn't figured out how do you transmit feedback reliably in a noisy channel there would be no such thing as information Theory there would be no such thing as computers. There were no such thing as binary logic there would be no such thing as Zoom you and I wouldn't be sitting in different cities talking to each other. So on one level it means that the causality behind what you and I are doing right now is much richer and much larger and much more complex and intertwined and tangled. So to some degree your karma and my karma and Norbert Wiener's and Claude Shannon's karma are all intertwined with each other. On another level and a deeper level what it means is that when I think about myself and who I am that is defined as much by my relationship to you and my relationship to Apple Computer who made the computer that I'm using as it is my idea of who I am internally separate from the world. That this whole idea of you and I and the other things that we see around us is being fundamentally separate from each other is according to Buddhism A) an illusion and B) the cause of suffering — because it is an illusion. So you could say that you caused my experience and I caused your experience as much as each of us causing our own experience. So there is a circularity to how and why things happen, which is a very Buddhist view which comes very much out of an Indian tradition and very compatible with a cybernetic view. Particularly when you go beyond this idea that cybernetics is just about, “How do I control things out there?” and the notion that what it's really about more fundamentally is, “How is it that I dance with this relationship that I have with the world where myself and my environment are creating and driving each other?” Jorge: The image that comes to my mind hearing you describe this, which is an image that I believe comes from the Buddhist tradition, is this notion of the Net of Indra, where there are jewels that are all interconnected and all the jewels reflect the other jewels and you can't intervene in one of them without impacting the others. And in this notion of systems thinking, one of the distinctions I make between that worldview and other approaches is that you're taking in a holistic perspective — as holistic a perspective of the situation as possible — whereas if you contrast it in a more reductionist approach, where we try to divide so we can control. It is a completely different approach, and I'm wondering — just because this subject can get fairly abstract fairly quickly — if there are ways that that impacts your approach both to how you do your work and perhaps the work that you do for clients? Jeff: Very much so. And it actually has very practical down-to-earth ramifications both for IT and also I think for design. One of the things that we've begun to learn in IT is that as we go to the cloud, the systems we manage become more complex. Which means that the parts become more and more intertwined with each other and I think actually the Net of Indra is a wonderful metaphor for that, where it's no longer possible to say, “Well there's a database over here, and there's a network over here, and we have an ERP application over here, and a website over there, and they're all independent from each other, and we can manage them separately.” It doesn't really work anymore; they all impact each other. And one of the practical ramifications of that is that when things break, what we typically try to do is to find the “root cause.” What is the one thing that was the original source of the problem? And in complex systems, you can't actually do that. What you find are contributing causes. That the problem happened because of A and B and C and D coming together. And if any one of them had not happened or happened differently or happened a little slowly or happened at a different time of day either the outage wouldn't have happened or it would have been more or less severe. And this perspective is actually really influenced by work that people have done in industrial safety systems, people who work on things like looking at airplane accidents, nuclear power plant meltdowns, that kind of thing. And they've been discovered for they've come to realization seems like this whole idea of identifying human error — the train conductor, the train driver fell asleep, that's why the train crashed therefore we need to automate the train and get rid of the drivers — that that doesn't actually work. That you need to take a much more holistic perspective on how all of the pieces fit together. Why did the train conductor fall asleep? Well, there are lots of technical reasons, there are political reasons, there are bureaucratic, financial, so on and so forth. And you have to look at them as a whole, and you have to understand that when you fix one thing, you cannot fully predict what changes will ripple through the system. So you might fix one thing a break another, and you there is no way to guarantee that you won't do that. I also think that has very profound implications for design right now, because design is going through this process of grappling with ethics. That we thought Facebook and Twitter would be the most wonderful thing in the world, and what's happening instead or in addition, perhaps, is that they are enabling manipulation of democratic processes and online hate and bullying and so on and so forth. And there's an idea that as designers, you have a responsibility to design systems that don't cause harm. The problem is that what you're trying to design are very, very complex systems and on some level, while it's important to think in terms of doing good and not doing harm, I think you also need to confront the inevitability that you will do harm on some level that there will be unintended consequences. And what's more interesting — and to me where the cybernetic approach comes in — is you could say that doing harm is is a very compelling version of there being a gap between actual and desired, right? We wanted to build a system that would help people collaborate better and instead we built a system that's starting to help people dislike each other more.Let's assume that's going to happen and let's look for it and let's design for it in a much more continuous way. Jorge: We're recording this in the second week of July. And I bring up that that time stamp because next week, we will be celebrating the 50th anniversary of the lunar landing, which in my mind is kind of the apex of big pre-planned projects. People refer to things that are hard to do as moonshots. Hard to do but achievable, right? And because this is happening next week I've been watching documentaries and reading books and listening to podcasts on the subject — I'm just fascinated by it. And one of the things that's come up over and over again is that the people who are a part of that project, many of them have expressed the belief that they would not have been able to successfully land people on the moon if Apollo 1 hadn't catastrophically burned in the launch pad. That accident was kind of a jolt that the program needed to bring up all these flaws that they had not accounted for. And they completely redesigned the command vehicle as a result of that happening. And unfortunately if three astronauts hadn't died in that accident, they probably wouldn't have had the shock to the system that the system needed in order to — pardon my French, to get their asses in gear, basically. Jeff: Well, that's a pretty provocative statement. Jorge: It's not mine. It's… I was very surprised to hear that, but it's a feeling that I've heard expressed several times by these folks that the accident is what actually got them to the Moon. Jeff: So that's a very interesting… It is a provocative statement, whether it's yours or not, and I'll give you a couple of responses to it. The first one is that one of the things that I think is mostly healthy — there is a little misunderstanding — is the whole idea of moving fast and breaking things is being met with new skepticism. Right? My business is predicated on the idea that it's possible to move fast without breaking things. And I teach people how to do that. I think the way that you do that is that you break things in much smaller units and much earlier in the process when it's safer to do it. I am certainly not recommending that doing things where people die as a learning mechanism is a good thing. However, I will go out on a limb. I had some things happen in my life when I was younger, which, looking back, felt like potentially large failures at the time. And when I look at what happened as a result, my life got tremendously better as a result. One of which was that I had cancer when I was 20 years old. I was at college, I'd been having my first year in college was sort of a mess. I'd gotten my act together; I was doing very well. I was very happy. I got very sick. I left college. I went home. I went through chemotherapy treatments — this was back in the early '80s when chemotherapy was really awful — I spent time in the oncology wing of the University of Pennsylvania hospital, watched a lot of people die from leukemia, face the prospect of my own death. It was the best thing that ever happened to me. It gave me a level of sort of resiliency in my life. And it's funny because you know at some point they said, “Okay, you're done with your treatment, you're in remission. Now, you can go on with your life.” Two weeks later, I was back in school. People were kind of freaked out like, “Who is this guy?” And, “He was gone and now he's back. And what does that mean?” But it was a it was a very positive thing for me and one of the things I've learned is that, you know, we have this idea of well, “Fail early, fail fast.” Is it really good? What we really want to do is learn. And it is true that what we really want to do is learn, but I think we have to deal with the fact that one of the ways we learn is by failing. By getting it wrong. Jorge: I hope my comment about the astronauts didn't come across as callous. I don't think that anyone involved in that program, from what I've heard them say, I don't think any of them wished for that to happen, much as what you are relating is an experience that fortunately, I've not had myself but I've read of folks saying, “You know, I almost died and it was the best thing that happened to me.” Because somehow it forces the… It's like a focusing force, right? And you're talking about learning, which as I understand it, an important part of systems thinking and cybernetics, right? This idea that you're adjusting based on feedback. There is implicit in that the idea that the system is somehow modified as a result of of the adjustment. And I'm wondering, just to bring this home to folks, if there are any mechanisms that you yourself use to either formalize that learning or to capture it or to integrate it into your life in a kind of a structured way? Jeff: I think it's a couple of things. One is I like to joke that I should offer a fixed fee consulting service where all I do is walk around your organization and say the same sentence over and over again, which is, “Make your work smaller.” Give yourself more opportunities to get feedback, to learn, to find out that you're wrong in smaller and safer ways. I think the other part of it — and this is one that I think that organizations that are trying to adopt agile and design thinking and DevOps and Lean Startup and so on and so forth really struggle with — is it requires a certain level of trust. Ranulph Glanville, who was a designer and a cyberneticist made a really fascinating comment when he said that the controller is controlled by the control. In other words, if you think you're in charge, if you think you're in control at whatever level, you're really not. And I think that the more that we can let go of thinking that we are and also thinking that we need to be, the more we can discover that we can actually get where we want to go in a way that feels sloppy but can be very efficient. I'll give you a straightforward example from my experience. The first time I worked with an offshore and group doing development, I was told by the US representative as I started the project, he said you have to give them a really good requirements. I said yeah, I'm good at that. I know I'm a good writer blah blah blah. And of course, I was way too busy, so I gave him really lousy requirements. Kind of poetic. And the initial version of the software they gave me was about 70 degrees off from what I wanted and I got really annoyed for about five minutes and then I realized you know, it's my own fault. You know, if you look at the requirements I gave them, you could imagine how they would get the result. So I sent them this long laundry list of everything that was wrong. And 48 hours, they came back with something that was 20 degrees off from what I wanted. So I sent another laundry list, 24 hours later it was about 3 degrees off. In other words, it was really good. And afterwards, I sat back and I thought, “Okay, well, how long did the process take? How much work did it take? And how good was the output?”” And I realized it was really good and it was really fast and it was really efficient. It felt very sloppy at the time but it actually was very precise. And I realized that this was a very powerful way of working and it was really at the heart of what agile was actually about: that you can get where you want to go if you have uncertainty about that in a way that feels very bumpy, but if you can relax into it, it can be extremely effective. I think the relaxing into it is really hard for all of us. Jorge: I agree … Jeff: So if you wanted to say it in a nutshell what cybernetics is about at its deepest heart. I think it's about working in smaller units and relaxing into it. Jorge: I love that Jeff. That's that's actually a great place to to wrap it up. We didn't get to your book, but I do want to call it out: you wrote a fantastic book for O'Reilly called Designing Delivery, which is about these subjects. And I am going to link it in the in the show notes. Where can folks follow up with you? What's the best place to send them to? Jeff: They can find me on Twitter at Jeff Sussna or they can find me on my company website at sussna-associates.com Jorge: Fantastic, so I'm going to include those in the show notes as well. I am thrilled that we had the opportunity to have this conversation. I think it's a very important subject and I hope it's not the last time that you and I get to catch up on this Jeff: Agreed, this has been great. It's been really enjoyable. Thanks a lot. Appreciate it.

Founder and CEO of Sussna Associates, Jeff Sussna has a unique ability to help clients integrate Agile, DevOps and Design Thinking into continuous learning loops. He teaches organizations how to continuously improve efficiency and quality by building user-centered experimentation into the service delivery life cycle.

Jeff Sussna joins us to talk about the number one thing that trips up organizations and teams when it comes to adopting agile principles and his concept of promise-driven design.

In this episode, Jeff Sussna, thought leader, author and speaker, talks about DevOps, Design Thinking and Services Delivery --- Support this podcast: https://anchor.fm/modernenterprise/support

Lou and Jeff Sussna discuss the challenge of synthesizing development and operations in a digital world. How do you scale design as part of a responsive digital business when everyone is digital? Jeff Sussna is the author of Designing Delivery. As principal at Ingineering.IT, he helps clients apply Agile, DevOps, and Design Thinking to maximize delivery speed and service quality. Join Jeff and Lou at the DesignOps Summit: http://rfld.me/2uvcarb Follow Jeff Sussna on Twitter: https://twitter.com/jeffsussna Follow Rosenfeld Media: https://twitter.com/rosenfeldmedia

This episode is held in English language. My guest is Jeff Sussna, founder and principal of ingineering.IT. He mainly works in the world of operations and is a well known speaker all over the world in the area of DevOps. Surprisingly, he approaches this field with the tools of Service Design, Cybernetics and Promise Theory. Using these ways of thinking, he also wrote a great book, „Designing Delivery“, in which describes the role and challenges of companies in the new world where brands and product development are dialogues. In this conversation, we discuss the following topics: - Services as a fundamental model of coping with a modern, complex world, in which companies need relationships and conversations with their clients. - The role of Design Thinking and Service Design - How Cybernetics can help us understand and decide in situations of complexity and uncertainty - How the model of Promise Theory helps us deal with systems that sometimes fail or are incomplete and how this again helps us to live with the unavoidable circumstance of failure - Thinking broad and embracing ambiguity and dealing with that through balance - Discussions on mindfulness Beyond all, what I really learned and appreciated in this interview was Jeff's ability to break down complex thoughts in easy to understand small steps, taking nothing as granted. Kind of like a good maths teacher. Content:  0:00:00 - Introduction 0:01:19 - When, how and why did Dev and Ops separated? 0:08:06 - Nostalgie of full stack dev and how we are facing bigger tasks because of the INternet’s success 0:14:01 - Jeff is not on the wrong end of the value chain with his topics, the whole company should embrace them 0:22:25 - Let’s have positiv impact on people, outside and inside of the company  0:28:05 - Is „the family“ and „relationship“ a good metaphor for how we should work? 0:32:58 - Announcement of winners of Give Aways from Episode 1 0:34:27 - Jeff’s Book „Designing Delivery“ and the concept of services, Jobs To Be Done, are physical products easier than digital products? 0:47:09 - Design Thinking and Service Design  0:55:27 - Cybernetics 1:01:04 - Portfolio and Feedbackloops as a Cybernetic Systems 1:02:13 - Promise Theory, embracing failure in computer and human systems, incompleteness of systems (also in maths) 1.11:16 - On thinking beyond, going broad and the power of serendipity 1:14:28 - Amiguity and Balance 1:15:11 - On mindfulness, your reaction defines the outcome, there are no shortcuts  

Guest: Jeff Sussna @jeffsussna Full show notes are at https://developeronfire.com/podcast/episode-172-jeff-sussna-mindful-empathy-and-service