Sunday, November 1, 2015

Dear IT: Stop Making People Feel Stupid

Have you ever walked down the halls of the IT department to be assaulted with massive diagrams filled with boxes and lines, printed on plotter paper? I have. As I look at these diagrams, I find myself wondering a few things:

  • What is the purpose of this diagram? Who is it for?
  • Does the diagram communicate important information that is read, discussed, debated and revised?
  • Does the diagram help people do these things? Does it create greater understanding?

Sometimes I wonder if these displays are designed to create understanding, or impress passers-by with the overwhelming complexity of technology; to enhance its mystique and thus the status of the technocrats who understand it.

While the display may make the creator feel smart, if the person reading it feels stupid, the reader will disengage and dialogue will falter.

I have realized that my most important job is to communicate technology issues to my colleagues in a way that:

  • Enhances understanding
  • Invites dialogue and revision
  • Helps people make informed decisions

Statistician George Box said two things that changed how I think about using models and diagrams to communicate.
A model is a simplified representation of the 'real world.'
All models are wrong, but some are useful.
 When I thought about these two ideas, I realized that:
  1. If I am going to use a model to communicate, I need to ensure that it is as simple a representation as required.
  2. To do this, I need to communicate the minimum information required to get the point across - deliberately sacrificing completeness for clarity and usefulness.
The amount of information that leaders needs to read, understand, and act upon increases as they move up the organizational hierarchy. Therefore, I need to synthesize information to create clarity - without becoming too reductionist.

It's a fine line. Sometimes, I get it right.

Because I spend a lot of time working with leaders on issues of technology strategy, I've developed two visuals that I go back to again and again. A former colleague of mine described one of them as my personal "best seller."

The first is new, but when I saw executive heads nodding when it was shown for the first time, I considered this a good indication that I'm onto something.

One challenge that people have is understanding the difference between a strategy and a plan. During one such discussion, I gave an off the cuff analogy of a funnel with a few filters in it, and doodled it on a whiteboard. When the CIO's head nodded and he said, " I get what you're talking about," I figured this might be a winner. When I saw executive and senior leader heads nod at a college leadership meeting, I felt that the assumption was confirmed.

These are the talking points that go with this model:

A technology strategy has to be enduring - usually it covers a time horizon of 3-5 years. Because so much can change in that time horizon, a good technology strategy should be used to shape how people make decisions about technology, rather than actually setting out the decisions. It's like deciding how IT should filter out stuff that it shouldn't do from all the stuff it could do. 
Based upon the strategy, a roadmap of things that IT should do can be created. This list of priorities is not cast in stone, but it does help leaders set out priorities and sequence of investments based upon the best information available at the time - with the strategy to guide those decisions. 
The roadmap should be revisited annually, and decisions made about what initiatives will be funded and executed. In the public sector, our budgets are set annually, and it is very difficult to forecast what our resources may be with much precision. Plus, this is IT, and technologies and conditions change quickly. The priority and sequence of initiatives needs to be adjusted regularly. This is the second filter. 
Finally, the initiatives that are funded are carried out. This is the third filter. A successful strategy leads to initiatives that are funded and executed. A good strategy does not lead to an unprioritized wish list of activities that people want IT to carry out - it leads to funded activities that IT will do. No funding, no execution = strategy failure.

(Brutal, huh? This is probably a whole blog post on its own.)

Here's a second visual that I have been using for five years, and it still works like a charm.

Here are the talking points for this model:

When we think about technology, we need to consider many things in order to be successful. Learning, teaching and the processes that are required to operate this organization (I work in the education sector) drive our information requirements. 
Our information and process requirements drive our choice of applications to manage them. These, in turn, drive device choices. Finally, we need to ensure that we have technology infrastructure that supports the demands placed on it by all of these other things.

Sometimes, I reverse that discussion. In this case, I explain to leaders that the infrastructure is the foundation and work my way up.

It's not the icons that are important in this model - it's the layers themselves. Delete the icons and use text boxes to illustrate everything from the project portfolio, service portfolio or budget allocations. This model becomes a familiar touchstone to start any number of discussions.

These two models are incomplete simplified representations of the real world of technology that create understanding and drive productive dialogue.

They don't make me look particularly smart - but they make the people who read them feel smart, and that is what counts.

I have embedded the presentations below. Please feel free to re-use, remix and modify them to suit your needs.

(Note that this deck shows alternate builds to use to walk people through the various layers.)


  1. As someone working in IT the two documents I've most often seen presented as 'massive diagrams filled with boxes and lines, printed on plotter paper' are data models and network diagrams. These diagrams can be useful for personnel in IT and are often on the wall because that's the only place available where they can be seen in their entirety which makes them easier to understand in context. These type of documents are normally used as reference material and most I used pass the three point bullet list OP wrote after her first paragraph.

    Perhaps IT isn't trying to make anyone feel stupid but, rather, using tools they have available to make their own lives easier. If you feel stupid you might want consider that you may not be the intended audience for these diagrams.

  2. This comment has been removed by the author.