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 #184 Kevin Hoffman - Leading Productive Meetings

September 21, 2012  ·  35 minutes

Listen Now

Download the MP3

“Meetings are a waste of time.” “Meetings, ugh—I have real work to do.” Heard these? The perception of meetings worsens when you have an unproductive one. The entire team feels like their time could have been better spent.

Show Notes

Kevin Hoffman has thought a lot about meetings. He views them as a design problem. There are dynamics that affect how successful a meeting can be. One thing Kevin has found successful is temporarily changing the organizational hierarchy. This allows everyone, leaders and their reports, to suggest ideas on an even plane. Inevitably this enhances the collaborative effort.

Another approach Kevin mentions is to view a meeting as a short-term company, formed to get a job done. Based on the definition of a company as a “network of promises”, this parallels both the idea of a meeting and the design process itself nicely.

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

Full Transcript

Jared Spool: Hello, everyone. Welcome to another episode of the SpoolCast. I got to tell you, today we're going to talk about something that you've definitely wanted to talk about, meetings. I've got Kevin Hoffman with me today, and Kevin is, at the User Interface 17 conference, going to be doing a full-day workshop on leading epically productive meetings. So he's going to lead an epically productive workshop on epically productive meetings. Kevin, welcome.
Kevin Hoffman: Good afternoon, Jared. How are you?
Jared: I'm doing great. I'm doing great. I want to talk about meetings. Now, this is the second time you've done this workshop on meetings, and we brought you back this year because you did such an awesome job last year. People really loved it. I know that people were talking all the time afterwards about how much their meetings improved because of the way you talk about how to turn meetings into productive activities.

But I also know that since last year, you've actually learned a bunch of things about running meetings. What's been new in your thinking about all this?
Kevin: Well, first of all, thanks for having me back again. I really appreciate it. I found the UI conference, this will be my third experience with UI, my second as a speaker and a workshop facilitator, and it's a very different and cool kind of conference. It has a level of depth and, really, connectivity between the attendees and the speakers that I thought sets it apart from a lot of the other conferences I've gone to. So I appreciate the invite to come back.
Jared: Wow, thanks.
Kevin: Sure. In the past year, I've had the good fortune of being involved in more strategic meetings that cross different levels of a hierarchy in an organization, and in some cases with some larger organizations, organizations like energy companies, large semi-regulated companies, some large television and radio companies.

I've always felt like the idea of understanding that an organizational hierarchy needs to change during the duration of the meeting, it's something in the literature and it's something that I've seen work well in smaller organizations, but it's become really apparent to me that conveying that at the beginning of a meeting, that being that although we may have a hierarchy, and although you may be my boss and someone else might be someone who reports to me, inside the context of a meeting, those relationships need to be leveled, or at least reconsidered, depending on what the protocol of the activity is.

If you have somebody who's facilitating, they're sort of in charge, in a sense. But allowing organizational leadership to relax a little bit and not necessarily, be judging the ideas of their direct reports or their second-level reports, but also be as responsible for contributing ideas, in a parallel way, has been really powerful.

It's been really interesting to do workshops with some larger companies, where people aren't used to that idea and, quickly, after initial discomfort, find themselves, after a few hours, just feeling like they're part of a team and can really easily measure their contribution in a different way, as opposed to thinking about what are the deadlines that they're supposed to hit.

Now, I realize this is time away from the work they normally do, and they have to get back to all of those deadlines, but that idea has been really powerful and been reinforced a lot over the past year.
Jared: This idea of changing the organizational hierarchy temporarily, for the status of the meeting is really intriguing to me. I think that it sends a message that says, "Look, what we're doing here is really important, and we need to work together, not use the sort of hippo management style of having the highest-paid person in the room just make the final decision on a list of agenda items, but instead to make it exploratory and investigative and to let people's questions come out and ideas surface." In the teams that I see do that, the end result is always so much more energizing and exhilarating and, frankly, just feels like it's moving us forward much faster.
Kevin: Yeah. There's a couple of things that come to mind with that dynamic. So the first thing is that the reason I like to talk about meeting design or looking at meetings as a design problem is because you have a lot of dynamics that influence the way in which work gets done in a meeting. There are two ways in which we work. We work as individuals and we work as groups.

