Sunday 3 April 2022

Speaking the right language

We've been deep in discussion around the way for a technology department to talk to the rest of the organisation - going into enough detail to engage in a conversation, but also keeping it interesting enough that they want to.

We've got a drill, and we think it will help. It's a Bosch, developed to the highest standards of German engineering. It is a hammer/drill with an 18V brushless motor, able to deliver over 110Nm torque with 0 - 31,500bpm and variable speed and power with a precision clutch. Also, good news! It only weighs 1.6kg (without the battery), has KickBack Control and can connect to the Toolbox App for customisation. And our other tools are also made by Bosch, which helps. Actually we have a few drills - we could go into detail about the others too?

Of course what they actually WANT is a hole, measuring 15mm diameter, created on the correct day...

It is no secret that we technologists speak our own language, and people talk about "learning the language" in order to understand the technology department. However, it is really our responsibility as technologists (and especially those in positions of leadership in technology) to solve this problem. We need to go to our colleagues, not expect them to learn our world. In tech, the thing we're delivering is a piece of technology and so when we talk about our work it is easy to end up talking about that thing. But the technology is worthless in a vacuum - we are working on it about it because it solves a problem and it is in that context we should be engaging with others. That is where the common language sits, and we can do the "translation" ourselves. We should talk about what the best hole looks like, rather than how we drill it.

This isn't to say all aspects of technical service providing should be hidden. That approach makes it very hard to talk about the complexities of maintenance or incident management - areas often ignored by the wider organisation. But even in these spaces we can talk about the problem space rather than the solution. We can talk about the desire for uptime, and online engagement patterns as ways to make deployment and incident resolution matter in context. We can talk about the organisation's need to be secure and be able to easily implement new business processes as context for explaining the need for maintenance and upgrade work. Again, stepping into the business context when communicating outside the technology department.

Furthermore, it's important the technical department shows its hand so decisions are made transparently, else the technologists end up hidden away in a shadowy corner making decisions nobody understands. This is not good for trust, as technology becomes something that is done to the wider organisation, rather than part of collaborative problem solving. Building open trust is important, however it can also put technology at a disadvantage - the greater need for transparency can easily end up morphing into a greater need to justify activities compared to other departments.

Discussions about technical decision making should be something that is available for those who want it, rather than the barrier to entry for any engagement with the technology department. There needs to be a clear and positive division between "you need to know this bit" and "you are welcome to engage with this bit if you want". This is especially important in this increasingly digital world where "engaging with the technology department" is analogous to "delivering any major project". It is our responsibility to make sure we are positive partners.

Couple of disclaimers - the drill / hole analogy is not mine, it has been around forever. And I know very little about drills.

No comments: