The anatomy of my typical coaching engagement

Context

COVID-19 has forced the issue. All my teams are now distributed because everyone’s working from home. As a coach, this has given me a few things to think about. Mostly about how I need to rethink many of my coaching strategies, as they mostly take advantage of the rich information flow that’s tacitly a part of face to face.

As part of my attempts at designing new coaching strategies that could be used with entirely remote teams, I’ve been going back to basics. This post is about the basic structure that my coaching engagements end up being designed around.

Structure

Broadly speaking, I’ve found that all my coaching boils down to one of two categories of topics – known unknowns and unknown unknowns. My coaching engagements usually have two strands running, one for each of these categories. They have different cadences and topics from the “unknown unknown strand” can make their way over into the “known unknown strand”. I’ve not yet seen a topic move in the other direction. Please read The Structure of a Coaching Intervention for a more accurate view of the content I cover when I coach.

Known unknowns are relatively straightforward. This is closer to training, or facilitated learning. Both coachee and I are clear about what knowledge is needed, and we can usually rely on accurate insights from the coachee about their levels of expertise and whether or not it is increasing. I usually end up producing a catalogue of concepts and lesson topics, and my coachee orders them in a list. I suggest changes to the ordering only if I feel there’s a more consumable flow of content (or some pre-requisites). This also has the handy side effect of demonstrating how a delivery team and a product owner can work together to collectively order a backlog.

Unknown unknowns are much harder (especially if the gaps are deep ones such as culture or values & beliefs). Some unknown unknowns can be converted into known unknowns with identification (as there’s a degree of unconscious knowledge in the coachee). Maintaining a general principle of doing no harm, I usually end up doing something along these lines

  1. Observe the natural state
  2. Form a hypothesis
  3. Run an experiment to test
  4. If proven, identify “treatment” options
  5. At some point, bring the coachee up-to speed with what’s happened
  6. Together with the coachee, agree the treatment option
  7. Design the treatment plan
  8. Implement, measure effect, choose to keep or roll back
  9. Restart the loop.

Step 1 cannot be rushed, otherwise my biases play too big a part. In step 8, I’ve only ever had to rollback once in my career, otherwise I’d never have even considered it an option.

Remote Execution

For the known unknown category of topics, being remote poses no fundamental problems, mostly logistical challenges and a greater noise-to-signal ratio in the communication between my coachee and I. It also adds delay to the building of rapport, but that is less crucial when both parties know exactly what needs to be learned, as the coachee can also attempt to infer credibility by their perception of the quality of my coaching materials (legitimately or not is beside the point).

Being remote adds a lot of complexity to my structure – specifically the first step (but none of the steps gets away unaffected). I’ll write up how I approach this later and link it.

Cultural factors that affect your designs

Context

COVID-19 has forced the issue. All my teams are now distributed because everyone’s working from home. As a coach, this has given me a few things to think about. Mostly about how I need to rethink many of my coaching strategies, as they mostly take advantage of the rich information flow that’s tacitly a part of face to face.

As part of my attempts at designing new coaching strategies that could be used with entirely remote teams, I’ve been going back to basics. I need to think about how cultural factors play a part in how I approach coaching. I’m using Geert Hofstede’s cultural dimensions as a framework.

Power Distance

This is the extent to which the less powerful accept and expect power to be distributed unevenly.

  1. Low Power Difference – people prefer to be engaged irregardless of their “position”. They’re more willing to challenge concepts if they disagree, but if they’re persuaded, they become strong advocates. This is where I can find future coaches in order to make myself obsolete.
  2. High Power Difference – people like authority, they prefer solid structures and rules. Agreements can be more easily obtained if they perceive you as being more powerful, but those agreements could swing to the next authority figure that comes along. If enough of the team is like this, then I’ll have to leave something like a “Documented Process with an Owner” to act as an authority figure.

Individualism vs Collectivism

