Can anyone be coached?

"You know, Tom. Not everyone can be coached."

This was said to me some time ago when I was discussing my experiences coaching / mentoring people and how some had moved forward, but others had not. It has been playing on my mind since.

It is rare anyone who knows me would describe me as an optimist. However, in this one area I think I am overly positive - possibly to the point of naivety. I generally believe that with some effort, most people can pick up most things. Sure, there are specific skills which might be problematic (I suspect that I would never be a halfway decent footballer, regardless of effort) but in the main, I think people can learn how to lead teams, write strategy, write code, and so on. But is this true?

I am a great believer in the power of mentoring. I spend a lot of my own time doing this, both in work and outside, and I am pleased to have seen people grow in their career, confidence, skills and so on. In fact, a year ago I wrote a post talking about how important it is and challenging others to do more. I stand by that.

But mentoring takes time, time is finite, and I certainly can see that some engagements have been more effective than others. When the diary is full, I certainly want to be prioritising my own time effectively and consider whether the effort spent on an individual is well invested or would be better spent elsewhere. Mentoring / coaching is a partnership - all the help in the world is worthless if the mentee is not willing to take that advice and run with it in order to grow.

This is the important question: is the coaching relationship ready, and does it justify the time? Especially important if, like me, you mostly do mentoring for free through org schemes or recommendations. Plus, of course, recognising that this is always a point-in-time assessment - people can become ready over time (or stop being).

A "ready" coaching relationship can come in many forms, but I think there are some common elements.

Honesty and trust, possibly into discomfort

Psychological safety is the most important element. Coaching should go deep. It should be a space safe enough to be open and vulnerable, and discuss things that may not come up with colleagues. It also means being able to discuss half-formed ideas - not everything needs to be thought through before airing it.

This trust and safety is important for the next part. The point of coaching is to enable growth, so the person being coached needs to challenge their own assumptions and sometimes consider direct challenge from the coach. This can be quite uncomfortable, so the environment needs to support riding that out as gently as possible.

Clear understanding of purpose

Conversations can be far more directed if we know why we're meeting. Do you want to discuss situations that have come up in your current role? Do you want to progress, and are we talking about what that might mean? The specific reason doesn't matter, but having a common understanding is essential.

Commitment

This is fairly obvious - coaching is a time commitment for both parties, and both need to respect this, including the admin burden for setting it up. If it is not a paid engagement (ie the coach is offering their time for free), I prefer the coached person to take the lead. As well as handling the admin, it also signals enthusiasm and desire to continue.

This also extends to preparing for a session. The coach will be reviewing notes and considering next steps. The recipient should be thinking about what they want to discuss and coming ready with some conversation in mind. I've seen some coaches use pre-session questions to prompt thinking. This seems like a good way to create focus for the session.

Evidence of change leading to them not needing you

I don't feel this last point is as important as the others - or rather it is considerably more nebulous. Successful coaching should have some kind of result, but the nature of that result is certainly not set in stone. Similarly, while in general the coached person should be growing to no longer need the coaching that is not universally true depending on the engagement.

The purpose of coaching is progress, but progress can mean different things - maybe insight, acceptance, or practical change. The key is that the engagement is generating some kind of value.

So, can anyone be coached?

So, back to the exam question. Can anyone be coached? I still think the answer is yes, but with careful consideration of the effort required.

If you are running a scholarship fund, you can support anyone. However, some people are more in need than others, and some will make better use of the opportunity than others. There are finite resources, so a value judgement has to be made. This is the same with coaching - your time is finite and the decision to expend that resource should be treated with similar care.

Maybe the first element of coaching is inward-looking to recognise the value of one's own time.

---

I do realise I've used "coach" and "mentor" somewhat interchangeably in this post, and this is incorrect. In my experience, a blend of the two approaches helps both to encourage self-reflection and provide some direct answers.

What skills should I develop?

Recently I had the pleasure of spending time with some postdocs from my old university, helping those of them considering leaving academia to prepare for job interviews and generally think about how they can position themselves for success in their future careers. The conversation got around to the core skills that everyone should develop, and they expressed some surprise at the things I pulled out - the same reactions I've had from software engineers when having the same conversation - so I thought it worth writing them down. In no particular order, these are they.

Writing

Like it or not, we end up writing a lot and I've found this only gets more true with seniority. Whether it is the ever-growing mountains of email, papers laying out a plan or strategy, or presentations we're going to be writing something down and we need to be both good at it and fluent enough to knock out quality documents at speed. The brutal truth is that people will judge you if your writing is incoherent and / or full of spelling and grammatical mistakes - developing a writing style is one of many tiny ways we can position ourselves as competent and helpful.

