Organisational GRIT

Many people wonder, "What's the difference between a successful organisation, and one that struggles?"
Throughout my decades of consulting and observation, I have observed four factors that I call "GRIT."
Take heed of these, and you're most likely in good shape. On the other hand, ignore these at your own risk.

The GRIT Factors

When analysing what's going on in a company, there are four factors at play that create GRIT - in healthy organisations, these are naturally tended to and require little effort.

However, unhealthy systems of work neglect one or more of these, with dire consequences:

Goals

The first factor of a healthy system of work is that people have clear goals: things we want to achieve in the future. That can be the personal goals, team goals, business goals.

Best case, everyone has all of these - and all of them align.

Worst case, people have no goals, in which case they will show up just to get paid.

The worst case scenario lends itself to all kind of doomsday scenarios for a business owner: nothing getting done, people wasting their time with unfruitful conflict, or people leaving to make more from their life.

Relationships

The second factor of a healthy system of work is that people have positive relationships with the people around them. That includes their team, other departments, business partners and customers.

Best case, everyone has sustainable, sufficiently close relationships that make their network resilient.

Worst case, people's relationships are toxic or adversarial.

I don't think it requires further explanation what happens when the customer is treated like an enemy - but many organisations seem to be entirely oblivious to the cost in time, effort - and ultimately money - that is wasted with infighting.

Improvement

The third factor of a healthy system of work is that people continuously pursue improvement at all levels: make work faster, easier, better. Reduce risk, friction, cost. Make customers happier. Go home with less stress and more happiness.

Best case, the system of work makes that a natural part of the work, and everyone actively contributes.

Worst case, processes and tools deteriorate and everyone is looking the other way.

It's easy to figure out what happens when improvement is not part of people's thoughts or actions, but that's the reality in many organisations: The tyranny of the Urgent makes improvement fall over the edge until the cost of fixing things has reached frightening levels, and people are scared to even get started.

Tomorrow

The fourth factor of a healthy system of work sounds very abstract - "tomorrow" - so let me make it a bit more tangible: Tomorrow, a competitor may arrive on the market. Your business model may get disrupted. A key player in your team may move on. Are you prepared?

Best case, the company is constantly and persistently putting efforts into being prepared for the uncertainties and inevitabilities of tomorrow, and people are not scared to look into the future.

Worst case, everyone knows that the business is heading downhill, but people close their eyes to this uncomfortable reality. And with every day, the looming specter of Tomorrow becomes more threatening.

It doesn't take a lot of imagination where a company is headed when they have no plans for Tomorrow. And yet, few can articulate a clear plan.

Building GRIT

Building a company with GRIT is easy if that's how you've always done it. But if you've never done it, it's staggeringly hard. In fact, it seems insurmountable. So I'll give you a few pointers for getting started on the journey of building GRIT.

1. Itemize the most important Challenges, Opportunities and ongoing Activities in each sector.
2. If a sector has few or no items in it, it's a blind spot. Take some time to think!
3. Ask yourself, "How can we improve our situation?"
4. Take action on the first item and see where it leads you.

Now, that wasn't hard, isn't it?

From now, you may frequently revisit your GRIT matrix, see what pops up and whether you're making progress.

By taking GRIT building serious, you will see a significant reduction in risk, stress and fear - and significant boosts in sustainability, employee satisfaction and business outcomes.

Give it a try!

SORT Canvas - Focusing change discussions

Often, everyone in the room has a different perspective on what could and should be done, and discussions go in circles. How do you facilitate the discussion to move forward?

I have created the SORT Canvas to discuss high-impact change initiatives. Its main area of applicability is complex, systemic long-term change, i.e. organizational change initiatives. 

It can also be used for Team Retrospectives, although that's not its main focus.

This simple canvas allows you to steer discussions about change initiatives towards agreement and first results. Plan 2 hours for a full canvas session.

An example use case for the canvas might be SAFe's "Inspect and Adapt Workshop", when the trains needs to discuss more than small changes.

Discussion Ground Rules