This is to what extent the consequences of an individual’s actions are thought about.

  1. Individualism – These folks take the initiative and act on their needs and desires. They make decisions for themselves. They can be partial to “what’s in it for them” discussions. Maybe focus on how changes can help their career progression.
  2. Collectivism – These folks consider the impact of their social groups such as their teams – e.g. “what will my friends think if I did this”. Discussions about how collectives they care about (their team, their community of practice) can be helped can be effective.

Uncertainty Avoidance

This is to what extent uncertainty and ambiguity are tolerated.

  1. High Uncertainty Avoidance – Prefer deductive approaches, they think things over, make decisions based on reducing the perception of risk (NOTE: that’s independent of actual risk reduction). Also make decisions that follow their preferred deductive strategies (e.g. rational, intuitive etc). Focus more on limiting the downsides, but pay special attention to how they reason.
  2. Low Uncertainty Avoidance – more open to new ideas, better risk taking appetite. Articulate the potential gains that could be achieved.

Tough vs Tender

This is to what extent aggressive competition or nurturing cooperation is preferred. This used to be called masculine/feminine but I prefer more gender/sex agnostic terms as they’re less controversial, especially with new coaching engagements.

  1. Tough – prefer heroic achievements, material gains and competition. Might be worth engaging from a perspective on how the person can stretch themselves, how they can get reward and recognition.
  2. Tender – prefer a more nurturing and caring approach. More interested in a balanced work/life split. Might be an overlap with Collectivism?

Short Term vs Long Term Orientation

This is to what extent time exists in a person’s mental model. From a coaching agile teams perspective, I’d say short term is 1-3 iterations, and long term is 6 months – 1 year.

  1. Short Term – More focus on past and present. Prefer quick results in line with known values and traditions. Language like “low hanging fruit” will probably resonate. These folks will need habit forming nudges to get beyond short term thinking.
  2. Long Term – Better focus on the future. More likely to make trade-offs with short term pain for longer term returns. You’ll need people like these if you’re going to attempt “seismic shifts”.

Indulgence vs Restraint

This is the extent to which a team would act in a way that fulfils their desires, or acts with restraint according to their environmental rules (e.g. office dress code etc)

I’m not really sure if there’s anything I can usefully do with this dimension. However, if something comes up, I’ll amend this post.

The Structure of a Coaching Intervention

Coaching is an act of leadership. The main purpose of coaching a team is to improve the overall effectiveness of that team. Three key dimensions in assessing this are:

  • Productive output that meets or exceeds the standards of quality/quantity/timeliness of the consumer
  • Social processes the team use that enhance the future capability of the members to work interdependently as a team
  • The group experience that contributes positively to the learning and personal wellbeing of the members

There is an additional factor, often classed as crucial to team effectiveness – the quality of personal relationships within the team. However, I’d class any work done with the team that directly addresses problems with personal relationships to be counselling in nature, and isn’t in scope for this post. In my experience, when the delivery effectiveness of a team improves, the morale boost in the team members has a side-effect of improving personal relationships.

The relative importance of these three dimensions will vary over time, but successful teams always make sure that they are all considered and balanced over time, never completely sacrificing one to optimise the other.

The effectiveness of a team at performing a task is influenced by these three key performance factors:

  • The effort a team expends
  • The appropriateness of the strategies and techniques that the team uses
  • The skills and knowledge that the team can bring to bear

Therefore, in order to have any sort of effect on a team’s performance (beyond the Hawthorne Effect), coaching will need to help one or more of these factors.

There are three important factors to consider when delivering a coaching intervention, and all three must be balanced in order for the intervention to be effective:

  • Content
  • Delivery approach
  • Timing

Coaching Content

The messages that are conveyed during a coaching intervention typically conform to one or more of these three main patterns:

  • Motivational: coaching that addresses effort, e.g. inspiring team members to increase effort, or minimising freewheeling
  • Consultative: coaching that addresses strategy choice, method selection, helps teams determine locally optimised methods
  • Educational: coaching that addresses skills and knowledge gaps