We have lots of ways in which we measure and evaluate the work we do as individuals, how much billable time we're doing or how much time on task or am I logged into the right application for the right amount of time. There's all these different ways to measure those things.

I don't think and I'm not aware of a model by which we measure how we're productive as a team, in real-time collaboration. Not necessarily, over a project's life cycle, but in real-time collaboration, are we making successful use of time? There are lots of dynamics that affect that. The dynamics of the hierarchy of the organization are one. Who do I report to, and am I afraid to share my ideas when my boss is in the room if my ideas are maybe not my boss's ideas?

Another dynamic is simply the dynamic of what people we are. So some of us are very extroverted or comfortable expressing ourselves in groups, and some of us are comfortable expressing ourselves in small groups, and some of us are comfortable expressing ourselves in front of large groups and making presentations.

The nice thing about meeting design and thinking about your meeting as a design problem is you can design for those variations in personality and organizational structure and try to create a system by which you can maximize the input of people and the emotional investment of people in their work that they might get sitting in front of the computer designing something by themselves.

It's not always going to be that way, but I've found, in the past year, as long as I've been doing these kinds of things, that that's always the case, that people are more invested in the project as the result of a successful interaction in a meeting than they are before that meeting, especially if they're challenged to do things they haven't done before.

There was an article in the "Harvard Business Review" recently, this year, about the idea of defining what a company is. I think the short definition, the tweetable definition, of a company was that a company is a network of promises.

In a conversation I had with Dave Gray in March at South by Southwest, we were talking about the idea of how you define a meeting. In a neat way, if you use the definition of a company as a network of promises, a meeting is a company. It's just a different company than the company that's having the meeting. It's almost a separate company. It's like we're going to form a very short-term company to get a job done. So what is that job and how do we measure success?
Jared: This is neat, because the design process is also just a network of promises, right?
Kevin: Exactly.
Jared: I'm always amused, because we have this glorified view of designers, that they sit at these artistic-like drawing boards with these high-tech tools, and they're creating their beautiful designs and orchestrating these beautiful symphonies of experiences, and that's what they spend their time doing.

But you and I both know that designers, UX people in general, spend a ton of time basically, sitting in meetings. Meetings with clients, meeting with coworkers, some of the meetings are planned. Some of the meetings are spontaneous. Having a way to make those meetings productive every minute, I think is a big challenge, but something that, when you've mastered that skill, pays off huge.
Kevin: One of the things that is a really lightweight thing that I've found people react to well in terms of thinking about impromptu meetings, in particular, if we can identify the goal of that impromptu meeting early in the process, and there's somebody who's got a good playbook of facilitation techniques, you can get certain things done in 7-10 minutes that might have taken trying a more traditional discussion, "Let's go around the table and take everybody's flavor of how do you feel about this issue," that will take the traditional 30 minutes to an hour that you book on the calendar.

The idea of, "You mean we can make a decision in seven minutes?" and even using that as a constraint, the idea of meeting constraints, like, "You know what? We're not even going to talk for more than seven minutes. Here's how we're going to do it. This is your only chance to make a difference," forces people to work in a different way.

I know Aaron and Adam are doing their workshop on critique at UI, and part of that workshop is taking people through a design studio. The fundamental constraint of design studio is time, limited time to accomplish a goal. Honestly, I had a conversation recently with the CEO of a radio station, and we were talking about the design team and their complaints about the web product and how they feel like, if they only had more resources, they could do more.

This is a guy who's a veteran radio leader. He was like, "In 45 years of doing this, there's never been a situation I've been in, public media, private, network, where resources were not limited." Resources are always going to be limited, and in many cases that's what leads to ideas.

