Fun with email

I have a love / hate relationship with the cliche "work smarter, not harder". On the one hand, as a technologist it forms the core of so much of how I approach problems. "I don't like this weekly task" leads to "how do I standardise this to think less?" then "now it's standard, can I automate it?". Then, much later "how does this script work again?" but I'm going to ignore this last step.

On the other hand, when it's said out loud it tends to be by people who are responsible for pushing too much work on to the individual, then sidestepping said responsibility when it comes time to actually help them out. Often with a side-dose of being too stupid to actually provide the "smarts" to lighten the load.

With this in mind, I want to think a little about collective efficiency, and how we can all help each other out when it comes to email.

When I was a starry-eyed, enthusiastic developer at the bottom of the social totem pole, I learned to hate the "I have a reckon" emails. Typically, someone would dash off a half-thought about some kind of feature development in about 2 minutes and send them over. I would then have to spend half an hour working out what they actually wanted then another couple of hours writing some kind of considered response (usually attempting to shut down this idea). That's the afternoon gone, immediately. Thanks, important person.

Now I'm In Leadership I try very hard to avoid this kind of email. I try to create an environment wherein I can answer my own questions, without bothering people who have better things to do than answer my questions. If I DO need to ask someone something, then I do my best to ask a clear, answerable question to help the victim / recipient spend as little time as possible on me.

So - linking to the original point about working smarter. Everyone knows that at work you aren't working alone, you are part of a team. It is not you that needs to be efficient - it is the ecosystem. If you're highly productive, but you're wasting your colleagues' time, energy or will to live then you are causing a problem for the collective. This is true from large actions (eg how one manages a project) through to the tiny (eg sending terrible email).

But this is more than simply unnecessary email. When one sends an email, the context is all in the head of the author. If the recipient has to spend time actually working out this context, that is time thinking which is going to be far longer than time spent writing. Even worse, if it is forwarding a conversation thread so the recipient also has to read a multi-step conversation between two people with little to no context. Oh, and of course the thread contains 30 page attachment too. Because why not at this point.

So, the original email is "what do you think?" - 20 seconds work on the part of the sender. The recipient can take half an hour or more getting through the information to come to the answer "err ... about what?". Now, consider that the recipient is actually five people. That time multiplies up very quickly.

Imagine instead that the original sender spent a bit more time summarising the content and asking a clear question. Maybe a whole hour? That's a long time to spend on an email, but this is one hour with five two minute responses for a total of 70 minutes from the wider "work ecosystem". In the original example, it's 120 minutes from the ecosystem as well as five rather irritated recipients. This is without mentioning that tying you up for the time you are writing a better initial email prevents you causing damage anywhere else...

So that's email. Now let's talk about booking meetings without causing diary conflicts...

(From Oracle Calendar - screenshot from back in 2011 - apparently I have been irritable for a long time)

"Gosh, that is an inane post" I hear some people crying. Yes and no. While the email example and numbers are clearly fabricated, this is a real problem. I've written before about writing well being a highly important skill and this is a variation of my usual comments, going beyond "clearer communication" into efficiency. As leaders, it's important to consider how much damage our actions can cause without any intent or us even realising. Our role is to empower our people to be the best they can be, and being considerate of their time and helping them be on the front foot is an important part of this.

I believe someone once wrote "do the hard work to make things simple"!

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.