It is important to use the right content to address the specific challenges that the team has. For example, if the challenge is a shortfall in specialised skills needed for a task, providing a highly rousing motivational speech isn’t going to help.

Three Main Coaching Approaches (plus a fourth – “eclectic”)

The reality is that most coaching interventions will have aspects that originate from more than one of these three approaches.

  • Process Consultation: structured/clinical examination of interactions from a workflow perspective:
    • between the team and external teams/stakeholders/etc
    • internal to the team
  • Behavioural Models: feedback on individual and team behaviours, mainly focussing on relationships and how feedback is given and received; often involves operant conditioning
  • Development Coaching: identification of areas that need improvement, along with focussed time set aside for learning / training sessions
  • Eclectic interventions: ad hoc interventions, with no specific underlying theoretical model; most commonly limited to personal relationships when coaches aren’t familiar with the specifics of the work the team is doing

It is important to use the most appropriate coaching style / approach to suit the context, the audience and the message. For example, when working with an inexperienced team to improve the effectiveness of their in-flight process flow, it is better to use their real work and their real process as opposed to a classroom styled session with an abstract case study.

Intervention Points

Teams go through different phases as part of them starting, working on, and finally finishing, a piece of work. There are several broad model categories that attempt to describe the team and their approach to work temporally (see https://en.wikipedia.org/wiki/Group_development ). Two patterns that I’m broadly aware of are:

  • Incremental (or Linear) Models (e.g. Tuckman)
  • Punctuated Equilibrium Models (e.g. Gersick)

The interesting thing (for me) is that I’ve seen groups of people becoming teams display characteristics found in both. For example, I see teams regularly using retrospectives, but for the most part, the improvements are relatively narrow and focussed in effect. However, there are usually a small number of seismic shifts in ways of working – usually as a result of a significant “precipice” being felt. The most common precipice is the realisation by the team that they’re halfway through their estimated (or constrained) timeframe. These events are where coaching can deliver the most impactful benefits and are typically found at:

  • the beginning,
  • the midpoint, and
  • the end

A side-effect of teams splitting large blocks of work down into smaller pieces (e.g. Epics, Stories etc.) is that these events occur far more frequently – each user story has a beginning/midpoint/end set that could be used as opportunities for coaching interventions. I’ve rarely seen coaching interventions at user story boundary, but I have seen them at Epic or Feature level.

Other team processes that also create opportunities for beginning/midpoint/ending events to occur include the use of iterative (or sprint) based development, using a delivery lifecycle (such as DAD’s risk/value lifecycle) etc.

Designing a Coaching Intervention

The design and structure of a team has a significant effect on the effectiveness of coaching interventions. “Well designed” teams gain more value from a coaching intervention, even a poorly executed coaching intervention. “Poorly designed” teams can suffer negatively during a poorly executed coaching intervention. I’ll focus on team design in a separate post. For this post, I’ll assume no ability to fundamentally change the structure of a team to better match the workload.

Looking at the three performance factors, what are the underlying constraints? If a team has a constrained “strategy & technique” factor, then any attempts to change the execution strategy is likely to be met with frustration.

Once you have some clarity on the performance factor you can help improve, pay attention to when you introduce the intervention. Teams at the start of a piece of work are generally unwilling (or sometimes even unable) to have an informed discussion about what their optimum delivery strategy should be – it’s usually better to get started and then make an adjustment at the midpoint event (when they have some actual experience to base the decision on).

Target Performance FactorEffectiveAvoid
Effort – Motivational Coaching
– The beginning
– Consultative Coaching
– Educational Coaching
Strategy  & Technique – Consultative Coaching
– The midpoint
– The end
Skill & Knowledge – Educational Coaching
– The end
– Motivational Coaching
– The beginning

Once you’ve got a sense of the target performance factor, the timing of the coaching intervention and the key messages that needs to be conveyed, the next step is the execution approach. It’s worth investing effort in explicitly designing coaching interventions (not to mention ensure sufficient variety to keep things interesting for you and your team). However, there are some natural alignments between the conceptual approaches and the content to be conveyed which could help get you started.

Coaching Content Approach
Motivational Behavioural Coaching – personal motivation, team camaraderie.
Developmental Coaching – focussed time set aside for “kick off events” (such as an Inception workshop or a Visioning workshop).
Consultative Process Coaching – clear understanding on pros and cons of alternative techniques so a mid-flow course correction can be made.
Educational Development Coaching – periods of reflection and improvement via a team retrospective, knowledge transfer via lunch & learn sessions, skills acquisition sessions using learning katas.

Building a Knowledge Sharing Community

Why am I trying to establish this?

Having an effective knowledge sharing strategy that my consultants and coaches use effectively can significantly boost the quality of their deliverables on engagements, as their access to knowledge and experiences will be richer. Richer knowledge leads to better decisions which lead to better outcomes blah blah blah.

No really, why?

The truth is far less grandiose. And much more personal. I want better relationships with my colleagues. And the main reason for that is selfish. When I’ve got something interesting/gnarly to solve, I’d MUCH rather solve it collaboratively with someone. I find the ideas that come out of a buzzing pair/trio are generally FAR superior (not just in terms of merit, but also the emotional responses – things like surprise, delight and even just pure joy) than anything I’d come up with on my own. A major contributor to that heightened emotional response is the fact that it’s a shared experience – this has a reinforcing effect on the individuals.

This topic is also related to my post on Courageous Executives – I think being able to create an environment where knowledge and help is shared freely and easily is helpful in establishing a progressive organisational culture.

Some things to consider

The first thing I need, is critical mass. I need enough colleagues with sufficient latent willingness to participate to increase the odds of interesting interactions to occur.

The second thing, is to recognise the reality of the group dynamic. I work for a consulting organisation, and like most others, they staff people on engagements. Those engagements have teams. Back at base though, I’m grouped with a set of similar people under the same line manager. That line manager’s “team” is not a team from a behavioural dynamics perspective, regardless of how the individuals describe themselves. Esther Derby is my go-to source for concise articulation of what it means to be a team.

The third fundamental aspect to consider, is how people participate. The “1/9/90” rule of thumb has been around for over a decade now, potentially longer. A quick recap: For online groups, there are three broad categories of interaction

  • 1% of the population will initiate a discussion thread
  • 9% of the population will actively contribute to discussion threads
  • 90% of the population will lurk

I also reasoned that in order to sell what I wanted people to do, it needed to be more engaging/arresting than just these numbers (which no doubt many of my target audience would have heard already, so there’d be little impact). While daydreaming about how to go about launching this, an idea flitted across my mind, which amused me. I ran with it, just to see how far I could go. Fishing.

  • Lures: These would be the “1% and 9%” of the population. Their job is to make the environment interesting/appealing enough for the others to participate.
  • Fish: These are the 90% of the population who lurk. My objective is to convert them into lures by engaging them.

Above all else, the most important thing to remember was that knowledge management was all about people. We have to avoid the temptation to create yet-another-document-repository, as those end up generally being pointless (keeping a stack of documents current is a huge time investment, so very few people do – the documents become outdated quickly and users lose confidence in the repository as a source of relevant information).

How did we start?

The first step was to get a sense of that latent willingness that I needed. To avoid unnecessary confusion, I stuck to a typical technique – I ran a workshop. The stated objective was to understand the key topic areas / themes that as a collective, we had some self-professed expertise in. The exam question was

write down topics, regardless of scale, that you would be happy for a colleague to come to you if they needed some help

Approaching the audience in this way would nudge them into feeling valued from the outset (the alternative would be giving them a candidate set of themes and asking them to sign up. The list at the end of both approaches would be the same, but the first scenario would have far more engaged individuals as they’d own the list). This workshop also let me find co-conspirators.

Then what?

In a word, admin. We had to create a navigable map of the topics that the audience had supplied (it would help people find the right place to ask questions). In the end, we settled on a very basic two-level tree consisting of high-level themes and more detailed topics. That allowed the grouping of individuals to be based on themes with related topics. The main rationale was that as experience and knowledge changed over time, the specifics of the topics would evolve, but the main theme would remain constant. That allowed for stability of membership – and that membership stability is a significant factor in determining whether or not a theme would survive. The candidate themes also had candidate lures – they were the list of people who volunteered for the topics that were under that theme.

We had to sell the themes to the potential lures.

We also had to set some expectations about what being a lure entailed. By this point the term “Theme Guardian” had started to emerge as the role that was to be played. This is what we ended up with.

  • Guardians own their Theme
  • Guardians are responsible for the quality and integrity of the Theme’s content
  • Guardians should invest in PDCA cycles to improve the environment in the Theme.
  • Guardians need to evolve their vision and strategy for their Theme.
  • Have “something” to help new joiners understand your Theme.
    • This doesn’t necessarily have to be a document. It could be quarterly intro sessions on WebEx (for example).
  • Set expectations of how you’d like the community to operate – and remind your community regularly

I find analogies very useful as abstraction models to help me understand a domain/problem. In the event that at least some of the candidate guardians operated in a similar manner, I picked a couple of potential models that they could use to refine their thinking about how they wished to operate:

  • Town Planners and Communal Spaces. What makes some public spaces incredibly successful, and others turn into ghost town?
  • Aboriginal Storytelling. In particular, explore the claims that the Dreamtime stories have remained intact for over 10,000 years without degrading, despite only having a verbal/pictorial, not written form.

Selling the concept

Now that we had a starting position (themes, candidate guardians, some guardian responsibilities), we needed to launch. To help that, we produced some general use guidance on themes:

  • People are at the core of any successful knowledge management strategy.
  • Information held in a person’s head is updated as a by-product of things that person does. Information stored in documents requires additional explicit effort.
  • For a Theme to be useful, knowledge needs to flow from person to person.
  • If a Theme’s only got one person who’s interested, it’s not a Theme.
  • When a question is asked, directly answer. Even if it’s been asked before. Never rely on a document (or link etc.) to answer for you. If necessary, end your answer with “this document/link/other goes further” (or words to that effect).
  • Think about what your “background radiation” looks like. Themes need to feel active otherwise you won’t get people stopping by and asking questions.
  • Have a variety in the complexity / subtlety / nuanced nature of the conversations and discussions. For example, if you only have very high brow discussions, you’re likely to put off the inexperienced. If you only have introductory content, then the experts may not participate.

Launch Day

These were our objectives

  • Start small: We picked one Theme that the co-conspirators were willing to act as Guardians or as participating members. We would attempt to orchestrate and create an active community for that theme.
  • Momentum: We wanted to create some observer habits in the wider community. With enough people checking in daily (for example), we’d greatly increase the chances that conversations would spark up. But we had to kick start the making-it-worth-everyone’s-time process.
  • Win over an influential sceptic: Having a known sceptic promote what we were trying to do would help persuade other sceptics that there may be some mileage in investing in this strategy.

What happens/happened next?

1 Week After Launch

There’s a smattering of interest from a handful of people. A few posts have been made and there has been some commenting on posts. Some of the early efforts from the co-conspirators have been around motivating and inspiring the community to participate. There is some optimism around that this approach feels different (probably because it isn’t tools oriented).

Predictions

It’s still early days, but these are my (current) predictions.

1 Month After Launch

The conversation topics broadly split into a handful of themes. Most of the themes appear to be consistent with what emerged from the initial workshop, but the actual topics discussed are quite different. There is some dissonance from the earlier adopters as there are multiple unrelated themes being discussed in the same “place”, causing confusion.

3 Months After Launch

Enough interest in different themes has triggered new spaces on the platform for the conversations about those themes to be segregated, to simplify the cognitive load on the users. There is some frustration from some members who are interested in multiple topics, most likely due to how the individuals have modelled the interactions mentally – e.g. why should two people who are talking about a range of subjects have to keep switching which “chatroom” they converse in. Relationships are still point-to-point.

6 Months After Launch

Most of the theme chatrooms are now dormant, most of the activity has gravitated towards one or two Themes. There’s some blurring between the competing mental models – relationships are person-to-person and person-to-community.

Analysing my predictions

One of the most significant challenges I’ve seen in Knowledge Management things is the belief (usually tacit) that it’s all about the content. I believe it’s all about the relationship, and the knowledge of who to talk to when a person needs to know something. My predictions have a base assumption that Knowledge can be structured and organised at a fine grain. I think that’s an assumption that’s also being made by the majority. I’m expecting this assumption to be proven to be false and that we will pivot back to trying to be more of a community than a knowledge repository. Looking at the population numbers, I don’t believe there’s any need for more than two or possibly three communities (eventually).

Are you limited by your Agile Coach Sourcing Strategy?

This is about a revolving door programme of hiring coaches. One of the things I’ve observed regularly, is that these kinds of hiring programmes create an implicit timeframe by which improvements must be “delivered”. In itself, that’s not necessarily a problem. What is a problem, is that the timeframes are nowhere near long enough (IMHO) if the aim is to change the culture.

How you measure your coaches also has an obvious effect on your outcomes. Procurement plays a big part here. I’ve seen a lot of coaches who have their success defined by some variation of how much effort they expend. Training courses run. Numbers of teams “coached”. Amount of collateral documented in a wiki/repository/etc. It’s even worse if that’s also what the coach genuinely believes is a measure of success.

It’s easy to buy the visible stuff. However, the visible stuff has no sustaining ability – that comes from the hidden stuff. Agile’s a culture, but how do you buy a culture? It’s much easier to buy a new set of processes, dress code, office layout, stationery, reporting templates etc.

By buying the visible stuff, you easily get to a set “maturity” of what-to-do (because your coach has implemented this a million times), but you might lose the learning-about-why and your ability to improve at some point comes to a crashing halt when your coach runs out of instructions to give you (or they leave). You’ve substituted thinking for doing what you’re told because an expert tells you.

One of the things that could lessen the likelihood of this happening to you is longevity. Although that does bring its own set of challenges. Longevity can come from humans, or guidance that’s respected enough to be followed (or at least attempted) – e.g. the guided continuous improvement advice from Disciplined Agile Delivery’s collateral.

Longevity can increase the chances that the underlying factors get some attention – beliefs, culture, mindset. But longevity is hard. When things go wrong (and lets face it, things always go wrong), it’s easy to blame the changes that are being attempted. I’ve often seen blame being thrown about as a precursor to the environment becoming more toxic. In those environments, unless there’s sufficient emotional investment, coaches leave.

In my view, the most effective counteracting force against that toxicity, is leadership. Your senior leadership must have the trust of the members of the organisation. However, trust doesn’t come from great speeches but from credibility. That means the senior leadership must also evolve and adopt a more collaborative/open/trusting/etc culture. They must behave differently. And they also need to provide regular, ongoing and consistent reassurance that the environment is safe so that teams can evolve to a more agile culture with no repercussions for steps that don’t quite make it on the first try. I think that works because humans emulate leaders. If the leaders are open and collaborative, then the teams are more likely to also become more open and collaborative.

Dear Board, what sort of “Agile Transformation” are you really after?

My problem with an “Agile Transformation” as a term, is that it’s not really helpful when trying to talk to people.

OK maybe if I used the definition of an Agile Entity as a thing that continuously adapts and evolves to best take advantage of it’s environment, then an “Agile Transformation”, being pedantic, could represent that first step the Entity takes from it’s Creation State to the first Changed State, with the constraint that the Changed State includes a working mechanism for internally triggered evolution (irrespective of how effective).

However, that’s also an unhelpful definition, as I haven’t seen that interpretation in anyone at C-Level who “buys an Agile Transformation Engagement from a Consultancy Organisation”. And that’s what I wanted to write about here. What I see there is usually something along the lines of “We should be better at our IT Development. Other organisations have used Agile and they seem to be better at IT. Maybe we should get some of that Agile IT to increase our effectiveness”.

Therefore I’m parking that thought, and once I’ve worked out how to clearly articulate what my opinion is on that subject, I’ll link to it here.

In the mean time, this is a list of questions I think are worth knowing the answers to as soon as possible in the life of an “Agile Transformation Engagement”. Or even before one starts.

Agile Organisations have very different cultural styles to hierarchical / bureaucratic / “traditional” (for the defensive clients) organisations. A Transformation Initiative (if such a thing can exist) will be about helping an organisation transform itself culturally into something else, one with more pronounced Agile Characteristics and Traits. I think anything that maintains the cultural status quo (especially if it’s a “negative-in-the-context-of-an-agile-organisation” one) is heading towards the Lip Service end of the adoption scale.

Warning: Some of these questions can be tricky to ask without risking being fired :-). All of these are aimed at either the Sponsor of the Transformation Engagement, or the C-Level Board if it’s broad enough.

Scope

Question: Where do you WANT to draw the boundary for the Transformation Initiative?

Question: Where do you HAVE to draw the boundary for the Transformation Initiative?

Outcomes

Question: WHAT do you define as “a Successful Transformation”?

Question: WHY do you think you need “an Agile Transformation”?

Question: Are you “all-in” on this Transformation? What happens if it’s not successful? Do you need a Backup Plan (or Escape Plan)?

Question: If the Transformation results in jobs changing, CAN you update your policy / HR strategy etc to suit? WILL you?

Question: If the transformation results in making some people redundant if they are unable/unwilling to re-train to the target operating model (candidates include middle managers), WILL you make them redundant?

Question: What did you have to do in order to get Board buy-in for the need for “an Agile Transformation”?

Question: When do you “need Demonstrable Results”? Why then? What constitutes “Demonstrable Results”?

Question: Do you have a “Trusted Adviser” to fact-check what you’re being told? If not, what is your level of trust? How can that be increased?

Sustainability

Question: What’s your strategy for sustaining the Transformation Initiative after I’ve left?

Question: What would happen if “after a while” (e.g. a couple of years), your organisation reverted back to the operating model as it stands now? Do you have to prevent that?

Finances

Question: How much are you willing to invest? Over what time frame? Is any of that investment conditional on evidence of progress?

