- 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
Andy Polaine 00:08
Hi, and welcome to Power of Ten, the podcast about design operating at many levels – zooming out from thoughtful detail through to organizational transformation, and on to changes in society and the world. My name’s Andy Polaine. I’m a service design and innovation consultant, educator and writer.
My guest today is Jeff Sussna, an internationally recognized IT coach and design thinking practitioner. Jeff specializes in helping digital organizations build continuous learning cultures. His career spans 30 years of building systems and leading organizations across the entire product development and operations spectrum. He’s especially known for introducing the global DevOps community to the importance of empathy. And he’s the author of Designing Delivery: Rethinking IT in the Digital Service Economy.
Jeff, welcome to Power of Ten.
Jeff Sussna 00:58
Thank you. Happy to be here.
So the first question in this current climate is how are you doing and what’s going on in your world?
I’m doing as well as can be hoped, I think. It’s funny, because I have reached that point of my life where I’ve started thinking about downsizing where I live. And at the moment, I’m really happy I haven’t, ’cause I have enough space so that my family members and I don’t get completely in each other’s faces and we can do our work in our own rooms. And where we live, there’s enough room to walk without running into people. It’s interesting, there’s a park, a nature preserve, just down the street from us and I was walking on the sidewalk there the other day, and another person came along, and we both made a conscious effort to walk as far apart from each other as we could. It was a really interesting new sort of social protocol, if you will, that we were doing – you know, that we both knew what to do, and we looked at each other like, ‘Yup, we’re gonna do this and we know why’. It was really interesting.
I’ve noticed a lot of intense investigative stares, I feel like, as I walk past. Because I live very close to the countryside and you can go easily – I live in a wine region, so it’s easy for us to go up and kind of walk amongst the vineyards and stuff. And you meet people on the way and everyone’s kind of looking at each other as they go – like tanks, right? The sort of turret swivels as you look at each other from a distance. I’m sure people are saying, ‘Is that person’s nose a bit red? Are they sniffling?’ to kind of check the other person out.
On the other hand, I live in Minnesota, which is not the most outgoing culture on the planet and we are all smiling at each other a lot more now because we’re much more eager for social contact than we have been.
Yeah. It’s really funny. One of the other hosts on This is HCD, Dr John Curran, I just did a kind of recording with him the other day. We were saying – well, he was saying, actually, that ‘social distancing’ is actually the wrong phrase and that ‘physical distancing’ is really what it is. And actually, a lot of people have got to know their neighbors and people in their neighborhood through social distancing, because people have started to kind of pull together as a community. It’s interesting. So has it changed your work at all much?
So far, no. I have not yet done my first fully remote workshop, so I think that will be a real adventure. You know, I work in an industry, I’m a consultant, I work with clients. My clients are typically IT digital service people, so there’s always somebody working from home. So the basic concept, it’s not a thing where we have to be next to each other in order to get our work done. One thing that’s really interesting is that Agile traditionally really emphasizes face-to-face contact, that you can solve problems together better when you’re standing in a room together.
One of the things that’s come up in Agile is things like Jira, and there’s been a certain pushback against that of ‘Well, maybe instead of pushing tickets around in Jira, we should just stand in front of a whiteboard together and put stickies up on the wall.’ So I think all of that is being challenged. And again, I think you’re right that through this social distancing, in a certain sense, we’re all going to learn how to collaborate better, because while we may be on Zoom or whatever the case may be, there will actually be a thirst to work together – talking to and seeing each other as opposed to just pushing tickets around through queues. And when you look at things like Agile and DevOps and Lean and the whole idea of avoiding queues and solving problems together, I think we may actually get better at it as a result of all of this.
Yeah, you still think remotely though – I mean working remotely but sort of working together?
Well, let’s wind back a little bit, because I sort of jumped into how things are doing in the new world of remote everything. So tell me a little bit about what you do and how you’ve got to where you are?
So, how I got to where I am is a long story. It started with being a liberal arts student in college and being surrounded by creative people. My father ran an architecture firm for many years and, when he retired, he became a watercolor painter. So I’ve been very strongly influenced by designers and artists, while not being one myself, particularly. And one thing led to another and I found myself wandering into the world of software development in the 1980s and did that for many years, and then discovered the world of software operations and data center operations. So I kind of have the perfect DevOps portfolio or background, if you will, but there was always this kind of design/art thing in the background that I didn’t quite know what to do.
And then about 10 years ago, a couple of things happen simultaneously that really profoundly impacted my approach to my work. The first was I read Tim Brown’s book Change by Design and was introduced to design thinking, which led me to discover service design. And at the same time, cloud computing was happening in my industry, and the fundamental promise behind cloud computing is that software becomes service. So the idea of service and service design and service operations came together in my brain. And basically what I’ve been doing ever since is trying to figure out how to bring those worlds together, how to get IT people to think in terms of service – service to customers and service to each other – and how to get design and product people to think in terms of operations. What are the things about digital services that the way that you build and the way that you deliver and operate it actually becomes part of the user experience, so they all need to come together? So in terms of my work at this point, it’s really about teaching organizations how to collaborate through mutual service in the broadest sense possible.
Yeah. So in your experience, have you found that designers don’t really think about the operational side of things as part of the experience?
Sadly, I would say that that is true. I can give you a couple of examples. One is I was very excited when I started navigating through the world of service design, and discovering the notion of the customer journey and also the service blueprint. Unfortunately, what I found too often is service design focusing primarily on the customer journey, and not nearly enough on connecting the service blueprint. Another more concrete example: I did a workshop on promise-driven service design, the idea of resilient emergent service design, at a conference of design leaders and managers. So these were all people who’d been designing something for 10 or more years. And I gave them an exercise which was: imagine that you have an e-commerce site and a customer has gone through a long, complicated process of searching and browsing and finding products and adding them to their shopping cart, and they’re about ready to check out and the database crashes. What is the experience like?
And everybody’s eyes got really big, because they had never thought about the idea that the database might crash. And traditionally, that’s IT’s problem, IT is supposed to make sure that the database doesn’t crash. And we do a lot of work and we spend 10s of millions of dollars making sure that the database doesn’t crash, or, if it crashes, there’s a redundant database, so nobody knows, so on and so forth. But guess what? In complex, service driven IT systems, things break. And you cannot completely prevent or predict failure. So this is something that you need to think about from an experience perspective. It’s something that this roomful of experienced designers had never considered. Now, the cool thing is that, once they considered it, they came up with some really great stuff.
Yeah. So it’s just about making sure that’s part of the conversation.
So I have to say, I’m going to defend service design a little bit here, because for my money – I completely recognize the symptoms that you’re describing, and I have seen that myself. I think that one of the things that at least – and we talked about in our book quite a lot – service design is the front stage and backstage. And the thing that I like about service blueprints being not so much a deliverable – which they sort of have become, as a big poster that people put on the wall – but as an artifact through which people have conversations about it is that, whether in front of that thing or asynchronously, you can have that conversation. I remember one very clearly with a bank, actually, and the bank said – we were talking about different customer experiences and improving it and so forth, and the couple of IT folks in the room – and that was the important part, right, you have this multidisciplinary group of people in the room – said, ‘This is all very well and I applaud it. It’s really great. But we’ve underfunded for the last’ – because this is post GFC. ‘We’ve underfunded our back end, our technology, for the last four or five years. There’s no way we can deliver this without the whole thing falling over.’
And so for me that was one of the really crucial bits. If you’re not having that conversation at the time, for my money, you’re not really doing service design properly. But I think it’s partly what’s happened in the US a bit, where UX and service design have become conflated a little bit, where UX is seen as the umbrella and service design as a thing underneath, whereas in Europe – and particularly Northern Europe and Scandinavia – I think it’s still seen the other way around. But I absolutely agree. I kind of think that’s a problem. Now, there’s a couple of things you’ve just touched on that really want to come back to. Before I do, you talk in the book about IT as a conversational medium, and I thought this was a kind of really interesting lens. Can you talk about that a little bit?
Yeah, it’s funny because while I work in what might be called IT, or information technology, I’ve never really liked that term IT. And maybe it’s because traditionally it was seen as or sometimes manifested as lacking in creativity or imagination. But I’ve started to think that there’s something deeper at play, which is that back in the old days, we called it MIS, management information system. The idea was that managers needed a bunch of information in order to make decisions and the job of MIS was to provide that information. But I think that IT has exploded way beyond that in the internet and the online service world is – and I mean, we’re seeing it this week and this month – we are all engaging with each other through digital technologies. It’s gone from being how companies got information to how companies actually function. So I think it’s become literally a medium that we converse with each other and we converse with our customers through that medium. I’ve actually played with the idea of using IT to refer to interaction technology, because it’s the technology that we use to interact with each other. But the point is, its job is no longer to produce a thing. Its job is to be more like air or water that we kind of fly around or swim around in as we – first as we did business together, but this week even, you know, have friends and families with each other. There are people getting married online now because they can’t go to the church to get married.
So in that sense, IT – or technology, loosely – becomes this medium through which we not only have conversations, but actually have social interactions as well.
That brings us kind of neatly onto the example of this idea that you were just talking about, which is that service outages are service experiences too and quite often that back end or that backstage that’s mediating – well, when I’ve talked about backstage, I talk about supporting the service experience, right, and the employees. In your book, you also talk about this idea of service outages as service experiences. The example you gave is a weary traveler – this must have happened to a lot of people recently – goes into a hotel, arrives at the hotel and says, ‘Hi, I’d like to check in I’ve got a room,’ and the person on reception says, ‘I’m sorry, I can’t check you in. The check-in system’s down.’ And that that’s obviously part of the service experience and you elaborate and talk about how many people don’t just say, ‘Oh, no, my flights been canceled.’ It’s like, ‘Guess what?’ – they kind of expect it to fail. Which kind of leads to this idea of services as a chain of promises, and I think this is a really nice idea.
I also think, incidentally, that I’ve often said error messages and failures are a lost touch points, right, because they’re often not really designed, they kind of become the default thing. It’s like a bit of the wiring starts kind of poking through the circuit board. I see a lot in airports, where you see a big display monitor that should have some flight information or an advert on it, and it’s just got one of those Windows NT alert error boxes just kind of floating around. I think, ‘Someone could have designed that.’ So tell us about this idea of services as a chain of promises. Because it’s really – there’s also a more recent Medium article called Visible Promises: How to Move Fast without Breaking Things. There’s some really nice points in it, so I’m going to let you say it in your own words.
So one of the things that has come out of the IT world in the last several years through the mechanism of DevOps is thinking about how digital systems become more and more complex, in the sense that there are a lot of moving parts that interact with each other in very fluid ways. So you can’t pull them apart and say, ‘Well, we’re going to worry about this piece over here. And we’re going to worry about that piece over there. And as long as the two pieces work, the whole system will work.’ You know, if you’re dealing with a car, as long as the engine and the transmission and the drive train all work properly, there’s an assumption that the car will work properly. But when you see the kinds of complex systems that you find in the natural and the social world, those rules don’t apply in the same way. And one of the things that service and in particular digital service bring to bear is this shift from complicated predictable systems to complex, unpredictable ones.
And one of the things about complex systems is that they fail. They fail in ways that you cannot avoid or predict. They have a certain sloppy resilience which allows them to survive that failure, as long as you take a different approach to them. There was some very groundbreaking work by a researcher named Mark Burgess who developed something called promise theory, which is a way of modeling complex systems from the perspective of components voluntarily working together in order to create systems that work, which is a real shift from the sort of top-down model of you have the boss and the boss’s boss, and everybody tells everybody what to do, and it gets down to the bottom level and somebody says, ‘Okay, my job is to move this widget from this part of the factory floor to that part of the factory floor.’ It kind of flips it upside down. And the notion is that we all make promises to each other, which are commitments to provide some kind of benefit, to help each other get something done.
And there are a couple of important aspects to promises. One is it’s a very customer centered, outcome centered approach to designing and operating systems. And the other, though, is the reason we use the word ‘promise’ is that we don’t always keep our promises. Sometimes we break them. And I like to use the example of the teenager promising to clean his bedroom. Right? What’s the likelihood that he’s actually going to get it done? It’s about 50%. So this is actually really good because it forces us to account for the possibility of failure, which ironically gives us a better chance of success. And on the one hand, you could say, if we go back to our database example, ‘Well, if I assume that the database might crash, I’ll spend a bunch of extra money in engineering in order to build a redundant clustered database system so that if one database crashes, I don’t care, because I have another one that’s still functioning.’ On the other hand, it leads us to do things like say, ‘Well, what happens to the user experience if the database crashes? How can I continue to provide a quality experience? How can I think from the perspective of what is it the customer is trying to accomplish? What they’re trying to accomplish is to get off the airplane and get into a hotel room and be able to relax. How can I make sure that I can help them have that experience, even if the check-in system is down, or I’m overbooked, or so on and so forth?’
And the other thing that I want to emphasize about promises is the core of my work with my clients now is something called promise-driven delivery, which is thinking about all of the parts of the organization as making promises to each other and really breaking down this idea that there are customers out there and then their employees in here. One of the challenges we face when we talk about things like making the whole organization customer centered – well, how do you do that when you have 500 or 1000 or 20,000 employees? You can’t just put everybody in front of the customer, you can’t just kind of hard wire, ‘Well, this is what the customer wants, so everybody’s supposed to work on that.’ It needs to be more flexible and more emergent than that. And so if we look at it from the perspective of teams and departments and management levels all treating each other as customers and providing service to each other, and making promises to each other, we actually create this emergent, constantly evolving, adaptive and resilient approach to being customer centered.
That’s nice. There’s a thing that we talk about when trying to validate services and you’re doing prototypes, which is this idea of there’s a kind of – I mean, I think they’re hierarchal; others will say that it doesn’t matter which order they’re in – set of questions which is: do people understand what this thing is, what this service is? Do they understand the value proposition? And then do they understand the value to their lives? Because obviously, there’s a situation where they might go, ‘Yeah, I understand what it is, but it’s not for me.’ And then there’s the next set of questions: do they understand how to use it? Do they understand the affordances, and so on and so forth to the knobs and levers of how the thing works. And quite often, design teams start at that one, which is, ‘Do people understand how to use it?’, without validating the first bit. I always think – the poor Google Wave folks, but I always think of something like Google Wave where, yeah, here’s a thing and I kind of get it but I don’t really know why exists. And then obviously, it doesn’t exist any more. There’s a similar thing I found when you’re talking about making promises visible, and asking a set of questions which are actually very simple. I wondered if you might run through those promises, or those questions about making your promises visible?
Yeah. So when I talk to people about promises and promise-driven delivery, there’s a level at which they get it almost immediately, because the word ‘promise’ means exactly what you think it does. It means the same thing that it means in ordinary usage. We make promises to each other all the time, right? I promise I’ll clean my room, I promise I’ll do the dishes, I promise I’ll take out the trash, right? And sometimes we get the dishes done, and sometimes we don’t. And the better a job we do at keeping those promises, the better harmony we have in our household. So there’s nothing mysterious about it.
And what they catch on to is the first question is quite simply what promises are we making to our customers and each other? What is the purpose and benefit of what we’re doing? And companies make implicit promises all the time. There’s a reason that people use Slack or Zoom or Jira or whatever the case may be. There’s something they’re trying to accomplish. It fits in very nicely with the whole idea of jobs to be done. You know, what are you trying to get done that you need help with? And as a company, if I start by thinking about what I’m helping you to accomplish – the example I use there is why is it that people get frustrated when hotel WiFi is really bad? Because what we’re trying to accomplish when we stay at a hotel is not just have a place to sleep. We are on a trip somewhere, whether that be a trip to take our kids to Disneyland or a trip to speak at a conference or a trip to close some sales deals. There’s something we’re trying to accomplish and the hotel needs to help us. So we need to get a decent night’s sleep, we need to be able to get some decent food, we probably need to either do some work or make some reservations for the ride at Disneyland or whatever the case may be. So if we think about it from a truly customer centered lens, what is the fundamental promise we’re making? Then we start to understand why things like hotel WiFi are important.
And then the next question is, well, how well are we keeping those promises? So, you know, if our fundamental promise is to help the customer have a satisfactory trip, and they’re a business customer and they need to access their work email and the WiFi is terrible or expensive or whatever the case may be, then we’re not doing a very good job of keeping that promise. Right? We may have very comfortable beds, and we may have a very nice buffet from nine o’clock in the morning, but we’re at least partly failing at the basic value proposition. And that leads us into a continuous process of asking, well, how can we do a better job of keeping our promises?
And it also leads us to a more interesting question, particularly from a design perspective, of are we actually making the right ones? It may be that the promise we’re making is just we’ll give you a comfortable bed and a decent breakfast in the morning. And when we look at it from the perspective of why our customer’s here, we recognize that the real promise is to help them have a successful trip. And by the way, I need to give credit to Airbnb, because a number of years ago an Airbnb designer gave a talk at a service design conference where she said that Airbnb had had an epiphany when they realized that the product was the trip. In other words, people didn’t reserve rooms in a house because they wanted a room in a house. They reserved a room in a house because – I mean, the origin of Airbnb was people were trying to get to South by Southwest and they couldn’t find places to stay. But the point of the exercise was not to have a place to stay. The point of the exercise was to be able to go to South by Southwest. And so it’s really a very simple process of building in this continuous process of asking ourselves, ‘What is the value that we’re trying to provide? Is that the right value? How well are we succeeding?’ And again, that comes from the DevOps world of saying, okay, we need to be continuously learning from failure, because failure is always happening in a complex environment.
And it’s a feedback mechanism.
And it is a feedback mechanism, yes. And the more continuous we make that feedback mechanism, and the more we focus on adaptation and improvement – as opposed to trying to get it right all the way the first time – the more value we can provide over time.
But you don’t just stop there, because you also – one of the things I thought was nice about this set of questions was you go on to these last two, which are: what promises from others do we depend on? And most importantly, what promises do our customers make? So you extend beyond – it’s not just a one sided thing.
Right. And so the first question is really about sort of breaking down boundaries between levels and thinking about it in terms of mutual service – that in order for the hotel to provide good WiFi they rely on – not WiFi, but good internet connectivity, they rely on service from their internet provider. And so when they’re thinking about, ‘Okay, we’ve installed all of these WiFi repeaters all the way through, we have one in every room in our hotel now,’ they also need to think about things like how reliable is our internet provider? And that goes all the way into the company.
One of the things we do now is we have this idea of breaking systems down into these little two-pizza-sized product teams, where we have a nice cross-functional team. And you’ve got a designer and you’ve got a developer and you’ve got a tester and you’ve got an ops person, and they all have pizza together and they go out to lunch together. Maybe they do it over Zoom now, they have Zoom lunches together, but anyway. But that misses the question of, well, that’s great; how do we put all of these pieces back together into a coherent, holistic service without reintroducing all of the friction and brittleness we’re trying to get away from in the first place? And the answer is by thinking about the promises we make to each other, the promises that we depend on from others, whether it be I depend on service from the database, or I depend on an API from this other team or I depend on the design ops groups to develop a design system that I can use so that I can build consistent interfaces quickly.
So the question of promises we provide to others and promises we depend on from others is basically saying that we are all, at every level, now in the service business. So if you are a design system team, your job is not just to build a design system; your job is to serve the teams that depend on that system. And that may seem like a simple but I think it’s a subtle and important difference. And then the question of the promises that our customers make is one that I find is really helpful for really answering this question of what are the right promises to make? So it’s about asking, ‘Why are you using my service?’ So if I’m a parent, I’ve promised to show my kids a good time on vacation, and that creates a whole set of stresses and expectations that I need the hotel’s help with. If I’m a business person or a salesperson, and I’ve promised to close some sales in order to make my quarterly numbers, that creates a whole set of stresses and expectations that I need help with. And if I’m the service provider, and I’m trying to figure out, ‘Well, why am I really in business? What is my purpose?’ Well, my purpose is to help Andy. Well, what is it that Andy needs to accomplish? What are the things that drive him? So this is really all about trying to think in terms of networks of needs and networks of expectations and networks of value that we can offer to each other in order to help each other get things done for our own and others benefit.
Yeah, it’s really interesting. I think it’s such a great lens because it really shows that kind of interconnectedness. Going back to the Airbnb example, obviously there’s promises in all sorts of directions because they have two sets of customers, right? Obviously their hosts and their guests. So the hosts are making promises to the guests as well, when the guests are also making a promise that ‘I’m not going to trash your place and have a party’, and if I do then the promise now from Airbnb is that we’ll recompense the host, and we’ll get rid of those guests off the platform and so forth. It’s interesting because obviously, probably the most ubiquitous promise that there is in the world is money, because money – I don’t know if it says it on US dollar bills, but on the UK pound notes, it used to say ‘I promise to pay the bearer of this 10 pounds’ or whatever. So money is obviously IOUs, promises, which are just constantly circulation. So they just kind of never get cashed in. You can no longer go into the Bank of England and ask for your gold, but you used to be able to. That’s what it was, right? Ultimately it kind of came back to that. And as you saw with the Global Financial Crisis, when those promises, that trust starts to break down – ‘I don’t think you’re going to keep your promise’ – then everything seizes up.
And it’s interesting right now, we’re just talking right at the beginning – or, as I say, the middle of the beginning – of the coronavirus outbreak and there’s a lot of stuff going on where you’re seeing what promises are being made, what promises are able to be kept, and also that responsibility to each other. We talked early on about going out for a walk where, as you walk past someone, everyone’s practicing social distancing. So you’re kind of keeping that – there’s this new social etiquette of keeping your distance, right?
Right, I promise not to walk within six feet of you.
I promise not to infect you. I promise not to go and clear out the supermarket shelves, the toilet paper, you know, all that kind of stuff. And you’re seeing how there’s different levels of people honoring those promises or not. It’s kind of fascinating. So that’s why I think it’s a kind of a brilliant lens. And how have you found this has landed with different parts of the organization – with the management and business C-suite folks versus IT leadership versus people really on the frontline?
Well, I think the interesting thing is one of the things that we’re going through right now, when you look at things like Agile and DevOps, is deeply within them is the notion of higher trust organizations. That in the 21st century digital service economy blah, blah, blah, blah, blah. You know, workers and teams need more empowerment and more autonomy. And the notion of a promise is it’s something voluntary. It’s the converse of a requirement or an imposition, right? ‘We make a promise to you’ is different from ‘you told us what to do’. And there’s a certain tension happening as organizations are learning how to do this. In some cases, you will see leadership really liking promises from the perspective of, ‘As the CEO or the CTO or the head of sales or whatever, I make promises to customers, and I need my employees to keep those promises.’ Right? It doesn’t quite work like that. So there’s a certain bumpiness which is completely natural as organizations are trying to adopt things like Agile in a bigger sense, and grappling with the sort of underlying post-Taylorist, if you will, ways of thinking that are required. One of the other unintended consequences that I hope will be an outcome of this fully remote working is it’s a lot harder to micromanage people’s time.
You have to trust them.
You have to trust them. And I think that’s a really good thing. In my fantasy world, a year from now this whole idea of top-down 20th century management will be a thing of the past because we were forced to assume that people are going to get up in the morning and get on Zoom or Teams or Slack or whatever it is, and do their work together and that good work will happen. My sense is that we’re going to learn a lot about hopefully the good side of people in the next year, and that we’re going to learn about it in the social realm but also in the workplace realm as the nature of the workplace fundamentally changes.
Well, the great thing is we’ll have a huge case study and a load of evidence to show and say, ‘Listen, you’re asking me to do this thing. During this crisis, we did this without you micromanaging me, and here’s the evidence to prove it.’ This seems like a good place to wrap up. As you know, the podcast is named after the Eames film Powers of Ten about the relative size of things in the universe. And one of the things I ask every guest is what one small thing – either that is well designed and overlooked, or really needs to be redesigned – has an outsized influence on the world?
So what came to mind for me is opportunities to do nothing. And let me explain what I mean by that. I went to a wonderful art installation at the Minneapolis Institute of Art by Robert Wilson. Oh, how do you describe what he does? He does very post-modern visual art installation like theater pieces. And he did this wonderful, very visually rich art installation. But the first room, you were brought into the room, it was almost entirely pitch black, and you were asked to sit quietly in that room for five minutes before you went into the rest of the show. And once you did that, everything else was so much richer and so much more compelling to look at.
One of the things that we’re all learning right now is to deal with a certain amount of boredom and stir craziness. Right? You can’t go to the movies. You can’t go out to dinner. You can’t go to a bar or a party with your friends. So we’re all being sort of thrown back on ourselves and having to spend a certain amount of time sort of just being with ourselves. And I think injecting that into our lives and our work – you know, having opportunities at the beginning of a meeting for everybody to just sit quietly for two minutes without saying anything, I think could have a tremendous amount of power in helping us all be together and accomplish things but also just live our lives together.
That’s very, very nice indeed. I shall try and find some links to that. Was that the China’s Last Dynasty installation from Robert Wilson?
Yes, it was.
I’ll put them in the show notes. So where can people find you online?
They can find me at sussna-associates.com. They can find me on Twitter at @jeffsussna. And that’s probably the best place to look for me.
They’ll find you on LinkedIn and Medium and other places too. I’ll make sure that’s in the notes. Jeff, thank you so much for being my guest on Power of Ten, and I hope you stay sane and safe during this time.
Thanks. Same to you and all your listeners, and thanks for having me. It’s been a pleasure.
Thanks for listening to Power of Ten. If you want to learn more about other shows on the This is HCD network, go to thisishcd.com, where you’ll find ProdPod with Adrienne Tan; Decoding Culture with Dr John Curran; EthnoPod with Jay Hasbrouck; Bringing Design Closer and Getting Started in Design with Gerry Scullion; and Talking Shop with Gerry, myself and some of the other hosts. You’ll also find the transcripts and links to this show. And you can sign up to our newsletter or join our Slack channel and connect with other designers around the world.
My name is Andy Polaine. You can find me polaine.com or @apolaine on Twitter. Thanks for listening and see you next time.