Writing at speed is key. Workloads just keep growing and, assuming you want to stay ahead, you'll need to move "writing a strategic document" from the sort of task where you put aside a month of thinking time to something you just do between other work. In more detail, that means having a writing process (and being able to deal with a blank page) and getting a feel for what "good enough" looks like for the different types of docs. This only comes from experience so I always recommend practising writing to everyone, whatever career stage they are in. I write this blog and I've kept a one-post-per-month routine since 2016 as a discipline to force me to keep writing and thinking about how I lay out my thoughts. Is it annoying? Yes, of course. But, while there is definitely much room for improvement, I feel much more confident writing quickly these days. In fact, I wrote a post about why I write a blog a few years ago.

Presenting

Second in the list of skills people don't want to develop but really should, we have presenting. Presenting comes in two forms - putting forward an idea to a room full of people (ie some variation of speaking to a PowerPoint) and something more freeform (ie speaking off the cuff to a room of people). These are different skills and both need practising. You will, at some point, need to present and ideally the first time you do this you aren't trying to secure funding from the investment board or explaining to the trustees / shareholders your five year vision. Like any skill, this takes practise to improve.

Earlier in my career I ran a fortnightly Show & Tell event which was a low-stakes way of getting people to do presentations and we all learned a great deal of confidence and technique through this. Again, I wrote a post on why Show & Tell really helped some years ago and I stand by all of that.

Talking off the cuff can be harder to practise, but when you end up chairing meetings or just the most senior person in the room you can be sure people will look to you to fill time when other people are setting up. Ideally we learn to stop using crutch or filler words and then we just sound ... smooth? I gained experience by chairing Show & Tell for many years - I think there is a useful lesson there about forcing oneself out of the comfort zone to develop new skills.

Storytelling

This one underpins both writing and presenting. When we reach out to people, we are usually either conveying information or attempting to persuade them of something. In either case we, presumably, want them to listen and understand what we are saying so we need to learn how to be compelling. We need to be able to tell a sensible, well-structured story understanding our audience and how to reach them. This is a hard skill to develop and really only comes through practising the above, and getting feedback. Alternatively, you could run some Dungeons & Dragons. Seriously!

Reading

Rather obviously, if we want to get on we need to be able to read. However, less obviously, as one climbs the hierarchy the amount of reading just goes up and up. Whether it's board papers, strategy documents or yet more email the torrent never ends and I've found that the more senior I get, the more people think that long = good. Reading fast and accurately is a skill that like everything else needs developing. Of everything on here, I find this one hardest. I find focusing on piles of tedious papers next to impossible so I have had to develop various skills to take a run at it. For me, I find the best approach to maintain focus is to take notes - or ideally annotate the papers. I've been using a Remarkable as an alternative to unending printing. I need a semi-controlled environment, with no alerts or distractions and some appropriate music and if these are updates I need to add a narrative to make me lock into the information - ie ask and answer "why am I reading this?" beyond "because I have to".

You can also ask an appropriate AI to summarise papers but don't come to me the first time it gets it completely wrong.

Basic numeracy

Believe it or not, numbers are important. Sorry. Far too many people haven't developed basic mental arithmetic skills and this creates situations where they are pulling out calculators to add two numbers together. While this is slow, and burns time you likely don't have, there is a more important aspect to basic numeracy. We all need a basic feel for numbers to be able to spot mistakes in budgets or other detailed documents. We need to be able to see 143 x 6 = 1200 and immediately get that mental nudge that says something isn't right even if we don't know what "right" is.

Again, practice makes perfect. I typically add up my shopping as I walk around the supermarket and see how close I am when I scan at the till - this helps keep me fluent at juggling numbers in my head. As a child I learned my multiplication tables and some of the simple tricks for approximating sums. For example, here 143 is approx 150, and that multiplies easily so in my head I go 143x6 => 150x6 => 300x3 = 900 so I'm expecting something a bit under 900. Thus 1200 is immediately a warning bell that someone has math'd wrong or something isn't right in the spreadsheet formulae. I cannot stress enough how many budget errors I've caught this way.

Using your tools - Word / Excel

Computers are a pain, but they are an essential pain. Do we know how to use PowerPoint? Or Word? Do we know when we should be using each tool? Similarly, learn the keyboard shortcuts. They help so much, both within an application and also when moving information between them. Don't forget Excel - and learn to use simple formulae for managing data. If it helps, using formulae will make maths mistakes less likely!