1. Have everyone in the room: Make sure that all parties contributing to the situation and the potential solution are in the room. This doesn't mean all people - representatives suffice.
2. Choose a topic: Pick a single topic, and focus on that topic. Agree to de-scope topics that are only borderline relevant or unrelated.
3. Use abstractions: Complex environments have a lot of nitty-gritty details. When discussions get into details that aren't relevant for the group as a whole, abstract.
4. Align perspectives: Every person has a different perspective when the discussion starts. Instead of having people elaborate their own perspective, focus the discussion on "What do others need to know?" and "Where is my perspective different from that of others?" in terms of the four topics.
5. Move sequentially: Explain the four segments of the discussion (Situation, Objectives, Roadmap, Tasks) - and decouple the steps. Do not pre-empt by jumping between the four sections. Have points in the discussion where you explicitly ask, "Can we move on to the next section?"
6. Write it down: As early as possible, write down a point. Move as quickly as possible to answer the question, "Can we all agree on this?" - if not, make sure disagreement is heard.
7. Stop circular discussion: When we return to a point that's already written down in the current section, stop.
8. Clarify the goal: The goal is to come up with a common understanding of what problem we currently have, what we are going to do about it - and how that will help us reach a better state.

S - Situation

The first step is to come to a common understanding of which situation we are currently facing. Especially in larger organizations, people have vastly different perspectives - more so if they come from different departments and experience a clash of interests.

Describing the situation usually starts with a short description of either the main problem we face or the main change we want to make.

For example:

• an initial problem description could be: "IT doesn't deliver high quality" versus "Business is too vague on Acceptance criteria". The conflict is obvious - the solution isn't.
• an initial change description could be: "We want to move from specialist teams to cross-functional teams."

Neither of these are workable, and there are typically a lot of reasons why the situation currently is like it is. Note down the key problems, such as unwanted side effects or unfortunate long-term outcomes along the way. The description of these will help us focus the discussion for later steps.

Techniques like Five Why, CLD or Fishbones could be used to guide this discussion, although that may already be method overkill. Most discussions are sufficiently focused.

Try to get the most critical 5-10 points written down before moving on.

After describing the situation, we can choose to limit our further discussion to a subset of the situation or problem statements before moving to the next section.

O - Objectives

Captain Obvious would state, "We don't want to have those problems any more" - although that is too generic. Let's be specific on what the future would look like: which problems are gone, and how is it instead?

For example:

• An objective describing the future state could be: "IT and business agree before implementation on what defines high quality" or "A single team has both all the competency and authority to deliver Working Software to Production"

As you noted in my example, they contain the words "and", so they are indeed more than one item, and should be separated out, for example the first item might turn into:

• "Business agrees that the solution is of high quality when the Acceptance Criteria are met",
• "Teams agree to deliver solutions that exactly match the Acceptance Criteria",
• "Teams will pro-actively communicate when AC's aren't clear",
• "Both parties will collaborate to finalize the AC's before the Sprint",
• "When teams feel AC's previously agreed upon no longer make sense, they will seek dialogue."

Point in case: specifying an objective without "And" or "Or" ensures that different perspectives are properly discriminated, conflations are resolved - and ambiguity is clarified.

It's entirely valid to have multiple objectives: it means that the change might be more complex, or that only a few of them would be pursued in the remaining discussion.

In some cases, a single change action will create progress on multiple objectives - in that case, it's good to be broad on the objectives. Otherwise, it might be a good time to pick a subset of objectives before moving to the next section.

R - Roadmap

When we know where we stand and where we want to go, it's a good time to start asking: "How do we get from here to there?"

During this stage of the discussion, we should try to find the most effective way to proceed from the current situation to where we want to go.

Simple changes mean that it's a single change, and that would also mean the roadmap is quick and easy. If all participants agree that no intermediate action is required, that's great - and we can move already to step 4.

More likely though, you'll have to iterate and make a series of incremental changes to achieve sub-goals. 

The purpose here, again, is not to make a comprehensive plan for perfection - it's to outline the major milestones on the road to success.

