It *is* about the technology (and all of the other stuff too)

Photo credit: Louis Reed via Unsplash

It’s not about the technology.

Have you ever said those words? I have said them several times in my career, and heard them many more times. They are usually followed with something like . . . it’s about culture / user experience / business outcomes / customers / change management.

I think that there are good reasons to use these words, and bad reasons to use these words.

They are useful words when we are in danger of losing sight of all the other factors. When building software solutions, it is easy to get lost in the details of tools, components, services and other technical considerations. It is not unusual for technical teams to lose weeks arguing about frameworks and languages, while forgetting about the outcomes that those frameworks and languages are intended to deliver.

However, I believe that the claim that it’s not about the technology is harmful more often than it is helpful. To see why, we have to consider the context in which the claim is made. Imagine that you want to track down an example of it’s not about the technology in the wild. I would suggest that you find a meeting, virtual or otherwise, which has three important characteristics.

First, the meeting should contain a technical expertise gradient: some people who are more expert than others, and some people who are less expert. This gradient may separate people with no technology background from people with some technology background, or it may separate people who are part of the technology team, but some with less technical roles (project managers; product managers) and some with more technical roles (architects; engineers).

Second, the meeting should contain an authority gradient: some people have more authority and some people have less authority. It’s not certain, but very likely, that this gradient will run in the opposite direction to the technical expertise gradient. Outside the technology industry, few people get to be in charge on the basis of technical expertise - and few of those who do get to be in charge successfully retain that expertise.

Third, the meeting should contain some form of decision in which technical expertise is relevant. It may be a decision about funding, or resource deployment, or about priorities. It may be a decision about architecture, or standards, or the purchase of a product or service. It might be something more open ended and forward looking, such as a strategy or a statement of vision. But it must be something which matters.

This is a recipe for discomfort. The people at the top of the authority gradient carry the power to make the decision - and also carry the accountability for its consequences. The people at the top of the expertise gradient have the insight to know what the decision should be. However, they often struggle to make themselves understood, leaving the decision makers in the difficult position of making choices and inviting consequences that they don’t understand.

At this point, there is a high chance that someone will say, Of course, it’s not about the technology . . ., and everyone will feel relief. Discomfort dissipates. If it’s not about the technology, then the people without expertise don’t really need to understand the technical details. And if it’s not about the technology, then the people with expertise don’t really need to explain those details. The meeting can talk about culture, or user experience, or business outcomes, where everyone feels qualified to have an opinion, and the gradients of expertise and authority typically run in the same direction.

Unfortunately, this relief is illusory.

I believe that those of us in the technology profession do ourselves a dis-service every time we say that it’s not about the technology, because those words simply aren’t true. It is about the technology. If it wasn’t for the invention of computing then everything would be different: the organisation of companies; the way we run our lives; scientific research and exploration; global collaboration, communication and connection. Our world runs on technology, and if we choose to ignore it for the sake of relieving discomfort, then we will make bad decisions.

What should we do? We can start with one little word: just. Just is a dangerous word in the world of technology. Could you just add this feature? Could you just scale the solution for another million users? Could you just have it ready to release by Friday? But in this case it can be useful: it’s not just about the technology.

Because, when people end the sentence by saying, . . . it’s about culture / user experience / business outcomes / customers / change management, they are not entirely wrong. All of those things matter too. But they are not reasons not to care about the technology: they are reasons to care more broadly.

Once we have added that one little word, just, we need to add a lot more words. The best way to resolve the discomfort that comes from a mismatch between the authority gradient and the expertise gradient is through mutual education and respect. Technologists should not feel relieved at the idea that they don’t have to explain the technical detail: they should feel frustrated that they don’t have a chance to share their knowledge. And leaders should not feel relieved that they don’t need to understand the technical detail: they should feel frustrated that no-one is explaining it to them.

It is about the technology (and about all the other things) - and we should embrace that fact with pride, curiosity and respect.

Previous
Previous

Three reasons to learn to code

Next
Next

In software, use is better than reuse