Mantra for IT: “Participate in the process rather than confront results”

Let’s sail into a stretch of a metaphor this time. You probably know by now how much I embrace metaphors as a way to impart, often via a concrete example, ideas and concepts that are hard to grasp. So let’s go way back and talk about a metaphorical influence from long ago.

When I was in early high school, we would occasionally spend English class watching and then discussing a variety of short subject films, many of them from the fertile minds at the National Film Board of Canada.  Some of these films, described by the NFB as “socially engaged documentary”, bordered on (or transcended) the bizarre; they thus spurred all sorts of avid arguments among teenagers, easily as much as Ethan Frome or Wang Lung, the more literary staples of the curriculum that I can remember from that year.  There was one such film in particular, in fact, that has stuck with me for decades.  After some digging, I’ve finally been able to identify it by name and origin.  The researchers at the NFB have now kindly confirmed for me that the film is titled “I.B.M.”, and that it was directed by Jacques Languirand. When I reflect on it, the film’s staying power with me makes sense, since it not only features IT elements, but also serves admirably and in multiple ways as a metaphor for IT issues.

As I recall the five-minute film, it features an unchanging close-up view of an automated keypunch machine, punching out a series of IBM computer punchcards with a mysterious and incomplete common message. The film shows the cards sliding into place and getting punched, one at a time, then rolling off into the output hopper. Only parts of the full message can be read at first, since some of the letters of each word are omitted or obscured. Little by little, though, over the course of the film’s duration, each successive card that is punched contains more and more of the message, until it becomes clear at the end of the film that the text reads, “Participate in the process rather than confront results.”

Think about the wisdom and depth of that line: “Participate in the process rather than confront results.” Three ways come to mind of relating this metaphor to IT, to its role across the enterprise, and even to effective IT management of staff. They share a common aspect: the duty (and the reward) of emphasizing participation over passive observation.

  • The duty of stakeholders. Stakeholders need to be involved in any project, not look in from outside.  Note the recent and encouraging ascent in the industry of certain Agile practices that emphasize the ongoing and deep participation in a software project by its stakeholders, who provide constant input and feedback on micro as well as macro levels.  Contrast that approach with the more traditional, “over the transom”-style, one-time hand-off of supposed user requirements.  Stakeholders, take this to heart: jump in and insist on ongoing involvement in the projects you care about, otherwise the results that you eventually confront may not be entirely to your liking.
  • The duty of IT. Equally, IT needs to work on an ongoing basis as part of the business, an equal partner at the table, and not just as IT in a vacuum, reacting to what it’s given.  At its worst, I’ve seen IT become little more than “order takers” for the enterprise — relegated to asking questions that are essentially equivalent to, “oh, do you want fries with that?” and obediently scribbling down the answers.  That approach of course seems cooperative and agreeable, but in truth, treating requirements gathering that way is actually a form of neglect of one’s responsibilities to the greater good of the enterprise.  Ironically, it often leads to long-term failure rather than success.  Don’t let this happen.  Instead, IT people need to be there at every juncture, going full throttle, to challenge and to help mold requirements towards greater viability and cost-effectiveness.  Few people in the enterprise are in as good a position as IT staffers to drive out the appropriate balance between long-term and short-term considerations.  User requirements often come in without context, or without practical weighing of consequences and ripple effects, or with a failure to consider plausible alternative approaches.  Molding and fleshing out those key requirements is a long arduous process; commit yourself to participate in it.
  • The duty of leadership. Think about how you behave as an IT leader towards your employees.  Here too, do you participate in the process, or do you tend to just confront the results?  As an IT leader, it’s my obligation to resist falling into the rut of sitting back and mainly evaluating my staff on how well they’re executing.  Instead, I have to make sure that I stay actively and regularly involved in coaching, trend-setting, and occasional course correction, all (of course) without drifting into micromanagement either.  In other words, I need to focus on being a collaborator more than a critic, helping to further our collective agenda.  If I see something that isn’t working, for example, I can’t just ding my employee for the gap; instead, I need to work together with him or her to figure out the best way to regroup and move ahead.  We’re in this together, after all.  Not fully understanding or following through on this key duty, collaboration over critique, is in fact a frequent way that I’ve seen IT leaders fail.

But back to the film.  Of course, its main “gimmick” is that the message that it’s communicating isn’t clear at the beginning; it emerges into full clarity only upon successive efforts at articulating and perfecting it.  Who in IT can’t relate to that?  Think about how user requirements constantly evolve, for example, or management expectations, or even industry standards of success.  The message also reminds us of the benefits of “continuous improvement”.  Incremental and tiny improvements end up creating whole-scale shifts over time, and drive everyone to new levels of clarity and achievement.

Finally, thinking about this film helps me realize anew how far we’ve come with all those incremental technological improvements over the years.  After all, I don’t know anyone who works with punchcards anymore.

Trackbacks

  1. […] takes all the credit.  (In another context, I warned against becoming the Wizard of Oz. In yet another, I urged us all as leaders to “participate in the process, rather than just confront results.” […]

  2. […] You need to be a collaborator at least as much as a critic. Solve problems together with your team.  That doesn’t mean do their work for them, but it means actively being there, understanding the issues, and helping figure out course corrections, not merely waiting to evaluate results. […]

  3. […] You need to be a collaborator at least as much as a critic. Solve problems together with your team.  That doesn’t mean do their work for them, but it means actively being there, understanding the issues, and helping figure out course corrections, not merely waiting to evaluate results. […]

  4. […] posted myself, early and often, on myriad ways to push effectively for IT/business alignment. So I’m anything but a blind proponent for a […]

Speak Your Mind

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Mastodon