If you'd like your IT projects and department to run more efficiently and effectively, you probably need to develop a keen appreciation for the work of archaeologists. That's right, real archaeologists. 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 paintbrushes 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. Archaeologists 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 archaeologists 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 potsherd, they can often determine how the pot 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 that the makers either traveled or traded. The techniques used to make the pot show how advanced the maker's knowledge of pottery technology was. The shape and decorations often convey the use of the object. The choices made by the ancient 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 each other. 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 phenomenon 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 that 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 have 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 include 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 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 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.
- Paul Glen is author of Leading Geeks: How to Manage and Lead the People Who Deliver Technology (Jossey-Bass, 2003) and principal of C2 Consulting in Los Angeles. He can be reached at firstname.lastname@example.org.