I’ve been thinking about how to remain effective as an Agile Coach while not being co-located with the entity (person / team / project / programme) that wants to be coached.
While a long term viable solution might be for me to rebuild my approach from the ground up as a “remote native” thing, I reckon my MVP is to patch up my existing process (see “The anatomy of my typical coaching engagement“) so that it is still fed with as rich a dataset as possible.
Mental model of a Person
- What they do
- things like their role, career history, future plans, what’s their speciality in the team etc.
- How they think
- things like how they build their mental models, how they make decisions, how they prioritise etc. I also look to understand how they see themselves.
- Main character traits
- things like whether they’re an extrovert, are they motivated by fame/recognition/peer acceptance, how they respond to stress and challenges etc.
I’m also looking to distil all this into some insights into what they feel is important, what they see is urgent and what they think they must avoid.
Benefit I get from using this model
The core benefit I get from populating this model of my coaching client, is it gives me a far richer relationship with my client, which typically translates into better / more accurate communication. These are some examples.
- By learning about the “What They Do” tree, I’m able to work out if I can mentor them, or who would be a good person to mentor them and help them progress from Present to Future Ambitions
- If I can combine aspects of “What They Think Is Important”, some of their Character Traits (e.g. Individualism or Collectivism) and that is either something I align with OR can mimic sufficiently to communicate, I can begin to build rapport with them. Rapport is the first step towards trust.
- If I understand “How They Make Decisions”, it makes it easier for me to structure a compelling argument, thereby increasing my levels of persuasion.
- If I understand how they’re motivated, that can also support my ability to structure a compelling argument.
- If I understand how they manage their risks, and what they’re trying to avoid, then not only does it help me structure an argument, I can help them think about relevant risk mitigation strategies.
- If I understand “How They Make Decisions”, and can describe it to them in a way that makes implicit processes more explicit, I have a chance to help them learn about new thinking models and they can devise new problem solving strategies.
Building this model
This is the easiest scenario. Much of this model can be built by forming hypotheses informed by the actions and behaviours that I observe. The person is also accessible so that I can discuss my models and predictions and see how close I can get to what they think. The main challenge is the amount of time it can take before some of the deeper elements can be inferred / estimated, if for no other reason that it requires a great deal of trust and honesty between the person and I, and that trust takes time to build.
Conceptually, my starting point was to find techniques for collecting the same raw data that worked with the alternate channels available – voice & video calling and email / written form. As everyone else was in the same boat, they also would need to work out digital equivalents for their normal team ceremonies and so I could piggy back and observe those easily enough.
I quickly hit a problem. While this approach was fine and would yield accurate data for the known unknowns (see this post for some context) such as the “What they do” sub-tree, it is easily corrupted into opinion (e.g. “How they think”) or even a duplicitous facade, portraying a view that they believe is socially acceptable even though it’s not the reality (e.g. “Character traits”).
I’m currently exploring what I can infer reliably from more open “essay writing” styled requests. For example:
- Please describe your recollection of the last completed iteration, highlighting the events that you personally saw as significant for your role in the team.
- Please describe the events during the iteration that led you to believe for the first time that your iteration goal may be at risk unless you and your team were able to get on the front foot.
- Please describe the events that led your team and product owner to collectively agree what stories were going to be brought into the current iteration.
I’m exploring the different perspectives each team member has on the same shared experience. My hypothesis is that it’ll give me a few insights into how various team members think (relative to each other, as it were) and maybe a few nuggets about some of the more prominent personality traits that I need to pay attention to. I’m also hoping that the different language styles would be useful, but it seems a bit too early to tell.