Mentoring & Coaching - Finding your outer Miyagi
In Part1 here I talked about mentoring. I talked about the fact that it is a function primarily based on building lasting relationships.
In this post I'll talk about quality coaching. What I think good looks like, the structure of a coaching session and round it off with a look at the differences and the similarities between mentoring and coaching.
The concepts and attitudes should be in a skilled testers toolkit. A good tester will, as part of their daily routine, mentor and coach the people around them. This coaching can be as overt or covert as you like, not everyone wants to stand in front of strangers but paying knowledge forward has no downside.
More importantly, a good leader will assume the role of a mentor and coach as part of their role.
What is a coach?
Technical - Functions, skills or jargon specific to a trade, profession, or field
Coach - 'A trainer or instructor'
A quality coach is a trainer or instructor that has practical skills in the techniques and approaches relating to quality. It's simple and to the point. It has other definitions but the one I use is context specific.
However, as simple and to the point as it is, it doesn't tell the whole story. Just as there's a difference between a tester and a skilled tester, there's a world of difference between a coach and a skilled coach.
When I think of successful coaches I think of Angelo Dundee, one of the most successful boxing coaches in history. His outstanding characteristics appeared to be his ability to impart knowledge gained from years of experience as a cornerman and bucket-guy and the fact that he was kind.
I think of Alex Ferguson, the former coach of Manchester United. There is no denying the success during his 26 season tenure though it appears to be a drastically different style from Angelo Dundee. His autocratic style enamoured him to some of his team but equally led to fractured relationships with others. I think of Ken Carter, immortalised in the 2012 film 'Coach Carter'. Who chose the more difficult path rather than the most expedient one for his charges. Each of these relate to sports. The one thing that analysis of these coaching legends tells us is that there doesn't appear to be a single blueprint for success. It's rare that quality coaching gets the same attention or praise. This is understandable as sport is followed by millions around the world whereas a technical coach may be responsible for a small team that are followed by the members within that team, or on a grander scale, the organisation the coach sits within.
Regardless of size of following, the base principles of being a good quality coach remain the same.
You want to help others
Your communication skills are above average
You have an in-depth knowledge of the subject matter
You can actively listen
My 3 guiding principles to be a quality coach (or what works for me)
You have to genuinely want to help others succeed
A helper mindset
This is the singular most important attribute a good quality coach can possess. Genuine enthusiasm is hard to fake. People remember good teachers, they remember the enthusiasm, the empathy, the patience. People respond to this way of teaching. You have to genuinely want to help others succeed. This is especially true in the field of technical coaching. A field that can be unbearably dry and one that is dry by design.
A technical coach has an ability to go from micro (small, individual sessions) to the macro (whole team sessions). They will create and run workshops. They undertake 1-2-1 coaching. They may analyse current processes and advise on improvements. They will undertake hands-on sessions. Technical in the software development space doesn't just mean hard skills. A large element of being a technical coach involves people skills. People are complex machines with opinions of their own.
A good coach will be adept at communication in all it's varied forms.
A good communicator
Many, many people have an in-depth knowledge of their particular fields. I've worked with developers who have brains the size of small planets but this is sadly not matched by their communication skills. A good coach will be adept at communication in all it's varied forms. They have active listening skills, they are empathetic, they use critical thinking to frame appropriate questions at appropriate times, they understand in-built bias and they are patient. A good coach will spend most of their time listening. As a coach, it's fundamental that you are able to communicate concepts and teach in an understandable manner.
Be aware that, even though by virtue of being a coach, there will be situations where you will find yourself thinking on the spot. The manner in which you respond to questions that you can't answer is every bit as useful as seamlessly imparting your knowledge onto the participants. It pays to have an awareness that coaching a testing technique or approach to a group of testers will result in open-ended questions. Good testers are curious by their very nature. Encourage this, even if it isn't the primary focus of the session.
There is an absolute difference between what you think you know and what you actually know
Subject Matter Knowledge
Simply having x years experience in a particular subject doesn't make you a technical coach. It does however, make you a candidate to become a technical coach. There is so much more to coaching than subject matter expertise though it is the absolute fundamental building block to be able to move forward. All the organisational, slick presentation skills in the world won't make you a good coach without a sound baseline understanding of the underlying subject matter.
As your career progresses you may find yourself becoming the go-to person for queries related to a particular subject or domain. This is a good thing. People already consider you to be an SME for that subject.
Take a learning mindset into each session you conduct
Even though you think you know your stuff, you need to take a learning mindset into each session. No two sessions should ever be the same. The participants, the environment, the subject matter may feel exactly the same but in reality, each will have subtleties that affect how you coach the subject.
Structuring a coaching session
If you find yourself answering the same queries repeatedly now would be a good time to consider the creation of a workshop to disseminate this learning. This isn't a throwaway task, well crafted workshops can take months to prepare. Articulating what you know into a format for teaching, in a pre-determined amount of time, to an as-yet, unknown audience can feel like a daunting task. My first workshop was created as a result of discussions where I would answer the same queries over and over again in an isolated 1-2-1 manner. Being naturally gregarious I started to think of ways in which I could show this en-masse to a 'semi' captive audience. I researched online, read many, many articles. I used experiences from being the attendee at numerous workshops, both the good and especially the bad.
I wanted to spread the knowledge, I've never adhered to the 'knowledge is power' mantra that seems to afflict some others. If I know it, and it's been useful, why not share it and allow your organisation to benefit.
I created a seven minute lightning talk, not earth-shattering by any means but enough to convince me that:
I knew my subject matter
I could distil 'what' I knew into meaningful chunks
I could have a positive impact on other peoples knowledge, skillset and learning
I came across two models that I used to guide me in preparing coaching sessions. I'm sure there are more but these have seemed to fulfil my needs.
FUEL - A conversation framework
GROW - A behaviour based model I prefer FUEL as that appears to be more aimed at behavioural outcomes though I use elements of GROW to set my goals and objectives;
Rather than dissect what each does, here's a handy link where they are broken down and compared.
My model is broken down into:
Setting the stage
Visuals trump text
Setting the stage
It's one thing to promote the purpose of a workshop in a loosely worded email. You may even have marketing literature that promotes your workshop. It's another when you're stood in front of a group of people eagerly awaiting for you to open the magic box and guide them along the path to enlightenment in the chosen subject.
Make the first few minutes of your workshop count. Communicate exactly what the participants will get out of this.
Repeating "This is about BDD" interspersed with throwaway platitudes sounds as bland to hear as it is to write.
Saying "We'll explore example mapping, we'll create concrete examples, maybe of real features you're developing, we'll turn those concrete examples into acceptance criteria, we'll use Gherkin to create scenarios, we'll talk about the impacts of collaboration to ensure a shared understanding. We'll learn what good looks like. We'll discuss the different approaches and how you can affect the outcomes of discussions.....etc..." "When you leave this room you'll be able to more effectively contribute towards the testing effort because you will understand the principles of 'x' to apply and when to apply them. You'll become the teachers."
Communicating the context of the session is a must. How you achieve this is entirely up to you and your particular style.
Set the stage, create the expectations
Regardless of the pre-requisites you wish to place on attendees, I can guarantee that attendees will turn up with various levels of experience around the subject matter. You may have participants that satisfy the pre-requisites that in actuality, don't understand the fundamentals of the subject matter at hand. Your job as a coach is to be aware that there is potential for this. The participants may think they understand the base concepts but as with most human-oriented learning, ego, and the presence of their peers, will compel them to not admit to a level of ignorance. This can lead to problems that will only increase as the material is taught (assuming that each concept is layered on top of the previous one). It can ultimately lead to dissatisfaction with the course itself, participants with unfulfilled expectations and by extension, your reputation as a coach.
Every time I run a workshop I make an absolute mental note to discover the participants existing knowledge.
I use a simple solution, though it is by no means fool-proof. I ask the participants to write a number on a post-it that summarises how comfortable they feel with the subject matter. I scale this 0-10 with a qualifying statement for the two extremes. This post-it is placed in a visible position in the room and is revisited at the completion of the workshop. I make a note of the participant scores. I'll then ease into the subject by asking a generic question of each participant with an internal emphasis on those who scored themselves above a 5. The answers enable me to gauge exactly where they really are as opposed to where they think they are. This isn't structured to embarrass or highlight their knowledge (or lack of). The point is to know the speed I can progress at whilst ensuring that no-one gets left behind.
I've been a participant in many workshops where there was an assumption that participants had the pre-requisite working knowledge to gain effective learning from the subject matter. I've been left behind in workshops where I wasn't familiar with the intricacies of a particular IDE (as that what was the instructor was using to demonstrate the concepts) It doesn't make for a particularly pleasant experience to be constantly asking for help whilst simultaneously being aware that you are, in effect, holding the progress of the workshop up.
At no time during this particular workshop did the instructor stop for a moment and reflect on the fact that I had a different amount of experience with their IDE so maybe some extra time to complete / otherwise assist a particular exercise would have been warranted....also asking for a volunteer/buddy to assist would have made a huge difference.
There is an absolute difference between what you think you know and what you do know.
Layer the learning
Logically splitting the subject matter into small chunks seems to work for me. It enables me to focus on a small amount of information at each stage. This is then expanded upon in subsequent sections. At the end of each section I try to recap how this fits into the bigger picture, i.e how using the principles of BDD contributes to a wider development lifecycle.
Logically split the subject matter into small, easily digestible pieces
A journey of a thousand miles begins with a single step
"A journey of a thousand miles begins with a single step" is a common saying thought to have originated from the Tao Te Ching. It's as valid now as it was back then. Separate the subject matter into easily digestible chunks. A process known as chunking. I use this in conjunction with the layered learning concept to optimise information understanding and retention. You can chunk-up (micro to the macro) or chunk-down (macro to micro) dependent on the participants interaction.
Present the information at a level of detail that is sufficient for your audience. The amount of detail can be varied in real-time depending on them. One method of knowing when to shift gears is to ask questions during the workshop. These questions should be targeted around the concepts that are being taught, they should promote creative thinking in the participants. They should be open-ended. Small exercises are useful, I tend to stay away from individually focused exercises, we don't develop software in a vacuum, why should learning in a group setting be any different?
A picture tells a thousand words. I use a lot of visuals to communicate concepts and ideas.
I support these visuals with bite-size text to help illustrate the concept
A succession of slides presented in a robotic manner with the 'coach' simply reading off each successive bullet point does not make a workshop. It makes for a very tedious couple of hours. Short bullet points are fine as long as they are used as a jumping-off point for an explanation of the concepts under instruction.
Death by Powerpoint is a very real thing
This is a hold-over from my military service though I have no doubt it is taught elsewhere.
At the conclusion of a briefing or ops group the briefer would go around the audience and ask members to paraphrase the instructions or orders given to that point. This would have the benefit of ensuring that the recipients understood the contents and allow the other participants to gauge or otherwise modify their understanding.
The concept is relatively simple:
At the end of a section, ask the participants to summarise their understanding of the information that has been presented to them. Be aware that individuals have differing levels of communication so a reactive style of question based around a practical application works well, even better if you can place the question in the context of how they work at the time
Differences between a mentor and a coach
A mentor is primarily a relationship game.
A mentor is a long-term commitment.
A mentor doesn't have to be a subject matter expert.
A mentor can use elements of coaching in their approach. A mentor will aim at developing the person
A coach is primarily an information provider with a human touch.
A coach builds short-term relationships, however, short-term does not mean transient.
A coach needs to be a subject matter expert.
A coach provides targeted teaching in a specific timeframe for a specific goal.
A good coach will leave people and processes better than they found them.
Once you have gained a certain level of knowledge it appears to be a natural progression to becoming a coach in that particular area if you feel that you can add value in the subject area.
A good coach will be remembered long after the workshop ends. Coaching doesn't have to define you, you can informally coach in a small capacity, think lightning talks and brown-bag sessions. Not everyone wants to be Tony Robbins.
If you're a tester in a position of authority I think you have a responsibility to coach those around you to be better at what they do, regardless of their specialisation.
You can follow me on twitter where I post presumed nuggets of learned QA wisdom.