The idea of introducing time as a constraint in meetings and being very deliberate about it. I wish calendar software, like Google Calendar and Outlook, I wish it was designed differently. I almost feel like it's designed to make you lazy and plan meetings that are longer than necessarily. As a result, you see those blocks fill up every week. If you could limit people to 10 minutes or limit people to smaller chunks of time, and they were visualized more reasonably, maybe as we get these higher-resolution displays, that'll be possible.
Jared: How does this work in these environments where people are taking apart their cube spaces and doing general workspaces, where everyone is sitting around the same table and they're together, they're working on their own independent stuff, but then these little ad hoc meetings come up?

In essence, those are these little, short meetings, right? They're little 5-minute, 10-minute meetings to address a particular question or issue, and then you dissolve the meeting the moment it's done. The structure that you teach, about having a facilitator and a recorder and all this stuff, does that still make sense in these little ad hoc meetings, or is that too much heavyweight, too much overkill?
Kevin: I think it's overkill. That's a question that comes up from people I talk to about these techniques and people I talk to about meeting facilitation generally is, "What is N?" N being the number where you actually can use a structured approach to roles and make a difference. What I've been talking about recently, with the idea of impromptu meetings, four people are less, if they're taking longer than five minutes, they're probably not going to benefit from defined roles.

However, when you get over five, six people, or you find that the discussion is pulling other people in, it's probably best not to have that meeting in a space that's designed for individual work, where you're working as an individual.

Collaborative spaces, where we're all sitting around a shared physical desk, I think it's an illusion, or at least a little bit deceptive, that that is actually a collaborative space. A physical space designed for collaboration, for collaborative discussion and exploration, is going to have different tools than the kind of tools we use to get work done as individuals.

The freedom to approach each other physically is the benefit of that space, but you still need what are called collaborative spaces. I was talking with Sarah Nelson recently, about the idea of physical space and collaboration. If you look at, and I'm trying to think of how you would put this, Jared, companies that have design at their core or companies that make design part of their mission, companies like, I would argue, Google, Apple, there's more that we were talking about in the conversation.

They actually have spaces that are intentionally collaborative. These are spaces where there are not laptops or screens. There's data, maybe real-time data represented in some way.

There was an interesting example at Proctor & Gamble, where they have these war-room-like collaborative spaces that have real-time stock data and all information flows that people would use to make decisions, or at least inform decisions, but provided with a lot of collaborative tools, like white boards and videoconferencing tools.

When you bring up the idea of going from a cube farm to a collaborative space, where people are working in the same physical space, there still is a need for the design of collaborative spaces.
Jared: So this idea of a collaborative space, that space, what makes it collaborative, I guess, is, again, this breakdown on hierarchy that we were talking about before, this idea that anybody can pick up a pen and start writing on the wall if they have a good idea. You have space to play things with Post-Its. As you know, you can't do design unless Post-Its are involved.
Kevin: Couldn't do anything before they existed.
Jared: Yeah. I don't know. Nothing got designed then. This way of thinking about the space has to do with being able to, at that moment, be equals and shift back and forth and then return back to whatever the hierarchy is within the organization and the structure and, "I go back and do my job, and you go back and do your job." But for a little while there, those jobs are irrelevant, and what we're doing now is just bringing all of our experience to the table.
Kevin: Exactly. That's a big piece of the collaborative spaces, that they're safe zones for expression of problem-solving. I think the other piece of those collaborative spaces is that there's a deliberate approach to provide the tools for collaborative thinking. There are a lot of really cool things you can do in the digital space collaboratively, with Google Documents and their ilk, cloud-based computing. There are lots of things you can collaborate on in digital space, and I think that's important.

I don't think it's a substitute for face-to-face collaboration around problem-solving. There are different sets of tools and different ways that people express themselves and different ways in which people absorb ideas that happen in groups as opposed to sitting in front of a computer screen.

