by dbward | Jul 29, 2019 | Facilitation Tips
We’ve all been in meetings where one person talks too much, haven’t we? As facilitators, this can be a challenging situation to manage. On the one hand, we want to honor each person’s contribution and willingness to participate. Shutting someone down can have a chilling effect, not just on the individual but on the group as a whole.
At the same time, it’s important to make sure everyone gets to participate, and if one person is dominating the conversation, the whole group misses out on hearing from other voices.
To paraphrase Sun Tzu, the best way to deal with this situation is to prevent it from happening in the first place. Be sure to set some ground rules in every workshop’s introductory comment. Make it clear that everyone in the group has a role to play and something to contribute. Encourage people to be mindful of sharing the stage and inviting others to speak.
I’ve even been known to do a little public math: “We have 20 people in the room for a one-hour meeting. If everyone speaks for 3 minutes, that’ll be the whole meeting.” For some people, it helps to hear the actual numbers explicitly called out.
And of course, despite the best preparation and guidelines, it still happens. Someone goes off on a tangent, unrolls an endless story, or otherwise monopolizes the group’s time and attention. They might have a good point or a useful observation, but it’s just gone on a bit longer than necessary.
Or maybe they’re just rambling and someone needs to stop them.
Here’s what I do when that happens: With a big smile and a nod or two, I hand the over-talker a pen and a stack of sticky notes. I say something along the lines of “Hey, that’s a really important point – could you write it down in your own words? I want to make we make sure we really capture it before we go much further.”
Depending on how much the talker is paying attention to the other people in the room, I might have to stand up and/or move closer to them, physically intervening to get their attention and create a pause in their monologue. I’m always amazed how a little shift in my posture or my location can help change a room’s dynamics.
This technique does several things simultaneously.
First, it solves the immediate problem of one person speaking too much, because it’s really hard for most people to talk and write at the same time. Putting a pen in someone’s hand basically turns off their mouth.
Second, it affirms the person’s contribution to the discussion. This is the opposite of “Shut up and move on.” Instead, it’s “Keep going, but do it in a different mode.”
Finally, it gives the person a chance to really clarify their point and distill it into a more focused package. They may discover that they weren’t really saying much worth writing, or they may uncover their actual point in a more cogent fashion. Everyone wins.
Got a facilitation tip? We’d love to hear it! Leave your suggestions in the comments section, or drop us an email at ITK@mitre.org to continue the conversation!
by dbward | Jul 22, 2019 | Uncategorized
Our Story From Last Week Continues…
Day Two: Brainstorming and Prioritizing Actions
At the end of the first day, the facilitation team met and affinitized the feedback we’d heard, grouping it into topics for the next day. Our intent was to form the participants into persistent teams of 5 or 6 people; these teams would move from topic to topic throughout the day.
We also noted which people had been helpful or disruptive in furthering group cohesion, and strategized how to ameliorate this. One of the VIPs, whose mere presence as a VIP was hampering conversation, solved our problem by recognizing that he should not be present for the second half.
The other critical tactic we used was to intentionally mix up the teams, so that each team had representation from two or more roles. Because folks had naturally sat with their ‘friends’, this was relatively easy to accomplish—we went around the room, table by table, and had everyone count off 1, 2, 3, etc. as their group assignment. This shuffled the groups nicely, resulting in a much more varied mix of people in each.
The Lotus Blossom encourages participants to brainstorm subtopics, and then dive into each subtopic to generate related ideas.
To gather ideas for possible actions, we used the Lotus Blossom method. The Lotus Blossom is a structured brainstorming tool that enabled the teams to ideate multiple solutions to the problems identified. Facilitators used “How Might We?” statements to help elicit ideas, shifting the focus from constraints to possibilities.
Using this method, we were able to generate around 40 potential solutions for each topic area in 50 minutes, successfully staying on-task without going too deep into any one topic or rat-hole. Because ideas are immediately written down on the Lotus Blossom worksheet, all participants can see what was brainstormed, and think laterally, rather than getting stuck on a particular topic.
Each table had a MITRE facilitator who helped fill out the diagram. This helped teams understand the context when coming to a new topic. Facilitators also kept the conversation moving, recording and reflected ideas back to the group.
We also wanted the teams to prioritize their ideas. To do this, we used the Impact/Effort Matrix method, sometimes also called the “2×2 matrix” method. (See, e.g. https://www.groupmap.com/map-templates/impact-effort-matrix/ for more details).
The Value/Effort matrix is a technique from the Six Sigma toolbox that helps
The axes we chose reflected our conflicting populations: impact, which would be specified by end users, and effort, specified by the development teams. The resulting priority was a function of both inputs: high impact/low effort actions would obviously be prioritized above low impact/high effort.
Time Pressures = Progress
The last piece of our method was to use the clock. We had an abbreviated schedule on the second day: about 4 hours of work time available. We knew we wanted groups to rotate between topics, with later groups building on the work of earlier groups. But by the third or fourth rotations, groups would be coming to a large amount of context; in this situation, brainstorming often begins to dry up and get less productive.
We eventually settled on an accelerating schedule. Groups had 30 minutes to brainstorm and prioritize actions for their first topic; then, 20 minutes on their second, then 10. After each round, groups reported out to the entire room, to help promote coherence, but also to help the participants feel invested in these ideas.
When we noticed they were unengaged or seeming reticent, we asked or volunteered individuals to represent ideas to the group at large. This was extremely helpful; in some cases, people who had been ‘floating along’ and letting the rest of the group do the work ended up pulling out an idea and making it their own. This vastly increases the likelihood of it being actioned in the future. For example, a sysadmin realized that, even though her office had solved lots of process problems, other offices might not have, and that she could share her experience with other offices for an overall improvement.
>After three rotations, all topics had a sufficient number of ideas brainstormed and prioritized, and we stopped and reflected back our key findings to the group as a whole; we then let the group break up into social groups, to continue to build common ground.
Results
The data—captured both as notes and as pictures – became the input for a response document delivered to the sponsor, which was met with strong approval; we were able to reflect the pains and opportunities in the current system, and provide potential actions, all using the words and ideas of the sponsor’s own people.
An equally important outcome was the increase in team cohesiveness across locations and constituencies; folks left with an air of “we can do this together”, which was a desired but not guaranteed outcome. Breaking down silos of knowledge, and teaching developers and users how to communicate, are key means of improving the overall user experience of a system.
The work with the sponsor is currently on hiatus, but we have already been asked to run a similar session with additional sponsor representatives in the future.
Big thanks to guest bloggers Alex Feinman, Tom Seibert and Tammy Freeman for sharing this story!
by dbward | Jul 15, 2019 | Uncategorized
Today’s post is the first in a series by guest bloggers Alex Feinman (with Tom Seibert and Tammy Freeman)
Sometimes, you have to mix and match methods to get the results you need. This story is example of how important it is to be able to modify and adapt the plan in response to new facts and constraints.
MITRE was called in to facilitate a conversation about replacing or upgrading a COTS piece of software that a sponsor was using. We put together a session that began with knowledge elicitation, to understand their domain; then focused on establishing user requirements; finally some progress toward conclusions and agreements on actions.
The sponsor sent close to 30 people to the two-day event. MITRE brought in a team of facilitators to help manage the large number of people.
While our team had some experience with the software in question, we also had more experience with other, better software. Hence, we were expecting to elicit the sponsor’s needs, as a step toward potentially guiding them toward a better option.
This plan, as they say, did not survive contact with reality.
The Map is Not the Terrain
We were expecting our participants to be a mix of end users, ops/sysadmin folks, and program administrators. Instead, on arrival, we discovered that the bulk of attendees were developers—some sponsor-based, and some who were contractors.
The two sets of developer were working on competing systems, both used by the sponsor. End users had to switch between these systems to get their work done. In addition to this, we had only a few actual end users, plus a number of sysadmins, who sat between those two populations.
The group was on the edge of fracturing, with finger-pointing starting to become more apparent—the makers of each system were defending their turf and jobs, and beginning to think about bad-mouthing the other “team”. It was time to help these developers understand how things looked from the user’s perspective, and fast.
Day One: Finding Common Ground
After a quick consult, the facilitators decided to continue to gather data on the work context—getting a sense for what things were on everyone’s minds about the systems. Concerns by most users centered around ease of use issues, responsiveness (or lack thereof) from development teams, and annoyances related to switching between two different systems with similar purposes. Concerns from sysadmins and developers centered on deployment and provisioning, and licensing of third-party data sources.
We used dot voting to identify which concerns were foremost. This backfired slightly: nearly everyone voted for “merge the two systems”—a solution masquerading as a pain. Additionally, some near-duplicates needed to be merged. In retrospect, we could have used a round of affinitization or Stormdrainingto reduce the number of issues prior to voting.
Based on this finding, we decided to dive into understanding why the systems were currently separate, and whether there were any benefits there. A subgroup worked to put together a rough system diagram on a whiteboard wall. This revealed a huge amount of complexity hiding behind the user interface and helped legitimize the current split situation. One of the systems had strong processing capabilities, while the other had a much stronger UI. With this brought to light, we worked to help the group see that there might be a double-win involving pieces from both systems.
Armed with this data, we gave the group six areas to focus on, ranging from user workflows and UI issues to system administration, data ingestion, and data processing. This allowed the group to break up naturally by role, which was both helpful and harmful—helpful in that each group made progress, but harmful in that it did not work toward building group coherence. However, it was a necessary step toward group formation—letting the folks there understand that we were intending to listen to them, understand their situation, and help them prioritize their concerns.
Informal discussions, such as those happening over lunch, were critical to getting folks to buy into MITRE’s role as an unbiased facilitator. These conversations helped cement their trust that we weren’t there to put half of them out of work, weren’t there to promote one system over another, and certainly weren’t there to sell them on software we created.
We also invested time with particularly reticent folks to bring them around to seeing other people’s perspectives, and give them hope of open lines of communications. While often overlooked during use of ITK “methods”, these informal conversations can make or break a long event such as this one!
By day’s end, we had a commitment from everyone to keep working together and keep talking—a great start given where we’d begun.
Stay tuned for the rest of the story in next week’s episode!
by dbward | Jul 8, 2019 | shared leadership, Team Toolkit
Knights of The Round Table
I often say the best thing Team Toolkit ever built was… the team itself.
Team Toolkit operates with a collaborative structure where each member has a lot of room to use their strengths, to support each other, and to have fun doing it. It’s a very low-ego environment, where we know each other’s strengths and celebrate each other’s contributions.
The team has terrific chemistry – we genuinely like each other. On the one hand it’s not possible to force this or manufacture good personal chemistry, but on the other hand this sort of thing does not happen by accident. Positive relationships within a team require a mix of deliberate effort and good luck.
From the start, Team Toolkit made it a priority to build these friendships and foster a certain type of environment. The fact that we worked on it and did it on purpose doesn’t make our relationships less real. It makes them more real.
Our mutual respect and appreciation for each other also made it easier for us to adopt a collegial, shared leadership structure, where everyone is able to make decisions and guide the direction of the team. There is no a single formal leader with executive decision-making authority for the team. Instead, everyone has the same authority. You could say it’s a leaderless group, but it is definitely not a leadershipless group. There’s a ton of leadership on Team Toolkit, and it comes from all of us.
For example, when someone has an idea for a new tool, workshop, or activity, we present the idea to the group and see who might be interested in doing it. We’re not assigning tasks or asking for permission as we would in a top-down style organization. Instead, we’re informing and making invitations. There is someone who leads each activity, and it varies depending on people’s interests, skills, and availability. In keeping with that spirit, let’s hear from some other members of Team Toolkit:
“The Shared Leadership structure shows up in our team meetings when no one person runs it every week. We take turns. Everyone runs point on workshops/has connections that they bring to the table.” – Rachel
“We play to each other’s strengths, both in sessions and through our weekly meetings. We acknowledge that we aren’t all experts, and are constant learners – learning from each other and from our shared experiences.” – Melanie
“The diversity of our team’s strengths and interests helps to ensure that folks commit to leading initiatives that they are genuinely interested in or good at, which leads to better results. i think we have strong trust too that you don’t have to worry about what’s NOT on your plate. You know other team members will deliver and that someone on the team will have your back/help if you should need it.” – Aileen
It’s a tremendously efficient and effective approach, and I think more groups should adopt it. There’s a lot of great research & resources out there about shared leadership, so if you want to learn more, consider starting with this piece by Joanne Fritz.
by dbward | Jul 1, 2019 | Tools 101 |
The TRIZ Prism tool is a powerful way to unlock a team’s creativity and discover new solutions to difficult problems. It’s a pretty straightforward practice to describe, but actually doing it can be a little trickier than it looks at first.
The Elephant-And-Straw example in the image below is based on a real-world project Dan worked on. The activity begins in the lower left corner (the box labeled 1 – Specific Problem), we wrote a very specific problem description… and realized it was a really hard problem, with no clear solution.
That’s where the TRIZ Prism comes in. We then stripped out all the particulars and developed a general problem statement. We came up with “the big thing does not fit through the small aperture,” then explored general solutions to that category of problem. Once we came up with some general “types-of-solutions-to-that-type-of-problem,” we reintroduced some specifics and came up with a specific solution. That may sound like an obvious way to generalize & summarize the problem, but getting there took significant effort.
How did we do it? In a word – incrementally. The process of moving from Box 1 to Box 2 went something like this:
- How can we get this satellite image through this bandwidth to this soldier on this timeline?
- How can we get anything through this bandwidth to this soldier on this timeline?
- How can we get anything through any medium to this soldier on this timeline?
- How can we get anything through any medium to anyone on this timeline?
- How can we bet anything through any medium to anyone on any timeline?
- How can we get anything to anyone?
With each version, we removed one level of specificity and replaced it with a generalized version. Alert readers may note that #6 does not say “How can we get a big thing through a small aperture?” That’s because #6 in the list above is actually not a very good generalized statement of our problem. We needed to massage it a bit and re-introduce some specifics to get something truly useful for our situation. I mention it to highlight the fact that any specific problem can be generalized in multiple ways… and some are better than others.
From “how can we get anything to anyone,” we put some of the specific constraints back into the problem statement and went with “How can we get a big thing through a small thing?” That statement has enough specificity to be useful, and is general enough to be open to a wide range of solutions.
We then explored a wide range of typical solutions to that category of problem, and came up with a specific solution that allowed the soldiers to draw a simple polygon on a map and request a small image chip. It worked great.
Interestingly, that solution meant our initial problem statement was actually a bit off base. They didn’t need the whole elephant in the first place. They just needed the trunk. And it turns out the trunk fit through the aperture nicely.
Disclaimer: No elephants were harmed in the production of this example.