Returning to our example, the roadmap could look like this:

• "Align Definition of Done with Business"
• "Business people actively participate in Planning"
• "Everyone knows how to ask key questions in Planning"
• "Acceptance Criteria are robust"

While having SMART items on the roadmap is nice, it's much more important that participants agree on the roadmap items, their value and effectiveness. We also need to ask how fast the change would proceed. If we already know that it's going to be years until the objectives are achieved, it's not even important what the items further down in the plan are - what's important is that we agree that the first two or three points are actionable.

We will inspect and adapt anyways.

T - Tasks

Once we know the key milestones on our change journey, it's important to agree on the specific next steps.

To reiterate: the purpose is not to come up with a comprehensive change plan. The purpose of this activity is to get actionable outcomes of the meeting, clear next steps that we'll work on.

When we define tasks, we first need to agree on the most critical milestones on our roadmap - what we want to achieve first, as well as that which has the highest probability to "make or break" the change. 

Here are actions to consider:

• Moving forward quickly, i.e. "quick wins".
• Actions that minimize change risk, i.e. "pivoting".
• Building the groundwork for future change, i.e. "go slow to go fast".

For each action, make sure that everyone agrees they are clearly linked to the objectives and roadmap.

Once you have agreed on maybe a dozen potential actions, decide which are the first three you will tackle. Be specific on what you want to do, who will do it - and when. Ensure that people commit to taking ownership - never assign a responsible person!

The general rule applies that you can't assign tasks to people who are not in the room. What you can do is formulate tasks like "Get buy-in from <person> for <action>" and have an attendee take ownership. Once you have identified that the specific person is necessary part of the change process, they need to be part of further sessions.

Make sure there's follow-up after the meeting ends.

An approach that might come to mind for dealing with following up on the tasks might be the "POPCORN Flow".

Wrapping up

With all participants, agree that the meeting has described a relevant problem, a desirable objective, a feasible roadmap and important actions.

Agree to a future appointment to follow up for an Inspect and Adapt session where the SORT will be repeated - revisiting all four segments.

Teams: Slices, components, features - and false dichotomies

There's a massive confusion about what is a "feature team", what is a "component team" - and what is a good strategy to proceed. Consequently, many organizations follow the advice of "Agile Gurus" without reflecting on their reality. Let me bring a little bit of light into the topic.

The flawed model

You've probably seen this kind of model - the idea that "Cross-functional feature teams are able to deliver vertical slices of value". So, basically, you'd design a team where at least one team member can tick the box in each of the quadrants:

Does "Vertical slicing" mean you can do all  things on the horizontal domain on the vertical domain?

If you believe that this means you will have independent teams who can "deliver business value autonomously" - sorry to say, you've been taken for a ride! The mental model is flawed.

Here's why:
The model makes a massive assumption: that a "product" has only these dimensions. That may be a developer's (or IT person's) point of view. But - is that really true?

The hidden third dimension

Yeah, the Business - who cares about the business? Is that even important?

Yes - we forgot the business! There's a hidden third dimension in the model that adds another level of complexity. The response you'd elicit from a lawyer if you'd tell them that the Legal domain is "simple and easy to learn" would probably be quite interesting - the business domain is at least as complex as the technical domain - moreso when we're talking about international operations and get into multilateral agreements, cultural and language differences. Indeed, when we look at traditional sales organizations, we realize that just the single domain of sales often gets split across different lines.
Typical Sales splitting lines could be products, channels, markets or regions or customer segments. So, even each of the single business domains could turn out to have multiple sub-dimensions.

In large enterprises, the model is no longer two dimensional, "horizontal or vertical slices", it's multi-dimensional with a potentially incomprehensibly large amount of dimensions!
As such, we're not even making "slices" - the delivery of value would mean that we have to cut across n dimensions!

Defining your Product

Once we realize that we're crossing borders in more than two dimensions, we need to answer the question of "What is the product we're working on?"

Crossing what?

If we define "cross-functional team" as "a single team that can deliver end to end value", we need to be cross-functional in all dimensions!
Let me take, for example - a company that wants to add Widgets to their portfolio.
Widgets need to appear in search engines, on commercials, linked to the Online Shop so that people can buy them - Widget contracts need to be bullet proof both in procurement and fulfilment - Widgets need to get shipped to the buyers, who need to get charged correctly for their Widgets - have the amount collected from their account - and finally, customer service may need to settle disputes on Widget purchases. The simple "Widget" may thus require changes to a whole boatload of technical platforms, across a wide range of business processes - and there is no "end to end customer value" until all of these functions are implemented!

This, of course, begs the question:
Can a single team of developers manage all of this?
If the business processes, technology landscape and development processes are sufficiently simple, the answer may be "Yes".

And what if they aren't?
What if there are independent technical solutions for Online Shopping, retail, B2B sales, wholesale?
What if ERP doesn't happen in the CRM solution? And what if fulfilment is outsourced to a third party? All these conditions are normal in Large Enterprises.

Organizing Teams

Especially when transitioning towards an agile organization, it's important to accept current reality and learn to understand where we are, then move from there.

"You go to war with the army you have -
not with the one you'd wish to have at a later time."

- Donald Rumsfeld

Most traditional organizations are set up to optimize IT for utilization - that is, there are different departments, groups and teams to do fragmented work:

The Classic IT Model

Classic IT is typically specialized with "project groups" where an IT project manager oversees teams specialized in a subset of technical Engineering domains, and -depending on project size- also specialized in a subset of technologies.
These teams are cross-functional in no dimension and can not deliver "full slices" of anything. They do piecemeal work and depend on other teams for everything.

From here, we get into the question: "Which direction do we want to go?"

Cross-Functional Development Teams

Scrum, among other models, assumes cross-functional teams - but what Scrum actually means is "cross functional in engineering", that is - analysis, development, test, deployment and operation are done within the same team.
Re-organizing especially smaller projects into one or two cross-functional development teams who have full control over their development process "from requested to Done" across the entire project's tech stack is a simple exercise. Breaking the team boundaries also opens the door to DevOps and thus offers some performance benefits.

Technical Component Teams

The clarification of "technical component" is important for later - because there are also business components.
An alternative approach in highly fragmented organizations is to bring together teams that can do end-to-end work on technical components. Breaking the barriers between analysis, test and development for certain technologies (e.g., a Database) can already be a quantum leap forward.
The downside is that such technical component teams need to constantly communicate and synchronize with other technical component teams to deliver anything that works.

The reason why technical component teams might actually make sense: If we have monolithic components used by multiple business processes and other technical components, then we may have nobody except these component specialists who can actually work with this component.

An example would be a centralized Enterprise Database which serves as single source of truth for Campaign Management, Sales, Customer Service, ERP and Revenue Assurance.
Such components are a pain to work with, but if that's what you have - you need to work with it.
Typically, these technical components become the bottleneck in most development efforts, so regardless of the size of the technical component team, there will always be a lot of coordination, stress and blaming going on.

Business Component Teams

While certainly preferable to technical components, Business Components are the same as technical components, on a different level of abstraction: Consider, for example, an out-of-the-box CRM platform that serves as a central customer database, and provides a frontend for typical business user processes.
While IT may claim that this CRM is a "vertical slice" and "provides end to end customer value", this only works when we have an extremely narrow definition of "end to end", "customer" and "value".

A CRM company can create an entire business model out of providing a standard product with a standard User Interface and standard functions like "create user, administer account, CRUD customer, CRUD product, CRUD order" - so the CRM company can "provide end to end customer value" to their customers, that is, companies buying their solution.

The picture looks different when an enterprise buys the CRM solution and integrates it into their business landscape: a new product is configured in the Product Management Tool, product information is provided to the CRM via API, and the CRM has to offer business insight information via API to ERP, DWH - and even business partner platforms!
In this case, the entire CRM solution is merely a component of a larger ecosystem - making the CRM team not a product team, but a component team - by nothing other than a change of perspective!

End to End Value Delivery Teams