I love and will always be a fan of the work of Dan Roam. The way Dan talks about having the ability to use visuals, specifically sketching, to express ideas and the different dimensions of that, and then using that as a feedback mechanism for saying, "Is this what you're saying when we have this conversation in this meeting? If not, let's adjust this sketch until it accurately reflects what we're talking about." So we have an agreed-upon definition of the problem or a potential solution. It's just incredibly valuable.

That doesn't happen the same way in non-face-to-face collaboration. There's an asynchronous nature to it, so you're waiting for that, "Is this what it is?" Besides the loss of body language and tone and other things, there's also the, "What information do I have at my hands right now that helps me make this decision, if this is really right or not?" Whereas if we're working in a space together and you have that constraint of time, your brain works differently.
Jared: Last year, when you were at UI16, you basically focused on workshop meetings, the sort of kick-off meetings, and the meetings that happen at the very beginning of a project to figure out what we're building, why we're building it, and get all the players on the same page. This year, we're expanding that to talk about all different types of meetings. What are some of the other meetings that you're interested in, and how are they different from kick-off meetings?
Kevin: I visualize meetings on a scale. Basically, every meeting, you can define it based on the type of investment that people have in what they're doing. So some people might be need-to-know people. They're not invested in the outcome in the sense that they want to direct it or they have strong opinions about what's right or wrong, but they need to know the outcome in order to do their job. On the other hand, you have people who see themselves as responsible for leading a process, so they have a much higher level of investment.

If you take that concept of investment in the outcome and the way someone sees their own role in a project, and you add the dimension of time and time constraint, you can scale a meeting. So if we know this is a need-to-know meeting--these are people that just need to know so they can do their jobs--you can scale back aggressively.

If you look at Agile processes, or Lean UX, for example, where they've adopted some aspects of Agile software methodology into collaborating on user experience design, there's a lot of these quick-hit, short meetings every day, where you scrum around, "What have you done, and what are you going to do?" and then you check back in the next day and see how far you've gotten. Very low time-intensive, but designed to give people that working-alone time but maximize that collaboration time.

I also still think that workshop design and fundamental workshop structures have the most potential benefit for design projects, as a whole. Understanding those will help you figure out when to invest more or less time in a project, to get at a project that your stakeholders are going to feel like they have a say in the outcome or they got the information to you that you needed to know.

But, secondly, you are going to be able to frontload projects more effectively by getting what the project needs to be without spending a lot of time building actual prototypes of things. You might be building them on paper in a sketch. You might be building them in some descriptive activity. But it's a lot cheaper to do that than it is to actually build a working prototype.

The skills involved, while you definitely want developers and visual designers and graphic designers involved in every step of the process, including the kickoff, you don't necessarily, want to have them build something as a way of ascertaining whether or not an idea is a good one. So I feel like understanding how to put a workshop together well is going to save you lots of time and your team is going to be more emotionally invested in the product.

They are going to trust you better, when you make changes. They are going to trust you more when you make changes. One thing that I have seen and I am seeing right now in some of the work that I am doing with my clients is, in the rush to production, they actually didn't take the time to explore the full spectrum of what was possible.

I think, by committing to some workshop time at the beginning of a design project, you are at least opening up the opportunity to define where your product or your website might go if you can't build it right there. If you don't know where it's going to go in three to five years, there is really not any point. You are just doing what you might call reactionary design, which is, "Well, this isn't working, " or "We don't like it. So let's make it different."
Jared: Some of these activities that happen are really about just, in some ways, putting idea placeholders out there, exploring the whole realm of possibilities, but then coming back to reality and saying, "OK. This is what we can do for the next version." But if we know that everybody here thinks that this thing, being able to do this cool thing in the future is really neat, we can make sure we don't do anything now that actually makes that really hard to do two years from now or whenever we can get to it."
Kevin: Yeah, totally. Plus one of the things, on which I'm trying to focus now, is I will do a workshop helping to define a particular aspect of a digital strategy for a client. Whatever cool ideas we come up with, it would be great if we had this thing that does this thing, going back and, as a user experience professional, being able to tie what you talk about in a meeting to measurable outcomes.