There is an even more basic computer skill. Can we type fast and accurately - and ideally touch-type? There are "proper" ways to touch-type and ways to learn these techniques, however personally I learned to type via brute force playing online games in the late '90s where you communicated by text and either typed fast or stayed silent. This is no longer an option, so instead get writing those blog posts (from "writing" above).

If you're in Tech you're likely thinking this section is really easy buuuut I know a lot of software engineers who stick to code and don't really develop these basic skills then find themselves very slow when asked to do "normal" things.

These days I will argue that getting familiar with AI and interacting with a prompt in something like ChatGPT is also a core skill. This is more vague, and your workplace will no doubt have policies around this, but like learning Excel / Word / PowerPoint it comes down to having some idea of the capabilities of your fingertips.

Interview technique

Everyone sane hates interviews. I'll be honest, I hate being on the other side of the table too. However, we all need to learn the basics of interviews. Learn what a competency question is and the mystic secrets of STAR answers and we have a framework for preparing for an interview. Then we learn to talk off the cuff and learn to tell a story (both above!) and we can fill in the gaps. Then get a job you like so you don't have to do them very often...

And lo, this is my list of the absolute basics. When I go through this list with people, most folk start with "yeah that's really obvious" then some slow enlightenment dawns as we drill in to each point. There are specific skills here, and we need to develop them with some deliberate action. There are also books on most of these areas (while I list these as "basic" I'm well aware that they all have the potential to be incredibly skilled and I don't mean to diminish the experts in these spaces) and there are certainly a couple missing (eg basic design - that is making your presentations / documents look not-horrible). I also skipped anything about basic time management or leadership skills as, for me, these are beyond the absolute basics. In my experience, we all neglect at least one (and likely many) of these areas and this will create issues. So I encourage everyone to deliberately practice writing, speaking, reading, telling a story, counting, computering and interviewing. It's an incredibly basic list, and that is why we often don't think about them.

When to mentor

I've been thinking again about mentoring. When is the right point to consider the challenge of mentoring someone? When does one know enough? When should one offer oneself as a mentor, without it coming across as seriously arrogant?

The answer is, of course, never. A mentor is calm, wise, and has seen it all before. They can easily understand everything that could possibly come up, have a very clear plan in place immediately and be able to take a mentee forward through any situation. Does this sound like me / you? Really? Plus, let's face it, if I / you know it then it's pretty obvious and can't possibly be worth offering to someone else.

Or at least that's what The Voices say to me every time I think about this. This is, of course, nonsense.

So what is the real answer? When is the right time to help those with less experience? Now. It doesn't matter what experience you have - it is more than some people. Sure, over time that number will increase and more folk will benefit from hearing from you, but you already know something that is unique and worth telling others. Mid-level developer? Plenty of people coming through the junior levels who need to learn from you. "Only" a junior? Well, there are plenty of people who are just starting out and have no experience at all.

This is before we get to the value of mentoring to you. Similarly to writing a blog, there is a discipline in structuring ideas and then clearly talking through ideas and concepts in a way someone else can understand them and like any form of teaching, one needs an extra level of understanding to be able to talk about a concept in this way. It is essential for a leader to be able to articulate their thinking clearly in order to bring others along with them. It is also very important to be able to think clearly on the fly - such as when people can drop awkward topics of discussion on you at any time.

As an aside, I really don't like the term "mentor" - or rather I don't like thinking of someone as "my mentee" because of the implied power dynamic there. I would say I don't have any mentees, but there are plenty of people who would disagree with that.

Ok, so how does one offer mentoring without sounding deeply arrogant? The easiest route, I think, is by offering to a group who are already in a place to be receptive, and maybe linked to individual topics you know you can claim some expertise. I've recently seen someone I respect offering consultation around salary negotiations. This is a form of targeted mentoring, and in a field she is visibly knowledgeable. 

As I said above, I already do some mentoring however my new year resolutions included giving more back to this industry. So I'm going to do two things. 

Firstly, if anyone is reading this and wants a chat about the tech industry - in particular technical leadership, moving from a technical job to a leadership role, the role of technical knowledge in the strategic / leadership space or similar - then please do reach out on LinkedIn or Twitter. I am also open to speaking to groups (which is whole different post).

Secondly, I'm going to make this same offer in an engineering leadership Slack which is filled with people I don't know. That idea scares me ... we'll see what happens.

An important caveat here. I know there are qualified coaches, mentors and so on. I am not that. I am simply someone who has been around a bit.

Anyway, I'm going to do something here and I challenge you, dear reader, to do so too. The important thing is that there is always something one can offer to others who are looking to learn. And there is always something one can learn from someone else. We all can find value by listening to and learning from each other.

Looking to the future

One of the symptoms of seniority that I still struggle to process is this idea that people want to hear what I have to say and understand how they can (professionally at least) be me. It's a weird feeling, both humbling and frightening, and has only grown in the last few months. I'm being asked to speak at conferences, and in a few weeks I'm on a panel discussing the future of the Tech industry. Why? Surely there is someone better for this?

Honestly, this is a question I've been asking myself since my time in the Civil Service, where I found myself in a meeting discussing how to spend five million pounds of public money. I should write a post about getting over myself and getting on with it. This, however, is not that post.

I moved away from development into management so I could make a difference to the industry. How do people get into Tech? How do people move to more senior technical roles? Showing the importance of senior leadership with technical backgrounds, and helping people get the right experience to be credible candidates. These are core to my motivation and it seems I have the beginning of a platform. This is a responsibility I want to take seriously. What can I offer to the wider industry?

I've got a few ideas and since there seems to be a few people reading this blog from LinkedIn, I suppose I can offer them up. First and foremost, I'm thinking of creating a set of interviews with people in my position telling their story, talking about how they got to where they are today. I don't kid myself that I'm some kind of Steve Jobs or Bill Gates, but then neither are the overwhelming majority of people. I am, however, fairly successful in the industry. I'm in a position that someone getting into Tech can reasonably aspire to attain. Not inspirational perhaps, but practical. There are lots of people like me, and the stories don't get told often enough so I like the idea of creating some kind of resource showing the different paths people can take. At the moment I'm thinking a podcast, but format to be decided. If you're reading this and think it's an interesting or useful idea, please do reach out.

In addition, I sit on the London Data Board, and I'm happy to offer some time to support other initiatives if they come up. Again, do reach out - especially if they are something to do with nature or animals. On top of this, I already do some mentoring, and I've got a whole post about that coming up soon.

I opened saying that people asking about my career and how to "be me" is weird. Actually, on reflection, it's a weirder feeling that I'm in a position to be feeling a sense of responsibility to the industry and asking any of the above questions. It's a great privilege to be working somewhere where I can spend some time looking outwards and hopefully make a difference. That's my intention anyway - so I've written it down in public so I can hold myself to account.

Time should wait for all men

Occasionally, I am asked what I consider the most important part of being a leader. There are lots of good answers for this - vision, transparency, pragmatism, empathy, competence, spreadsheets, blah, blah.

The answer I always give is "making time for people".

I've written before and at length about how as a leader the people around you are your most important resource, asset, capability, etc. Find good people, set a clear direction, give them space to be good at what they do, trust them and the results follow. But there is always more to do than can be done, so when you've been in the office for ten hours a day for a week or longer and just want to cut it all back what is the last thing to drop?

Over the years some of the most negative feedback I've received is from colleagues questioning why I spend so much time talking to people. Why spend the time face to face? You're wasting your and their time with something that could be sorted out via email.

This is very true - email refines communication down to the words only and that can be very short and to the point. However, much like boiling vegetables can remove most of the benefit of eating them, it removes most of what matters when talking to someone - the opportunity to create a connection. It might be noticing that someone has a problem that can be solved, asking about their new child, hearing something that frustrates them in the office and gives a better appreciation of the environment in which they are working or one of a million other cues. As a manager you can spot the signs of stress or anxiety and help alleviate them. If I were to think in purely mercenary terms, I can't think of many times I've invested time in a relationship and not seen an extremely favourable rate of return.

My director is very good at this - I know he is very busy, but on the occasions when I need to talk to him in urgency he always makes time for me. Our unspoken pact is that I don't bother him unless it's very important and he respects my judgement for when that is. This is built on the back of a strong relationship of (I believe) mutual respect which comes from - yes - making time to talk and drink coffee together.

Simply giving people time can improve their confidence and effectiveness. By making time for me, my director has learnt he can trust me on a long leash and as a result he's getting a significant return in his investment in terms of my effort. In turn, I feel confident that he respects my ability to make decisions - so I feel empowered to keep making them, which makes me more effective.