Is it feasible to simply assume that someone who was formerly a Java coding specialist for a CRM system to take coding responsibility for the python product management and ABAP ERP as well? That's not universal to answer - yet if the answer is "No", then having business component teams with end to end responsibility for a single component's stack and processes is probably already the limit.

Given this scenario, an "end to end value delivery team" would need the ability and expertise to work across a wide range of business processes, technologies and development functions. Using the initial 3D model, such a team doesn't deliver "vertical slices" - it serves "multidimensional cubes"!

While this may be a very fascinating perfection vision, when asking the question, "How do we work today - and how do we want to work tomorrow?" - most organizations are not even remotely at a level where it's a feasible option to immediately regroup into small teams that combine all development, technology and content expertise of the entire company!

The False Dichotomy of Feature Teams

Some agilists have very strong opinions about whether we should do "Feature Teams or Component Teams" - promoting the advantages of "feature teams" and listing the disadvantages of "component teams". Yet, when taking all the previous factors into play, we quickly realize that "feature team vs. component team" is a false dichotomy.

Cross-Functionality vs. Specialization

Feature Teams are Cross-Functional and Component Teams are specialized - that's easy to proclaim. What's assumed, yet never pronounced: "Feature Teams are cross-functional in development process and technology, but specialized in the business content domain."
If we look at development from different perspectives, the statement boils down to "feature teams are specialists from a business perspective - component teams are specialists from a technical perspective." Therefore, "teams are specialists" poses a false dichotomy. All teams specialize in something.

Component work vs. end-to-end customer value

Component Teams deliver piecemeal that needs to be integrated, whereas Feature Teams can deliver end-to-end customer value. Again, we have a hidden assumption: the "customer". If we consider "the customer" to be a project, then a database operations team can well claim to deliver end-to-end customer value: from installation over configuration to access management and service requests, the team does everything.

Would we agree that AWS is a component of software systems? As an Enterprise application developer, yes. As a member of Amazon, working in the AWS development unit, this component is the product! Does Amazon deliver a product with features - or are they delivering piecemeal that needs to be integrated?
We end up at the same problem as before: by assuming a different perspective, one person's "component team" may be another person's "end to end customer value delivery team". Therefore, "teams deliver end to end customer value" is yet another false dichotomy. Depending on how the customer is defined, all teams (or: no teams) deliver end-to-end customer value.

Levels of abstraction

Component Teams work only on a small portion of the Value Stream, whereas Feature Teams can deliver a Feature across the Value Stream. There's another hidden assumption: that the "Value Stream" is an absolute, and has only one definition.

Returning to our AWS example - the AWS platform is merely the technical platform of an Enterprise Platform. Suppose that Enterprise Platform spans a business process, then that platform is just a component of an Enterprise Process. And if that process is part of a Value Stream, then that process is again just a component. And that value stream may be a component of a Value Chain, ... again: component. And if that value chain is used by another company: again: component.

The bigger we perceive the system, everything we previously considered "end to end" becomes a component on the next level of abstraction. As the complexity of an Enterprise grows, there may be a myriad of abstraction layers. Eventually, it becomes impossible for any single person to even understand how many technical changes need to be made in order to provide "end to end customer value", or: vice versa - how much new "end to end customer value" can be generated by a single technical change.

Therefore: claiming that a team "delivers end to end customer value" poses even a second another false dichotomy: it assumes an organization without abstraction layers. Only when a single team has direct access both to the low-level tech stack of all components and the end customers of the value chain - only then will any team ever deliver end to end customer value.

Aligning mental models

In the dispute of "feature teams or component teams", we need to clarify some terminology, concepts and expectations - otherwise, we get nowhere.

Specialization

We have explored in depth the different potential domains of specialization: development specialists, technology specialists - and content specialists. By now adding the question of abstraction layers, we need to also answer the question of layer specialization. The term "full stack developer" assumes a developer working on the tech stack of a single business platform - not a potentially infinite array of business platforms with a potentially infinite array of tech stacks. At some point, the "full stack developer" would become a "Master of (almost) none." - and whether they'd actually be a "Jack of all trades" becomes increasingly doubtful as the stack grows.
We need to agree on what we call "specialization" and in what context we expect "generalization", lest we're potentially talking about "being everything for everyone".

"We can't do everything for everyone everywhere, but we can do something for someone somewhere."

- Richard L. Evans

End to End Work

When we talk about end-to-end, we have different concepts, and things become difficult from there.
A really obvious example is the difference in definitions of "lead time". Whereas the common Lean understanding is that it's the time between initiation and completion of a process - this gets defined differently. While most IT project managers would calculate "lead time" as the time between when a development project gets approved and closed, the book "Accelerate" defines "lead time" as the time between "code committed" and "code deployed on Production".
Returning from the specific idea of "lead time" - one person may define "end to end" as "from customer to customer", another as "from request to delivery", another as "from development to deployment", and yet another as "from build to production".
We need to agree on the definition of "end to end", to make any discussion around "end to end teams" meaningful.

Components

We have already exhausted the subject of abstraction levels. While Software Vendors deliver certain Products, these products are just components of bigger enterprise architectures. Software Integrators do nothing other than customize and integrate one of more of these "products" into a software landscape. And even an entire array of vendor products, fully integrated into a business process - may be seen as but a component of a larger value stream.
It's irrelevant of how many layers of abstraction we have in an organization - everything one layer below is a "component". By adding one abstraction layer, every "product" turns into a "component".
We need to agree on the abstraction level we're talking about, otherwise every discussion around "component vs. product" is entirely futile.

Systems

I have painstakingly avoided the term "system" wherever possible here. The reason: everyone has a different understanding of what "The System" is supposed to be!
When we're talking about "The System", do we mean a piece of software? Do we mean the larger architectural context within which this piece of software operates, its integration context? Or do we mean the development organization developing (and integrating) said software? How about abstraction layers? How would "the system" look like at another abstraction layer?
It's common that a developer means "the piece of code that's running on a server" when they use the term "the system" - whereas a business user might consider a complex, b2b mesh of services encapsulated by a single frontend to be "the system". A systems thinker would abhor both ideas, and would equally include processes, rules and people into "the system".
We need to agree on a common understanding of "the system", lest different understandings generate confusion and misunderstanding.

Complexity

When deciding whether a team is doing simple, complicated or complex work - we're quickly falling into the trap of category errors, because "complexity", like "end to end", depends on the domains we consider. Software development is pretty simple for a single piece of content and in a single technology. As we cross technology boundaries, a simple feature can quickly become a monstrosity of technical complexity - and as we cross content boundaries, possibly even organizational boundaries - even technically simple changes can become infinitely complex.
The problem: Until we have decided the dimensions in which we assume linearity and the dimensions in which we have variation, we do not understand how much complexity we're actually dealing with!
Whereas common sense dictates that "complexity" needs to consider all relevant dimensions, these dimensions can become infinite - making everything so complex that the very word becomes meaningless!
We need to agree to what we call "complexity" - and what we don't.

Bringing the right people together

After much philosophical ado, we can use all of the above to determine how to organize teams.

A team is able to work with minimal constraints if it is:

1. Appropriately specialized, i.e. they don't rely on third parties for knowledge
2. Doing end-to-end work, i.e. don't have handovers as part of their process
3. Able to work on all relevant components, i.e. don't give or receive "orders" for component work
4. Autonomous within the overarching System, i.e. team performance depends on the team and not outside factors.
5. Feasibly complex, i.e. given the complexity of all relevant domains and the cumulative skills of all team members, there's a realistic learning curve

Will the outcome of these five factors be a "feature team" or a "component team"?

Back to square one - that's a false dichotomy. And it's the wrong question.

In most organizations, it will be a huge struggle and steep learning journey to form such teams, and it's entirely moot to discuss how we label them. 

Before even considering whether we should re-organize, we should ponder whether any of the above five factors is currently the hindering constraint in organizational performance.

If, instead of all of these, the performance constraint rests outside the current teams - for example, in policies and procedures, in politics or processes, in budget or timelines - then it's entirely irrelevant how teams are organized, as even the "ideal feature team" would still suffer from the same constraints.

Conclusion

The entire discussion of "feature teams or component teams" is a red herring.

Reorganizing teams is only relevant if it elevates the current constraint - and the question is not whether it should be a "proper Feature Team" or whether "component teams have dependencies". 

The right question is: "will the reorganization elevate the constraint on the current system?" - only if that is the case, then will the new team structure generate any better outcomes than the previous structure! 

Hence: Work on your systemic constraints. Bring those people together who can elevate the constraint. Just let people work until the team structure is the constraint! And don't assume it is until you have supporting evidence!

The Cost of Learning

Time and again, I read stuff like: "The role of the coach is to guide a client in solving their problems, rather than providing a solution". Well - Reducing complexity is a talent, and this statement is a strong simplification. Here's why I personally think this isn't always the best choice.

Cost of Change

One basic premise of agility is "Responding to change over following a plan".This value is made real by constantly reducing the cost of change, to the point where you'll never need to follow an invalid plan simply because it costs less to continue doing the wrong thing. A low CoC is a premise for "being agile".

Correlation between agility and Cost of Change

Let's look closer: Change does have a cost associated, and you can't simply declare that cost to be Zero, in disregard of every evidence to the contrary. You must understand what the cost of change for a given change at a given time actually is.

This is where the coach/consultant comes into play. Both have the responsibility of inducing change. The coach would work on getting the responsible people, for example the teams, to embark the change process by learning by themselves. They need to be cautious, as especially in the initial stages of agility, the cost of change may be extremely high.

Cost of Failure

There's a problem in the learning process: Learning, obviously, means that you haven't done it yet. And that can pose a problem: You might fail. Well, failure is not inherently bad. We might argue that failure is an essential part of the learning process. That may be true, but you need to be aware of the failure costs.

Expected Cost of Failure

The danger that a person/team/organization is exposed to is a correlation of likelihood and incurred damage. For example, it's low danger to "learn" that putting salt into a cup of coffee is bad and therefore, you should use different containers for salt and sugar next time.
It's a completely different thing to "learn" that it's a bad idea to first pull the pin from a hand grenade, then put the grenade into your pocket: There won't be a next time.

In both cases, we assume that failure may occur. In the first case, we will assume that we can safely let people find out what happens, because the cost of failure is low. In the second case, however, it would be highly immoral to know the cost of failure and still let people figure out what happens.

Impact on the approach

We should always consider the cost of failure for any potential course of action. Low-risk topics that pose little danger to organizational health are not typical scenarios for requiring external support. Hence you wouldn't hire a consultant for that. People are more likely to ask for help the closer they feel to being to the Point of No Return.

Self-learning is a better course of action only when two conditions are met: 1) We will not cross the point of No Return and 2) It's a positive long-term business case.
Even though, I do admit that 1) automatically invalidates 2), the latter might still be easier to figure.
If those conditions are not met, a prescriptive course of action is more appropriate.

A feasible learning model

Depending on the consequences, we a different strategy is required:

When the cost of failure is low and people are likely to come up with a good solution, there is no need for outside involvement. Where the consequences are bearable while time is precious, guided learning can speed up the process and we can avoid reinventing the wheel. 

When there's a high risk of incurring an irrevocable, negative outcome by not doing things in a specific way, then "Do this, think about it later" is an appropriate course of action.

The highlighted boxes in the model are the most economic situational approach - the green, blue and red horizontal areas with lighter color should be considered depending on the predicted outcome.

Summary

There is no one answer to how learning should take place.
While it's very convenient to simply lean back and "encourage self-learning", that's not always appropriate.
Just like a parent would not encourage their two-year old kid to "discover the miracles of 220V AC", a coach might need to become quite prescriptive.

The directive is basic human ethics: "minimize overall harm". We can both do harm by neglect (damage to team's credibility, business etc.) and intervention (damage to understanding and desire to explore). There's a tradeoff, so choose wisely.