Posted by j.laird on 2 December 2020 - 9:30am

Photo by J A N U P R A S A D on Unsplash

By SSI Fellow Sorrel Harriet.

This article has 3 aims:

1) To offer a broad definition of coaching in the software development context.
2) To explain why coaching is relevant to software engineers, particularly those who are engaging in collaborative software development, and how it relates to software sustainability.
3) To (hopefully) convince some readers to become involved in a new coaching initiative aimed at academics and RSEs.

First off…

What is a coach?

A coach is someone who can help you and your team become better at solving your own problems. They do this by challenging your entrenched patterns of thinking and encouraging you to examine a problem from different angles and perspectives. The kind of problems a coach can help with include (but are not limited to) resolving dysfunctionalities in a team, mending unfit or poorly applied processes, creating a culture of learning and improving, and supporting individuals to identify and realise their development goals.

Coaching recognises that a team of professionals can be reduced down to a group of individuals, each bringing their own unique set of experiences to the mix. It is consistent with a person-centred approach to leadership; one which trusts and empowers the individuals who make up a team to make good choices and create their own solutions.

What does coaching involve?

There are many flavours of coaching and many contexts in which it can be applied. In this article I will avoid giving too much focus to any particular type of coaching, since many of the techniques used by coaches are universal. Perhaps most significant in the coach’s toolkit are questions. Coaches use questioning to unlock learning, whether at the level of the organisation, team or individual. By practising committed listening and asking powerful questions, a coach can help the learner(s) see themselves and their situation from different angles, gaining new insights that can lead to solutions.

What a coach is not

A coach is not there to solve your problems or to impart their own life experience, nor are they a mentor. To appreciate the difference between a coach and a mentor, I find the following analogy helpful.

Imagine you’re trying to climb a mountain in the dark. Your mentor is that person at the top of the mountain, guiding you onward from their superior vantage point. The mentor can see things you can’t because they’ve been there before. They’ll speak from their own experience which can at times be valuable and at other times limited. After all, they are not you, and they aren’t making their journey now. They have different strengths and weaknesses and have faced different obstacles under different conditions.

And the coach? The coach is there on the side of the mountain with you. They’re the one holding the flashlight for you, illuminating the landscape around you, but never instructing you where to go next. When you find yourself stuck, they’ll shine a light on your next foothold.

Both of these roles are valuable and can complement one another.

Another thing a coach is not is a therapist. A coach is not there to rake over the past, or to perform root cause analysis on your most personal issues. At times a coach may use cognitive behavioural techniques to challenge unhelpful behaviours and patterns of thinking, but they will not attempt to psychoanalyse or ‘treat’ you. A good coach will recognise when a problem needs a therapeutic intervention and will recommend alternatives.

Ok, but how is this relevant to software engineering?

Two reasons why coaching can be a valuable tool for software teams:

1. We are all human beings

Many of us make a conscious decision to draw a dividing line between our personal and professional lives. In our professional lives, we tend to value objectivity over subjectivity, and will respect rational behaviour over emotional behaviour. While this is a perfectly reasonable goal, in practice, we can never truly separate these aspects of our lives. When you turn up to work each day, (or enter your home office), you bring with you your whole self. Everything you do, every interaction you have, is inevitably coloured by your life experiences.

Now, in the academic sphere, the boundaries are often even more blurry due to the tendency for work to consume our every waking moment. This is not a good thing, but it’s a topic for another day! The point is, when you’re operating under high levels of stress for prolonged periods of time, the work-life boundaries become even more fragile. It’s much harder to maintain objectivity and rationality while the cortisol and adrenalin are constantly pumping.

So let’s stop trying to be ‘beyond human’, and learn that it’s OK to acknowledge those parts of yourself you’d rather leave at home. Acknowledging them does not mean you have to give them floor space.

2. Software development is a social activity

Let’s also recognise that collaborative software development is a social activity. It is an action taken by a group of people, aimed at solving a problem and generating impact. We can achieve greater impact when there is social cohesion between members of the group, and a culture that supports open communication, inspection and continuous learning and improvement. If this sounds like a war cry for everyone to adopt agile, it’s really not — just ask a social anthropologist.

And software sustainability??

The final point I will make about coaching brings us to the topic of software sustainability. In a recent study, in which I explored the impact of project management and process on research software project success (publication pending), I made the point that software projects are, to some extent, successful by default, by virtue of the fact the money is in the bank before a line of code is ever written (slight exaggeration, but you take my point). However, if we only ever judge success by looking at the project in isolation, we may be missing half the picture. I believe we need to look beyond the software output from one project, to the future of that software and the team who created it. Software is more likely to endure if the people who make it work well together and follow robust processes. There is so much software waste in academia, some of which is necessary, and some of which is undesirable. Strong teams are better placed to develop good quality, extensible software that has a future beyond the project it was originally designed for.

Convinced yet?

If you are coaching-curious as a result of reading this article, please consider registering your interest in a coaching initiative founded by Sorrel Harriet and David Pérez-Suárez on behalf of the SSI.