There is general confusion in the business and Agile world about the differences between coaching and mentoring. One can easily be confused with the other given the similarities between them.
Some key authorities on coaching and mentoring (such as Clutterbuck and Megginson) argue that any attempts to polarise the two fields is futile and negatively affects both. I agree, and by shedding some light on these disciplines we can start to make sense of the delineations and overlaps.
Mentoring is said to have originated from the Greek mythology of Homer’s Odyssey in which Mentor is mentioned as an advisor to Telemachus, the son of Odysseus. The use of the word mentor entered organisational vocabulary through a seventeenth century book The Adventures of Telemachus by the French writer Fenelon. Fenelon portrayed Mentor to embody the attributes of a teacher, guide and counsellor - a definition which still holds true today. Over the ages we have great examples of ‘mentors’ by this definition: Sigmund Freud for Carl Jung, Haydn for Beethoven, Phil Jackson for Michael Jordan and Tina Turner for Mick Jagger.
The Online Etymology Dictionary suggests the term coaching originates from the ‘koczi' - a covered carriage or wagon that was originally invented in the village Kocs in northern Hungary. The wagon was designed to protect valued passengers from the elements on their journey through a rough terrain. The word coach in the context of a trainer or instructor is said to stem from the 1830’s, when Oxford University used it as slang for a tutor who ‘carried’ a student through the exam.
The greek philosopher Socrates is considered by many as the first significant coach. He made a valuable contribution to coaching with the Socratic method, which is based on open-ended questioning in order to encourage reflection. This method is now well integrated in the coaching philosophy and is focused on coachees generating their own perspectives and actions for addressing challenges.
The practice of team coaching has also become a popular intervention in recent years. In this case there is a fine line between coaching and facilitation. Although the approach may differ, the same basic principles apply in that the coaching will challenge certain beliefs and assumptions and use specific models to resolve a specific challenge.
Mentoring has long been a popular way of transferring knowledge from generation to generation. Today mentoring programmes are widely used in organisations both on an individual and team level. Mentoring is often associated with induction, career development, and as a support mechanism in career change. The agenda is determined by the mentee and may be of organisational or individual focus. The mentor does not always work in the same organisation as the mentee or protégé, but has an in-depth understanding of the challenges and issues the mentee has to deal with. The mentoring disciplines are less likely to refer to specific tools instead emphasises more personal qualities and abilities.
Coaching, on the other hand, is still very much in its infancy both from a practice and research point of view. The multitude of definitions, tools, theories and traditions that are attributed to coaching points to the eclectic nature of the discipline. Similar to mentoring, coaching has its roots in education, organisational development, psychology, counselling and sports.
Coaching is generally seen as a thinking partnership between equals where the coach encourages clients to create their own solutions, and develop awareness of conscious and unconscious behaviour and assumptions. Cavanagh (2006) argues that the purpose of coaching is to “push the coachee towards the edge of chaos, towards a controlled and managed instability, a condition in which human growth and change is most likely”.
Coaching approaches individuals holistically and cannot be optimal without taking all aspects of the person’s life into account. Business coaches do not only focus on assisting individuals defining their core purpose, strategies, developmental strategies, developmental strengths, weaknesses and obstacles, but also take all aspects of the individual’s life into account. Aspects typically included are meaning and purpose of their work, leadership, processes and systems and work-life balance (Stout-Rostron, 2012: 4)
As an applied science, coaching has a multitude of applications and prefixes, but could broadly be classified into two categories: performance (acquisitional) coaching and personal developmental (transformational) coaching. Performance coaching is more model driven and goal focused whereas development coaching has a purpose of development of awareness, skills, behaviour modification, emotional intelligence, personal mastery and transformation. David Clutterbuck argues that despite the plethora of coaching models and approaches the mature (system eclectic) coach has a liberated approach which includes a wide-ranged portfolio of tools and techniques.
It is worthwhile to take note of the conclusion of a recent study (Salter & Gannon, 2015) exploring the similarities and distinctions of coaching and mentoring. They suggest an alternative approach to seeking differentiation between the disciplines would be to embrace diversity in acquiring additional skills and applying the intervention best suited for the optimal outcome at a given time. They specify that the practitioner should be aware of the discipline and boundaries they are operating in and be contracted with the client whether the conversation is one of giving advice or incisive questioning.
In conclusion, it seems fair to say that when you need advice and expert knowledge from a more experienced person on a specific topic, you probably need a mentor. The engagement may be less formal and structured. From a coaching point of view, you can be expected to be challenged on your world views, limiting beliefs and assumptions in order to enable you to develop your own solutions rather than the coach providing them for you.
The coaching relationship is an equal relationship of discovery, where the coach is the expert on coaching and the client the expert in their field. In business coaching it is important that the coach understands the business domain to be able to ask the right questions. A coach may sometimes act as a mentor if needed, but only when specifically required to do so.
References
Bachkirova, T, Cox, E. & Clutterbuck, D. 2010. Introduction. In E. Cox, T. Bachkirova & D. Clutterbuck (Eds.). The complete handbook of coaching. SAGE, 1-20
Chapman, T., Best, B., & Van Casteren, P. 2003. Executive coaching: Exploding the myths. Palgrave Macmillan.Chicago
Clutterbuck, D & John Wiley & Sons, Inc., from The Handbook of Knowledge-Based Coaching: From theory to practice edited by Leni Wildflower and Diane Brennan to be published in June 2011
Demik, Randal J. 2007.Coaching, Counseling, and Mentoring: A Strategic Need in Training and Development. Online Submission, Paper presented at the Academy of Human Resource Development International Research Conference in The Americas (Indianapolis, IN, Feb 2007).
Du Toit, A. 2014. Making Sense of Coaching. Sage: London.
Eby, J.E.. Allen. T.D. 2007. The Blackwell Handbook of Mentoring. Blackwell Publishing Ltd
Grant, A.M., 2012. An integrated model of goal-focused coaching : An evidence-based framework for teaching and practice. International Coaching Psychology Review ●, 7(2), p.146-165.
Larsen, SL. 2009. Social construction on the road to transformation: applying rites, rituals and play to executive coaching. Submitted in partial fulfilment of requirements for the Doctor of Education. University of St. Thomas, St. Paul, Minnesota.
Passmore, J., Peterson, D.B. & Freire, T.,(eds) 2013. The Wiley-Blackwell Handbook of the Psychology of Coaching and Mentoring, John Wiley and Sons.
Salter, T., & Gannon, J. M. 2015. Exploring shared and distinctive aspects of coaching and mentoring approaches through six disciplines. European Journal of Training and Development, 39(5), 373-392.
Stern, L. R. 2004. Executive Coaching: A Working Definition. Consulting Psychology Journal: Practice and Research, 56(3), 154.
Stober, D R.,,Grant, A.M. 2006 , eds. Evidence based coaching handbook: Putting best practices to work for your clients. John Wiley & Sons.
Stout-Rostron, S. 2012. Business Coaching: Wisdom and Practice. Knowles, Randburg, South Africa.
Organisations often adopt agile as a way to challenge their status quo. However, if agile is only seen as a process or method to manage the agility of your teams without first changing the way you think, it’s not going to work.
Often organisations aren’t happy with the rate of delivery on certain projects. They have no transparency and realise very late in the process that they are behind schedule. When they can’t keep up with the demand, someone else always seems to deliver faster. That’s when things need to change, and they turn to agile for the answer.
Since agile teams deliver faster, they continuously improve, sprint after sprint. The teams’ velocity increases iteration after iteration, so the thinking goes that – if they can be measured by velocity – they can be managed when ‘slacking’.
This goes on for a while, but when the teams’ velocity starts to slip, someone else inevitably decides what the velocity should be. From that point teams start getting measured on stats, but without first understanding individual teams’ stories this can quite quickly instil fear. Fear kills innovation, which drives the wrong behaviour. Instead of being open and transparent, teams start telling management what they want to hear, hiding behind reality.
Managers need to change the way they think, which in turn will change the way they act. This is the key to agility: it’s a different way of thinking.
A stored procedure, SQL query or class does not overnight become easier when you decide to adopt an agile framework. Lines of code aren’t shorter than before; instead teams find ways to work smarter to deliver business value faster.
They become self-organising, guided by good leaders. Good leaders understand that when teams become more self-organising, they (as managers) might lose some of their ‘powers’. That’s a positive; they instead empower their teams to make decisions, building trust within the group.
Good leaders understand that they need to allow their teams to make mistakes, because they understand the importance of learning. For instance, if a team makes a mistake with a deployment to production instead of creating another SOP (standard operating procedure) or more governance, they will find a way together to make deployments easier. Instead of only deploying twice a year, they encourage their teams to deploy more often.
Daniel Ek, the CEO of Spotify, has a saying: Good leaders think like this: if we aren't failing then we're not innovating. We aim to make mistakes faster than anyone else.”
I recently had a conversation with a test analyst. She reported a bug in her company’s daily scrum. The developers said it is a new story, but she was adamant it was a bug. So she asked me how they should manage it, since she’s obliged to report on all the bugs.
Bug-story-bug-story… what does it matter? Set the priority and get it done. Often developers have some sort of KPI attached to the amount of bugs they code, and testers are rated on the amount of bugs they find. In both cases their increases or bonuses are connected to these stats. Yet we are blind to the behaviour this drives in our teams. No wonder they clash so regularly.
Let’s think differently. We’ll call it a ‘learning opportunity’ or a ‘cool story’. It might be a team’s first time building a specific feature and they are still learning. Other more senior teams may have built something similar hundreds of times before. So rather than managing the team with the bug stats report, why not think: they had several learning opportunities. Good leaders will also give open and honest feedback, not allowing teams to make the same mistake over and over.
Leaders understand that creativity lies in the midst of chaos. It is okay to have chaos every now and then. But in this chaotic state they allow their teams to manage themselves and won’t interfere or try to fix the situation unless asked.
They also understand that they don’t always know everything, knowing how and when to submit to a fellow team member.
I will never forget my early Scrum Master days, when I experienced leadership that changed my whole career. The CTO of the company I worked for asked me to investigate why a team best known for delivery suddenly stopped delivering. I did the investigation and took the results back to him, explaining what happened. He then asked for recommendations and my opinion on how to fix the problem. I gave him my opinion; he looked at me, said “go do it,” and walked away.
He trusted me, valued my opinion, and without second thought allowed me to experiment. He did not expect any solution the next day or even the next week, as long as we managed the challenges. Under his leadership, I had many opportunities to ‘experiment’ with teams, taking good teams and making them great.
Leaders don’t always have the opportunity to pick who will follow them. In organisations – unlike politics and sport – the followers don’t have the opportunity to appoint the leader; they either emerge or get appointed by management.
Why not allow your teams to pick their leader for a specific situation? Be the commander on the battlefield that allows his soldiers to call an airstrike. Magic happens when we take agility to the next level, by thinking differently from the norm.
Imagine this: you wake up in the middle of the night to get a drink. You don't want to turn on the lights because you're still half asleep, but you need to or else you won't find your way. Luckily your lights are programmed to switch on, dimly, if they detect motion towards the kitchen. By the time you wake up, around seven, your music system knows to turn on the easy listening channel. You also get regular updates on your indoor temperature, notified of suspicious activity on your property, and the sprinklers know when to chase the early birds away.
Now stop imagining, because I've just built this smart house for myself, and these are some of the lessons I learned while doing it.
The first challenge was finding the right platform – information platform that is. There is a great deal of data that needs to be sent around the home network, depending on the activities in question. My first choice was .NET, because that's my default for all things cool, but after just a few iterations I had a truckload of source code for very basic tasks – and I hadn't even started on the fancy stuff.
After much research I found an open source platform built on top of node called Node RED, by IBM. It's an event processing engine that excels at orchestrating multiple data sources and consumers.
This seemed to provide just the right amount of abstraction, allowing me to think in terms of what I wanted to achieve, rather than getting bogged down in hundreds of lines of code. It uses a graphical drag and drop approach to writing software, making it very easy to mix and match multiple data sources.
While I still needed to write a bit of JavaScript, it was fairly minimal and easily managed. I believe this approach to building software will catch on more as the internet of things (IoT) becomes more widespread. I have also used it to great effect while teaching absolute beginners how to code. You can check some of the nodes I wrote on my Github page.
Within a short time, I had my basic infrastructure set up, and the house was happily sending and receiving data via multiple online services. With a few drags I could wire up a Twitter feed to update me on the current temperature, push that data to mongo for storage or update my mobile phone when there was any unexpected movement inside. It's pretty liberating and fun to use.
The only drawback to this platform is node itself. Many of the packages I relied on for low-level tasks turned out to be surprisingly buggy, and my smart house would crash very often, too often to actually be useful. The best I managed was three days of continuous use, and this was on very good hardware. I expect stability will come with maturity, but for now, a healthy dose of patience is required.
The other challenge I faced was the availability of sensors and other IoT hardware. The South African market appears to be oblivious to this need, and the few shops on the web that sell sensors are way behind the state of the art, and their devices require a lot of electronic skills to use. Your only choice is to import these gadgets from overseas, and pay more than the cost of the device in shipping and duty costs.
I'm sure this will be resolved once businesses get on board and demand makes it profitable for people to sell devices. For now, you'll have to either cough up or pull out your soldering iron. On a more positive note, it seems that the capabilities of the devices being released are increasing at a much faster rate than when I started, and the costs are going down.
As with any software project, the last and most important aspect was testing. Testing a smart house is not like testing a website or mobile app. Unit tests do nothing to verify the overall correctness or robustness of the system, and actually increase the amount of code you have to maintain. There is usually so much going on that I found it easier to just do manual testing. I haven't found a great way to test the resulting product as a whole, but the platform I used helped to simplify my code into tiny bits of functionality called nodes which I could easily test with mocha.
Today I have a fully functioning and working smart house, built on the same principles we use every day in our software development and testing projects. It may have taken a bit more elbow grease and creativity to get around the logistical challenges, but it's encouraging to know the model can be replicated with great success beyond the web and smartphone.
This is a deceptively simple question because expensive means different things to different people. For a project manager, it tends to be that testing mostly is done at the wrong time, at the end of a project when budgets are depleted and fixing errors is time-consuming. For the call centre, it is the number of support calls from frustrated users.
In other words, do you and your stakeholders have the same definition of what expensive is?
My real point is that the concept of value is multi-dimensional. Thus, in order to determine whether testing is expensive, we need to consider all the dimensions. I think there are five key dimensions, which we can call the five Ws:
- What in general makes testing expensive?
- When is it expensive?
- Where is it expensive?
- Who makes it expensive?
- Why do we even require testing in the first place?
I am no expert on how to run a profitable business and satisfy all the stakeholders involved financially, but I have to admit that, as a quality assurance professional, I am surprised to find that those five Ws are not asked. It is as if business schools only teach people how to be successful when things are going well, and not to assess and mitigate risks. Maybe it’s easier and cheaper just to say “sorry”. I suppose I shouldn’t complain because this is probably why people like me have a career in testing and quality assurance in the first place!
To get an idea what I am ranting about, let’s look at a typical process which is generally ignored during planning because it is very unlikely that there will be sufficient control over information to measure effectively the tasks performed. The process I am referring to is the defect (bug) life cycle. How much does it really cost to fix a bug found during acceptance testing or in production?
Looking at the rough sample diagram above we can see about nine possible stages to a bug life cycle. On the right are lists of typical tasks performed during each stage. If you measure the effort spent, and the cost of the people involved you might be surprised with the numbers. Assume 25 bugs out of a total of 250 bugs need to be fixed by the end of a two week period. Will you be confident to release to production without measuring the current quality through testing?
Many times we are being challenged and struggle to show quality because it might only be visible in getting to production. Over the course of development, developers will be less likely to test all of the things that can go wrong. I think it is muscle memory by constantly focusing only on getting the code to work. This explains the theory behind the graph that is part of all test related training - bugs become exponentially more expensive to manage during the SDLC.
“How much is that bug worth to the people that matter?”
The irony is that little attention is assumed to guarantee quality according to the context of the system - until something goes wrong and it negatively affects someone. During crunch periods, there tends to be an increase in the total number of testers involved on the project. Sometimes the testers with the wrong skill sets are pulled in just to get numbers up and to add more eyes to the system. However, is it sustainable, effective, efficient, or repeatable? At times, you do require the rare skills of test specialists or a tester with a broad range of skills, but the contracting fees cannot fit in your already limited budget.
Many times I run into situations where people were employed for their personality and not for their skills to make the project a success. Add to that the costs for performance testing tools and environments. Security testing is not cheap either. There are design risks if globalisation is not considered and can result in a big rework. There is also that dreadful maintenance risk to keep the system running for the next 3 to 5 years. How much is red tape crippling the efficiency and effectiveness of testing in some businesses?
Remember too that some people using the product will exploit your system. If you are still not convinced then have a read on sites like CNET.com and search for the term “glitch”.
“Could it be an intentional blindness forced onto decision makers by society to ignore the negativity of asking “what if” questions?”
Obviously there will be solutions to many challenges, at a price of course. However, changing cultures and processes over a short period seldom go according to plan. No matter how much money you throw at problems, they cannot get solved in the desired timeframes.
I believe testing can become cheaper or at the very least become better. Bring the minds of the right people together from the beginning to ensure quality throughout the SDLC with the required levels of testing. Involve all the stakeholders, including the clients, to collaborate, set realistic goals and take responsibility for the quality.
Respect the role and responsibilities of each other in the team but also understand and accept the team’s capabilities.