If this is truly what the best strategy is for us, if this is the cool thing that we need to build, how will we know that it's working? That gets back to basic usability. But also, what metrics are we looking at? By introducing that constraint in that workshop design, you can get at some really interesting conversations, as a part of that blue sky thinking or maybe blue with a few cloudy sky thinking, if you want to be realistic.

One of the cool things that I was able to do, while I was working with Happy Cog, is I facilitated a daylong workshop for a process, by which we were trying to do a site redesign in a week. We had really stripped business constraints in terms of measuring how the site would be successful and what kind of behavior the site was supposed to trigger that aren't necessarily explicit on the site at all in its current incarnation, but it has been very successful at doing.

That was one of the reasons that happened. In the requirements gathering process, prior to the workshop, we were able to introduce constraints into the activities that we did in the workshop that never eliminated measurable outcomes from that blue sky thinking.

So, as the Happy Cog work continues to evolve, and I'm sure it will, those constraints, and I don't even think of them as constraints at this point, those business goals will never disappear from the product. They were baked into all of the blue sky discussion facilitation techniques from the beginning.
Jared: One of the things that strikes me about this is that different types of meetings must require different types of structure. That blue sky or blue sky with gray lining clouds kickoff meeting is different than a meeting, where suddenly a new technological constraint has been introduced.

They say that if we try and do this it will crash the servers. So now we have to come up with a design alternative quickly that fits into the design that is already in progress. How different are those meetings, structurally? Does someone need to know different things to be able to be effective in running and facilitating those meetings? Or are they basically the same problem, just at different times in the project?
Kevin: I would say there are fundamental forces, that a good facilitator is aware and tries to orchestrate in discussion, that don't change at the beginning or at the end of a process. When a new constraint is introduced, you are still responsible for knowing how to balance the discussion, how to recognize an inclusive solution, how to navigate between different ideation.

Is this ideation that is expanding our menu or is this ideation that is zeroing in on a solution? It is recognizing if everyone in the room is aware of that path and facilitating that path. It is our tendency to not follow a path at all. It is our tendency to find the thing that we understand, whatever our discipline may be. If I am a developer, I'm going to look at this from a development perspective and say, "This is where the barriers are."

If I am a visual designer, I'm going to look at this and say, "This can be designed to be more attractive or user-friendly.", or whatever my visual design philosophy is, but figuring out, as a facilitator, knowing all of those motivations, because you have some domain knowledge. But at the same time, it's recognizing that we are now in the phase of converging on two or three solutions from a menu of fifteen.

That is the same as in a kickoff meeting, where you are trying to get the best blue sky ideas, as it is in a meeting, where you have introduced the technical constraint and you are trying to get the best solution. You need to get the solution that respects the expertise of everyone in the room or everyone that should be in the room and be able to facilitate movement towards the end goal.

I wouldn't say it's any different really. Now, how you play with the constraint of time to make better use of time, how you play with the constraint of who is involved in a meeting, those are things that certainly can change over the life of a project, as you get closer to a launch or as you are dealing with life cycles of products. I think those things change all the time.

But the fundamental principles of good facilitation and understanding where the conversation is moving or where you want it to move, I think are the same at any meeting in the process. Does that answer your question?
Jared: I think it answers my question. I thought it was brilliant. One of the things that excites me about this workshop is this idea that we don't just assume that the way things have always been done is the way that they could be done most effectively.

Sitting back and rethinking just, "how do I run a meeting?", we get trained in our craft as designers, whether we go to school or we teach it to ourselves. Meetings are not something that comes up. We don't talk about holding a meeting, having a meeting and effective meetings. Yet, these are the things that we do so often with our hours.

