Tuesday, 28 April 2026

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.

Tuesday, 10 February 2026

Pragmatism


Friday, 2 January 2026

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.