I often hear complaints about how unmotivated technical groups can be, but managers sometimes seem to miss some of the most important opportunities to create an environment in which motivation can grow.
As best I can tell, this is deeply rooted in our backgrounds as engineers. Most IT managers start out as technicians, so we are steeped in the world of facts. We search for them. We love them. We live and die by them. They are our bedrock. But we are so enamored of the facts of our work that we sometimes forget to explicitly speak of its meaning. We assume either that the facts of our work are the meaning or that the connection is so self-evident that we never need discuss it.
But the meaning of the work can be one of the most important sources of motivation for a group.
For example, a few years ago, I attended a meeting and listened to a presentation from the CIO of UNICEF, the United Nations Children's Fund. He was talking about the work his staff was doing, setting up satellite-network nodes in countries around the world. His description of the facts of the group's work seemed rather grim. I imagined what it might be like to be part of his team.
The work seemed pretty repetitive: setting up the same network equipment over and over again. The pay was probably poor, since it was through the UN. The travel sounded relentless: People were likely on the road for weeks or months at a time, and they weren't traveling to the garden spots of the world. In fact, many of these installations were being done in war zones, so the work might occasionally entail being shot at.
The facts of this job seemed remarkably unappealing: poor pay, boring work, isolation from family, and dangerous conditions. Why would anyone want to do it? Perhaps for every network node installed, 100,000 children have a chance to eat. If that's the answer, it's worth it.
In this case, the facts and the meaning of the work are completely different things. The facts seem like excellent de-motivators, while the meaning is extraordinarily compelling.
Of course, not every project offers such rich opportunity to explore meaning. If the goal of your project is to reduce inventory costs by one-eighth of a percentage point, don't expect people to weep in ecstasy during the rollout. Sometimes you have to look for motivation elsewhere.
So, how do you know if you're thinking about the facts or the meaning of your work? Here's one way to look at it:
Facts are simple points. They're cold and lifeless. They just lie on the page and express some simple truth.
Meaning requires a more narrative structure. There are characters -- people who inhabit the narrative. There's action -- things that happen to the characters, or could happen. There are settings -- spaces where the action happens. And there's transformation, internal and external. The heroes struggle, and the villains suffer.
In the narrative form, facts come alive and are woven into the story line. They support the larger structure and are thereby imbued with meaning. Here, a project is no longer just a series of tasks lying dead on a Gantt chart. It's a heroic story with a theme and lessons.
So next time you wonder why your group seems unmotivated, ask whether people have a sense of more than just the facts of their work. Ask what they think it means, and you may find that everyone has a different idea. But just having them think and talk about the meaning can be a step toward deeper motivation and engagement.
Paul Glen is the founder of the GeekLeaders.com Web community and author of the award-winning book Leading Geeks: How to Manage and Lead People Who Deliver Technology (Jossey-Bass, 2003). Contact him at firstname.lastname@example.org.