The idea that there is a better way that could do this and that we could get more out of the meeting and everybody could walk out of the room energized and feeling like they have just had a great use of time and, more importantly, feeling like they are part of something bigger and that they want to come back and do some more of it, that to me really is the hallmark of a really great designer and a really great organization that understands how to design something, even if it is meetings for their own internal use.

So I'm really happy that you are out there talking about this stuff and you are making us all realize that there are better ways to do this.
Kevin: Thanks Jared. I appreciate that. We had a chat a while back, you and I, about design on Happy Cog's blog. I asked you a question about, in terms of design, specifically web design, what is more important. I can't remember exactly the way the question was phrased.

I don't know if it was what is more important or what has been a more powerful force, the idea of standardization or innovation. You came down hard, almost 100 percent, on the side of innovation. I thought that was really interesting, because really the way you put it, and I'll have to go back to the article or you can provide a link to the article and get an accurate way, but what I took away from it was the idea that the whole point of this is innovation.

We are always looking for better ways to do something. Any standardization is just a temporary placeholder. It is what we are all agreeing to so we can move on to the next innovation. If you look at the history of things like HTML or computing devices or anything, I think you will see that pretty much bears out.

Once we have all agreed on something like XHTML, eventually an innovation is going to come along as a result of technological increases in capacity or a better way of doing things that will make that standardization obsolete. That's a good thing. That's what we want to do.

It doesn't mean we avoid agreeing upon some standards over time. But the goal is to move things forward. If you look at people, who have maybe not catastrophic failures, but significant failures, I would say that sometimes, if not always, there is a component of holding onto something that maybe was a standardized agreement.

We agreed that we were going to do things a certain way. I think that actually the best example of this is if you look at the ongoing evolution of news and the way that journalism is trying to evolve. You are seeing it happen. In some places, it's actually happening in some pretty cool ways.

But if you had talked to a journalist or the managing editor of a major newspaper a couple of years ago, or even more recently, there was a sense of real frustration, because they were tied to this very old model. The same thing goes for television. If you look at television and you think about standardization, well standardization in television is advertising sold based on timeslots.

But now Hulu is a way that people watch television. They watch older television on Netflix. Anybody who uses Hulu regularly or Hulu Plus, will tell you that you can feel how this is evolving and how they are still trying to cram some of the old models into that experience. But what it is evolving into is still very different, based on the capacity of the technology.

So I don't think anything is ever not fair game. In meetings, one of the things that I like to talk about is my dad. My dad lived in his career. He had one job in his career, from when he graduated from graduate school, until he retired. In that job, he lived through the evolution of computing as we know it.

He started in the '60s and was dealing with these massive roomfuls of computers that did punch cards. Eventually, he got to working on personal computers and retired in the 2000s. Through that whole incredible quick evolution, if you think about the history of it, he was always in meetings. There were always meetings that were part of his life and they were a frustration for him from time to time.

Those didn't change the way that computing changed. I don't know why that isn't the case, because there are lots of really good ideas about changing them out there. I think the more that we treat it as a design problem, the better off we'll be at being able to develop ways in which we can successfully reproduce productive, time-saving meetings and collaboration, regardless of where we are in a process.
Jared: I think that that's really an interesting insight, and this idea that we can keep innovating even on things that we take as our most basic practice and to say, "You know what? There's new stuff we can do." This has been really awesome. Thank you for taking the time to talk to us here.
Kevin: My pleasure.
Jared: Those of you listening at home, you definitely want to check out Kevin's workshop, "Having Epically Productive Meetings," leading them, at UI17. It's going to be an awesome full-day workshop. We're very excited about it. That's "Leading Epically Productive Meetings." November 5th through 7th, Kevin's going to be on the 7th in Boston at the User Interface 17 conference. You can check that out at

Once again, thank you very much for listening to another episode of the SpoolCast. As always, want to thank you for taking the time with us and, of course, encouraging our behavior. Take care. We'll talk to you soon.