Corvus Consulting

Who doesn’t remember The Blair Witch Project? Though remarkably un-scary, I was mesmerized by the characters’ experience of being lost. In recent years, Blair Witch airs every Halloween, and re-watching it reminds me of a lesson learned in crafting information architectures and software designs.

For those who haven’t seen the movie, a great deal of camera time is spent following the characters as they trudge through the woods, becoming increasingly unhinged as they are unable to find a way out. As they slowly realize that they are hopelessly going in circles, they employ the usual rules of wayfinding in the woods: check the map, stick to the river, mark where you’ve been. But it’s to no avail, for these are enchanted woods and the Blair Witch is messing with them.

The characters are badly lost, going in circles despite following the rules for getting un-lost. They check and re-check reference points, they reiterate the rules, but they remain lost and things quickly turn to blame and recrimination. It ain’t pretty.

And that feeling of going in circles is one I’ve come to recognize in the IA and product design process. It happens in even the most agile and creative teams, and the trick is to recognize when it does and to accept that for all your team’s brilliance, you’ve fallen into GroupThink.

GroupThink happens when a team has lost the ability to incorporate new information into a design approach, and can happen for any number of reasons. It’s the kind of thing you can’t see until it’s already happening, and the realization is usually folllowed with a sense of lost time and wasted effort. If only I had seen this was happening sooner, you might think. You’re on the right track; early detection is key, and that’s where the Blair Witch Test comes in.

The Blair Witch Test

Step 1: Trust your gut. If you have a slight feeling that your team is treading over the same territory, stop and pay attention to that feeling.

Step 2: Check the internal signs. Have you started skipping steps in the process? Have you started giving stronger voice to how you personally want to work? Is your team constantly referring back to source documents but not coming up with something new?

Step 3: Do you suspect one or more of your teammates are letting you down? Maybe they are. But if you’re feeling this over one issue, you’re likely wrong. The fact that it’s getting personal is a sign that something needs to change, and fast. As in today.

OK, We’re Lost in GroupThink – What Next?

The fatal mistake of the confused and scared Blair Wtich victims is that they rely completely on internal reference points – things that are within the woods. Setting thematic magic aside, had they been able to find something external to the woods to fix their position they might have broken out and escaped the woods.

The same thing happens in GroupThink – if you’re lost on cracking a problem, it’s time to stop going in circles and bring in your customers. There are all knids of ways to do this, from surveys to user interface testing to simply getting on the phone with some trusted voices and asking what they think. As an information architect or product designer, you already have the skills and tools you need to do this; you just might not be used to doing it at this stage of the process.

Your customers can’t solve your design challenges for you. What they can do is to put you back in touch with their real-world needs and aspirations. They can give you examples and scenarios and passing comments that become the reference points your project needs to break out of GroupThink and to find that sweet spot where you know you’re on the right track.

Like the Blair Witch, GroupThink never reveals itself directly in the form of a bug or a missing piece of data. It must be sensed, sussed out and acted on, or it will consume your project. Do you have a way to bring customers into your process at unexpected points? If not, you’re missing an important project tool, one that can be as important as a compass in unfamiliar territory.

I was writing an email to schedule a meeting this weekend when I had a revelation. Yes, a revelation, one that I’d like to share.

First, some background: people who know me will agree that I’ve got a real penchant for effective meetings. I like my meetings guided by agenda, focussed on outputs and outcomes, civil and with a definite end point.*

That dedication can turn me into a bit of a whip when it comes to starting on time, as the urgency helps teams build a culture that values the time spent in meetings and makes the most of it. Usually this approach is just fine, but sometimes starting a meeting on time is not an act of will as much as it is an allowance of probability.

That last part was the revelation. On small, agile teams, starting a meeting on time isn’t always possible or even desirable, as the team members wear several hats. Operations is one of those hats, and it’s all too common for small emergencies to take precendence and to derail that precious starting time. After being thrown off schedule, everything can fall apart and the next thing you know your meeting is taking place another day, with a loss of momentum.

So how do you schedule start times for agile teams? You don’t try to force it, that’s for sure. Instead, go with the reality you’re working in. I asked the team to expect a meeting of an hour or so in the early afternoon, and that we’d aim to begin between 1:00 and 1:30. Just before 1:00, I use instant messaging to feel out where the team is at in their day. Based on that we nail down a solid start time when everyone can set aside their work and focus on the meeting.

The result is that I’m not asking people to decide between two imperatives, and instead line them up in their proper order on the fly. As an aside, this is an example of where instant messaging can be a hugely productive tool on a team, better than email, the phone, and any project management tool.

This might seem obvious, but on small multitasking teams, coordinating to meet at specific times can be a challenge. The lesson here is that relaxing time to timeframe is a more humane and realistic way to organize people around the daily hurly burly of having development and operations in the same set of hands.

*For what I consider the gospel of running a good meeting, check out How to Make Meetings Work by Michael Doyle and David Strauss. Read this book on Tuesday and on Wednesday you can have a dramatically improved meeting experience. If it doesn’t work for you, I’ll personally buy your copy of the book for ten bucks.