Moving away from the cold mathematics of relationship building, the welcoming and humanising effects of making time for people can't be underestimated. Everyone has a story to tell and most rarely get to tell it - especially to someone who is in a position of authority. It's extremely empowering to think that the person in charge knows who you are and cares that you're getting on. If that person is you, it's on you to share the love.

There is a danger, of course. A leader needs to be able to control their time so they can still deliver things and there is too much of a good thing. Far more significantly, if too much time is spent with others and the pressure of individual delivery is mounting it is all too easy to spend time talking while also answering email or doing other work. This is utter poison - if you're going to make time for someone, do it properly. If you're not going to be present then don't bother - it's more demeaning to watch someone write email and not listen than it is to just not meet at all.

There is a lot that can be written about the cold logic of this but it devalues the humanity to define relationship building by what one can get out of the deal. We spent a frightening amount of our waking adult life in work and in my opinion it does a huge disservice to everyone involved if that time is just about raw output - we're not just in work to work. For most of us, it's the source of most of our human contact and community throughout our adult life so it's worth putting in the effort.

Magic happens

I use the phrase "magic happens" quite frequently when giving an overview of something technical. For example, if I'm trying to explain the concept of the client / server model I might talk about how a web request is routed from a client to a server where magic happens and some HTML is returned as a response. This isn't supposed to be condescending - it's a shorthand for "this is a black box where something else is going on, but talking about it will draw our focus away from the thing we're talking about here". Unremarkable, but the phrase got stuck in my head the other day and while turning it over it made me think about how learning has changed for developers.

When I was starting as a developer I hated magic. I dug into these black boxes and learned a great deal around the problem until I had a good working knowledge of hosting, networking, etc etc. At the time, you pretty much had to learn this stuff to get a decent local dev environment running. This was before frameworks like Rails made it relatively easy to run up a complete environment with a couple of console commands, and a long time before cloud hosts like Heroku allowed the application to be run in the wild with little more effort. Consequently, there was a huge technical barrier to entry for those learning to program. A barrier that now much lower.

This is in no way a post about how the kids today have it easy, or any other such nonsense. It's a musing on what new developers are learning and what that means for the older generation when it comes to mentoring the next generations (amusingly, my spellcheck wants that to read "tormenting the next generations"). It is now conceivable to have reasonably experienced developers (ie not juniors) who are highly competent, having worked in Rails environments pushed to cloud hosting, who have never had to worry about how anything under that works. No knowledge of linux, networking or other things from the sysadmin world. This has a significant impact on debugging problems and system design, which has a knock-on effect on production costs, maintenance and out of hours support rotas.

On the other hand, and before us more experienced folk feel smug, this focused learning means these developers are likely far better at the core language than we were at the same level of experience. If true, they will be better at their jobs than we were (for a narrow definition of "better", granted). However, it will also stunt career progress as a developer wanting to take the lead in designing or building a system generally needs a wider understanding of the subject area. Skills I learned early on were far less useful while I was a mid-level developer but that knowledge was pretty much essential when I moved into more senior work. This is a key area where our responsibility as more senior people comes in - it's not just juniors who need space to learn things.

In my experience, there is another benefit of this focused learning. Good developers who have learned their particular subject in-depth are aware of the edges of their knowledge. They are aware where, for them, "magic happens", and are capable of explaining that well. I'm not advocating siloed thinking or working, but learning how to define and articulate your problem space is an important skill as a developer - one that people who know everything (sigh) sometimes fail at. It's particularly helpful when discussing work and solutions with other, non-technical disciplines such as product and delivery managers.

Also worth remembering is that we learned around the subject out of necessity and back then it was much easier to get a really solid overview of everything. "Everything" has context of course - how many of us studied machine code, chip architecture and instruction sets, memory rings and so on? Some did, of course, but by no means all. Our window of learning took in what we needed. These days there are many more layers of abstraction in the hosting world as well as many more layers of complexity with SCSS processors, Javascript frameworks and transpilation, and on and on and on. The world today is far more complicated and while we may (MAY) have kept pace with new innovations, that is not the same thing as learning it all at once - especially since change continues to happen.

I have a feeling we're going to be seeing a lot more magic happening as the industry matures. We'll have more black boxes and more abstraction of important concepts - indeed making use magic components is a core part of cost saving strategies. Why on earth would you run up your own virtualisation environment when services like Linode exists, for instance? We are going to need to be increasingly aware of how we talk about technology - not just to those outside our discipline, but to those inside too. We're going to need to put an increasing amount of effort into making sure the next generation can get on - either by learning what they need around the subject, or by shaping our organisations to celebrate the new learning.