Question: Can you tolerate the “Agile Transformation Initiative” as an annual overhead cost to be paid before projects and change budgets are calculated?

Question: Can you tolerate the “Agile Transformation Initiative” as just another project and therefore will need to justify its budget?

Agile Brands

Question: Is there a perception in the “entity-under-consideration” that Brand A/B/C is the right one? Have conferences, articles, experiences etc influenced that perception?

Question: Is there a strategic goal of “Installing” / “Implementing” Brand X? Or is the strategic goal “Adopting” Brand X?

Question: What happens to your Credibility / Authority / Respectability if despite the prevailing “Brand X Bias”, an alternative Brand is Implemented / Adopted?

Janus and the art of partitioning

Why Janus? Well, not only is he the Roman God of Beginnings and Gateways (or doors, transitions, journeys, that sort of thing), he’s normally depicted with two heads, one looking to the past or beginning and the other looking to the future. Seems to resonate with what I try to do with my clients – help them along a journey.

Why this post? It was triggered by me reading the book Unlearn by Barry O’Reilly. The book helped me crystallise or make explicit something I think I’ve been doing often enough to be considered “typical behaviour” – the act of unlearning.

I’ve been thinking about how to use this new found explicit conscious awareness to help my current employer (as well as my current and future clients). My typical role on an engagement is some form of…no wait, this link might give you a sense. Alternatively choose any number of words from the following set and arrange in any order to give you my title (naturally, duplicates are encouraged) “agile/ninga/coach/therapist/comic/beer-buyer/disruptor/transformation/hygienist”. The key thing about my clients (and my current employer) is  that their overall delivery maturity is nothing worth writing home about. They’re certainly no bleeding edge delivery outfit, constantly testing hypotheses by using practical experiments, with unicorn tendencies.

So who hires me? Mostly Laggards and Late Majority organisations (See Everett Roger’s book Diffusion of Innovations).

What does that mean for me? Generally, the mental models I have in my head for how “software delivery should work” are two or three decades(*) ahead of the executives and senior management types that I spend time with. That means that unless I take great care, I’ll end up using language that’s incongruous with the recipient’s world view. And there are enough snake oil salesmen out there to replace me, making it easy to put lipstick on a pig – see the Internet on cases where “agile transformations don’t work” or “agile transformations not delivering on orders of magnitude improvements” or variations on the theme. For me, that’s Janus looking forwards.

How am I trying to solve this? I learned a foreign language. This one’s called “Management from Yesteryear”. I learned it because if I was to stand any hope of working out if something I say is being misinterpreted, then I need to understand how it’s interpreted. Some people could call this empathy, but I disagree. It’s more a model of a person from the nineties (say), to help me understand how a real person would behave. For me, that’s Janus looking backwards.

So how does Barry’s book fit into all this? Well I realised that if my client needs to evolve by 20 years, they’ll need to go through an awful lot of unlearning and relearning. That’s assuming that if someone is going through that much evolution, they’re able to skip a few of the intermediate states. If that’s not possible, well that just increases the amount that needs to be learned and unlearned in a comparatively short space of time.

So what I need to do, is help them get starting along that journey, and supply the occasional nudge if they start going too far off track – say unlearning something that’s still relevant or learning something that isn’t helpful. That’s harder than it sounds, as it’s tricky to understand what off-track actually means, not to mention how on earth I’d be able to observe this. What would be ideal, is if they themselves could work out how to tell if they were going off track. A more realistic scenario is that I’d have a sense of how they’re thinking and try to use that to gauge the degree of discomfort they’re feeling and from that attempt to infer the degree of off-track-ness. That said, sometimes it’s helpful in the longer term to learn something, realise it’s incorrect and fix that. All adding yet more uncertainty into the “are they on track or not” overly simplistic question.

That’s where my internal-model-of-a-person-from-the-nineties comes in. I fancy myself in (very) amateur dramatics circles, as someone of the method acting school of thought. When working with someone, and I’m asking them to go through cycles of unlearning and learning, it seems only fair that a part of me goes along that journey with them. It’ll help me build some empathy. It’ll also help me spot when things aren’t going well, because in addition to seeing their expressions, I’ll be feeling similar things too. It’ll help them trust me a little more than otherwise. It’s a great way for us to discover potentially exciting new things that neither of us would have foreseen. And finally, that shared experience is also a good foundation for building some psychological safety.

A brief segue into psychological safety.

I’m trying this approach with my current client, and so far it’s been proving to be an interesting experiment. I’m not too clear about how cleanly I’m partitioning the me-from-now and the virtualised-me-from-the-nineties, but if nothing else, I do appear to have more empathy and connection with my client. So that seems to be positive. I’ll keep trying this approach and see if it gets any better or give’s me something different. Might even blog about this later.

 

 

(*) I know that sounds harsh, but for example organising teams by components and architectural layers for efficiency reasons is just so nineties. And not in a cool retro way.