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)
Click Here to sign up for FREE B2B / Technology newsletters!
Paul Glen is an IT management consultant and the author of the award-
winning book “Leading Geeks: How to Manage and Lead People Who Deliver
Technology” (Jossey-Bass Pfeiffer,2003). He regularly speaks for
corporations and national associations across North America. For more
information go to: http://www.paulglen.com. He can be reached at
info@paulglen.com.
