Things I’ve Learned As a Coach
31 May 2018 |
Chris Wintle | About a 6 minute read
Being a professional coach is a weird job, whatever field you’re in. Before I came to AND Digital, I spent my whole career in delivery-focused roles, then I suddenly found myself outside of the delivery cycle, acting in a supporting role. It was certainly a jarring, but welcome shift , and it’s taught me a lot of useful lessons.
Over the last 2 years or so, I’ve slowly morphed from a pure Technical Coach, to become more of a catch-all Tech-AND-Agile Coach. This has allowed me to learn even more by coming at problems from several angles, so I thought i’d share a few things i’ve learned during my time as a Coach:
You have to measure impact, or you go insane
Coaching is one of those strange roles where it can sometimes be really hard to measure whether you’re having a positive impact. There’ll usually be smaller-scale examples where it’s easy to see that you’ve had a net positive effect on something,which can be as simple as someone saying “thanks, that was helpful”. On a larger scale, however, it can be hard to measure whether that’s the case.
Coaching a team or individual could take months to actually reap any benefits, or the benefits could be invisible!
This has two nasty side-effects as a coach; firstly, it drastically limits your ability to have a meaningful feedback loop when you’re unsure whether or not things are changing for the better, and if so, why.
Secondly, as someone that thrives on problem solving and helping people, it can be incredibly frustrating and demotivating to think that you’re not actually helping things.
Luckily, this is where data comes to the rescue. At AND Digital we’ve built our Inspect tool, which we use to measure data about how effective our teams are, showing upward or downward trends. It’s a simple case of looking at the teams where coaches spend their time, and measuring whether there’s an upward trend. It’s not perfect as a system, but it’s a good start.
Nudging is usually more effective than guiding
Coming from a software engineering background, I am naturally hard-wired to solve problems. Someone puts a problem in front of me, my first instinct is to solve that problem as efficiently and quickly as possible.
The problem there is that as a Coach, that’s actually completely the wrong thing to do in most cases. As a Coach, the primary concern should always be to make sure the people you’re coaching are actually learning stuff, which is pretty hard if you’re solving the problems yourself!
A big learning experience for me is developing the ability to step back from a problem and help to nudge people towards getting to the answer themselves. I still have a long way to go on this front, as it means rewiring a decade of conditioning as an engineer, but I think i’m getting there!
Being an effective coach often boils down to knowing when to actively coach, when to mentor and when to directly teach! Finding that balance is sometimes really difficult, but it’s a part of the learning journey for any coach.
Maintain a Ranked Backlog
Autonomy is one of those double-edged swords where on paper it sounds great to manage your own time and decide what your priorities are, but in reality, the priorities are myriad and fires to put out are many.
As a coach my role is enormously autonomous, but relies very heavily on reacting to priorities in the business and being in the right place at the right time to help.
In the past I tended to be quite reactive with this, which often meant that I was stretched over several things at once, along with dealing with ‘whoever is shouting the loudest’. Not only was this really tiring, but it also stopped me from actually doing my job properly, as my focus was stretched too thin.
To combat this, I had a think about how I could be more Agile in the way I run my days, weeks and months, while not actually existing within a full Scrum team or similar. The solution I came up with was to maintain a ranked backlog of priorities which are amended as priorities come to me from the business. Once a month I review my current ranked list with the business and confirm that we’re on the same page for where I intend to focus my efforts. Once every two weeks, I do the same thing on a smaller scale with the guys who are actually on the ground, so I can be aware of any immediate problems which might need to take priority. What this hopefully (it’s a very new system) provides is full transparency of exactly which teams I am helping (and for how long), with the ability for the business to disagree/shift priorities, and a more stable way of working for me! This seems like the most pragmatic blend of Agile concepts I could come up with to help shape such a reactive and autonomous role, but i’d love for people to reach out if they’ve seen better systems work in the real world.
It’s OK not to know everything
Just before I started as a Tech Coach here at AND, I was concerned about how effective a Tech Coach could actually be, as it would be impossible for one person to have a huge enough range of technical knowledge to be able to help in every situation.
The reality is that it’s completely OK not to have an answer to everything – if you don’t know, it’s a great opportunity for you to learn something with the person you’re coaching. The trick to coaching is to remember that if someone is learning something from interacting with you (even if it’s not you directly teaching them), then you’re probably doing OK!
It’s almost always a people problem
I touched on this a bit in a previous blog post here, and in the year since then my opinion has just become more cemented – If you’re struggling to build software (or anything, really), the issue is almost invariably going to boil down to the fact that there’s an interpersonal, cultural or communication issue. A business where people are empowered, communicate freely and have a stake in what they’re building is going to out-perform a business where the opposite is true in every conceivable scenario.
This is really the heart of Agile as a concept, as it’s all about getting people talking to each other while being able to take accountability for their own work. If your culture doesn’t allow for those things, trying to adopt Agile methodologies is pretty unlikely to be successful!Read More From This Author
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested