The SpoolCast with Jared Spool

The SpoolCast has been bringing UX learning to designers’ ears around the world since 2005. Dozens and dozens of hours of Jared Spool interviewing some of the greatest minds in design are available for you to explore.

Episode #213 Kevin Hoffman - Leading Super Productive Meetings

July 12, 2013  ·  33 minutes

Listen Now

Download the MP3

It’s common in the current technological landscape for teams to have remote members. Firing up a Skype session to join the whole team in a meeting is easy. However, having a remote element to your team is not without complications. There can be hurdles in terms of collaboration, not to mention the possibility of technical issues. In the end, co-located or remote won’t matter if the meeting itself is poorly designed.

Show Notes

Kevin Hoffman believes that the culture of an organization, not whether the team is remote or not, is the biggest factor in having productive meetings. Having a good set of principles really sets the tone for the collaborative process. Being able to quickly see options and constraints, and be able to collect feedback is instrumental to moving things forward.

Check out Kevin’s daylong workshop from the User Interface 18 conference, now in our All You Can Learn Library.

Full Transcript

Jared Spool: Hello there. You've tuned in to another episode of the Spoolcast. Today, I have with me one of my favoritest people in the world, Mr. Kevin Hoffman. Kevin, how are you doing?
Kevin Hoffman: I'm fantastic. Good morning.
Jared: Kevin, I bet you didn't know this, but you're teaching a full-day workshop at UI18 this year. Did you know that?
Kevin: I did not know that. I should probably put that on my calendar.
Jared: [laughs] Yes. It's going to be October 21st. You're doing a workshop on leading super-productive meetings. You know why you're doing that?
Kevin: I hope because I like doing it.
Jared: That's one reason. The other reason is there isn't anybody out there who knows more about producing super-productive meetings than you.
Kevin: Thanks. I appreciate it.
Jared: So yes, everybody, we've got Mr. Kevin Hoffman with us today, and I'm very excited that he is here and he is going to be talking about this. One of the things that has been on my mind lately is this reaction people have to really bad meetings, and in particular, bad meetings that are under the guise of coming up with ideas to solve a problem or to work on a design or something of those sorts. We hear all these things about design by committee and the evils of that, and yet, what you've been doing with meetings is like the complete opposite. You've been getting a bunch of really smart people in the room, and really innovative ideas have come out. I'm really curious about what the magic underlying that is because it's so easy for these meetings to turn miserable, don't you think?
Kevin: Yeah, I do. At the heart of what I think you're referring to as magic...I like the idea of it being magic because that implies that if we were sufficiently smart, there would actually be a technology behind it, but if we don't know that technology, that it feels like magic. I think that there's a fundamental distinction between the idea of a committee and the concept of co-design. Co-design is a word that has popped up in conversations about meetings that I've had with a lot of different folks, people in big organizations and people who are independent and people who run small companies. Co-design I like as a term because there are some assumptions with co-design that aren't assumptions when you say, "Let's put a committee together to make a decision or to move a process forward." That assumption is that, like you said, it's a group of smart people, but specifically, you're trying to take advantage of the specific knowledge that each of those people have in a combined way that wouldn't exist if they were working independently. There's been a lot of discussion, and, in fact, if you look at the stuff that Yahoo! Decided recently...I guess they decided in January or February when that memo was leaked about all the telecommuting stuff, saying that the telecommuting workers, and I think it's only like a couple hundred people, were going to have to move back the Yahoo! Campus. There was a lot of negative fallout from that, and then Marissa Mayer responded to that. But at the end of the day, I don't think it really matters whether or not you co-locate. It matters how aware you are of the relationship between co-location and the success of your culture. I think Marissa Mayer took a look at the numbers and decided that there was a relationship between good ideas and good projects and co-location and wanted to push that in her company, and that makes sense. I also think it makes sense to do remote collaboration if it works really well in your culture and gets good results, but those good results come from people maximizing their potential and their experience and their contributions in a collaborative way that is designed. The design piece is the part that's lacking. Co-design meaning there's some design thinking, or, not to use a cliche term but, there's some thought put into the design of how we collaborate. And like any good design process, that it's flexible enough so that you guys can respond to what's working and what isn't. Some people confuse that with agile and being agile. That's a whole other thing that we can talk about, if you like. The thing that feels like magic is there are design frameworks or principles that you can use to get better potential out of collaborative processes rather than just falling back on the ones that are the ones that you're born with, which is hopefully the ability to keep a conversation going, and stuff like Robert's Rules of Order, which are silly.
Jared: This is interesting to me, this idea that we could apply design to the way we interact with each other in a meeting. If I think about designing, let's say, a mobile application, part of the designing process is coming up with approaches and knowing what all my options are, having like a design pattern library that helps me understand, well, what are all the different ways I could ask for input from this thing. Part of it is also having a feedback mechanism, a way to try an idea and try it out myself or put it in front of other people and say, is this working? Part of the feedback mechanism and the definition of, is this working means that I have to have a clear definition of what my design is trying to achieve. Does that sort of thing of having a pattern library that lays out your options and having a way to collect feedback about whether it's working and having a definition of what working means. That applies to meetings, too, right?
Kevin: Yeah, absolutely. Let's review for a second, we're talking about, remind me what the first concept was.
Jared: Oh, this idea that you have like a collection, I call them a pattern library. But really, a collection of design techniques that other people have come up with or that you've come up with that tell you, these are all the things that I could do. I could use a gesture, I could use a check box, I could use a stylus, I could use...
Kevin: Yeah. I think those three things, library, outcome and feedback, those are the three that I heard. Library, I think, is the one that has the most potential of the three. The library you want is the library that clarifies the outcome and provides channels for the feedback. I think that, really, the outcome piece, when people talk about bad meeting culture in large organizations, it's usually related to the outcome piece. On the one hand, it's related to feeling pre-determined, so people have a sense of powerlessness. Like, we're having a meeting but we know that, really, this is what's going to happen, because this is what's happened before in our organization. Or I heard a rumor that somebody said this meeting is just to make it feel like we have input or what have you. In that circumstance, the meeting is happening at the wrong time for the wrong reason. Then, the feedback piece, I think, is really interesting because the feedback piece, the design constraint, what are the design constraints there? Especially for co-located teams, but also for virtual teams, is human personality and character and how people actually interact with each other. You design a system like Twitter and that system has a lot of constraints on the way in which we collaborate. If we were going to collaborate via Twitter on a conversation, we have character constraints. We have timing constraints. We have channel constraints, so we can be corresponding via direct messages or via at messages or even just publicly, just vomiting our thoughts to everybody and everybody vomiting back. So there are some constraints in that system. I think, in meetings, actually we're a lot more naked in terms of who we are as people, how we express ourselves, our tendencies to fall back on whatever patterns have worked for us as communicators in the past. As a result, the lack of constraint usually leads to, I think, people just feeling hurt or ineffective or frustrated or like they're wasting time. I also think that because meetings tend to be one way, at least by default. That's the default kind of design framework for meetings in that we're going to get a group together and we're all going to learn a thing from a smaller group of people. That's not a very effective channel, listening. Listening has a bandwidth limitation. You can only absorb so much of what you hear. But thinking about more creative ways to take advantage of more channels and meetings is another way to start solving that feedback mechanism. You can tell in real time, oh yeah, there's a feedback mechanism for this meeting. It's not going well, and what do I do about that in that scenario?
Jared: Yeah, it's fascinating to me that we can do this. Like, let's say we're doing some sort of meeting where the goal is to figure out what changes do we want to make in our next release. Maybe that's where we're at. We're at this point where we've just shipped the old release and we have a good sense of what's working and what's not. We now want to get people together and start figuring out what that road map will be for the next release. What's going to be in, what's going to be out, what's working, what's not. That's my goal. I want to get a bunch of people from the team together to talk about this. Now, is there work I do up front before I even select the people to make sure that my outcome is the outcome I want to have? Or do I just get the people together and we figure it out together, more impromptu, more sort of fast iterations, as it were? Do we apply what we know from design in terms of planning and preparation and doing a lot of work up front? Because I think a lot of meetings, the only preparation that's done is finding that time slot that everyone can get together.
Kevin: Yeah. My answer to your question is yes. I think that in order to design a thing, you need to prepare for understanding the purchase of that thing, and what the desired outcome of that thing is. The desired outcome of a particular app is X, so we want to design it to facilitate these primary behaviors really easily. The question is, how much effort do you put into the design of a particular meeting to get at what kind of features are we going to tweak or build in our next release for a software product or an application or what have you. I think it's a question of scale. First, it's a question of what is the scale of the organization? Is it a group of three guys at a start-up or three girls at a start-up that are building an app collaboratively? They're very high touch, but they're distributed. What do they want to get out of that collaboration time? Or is it a question of 10 different departments, all with different insights into the problem, all with different data sets. Some with really strong passion about what they think the product should be in a vision, some with really good arguments based on research and based on their understanding of cognitive science. Some with just really strong opinions about the color blue because somebody painted their bathroom that color. You get all of those people together, that's a question of scale where you need frameworks that accommodate scale well and that prevent meandering that is not productive. That's not to say that meandering can't be productive. I think meandering are recognizing that there needs to be room for a system to breathe. That's one of the things I love about Twitter. If you look at the way Twitter was designed, they didn't try to really explain what you do with it. Because they wanted to leave some of that to interpretation and see what kind of emergent behaviors came out of that. You need to design a meeting to allow the right kinds of ideas and innovations, if that's what you're looking for, to emerge. But at the same time, getting something to emerge from five people or 50 people or even 100 or 150 people, those are different design problems and the variable is scale. What frameworks scale well and what frameworks don't. What kind of frameworks can you scale out of the meeting? Which is another really interesting question. How can you move the more you're dealing with an issue of scale. But I would say at about six or seven people you start to run into problems of scale. The more you're dealing with that, how can you design the meeting experience to facilitate people coming in in the best position to hit the potential that they have to provide?
Jared: I've been thinking a lot lately about the things a designer needs to know in order to be a good designer, the skills that designers need to have. How do designers get those skills. Let's say someone who's going to be designing a mobile app, let's go back to that, probably needs some really good interaction design skills, they need to know how the app works. They need to know how the visual design works. They're going to work with developers, so they need to know how to communicate with those developers. They're going to work with product managers and other stakeholders to figure out how to communicate with that. What's interesting is, how do we pick those up? There's a lot written about how to do design. There are schools that teach design. But there aren't schools that teach us, for example, how to attend meetings. There aren't very many books on how to attend meetings. Really, until you really started talking about this a few years back, my eyes were not open to the fact that these are essential skills and we never talk about them. It's up there with interviewing skills, where we ask people to interview new candidates. But we don't talk about, well, what is an interview supposed to have in it? You just sort of think about all the interviews you've ever been in, which ones you thought were good interviews and which ones you thought weren't, and you just mimic those, hoping that you'll find the magic sauce. I think that's how a lot of people enter the world of meetings. They think about the meetings they were in and they're thinking, well, I'll just do what I did in that other meeting and hopefully, whatever it was I just did will work.
Kevin: Yeah. I think, in a culture that succeeds, and you can look at some of what Jason Fried has written about, because I think he his culture, the 37 Signals culture is a good example of a successful culture.
Jared: Yeah, like in his book, "Rework," right?
Kevin: In "Rework" or in the book I'm looking forward to checking out that's coming out.
Jared: The "Remote," right?
Kevin: About "Remote." I think, in a successful culture, the, do what I've done before that made it work well. If everybody wants to do the same thing and everybody has the same definition of work well, then your culture feels very productive. It feels like you can do great things, and it feels good. But when those things start to vary a little more, when people's definitions of work well start to vary. One of the more interesting kind of ways of looking at design and what's working and what isn't working is, I think if you look at the evolution of Google's design execution across their application in different channels on mobile. You can definitely see they've kind of picked up their game a lot in recognizing that designing a good experience is a lot more than just engineering excellence and getting at really fast load times. But I think that was an interesting kind of emergent evolution for them. I don't think it was something that they consciously decided to do, it just started happening in different product groups. Then eventually, people were like, oh, yeah, that actually does work well. We have all the engineering speed, things are loading great and things work really well. But it's also being used more because I like using Gmail better on the iPhone, or I like the way Google maps works better than Apple maps or what have you. I'm really interested in the meeting sense, how can you start to detect those emergent properties for your culture and capitalize on them, but at the same time, use frameworks that allow those things to emerge? Because a lot of our tendencies in meetings is actually to prevent emergents. I think there are two things that are classic ways of starting meetings. One of the classic ways of starting meetings is to say, "We're not going to leave until we decide." I did a workshop in Portugal last month and was talking to some folks at larger software companies. One of them was like, I hate that about our culture is that, how do we solve the problem of like, we have a meeting that ends at 2 PM, but they always end at 4 PM, because we don't leave until we make a decision. I think the problem there is, you're not actually allowing exploration. You're focusing people to eliminate before they've considered the problem fully. That's a really simple design principle that you can say, doesn't take a lot of prep, just ask the question. Does the conversation that we want to have in this meeting allow for exploration and illumination?" On the flip side, there's the, I don't like to say hippie but the really more spiritual culture of, "We're just going to see what happens. We're just going to explore and talk and go on tangents and figure out where we're going to go." People don't really respond well to those kinds of meetings either because they feel like they didn't get anything done. They just feel like, "Well, we put a lot of interesting ideas out there and it was fun to do that, but what are we actually going to do?" They go back to their desk feeling like, "Now I actually have to work and sort through this stuff." As a design framework, just saying, "Is the content of our meeting, does it have space to grow and does it have space to contract?" is a way gut check the design of a a conversation. It's really good way to assess whether or not the conversation is going well. Have we expanded enough? Have we contracted yet? Are we contracting at the beginning when we should be allowing more options? Keeping that advice is a really good way to solve problems like wallflowers who are really reluctant to contribute either because they don't want to be berated by their boss in a meeting or they don't feel like their contribution is going to be taken seriously or they're just shy. On the flip side, it's a great way to start to handle people who are really alpha personalities in meetings who, once they start talking, the meeting kind of steers toward their agenda. Having somebody whose job it is to watch that conversation for the natural ebb and flow helps manage those things, which are natural tendencies and can be used to get to better ideas.
Jared: When we get really good at doing meetings, does that ripple out through the organization? Do we see change elsewhere?
Kevin: I would love to study that question. I think the question of skills transfer generally is an interesting one. How do you orient people to a culture? I've seen really cool examples of the answer to that particular question which is a more general question than the one that you asked, which is, "How do we orient people to a business culture?" I love -- love!- - the Valve Software employee manual. In a way, I think it says a lot about meetings without actually ever talking about what meetings are like at Valve. There's a lot about personal responsibility and a lack of hierarchy, and that's their corporate culture and that's not everybody's corporate culture. You read it and some of it sounds like an imaginary fantasy workplace. But it's obviously very successful for them. They're pretty successful and a stable, growing company. I think they handle the question of orienting people to culture well. I visited a design agency in Portland earlier this year. They do really interesting things with handmade artifacts that are part of their orientation process. One of the jobs of their support staff is they sit there with an exacto knife and cut out these intricate welcome things. They orient people to very specific aspects of their culture in a deliberate sequence to get people comfortable with this is what I bring to the table, but this also what's expected of me. I really like those examples. I would like to study the question of "how can you do this in collaborative culture?" The part of your culture that's about where you get together to work and get things done, how can you bring people that are new to that culture into your way of doing things? But also be open to the fact that their contributions may evolve that way a little bit and maximize that evolution to get to better stuff, whatever that stuff may be.
Jared: I think that part of it I'm wondering is, once you start focusing on meetings, it brings an awareness to just communication in general.
Kevin: I think so. I really like the fact that you can find examples where a particular company has gotten really frustrated with meetings and, as a result, examined the communication question as a way of solving their meeting challenge, whether it's experimenting with more lean processes or moving conversations about deliverables or decisions into visual spaces or looking at software as a solution and looking at internal, asynchronous communication. Just saying, "We need everybody to know X, and we don't need them all to know at the same time, but we need to know that they know it. Our default design tool for accomplishment that goal is a meeting but, if we design software, email already does, but internally, this is what you need to know and we need to know that you've read it. We need to know that you've absorbed." There are companies that have done that and eliminated certain genres of meetings from their culture to positive effect and filled that up with either better meetings or fewer meetings if that's what their culture dictates. The more I talk about meetings and I talk to folks that I respect who have been talking about facilitation and collaboration a lot longer than I have, folks like Dave Gray or David Sibbet, some of the younger folks like Sunni Brown and James Macanufo who're doing interesting writing in visual facilitation and just facilitation generally, the more I find that being sensitive to the context of culture is really the first thing you have to do and exploring and investigating that culture. Then, going back with that earned knowledge and saying, "What role do meetings play in our culture? How are we going to maximize that? Where are the pain points and why are they there?" I spoke at a fairly large, well known software company in Boston recently and presented a lot of frameworks. I was like, "These are all things that I've done. This is how I've applied them. This is how I've worked with larger organizations, with smaller organizations." From giving the talk, I didn't really have a good sense of what they were connecting with and what they weren't. As soon as I was done, the kind of questions I was getting, it was like immediately they were ready to start experimenting with meetings in their organization and asked themselves, "What can we do differently?" Getting that kind of conversation going, I felt like it was the best thing I could do for them is just getting them open to the conversation and recognizing the fact. Right after I gave the presentation, one of the senior leadership came up and said, "I have to apologize. The meeting that we're going to be having next is going to be a bad one. But I'm really glad we know what we can start to do about that now." So that was really nice. It was a nice experience.
Jared: It's interesting. I'd be curious to check back with those guys and see if their meetings have slowly morphed into more productive, useful things. Part of it is just having that awareness that you have options.
Kevin: I think part of it is having the awareness. The other big piece is that understanding the relationship between symptoms and cure. The metaphor that I would use for that is in my own medical life, the doctors that I see and for anybody who's ever been sick, either chronically ill or you've just had a bout of illness. There are certain scenarios were you have something and there are symptoms that present itself. You go in and the doctor says, "I know exactly what that is!" and they give you a very specific pill and it goes away. But, in reality, my stance of medicine is that those scenarios are relatively rare and they kind of move through the system pretty quickly. What is much more common and really what medicine is about and research is about is the fact that you have bizarre combinations of symptoms that aren't immediately apparent how to solve. What you have to do is you have to experiment and you have to try things. The way that medicine works, and I'm not a doctor, so this is my patient experience of how medicine works, is that you start small. You try the least heavy duty side effect medication and you see what happens to your symptoms. If your symptoms modulate in a positive way, you continue that and maybe you up the dose. If they modulate in a negative way, you stop and you do something else. I think what you take from that and apply to meetings is that the last thing you want to do if you feel like meetings are a problem in your culture is prescribe chemotherapy for meetings. You don't want to say, "Let's eliminate all of our meetings." You don't want to say, "Let's go to an agile process as prescribed by the Agile manifesto of that Agile doctrine of the Church of Agile right away." What you want to do is say, "What's a small thing we can change to try to effect positive improvement in the way we collaborate, when we're having conversations or when we're meeting or when we're online doing virtual meetings? What if we introduced a facilitator in a subset of meetings? What if we introduced time constraints for a particular kind of meeting? What if we cut one genre of meeting from the kind of meetings that we have? Let's do that for a month and see what happens. Let's do that for a quarter and see what happens." Experiment much like the way you experiment with medication in trying to find out if it's a good fit for symptoms. I think a lot of people, because they feel intense pain related to meetings, they want the chemotherapy of meetings. They want to know if I just do what person X says to do that everything will change. I think sea changes do happen just like they happen in medicine. That's why they make for great drama and they make for great stories, but I don't think it's the reality of most people's existence and their professional lives. I think the reality is you're looking for ways in which you can continually get better and some of those are going to be small wins. Every once in a while, you get that big win, but you get there by making those small steps. Jared, you actually recommended a book to me which I've read that also rings with this. It has to do with the process of writing, the book "Bird by Bird."
Jared: Yeah, Anne Lamott's book.
Kevin: Having read that book, it really helped me think more about how I write and what I want to write but, more importantly, it just said, "Don't try to write the book. Just write a small idea. Just write what you feel like writing that day. Just write 750 words and then go back." Because experiments are experiments, they're not solutions, and that's OK. You need to be OK with that and recognize that any process takes time.
Jared: I think that's brilliant advice. Baby steps, just keep working on baby steps.
Kevin: Don't confuse the pain of meetings in your culture. It doesn't mean you have cancer. Lots of organizations are really successful but feel a lot of pain. What you want to try to do is start to experiment with alleviating some of that pain. But don't jump to chemotherapy right away. [laughs]
Jared: That makes perfect, perfect sense. Kevin, I am so looking forward to your workshop at UI18.
Kevin: I love doing it. I always have a great time.
Jared: One of our top rated workshops every year. People have been really coming out it saying, "My gosh, this is going to change my life. It's going to change the way we work." It's really exciting that you're coming back. For those of you don't know, that's User Interface 18 Conference. You can find out more information about it at Kevin is doing a full day workshop on leading super productive meetings. That'll be on the first day, Monday October 21st, and it's going to be awesome. It will be very exciting. Kevin, thanks for taking the time to talk today.
Kevin: Anytime. Always a pleasure.
Jared: Fabulous. Once again, I want to thank our lovely audience. If you listen to the podcast and you have a chance, go to the iTunes and look us up and put in a little review. Just give us the number of stars you think we're worth, because that does actually help us get the word out to other people. People find us better that way. Glad you were able to join us and thanks for encouraging our behavior. We'll talk to you soon. Take care.