10.10.03
 By
Paul Glen
If you’d like your IT projects and department to run more efficiently
and effectively, you probably need to develop a keen appreciation
of the work of archeologists. That’s right, real archeologists. I’m
not talking about the Indiana Jones variety of adventurous grave-robbers,
but of those men and women who spend their summers patiently digging
in the dirt with trowels, dental picks and paint brushes looking for
sticks, stones and bones.
For us, what’s important about their work isn’t the excavation
part, but what they do with the artifacts after they’ve removed them
from the site. Archeologists are students of the history of human
technology. The fundamental premise of the field is that by carefully
examining the artifacts of a past culture, we can understand the people
who made those objects. We can learn not only about how the objects
were made, but also about the ideas, values, culture and history of
those who made them. We can understand to some degree how they lived
and what they thought. |
What archeologists have recognized is that technology doesn’t exist
independently from people. In their eyes, a piece of technology is
a durable form of human expression. When they look at a pot shard
they can often determine how it was made, including where the clay
came from, what tempering was added to the clay and how it was fired.
If the clay originated far from where the object was found, it indicates
either that the makers traveled or traded. The techniques used to
make it show how advanced their knowledge of pottery technology was.
The shape and decorations often convey the use of the object. The
choices made by the pre-historic artisans offer a glimpse into their
minds and values.
This is no different from the technology coming out of any modern
IT group. The technology that you create bears the marks of your team
just as a stone ax shows the marks of an ancient flintknapper. The
technology that you create is a reflection of the individuals who
make it, the values of the makers and of the dynamics of the group.
In short, technology is the collective expression of the team that
creates it. It doesn’t exist as an entity separate from the team.
They are reflections of one another. The team often organizes itself
according to the demands of the technology and the technology is produced
through the dynamics of the team. In his book, “The Dynamics of Software
Development,” Jim McCarthy refers to this phenomena as “Team = Software.”
For example, imagine that you’re developing some sort of software
system, and you get to the system integration phase and find that
two chunks of code don’t integrate well with each other. In this situation,
you can be pretty sure that the two groups who developed those different
chunks of code don’t communicate well. In fact, they probably don’t
like each other much, either. The dynamics of the human interaction
has been expressed in the form of code.
I’m sure you’ve all seen a system in which the user interface made
perfect sense to the programmers but was completely unintelligible
to the users? Usually the interfaces on these systems reflect the
underlying structure of the code rather than the business processes
of the users. You can be assured that the cultural assumptions of
that group included the idea that understanding technology is more
important than understanding business improvement. The values of the
group are clearly expressed in the design of the interface.
Have you ever worked on a system that was beautiful to behold, but
was completely impossible to deploy and/or support? You can be pretty
sure that the group that develops such a system holds programmers
in higher esteem than deployment specialists, operations personnel
or help desk technicians. The concerns of these groups were discounted
or ignored during the design and construction. The social hierarchy
of the group is right there like a fingerprint on the neck of an Aztec
water jug.
If you pay close attention to the dynamics of your group, you’ll probably
be able to predict what your technology will look like long before
the money is spent developing and deploying it -- and maybe your work
will live on rather than being dug up by some future archaeologist.
(This article originally appeared in Computerworld, Computerworld
Australia, and IT World Canada)
About the Author:
Paul Glen is the author of "Leading Geeks: How to Manage and Lead
People Who Deliver Technology" (Jossey Bass Pfeiffer, 2002) and Principal
of C2 Consulting. C2 Consulting helps clients build effective technology
organizations. Paul Glen regularly speaks for corporations and national
associations across North America. For more information go to http://www.c2-consulting.com.
He can be reached at info@c2-consulting.com.
Read this newsletter at: http://www.ctoupdate.com/2003/1010.html |
|
| From
the Forum: |
| Sharing printer w/ 2 comp. |
I am running 2 computers with windows 2000 professional installed and I am trying to share my HP1000 printer between the 2 computers...
|
|
|
