Communication - the basics of "how"

If we think about Pareto's Law in communication skills, the 80% is covered by two really crucial concerns: narratives; and adapting to an audience. Let's take the second one first.

Understanding your audience

The starting point for any communication is to understand what your target audience will actually get from what you're saying. The classic mistake here is to go into a lot of technical detail with a non-technical audience, but we can go a lot further than that.

For any meeting where you're speaking, think about who is there and what their jobs are. Get to know people and learn about what interests them.

Communicating in narratives

Terry Pratchett once said that our species should be called "Pan Narrens" - the storytelling ape. We think in terms of narratives, with start, middle and end. Our narratives can survive for thousands of years by retelling, and a memorable narrative needs structure.

Knowing that, we can structure our own communications with narrative form. Start by setting the scene and providing context. Then go on to talk about whatever is your topic. Finally, leave your audience with a conclusion (they won't remember more than 3 points normally, so try to keep your conclusion pithy).

Keep those two rules in mind - "what story am I telling?" and "what is my audience interested in?" and your message will land well and be remembered.

Communication - the 'why'

Everything that software and IT systems do is fundamentally communication, and equally everything we do as consultants is communication of some sort too.

Everything that we do as tech workers (whether we’re analysts, devs UXers, delivery or anything else) is based around communication. That’s obvious for most of the roles - we’re about talking to clients after all. But even when we’re actively writing code we’re still all about communication.

• Software is the medium by which clients communicate with their customers
• Source code is nothing more than the most rigorous possible description of the client’s business process
• Software is built by teams, working together, communicating with each other and with stakeholders
• Source code is a message that the next maintainer needs to understand
• We can’t write code until we understand what’s needed (then we need to check that’s what we’ve created)

Consultancy is communication. We are working with new people and new teams all the time. We have to know how to settle in quickly in a new environment, learn about our new co-workers and build trusting relationships with them. We are bringing new ideas from outside, and learning about how the existing teams do things - that means understanding and communicating empathically.

Career development is built on communication. All the tech skills in the world mean nothing if no one knows you have them. To build credibility you need to not only know how to do the work, but how to communicate to people that you have that knowledge.

In the next post I'll start to talk about what we can do to improve our communication and ensure our message gets across.

Pragmatism

pragmatism

noun [ U ]

UK 

 /ˈpræɡ.mə.tɪ.zəm/ US 

 /ˈpræɡ.mə.tɪ.zəm/

the quality of dealing with a problem in a sensible way that suits the conditions that really exist, rather than following fixed theories, ideas, or rules:

The council has operated much more effectively since pragmatism replaced political dogma.

(Source: https://dictionary.cambridge.org/dictionary/english/pragmatism)

Problem space partitioning

When I started to write about problem solving, one of the first things I talked about was isolating a problem by breaking the problem space down into smaller pieces. As I talked about this with people, I started to realise that intuitively knowing where the boundaries are in the problem is an important component of problem solving skill. So I started to think about how I know where the boundaries are, and how I learned to identify them.

Problem solving basics

 Problem solving is fundamental to all the work we do, but it’s not a skill that’s taught or talked about explicitly all that much. This can be a major barrier for people in their day to day work, and also in their career development. I want to address that a little by talking through some classes of problem, and problem solving techniques and strategies.

Thinking about consulting

I've been working in tech consultancy for about 25 years. I won't pretend that I've always been that good at it by my own expectations, although customers usually seem happy and that's my main criterion. In tandem for about 13 years I was studying cognitive psychology, which turned out to be more relevant than it might first appear.

In the last few years I've started to get really interested in the skillsets and mindsets associated with 'Consulting in Tech'. The constant change and need to learn very complex new skills quickly tends to attract people with a lot of cognitive flexibility and a strong drive to learn. 

In following articles I aim to explore what I think makes someone good at consulting in tech, the traits we can adopt (or improve) to do the job ever better, and why that might be important outside our day jobs. Here at the beginning of 2026 the future looks very hazy: there are massive challenges ahead for our society as we seek to adapt to climate change and resource depletion; the availability of very sophisticated AI automation tools; political conflict and increasing recognition of historical injustice; the near certainty of future pandemics and who knows how many other factors.

The future is going to need smart, adaptable problem solvers.