Users. God love ‘em!

Without users, we’d all be writing … well, not much, I guess. For better or worse, they are IT’s raison d’être – they drive the enterprise, they fill up the queue, they set our agenda.

And while they need us more and more, in recent years they seem to trust us less and less.

More to the point, as our industry has grown, so have our options. We can generally offer our user communities several answers to any given problem or need, and while this requires more whittling on both sides to get to a solution, it’s surely not a bad thing, right? Yet this new reality doesn’t seem to inspire greater confidence in our customers; on the contrary, they grow increasingly wary.

I’ve puzzled over this a lot, and recently I had an epiphany. For a number of years my role was consultant and trainer. It was my job to take up temporary residence in an organization and pour forth with all those options we have today. Frankly, this kind of made me the hero: people love it when somebody waltzes in from outside and assures them there is light at the end of the tunnel.

But not so long ago, I took up permanent residence again after years on the trail – and was reminded what it’s like on the other side. When you’re doing the hard work of whittling down to solutions, and you work just down the hall from the users who are sitting in requirements discussions with you and your team, it’s a whole new game.

Bandwidth issues

Brainstorming with a group of IT professionals and brainstorming with a group of users are two completely different kinds of brainstorming. As with any professional group, a shorthand exists among IT folks, where many things can go unsaid and everyone still understands one another. When I was a consultant and IT trainer, I was among that crowd, and lots of things were mutually understood.

But it’s not that way when IT meets Users. Users who interface with IT are usually really sharp, and are of course professionals in their own right – and many do have a strong grasp of systems and speak some of the lingo. But it’s still asking quite a bit that they grasp all the upside and downside of every solution proposed to an application problem, in a list of five or six, in a single discussion. Put simply, we overload them when we don’t take this into account.

Easy to be hard

Moreover, IT professionals tend to nurture a theoretical side. However practical an IT developer, architect, or hands-on manager might be in the down-and-dirty work, we all have that what-if mode that serves us well in many aspects of our work. It’s one of the features of the profession that called us, right?

So when we’re in brainstorming mode, we let that what-if circuit run wide open. We’re not thinking easy/hard, or practical/impractical; we usually are still parsing possible/impossible.

But the user across the table doesn’t know that. When we brainstorm, everything we’re spewing forth can sound equally magical or equally difficult. And those misperceptions can stick in their heads …

… and get repeated, when they leave a meeting with us. To their peers. To their managers. Who might repeat them to our managers.

It would be very, very interesting to conduct an experiment along these lines, to measure just how much our IT brainstorms can screw up a project: put two or three of us in a room with half a dozen client users, and give them all two or three possible solutions apiece; then turn them loose, and follow up with everybody they talk to afterwards, and find out just what they said we said. We’d probably be horrified. And have no one but ourselves to blame.

The moral being this: what goes on in the conference room doesn’t stay in the conference room. So be careful, careful, careful what you say!

Why is he telling us this?

I’m telling you this because (you guessed it) I myself got spanked for it, not long ago, and I deserved it. Context is everything, and in our increasingly complex IT universe, the proliferation of options is a two-edged sword. It has made our universe more confusing, and even moreso for those who have to listen to us.

The solution? Simple, really: discuss some boundaries for brainstorming with your peers, and agree on those boundaries. When client users invite you to an initial meeting, say as little as possible – just listen. Do the brainstorming off-line, and when you’re back with the users, bring out the top two or three options at most, and offer only the detail that’s really necessary.

Most of us aren’t, after all, paid by the word …