In my last article, I compared agile coaches to the catering corps in the army, saying that we support the troops rather than leading them or engaging in heroics.
Cooking and cleaning for the heroes sounds like like a humble, servant leader thing to do. But does that metaphor really drum up an image of a transformational leader, helping people change the world.
Maybe not. So maybe it does not really describe my attitude toward coaching (or my “coaching mindset” if I want to sound more sophisticated).
My attitude toward coaching has remained the same in some ways, for a long time and I am probably not alone in that. My mindset about leadership, coaching and many related things probably formed when I was at school and in my early working life. As much as I read and stretch myself, the core operating system that makes up my mindset is probably an old legacy system with lots of patches and few major upgrades.
20 years ago I would have told you that “coaching” is generally about helping people to clarify and achieve their goals and that, as such, it is a broad term and you can do it however you can make it work.
I covered that in an article a couple of years ago and, although the definition is broad, it is the one I still stick with.
But I don’t believe that you can leave the definition that vague when you are actually doing it. I suggest in that same article, that the coach and the team/coachee need to spend some time defining what coaching means in their context in order to be effective.
But we don’t start from scratch, because all coaches have a view of who they are and what coaching means to them, just as those seeking out coaching have an idea of what coaching will mean.
That is what I would call our individual coaching mindsets or “attitudes to coaching”. And just as other coaches have an mindset that encapsulates their attitude toward coaching, so do I.
Then what is my attitude to coaching?
So what is my view of coaching? Who am I when I coach and what does it look like when I am coaching?
This is something that has, strangely I suppose, proven to be unstable over time.
As I grow and find myself in different situations I seem to redefine “agile coaching” to suit my current circumstances, rather than having a clear ideal that I work towards or a master coach that I want to emulate. Far from being a template zombie applying a set framework, I am not even a consistent believer in one ideal of what coaching is, or agile or leadership for that matter.
I guess Aristotle and Confucius would be disappointed, but neither of them was a certified agile coach, so we can pretty much ignore their feeble attempts at wisdom.
The seeds of leadership
I coached teams before I knew what agile was, so when agile came along I brought my existing understanding of what a coach was. That might be different to some agile coaches these days who started work in an agile environment and then learned to coach in that context. This potential difference does, I think my mindset.
In my first job, we were all about professionalism with a taste of informality. I was empowered to do my work and I made important decisions about work from day one. But I was not alone, because I had more experienced people around me, who would frequently express either horror or respect for what I did, they also hinted at better ways of doing things and shared their perspectives on things whenever I asked. Importantly, they also provided some constraints in the way of peer reviews and other checks and balances, so that my clients were safe from the most absurd of my mistakes.
It was a time of great change in the industry that I was in and my role continually evolved as a result. I learned a combination of administration, stakeholder management, system configuration, data analysis/management, legislative compliance and applied maths, which became my craft, I guess. I did not have a formal job that could be defined like a carpenter or a front end developer, but rather a vague definition of “person with a useful kitbag that solves problems and gets things done”. Over time, I extended my kitbag through practice and through the continuous feedback from a group fellow learners and from more experienced people who were happy to teach and support me.
Looking back, I think this framed much of my thinking about coaching. There was a concept around at the time called “Leader as Coach” and any senior team member or team leader was expected to coach others. In every role since then I have kind of assumed that once you learn, you teach others and that you do this through giving them space and feedback as much as by showing them the ropes.
So for me, Coaching meant a mix of “teaching the craft” and “Role modeling the culture” – but it did not telling people what to do and not faithfully following the instructions of my boss. I guess it was less Shu-Ha-Ri and more questioning and exploring.
My fundamental questions were along the lines of:
- What on earth made you think that?
- What do you think you could do here now?
- What do you think will happen if you do that?
I lacked finesse, but I did empower people to think for themselves. When that failed, guess I jumped to telling people what I thought had to happen, why it had to happen and then how I thought they could accomplish it. But I still assumed that people would argue with me and question me – I assumed that they wanted to be in control of their work.
Anyway, when I became a manager, I took that with me. I assumed that my role was fundamentally to coach people to become empowered, to remove the obstacles that they could not tackle themselves and to provide clear constraints to what the should and should not do.
Then I encountered “agile” and it seemed like a natural fit.
Coaching with frameworks and technical practices
When I say agile, I don’t mean Scrum or Safe, because I only vaguely knew about Scrum and Safe did not exist.
I also don’t mean product management, because I was was mostly applying agile to my projects. I used similar approaches to BAU (Business as usual, or ongoing operations), but at the time I just assumed that Lean and TQM and things had that covered.
In fact I probably thought of agile approaches as being the application of BAU thinking to projects. I wanted to strip the big up-front waffle from work and replace it with continuous progress, with building and learning and getting one thing actually working before adding more to the goal.
What I was clear on though, was that agile meant was really empowerment, continuous improvement and collaboration. I started using a home-grown agile approach that vaguely represented FDD (feature driven development) and Adaptive Project Management. I was ruthless in imposing continuous testing, even if it upset empowered people that I forced this on them, but, beyond that, I was open to working as a team to define our working practices.
Then I learned that my developers and BAs wanted to actually learn to apply the same concepts to the work, not just to how we worked together. I brought in a consultant/coach to help with that because I am not a developer (thanks Shane). He “taught” the team about TDD and other cool acronyms, but really what he did is sow the seeds of interest in improved technical practices.
In hindsight, I think if I started from scratch, the technical practices are kind of the heart of agile. Without good craftsmanship, the “leader as coach” is not really coaching excellence as much as inspiring the next generation to learn it themselves.
This has always been a challenge for me because I think agile goes beyond technical practices and frameworks to become “working as an empowered community.” This sounds good but it does not really differentiate Agile Ways of Working from 1980’s management theory.
In fact many of the organisations I worked with as an external coach wanted access to what they did not have – a different perspective on how to apply the theories of empowerment, high quality, etc. They didn’t just want someone to come and encourage rebellion among the troops until they took over leading themselves – they wanted concrete steps to take in order to make concrete improvements in delivery and customer outcomes.
So now I believe that there are sets of practices that go into the agile toolkit. Good testing and regular cadence are core parts of agility, while good upfront planning and outsourcing work to specialist gurus are good practices, but not agile. I would probably bring in some framework like Scrum or Kanban to learn from and then adapt, rather than building from scratch.
I would also bring in design thinking because in my early days “start with the customer” meant asking the customer what they wanted and then iterating. It did not mean designing a product from emerging evidence and ongoing collaboration.
So where did that get me to?
So my attitude to agile is now (and probably has always been) that we do not flip from being non-agile-heathen, to become civilised-agilists, but rather we incorporate different practices to increase our “agility” in the context we are working in.
By “agile” I mean “quick and easy of movement” so the practices and frameworks I include in my agile toolkit are those that make it quicker and easier for an empowered team to understand and create value.
The rest is to understand a way of working that suits the context of the work we are doing, such as lean, ITIL, Design thinking, Lean startup or what ever seems to be a good starting point. As a coach I now see part of my value being to help people identify tools and practices that work, and to adapt them for local use.
But wait there is more … starting with the end in mind
But that means that I need to know what I am trying to achieve “quickly and easily”.
The first principle in the agile manifesto is to “satisfy the customer with early and continuous delivery of value” which is nice. I guess that is usually the goal and so you could almost say it is not worth saying. But in fact it is what people often forget when things are not easy and when they try to make things quick, or cheap. They forget that what matters is the end result.
Often the end result is to deliver something to the paying customer or the citizen of the state or something, but I find this too broad in some of my coaching, so I think part of coaching is to help the team discover what it is that they are intending to do.
In other words – “We want it to be quicker and easier to ….(what)?”
So I am back with the basic definition of “helping people make sense of things, set a goal and then realise it.”
Leader, mentor or “Coach”
I still think in terms of “leader as coach” and “experienced artisan as mentor”, so I think a “coach” can actually be a mentor or a boss”
But depending on your definition of “mentor”, not all coaches are mentors, and depending on your definition of leader, not all leaders excel as coaches.
Some of my “mentors” have not really been coaches, but rather champions and supporters.
Some of the big breaks I had in my career were really not about my growth or competence, they were about me getting an opportunity to prove my growth and competence because my “mentor” put me forward confidently to take on the opportunity. Others may have also been able to take on the opportunity and I may have not really been ready yet, but the opportunities came because someone extended their credibility to me and said “if you trust me, you can trust James.”
This kind of “mentor” is good to have and at times I have seen the potential in people and championed them so they get an opportunity to prove themselves and to grow. This is an important part of leadership, but I don’t think that it is really coaching, as such.
The kind of mentoring that I get called on to do, as a coach, is to help people learn new skills (as a teacher) and to help them better understand the outside world (As an old guy who has been down that road before).
For example I might show them how to run a retrospective (teaching) or give them advice on how presenting to senior management is different to presenting to their current teams.
Thus teaching is, for me, an “outside in” activity where I bring knowledge that people can internalise and use.
Mentoring is and extension of teaching but less focused, in that I bring advice and experience that people can choose to interpret and apply to their situation. I guess teaching is where you have a body of knowledge that your unpack for people while mentoring basically mansplaining and telling of war stories, where your victim needs to work out what to unpack for themselves.
Teachers are revered, while mentors are listened to as long as their batting average remains high enough. People can access a mentor when they want guidance and then choose their path based on whether they think the resulting advice if sound.
I used to think these were what coaching was – sharing experience and knowledge so that others can grow, but over time I came to see mentoring without the illusion of expertise. If the coach has no more expertise than the one being coached, then there is no benefit in manplaining or war stories, as such. Instead the coaching process is “inside-out”. It is about helping people access what talent, understanding and perspectives they have inside them and bringing that out for them to build and act on.
Both mentoring and coaching are good and in fact, I think it is good to move between coaching, mentoring and teaching when in any leadership or coaching role. To call yourself a coach is not to restrict yourself to only listening to people, but rather to claim you know when to coach, when to mentor and when just get out of the way.
Why then does it matter?
You can see that I have always had a loose definition of “coach” and that if the outcome is helping people to define and achieve growth and meaningful goals, then it good, no matter how you see yourself.
But I have come to think that for the coach to be really effective, they need to decide which approach they are taking at a given point in time, and those they work with need to understand what they are doing.
So I need some way to explain coaching, and some way to see myself when I am a coach. Unfortunatly, “like the catering corp, but not in the army” is probably not all that helpful afterall, though is is still better than “like the special forces of agile, more agile than you mere humble folk”.
So this is where I think I can arrive at a definition. Good coaches are flexible, but it is not just that they have a range of roles to jump into. They also know when to “connect with those on the journey” and when to “engage with those on the journey” and they can move between these approaches. This is a bit obscure so let me explain:
A lot of the time when someone asks for coaching, they want the coach to “engage” with them, to help them know where to focus their attention in order to improve and grow. They want someone who knows what to do, or can at least work that out, and guide the conversation. This is close to the definition of a mentor, but it can also involve someone who is good at assessing the situation and advising what to do based on their analysis (a consultant).
People a coach to guide the conversation, provide insights and keep them honest in the pursuit of the goal. Good coaching in this way involves focused questioning, the agreement of a shared outcome, providing an outside perspective and seeking data make things clear that were once murky. I am going to say that it is like going to the doctor to get a diagnosis and some “medicine” to take in order to get better.
On the other hand “engaging a coach” or being a coach that “engages with a team” suggests that the coach is there for (an agreed) purpose and that they are separate from those that they coach. The coach effectively sits outside the system so that he/she can guide things in the right direction and see things that others see.
As good as this sounds, it assumes too things:
- The coach is seeing things that the team are not; and
- The coach has a good understanding of where to go next.
If I went to a doctor and they said “look within and you will understand how to cure yourself” I would probably seek another doctor.
While these two things are great when they are true, they also take empowerment away from the team. A doctor can diagnose a patient but I think in the case of the agile team (or leader) there is an expectation that the individuals should lead themselves, not follow the prescription of the coach.
So, while a “doctor as coach” might be what the team asks for, it is not the essence of coaching for me.
In pure coaching it is the team who should be seeing more and developing the understanding, not the coach. The coach is there to help the team find their own way, not to guide them.
The the flipside is for the coach to stop looking from the outside and connect with the team.
This means asking what the team want to achieve and then connecting to that in the coaching. It also means joining the team in their their discovery as they go. This helps the team to unleash their own potential and discover their own way. It also benefits from two great insights:
- The wisdom of the crowd suggests that a team, including the coach, will always be smarter than the coach alone; and
- The people doing the work will understand it in a way that nobody else can, meaning that the craftsmen working at the forge or talking to the customer, have insights that nobody else can uncover. The team in effect, have more potential insights available to them through their own inquiry, than any outside coach can discover through observation, data or previous experience.
But again it has its limitations. Connecting with the team rather than engaging with them means trusting them to know the path, rather that guiding them along the path. That means that the team may make decisions based on their own biases and limitations in perspective. This is bad if the team are locked into their current thinking or struggling on a path they have never been on before. Asking them to find their own way might be like a doctor advising people to “do you own research on google and twitter.”
There is a middle row though, where I think real coaching belongs. It is being a partner for the team, but being there to solve the problem for them. Rather the coach is a “thinking partner” who helps the team uncover and explore their own thinking, perhaps with some insights or different perspectives to consider, but largely by asking questions, listening and reflecting back what is heard. This coach is not their to guide the team but to help them think things through, so they can better guide themselves and to help collaborate so they can better guide and support each other.
So the role of the coach is, I believe is a bit subtle. At times the coach should act as the guide or even the “doctor” for teams who need an outside perspective and then act as “fellow traveller” or partner for teams who have the potential to find their way but are not accessing that potential.
A better analogy than catering corps?
To go back to analogies and metaphors. Some coaches think that they are team’s doctor, whereas I think that we are the thinking partners for the already capable team. Both might be right and maybe the coach should be able to play both roles, as well as the role of “member of the team on the journey with us.” Lets look at each metaphor in turn.
Coach as doctor
If the coach is like a doctor then:
- The doctor coach is engaged by the team or its managers;
- The doctor coach performs and assessment, perhaps observing the patient (team or coachee), asking the patient some targeted questions and perhaps running some tests.
- The doctor coach assesses the results of the questions and tests and applies their expertise in forming a diagnosis
- The doctor coach shares the diagnosis and recommended treatment with the team
- The team agree with the prescription and follow treatment
- The team gets better
This is, I think a common expectation of coaching. It can work, but it is based on the assumption that the coach is an expert in diagnosis and treatment and that the team can, to an extent, rely on the coach to do the thinking. This can limit the growth of the team who should be learning to self-diagnose and to decide on their own “treatment protocols” or “fitness regimes”.
Where a company engages an outside consultant, or a teach of coaches roams the organisation, assessing teams and making recommendations then they are probably acting as “doctor coaches.” Similarly, a fitness consultant, therapist or (literally) a doctor might do this to help the person or team improve and attain important goals.
Coach as contributor or partner
If the coach is a contributor, they collaborate with the team to solve shared problems, perhaps like a fellow artisan or a partner in an action movie:
- The coach and the team/coachee come together for a shared experience
- The coachee/team is like the action hero and the coach is the side-kick or partner
- Both the coach and the action hero stumble forward, learning from setbacks and sharing victories
- By combining their different skills and shared passion, they over come all obstacles and win the prize in the end.
- They part ways and wait for a sequel
In this analogy, both the coach and the team are in it together. They collaborate to solve problems together and they win or lose together. But the coach is really more an extra team member, with skills in frameworks, techniques or collaboration.
A complaint I have heard about some “agile coaches” is that they are just another person without a clearly defined role, so maybe if you are acting as the “coach as contributor” then the team is expecting something different – a doctor or thinking partner rather than a contributor.
This is not always the case though.
Someone recently sent me this article, about the “pendulum” that engineering managers swing on, maybe needing to be more technical to lead technical people or maybe needing to learn to manage. Which ever they do, there is a need to swing back to the other perspective.
I think this applies to agile coaches too because I have heard complaints that “agile coaches” are not technical and lack the real perspective of a hands on practitioner in the team.
In this way a tech lead who is teaching the others better coding, a developer who is also acting as scrum master to help the team improve their collaboration, or a QA who is helping the team learn better approaches to testing, are actually coaches who are playing the role of “contributor”.
This would also apply to the team member who the team relies on to share a framework, method or way of working together in addition to contributing to getting the work done using that framework. I guess this is almost the ideal scrum master for me.
Coach as thinking partner
My current favourite analogy for coaching though is to be a thinking partner.
This is based on the idea that the coachee or team need to be empowered and self-sufficient and not rely on the coach to think for them – They need to be able to solve their own problems and choose their own path.
It also assumes that people are going to align to the organisation’s goal, want to work together and want to do good work.
This then frames the role of the coach quite well:
- Every person or team is responsible for doing their own thinking and getting their own work done;
- Every person is able to make sense of the work that needs to be done and to find a way to do it well – bringing their own perceptions with them as they do so;
- The way people perceive the world guides what they focus on and how they act;
- The way people act then impacts how they collaborate and how they learn and grow; and so
- The way people perceive the world both enables growth, by helping people make sense of the world and also constrains growth, by introducing bias, self-recrimination, arrogance and other things detrimental to growth.
Based on all of this, people tell themselves stories and create a shared understanding through collaborating together. This is the key to their growth but also a constraint on that growth. In the worst cases it can even lead to group think, factions and ultimate doom.
The role of the coach then, is to help people understand their stories and to help them collaborate more effectively, uncovering their biases and assumptions while also building on their shared sense making.
Thus, rather than diagnosing and prescribing treatments, the coach listens and reflects back what they hear. By doing this, they help people uncover contradictions in their own thinking and clear the noise that stops them from finding their own focus.
The coach also provides different perspectives to consider but they also pause to consider the process of thinking things through and sharing ideas, so the team members can focus on doing the thinking.
Sometimes this means just connecting with someone and giving them the space to think. Other times it is a more formal engagement where the person wants to form a clear goal, change a behaviour or implement change, but wants help clarifying their thinking and moving from thinking to acting.
When more than one person is being coached, the coach helps the teams to replace their debates and polite conversations with “generative conversations” where they are able to safely challenge each other and also feel supported and valued.
The coach has to sometimes connect to be part of the conversation and sometimes step back to observe the conversation and make observations about how to improve that same conversation, rather than participating in it directly.
So in this analogy, the coach may not know more than the team and the coach is not really contributing directly to the problem solving. They are facilitating the process of thinking and they are helping people make sense of the world and take ownership so that they can better solve their own problems.
This last analogy is my current attitude. It is what I think a coach is really there for. But it has not always been my view and it has taken me a long time to get here. It is also not always what the team needs most and I reserve the right to shift my focus accordingly.
What do you think?
What do you think an agile coach is and what do you think they should do?
I am honestly curious because I continue to shift my thinking as I travel the path of coaching.