Is Leadership Invitation always the correct approach? The answer is no


Agility runs on actionable feedback. In this essay we describe how to design decision systems for generating and then evaluating more feedback, using an invitational leadership approach.

Executive Summary: 

1. Management structures are often optimized for “convenience of operation” or “management convenience”, rather than improved value delivery, sustainability, productivity, quality, etc. Structures can get out of alignment and impede these goals.

2. Delegation is very useful, but far less useful (or even ineffective) in situations that are complex, that display frequent change, and in situations that are forcing decisions in the face in ‘incomplete information’

3. Invitations from top decision makers generate 10X to 20X more feedback than delegations, and business agility runs on high-volume, high-quality feedback.

4. The invitation-vs-delegation debate is not “either-or” and actually displays a lot of nuance in terms of the trade-offs. Executive leadership teams need to understand this to be effective leading change in organizations.

5. More and more of work is displaying frequent change, suggesting the use of invitation and more agency. However, leading by delegating till makes sense when the work is a well understood “defined process” that is typically repetitive.

Delegate or Invite?

Management and executive leadership must be expert at delegation of responsibility and authority. Delegations can be rapidly designed and finalized. Delegation also reduces communication to the bare essentials and improves speed of response. But delegation also may discourage feedback. And that is a problem.

Complex situations force decisions and action in the face of ‘incomplete information.’ A chessboard, by contrast, displays ‘complete information‘. The board shows what is where, and all moves that are possible. Business scenarios are not like this. Business decisions are typically made under considerable uncertainty of information. This has become the norm.

In these situations, invitations can be used to determine the following: 

1. Who is willing to engage in working on the problem

2. What the problem dimensions actually are

3. Who really cares? Who are the emerging leaders who want to address & solve the issue? Soliciting volunteers helps you find out.

4. Who is passionate about the solving the problem? Who is demonstrating a willingness to be responsible for contributing to the solution?

5. What is being missed in the assessment of the problem? More observers mean more perspectives and potentially, a clearer view of the situation

All of this feedback is actionable and therefore valuable.

Selecting the Right Option

When the business issue displays more and more complete information, like a chessboard, we may say the situation is more understandable, more knowable, and easier to make sense of. And address. But in situations where information is very far from complete, and decisions must be made, and actions taken, without complete information, under uncertainty, inviting volunteers to help is a primary way to successfully deal with change, make decisions and take action.

The main reason are as follows:

1. The ability to “make sense” of the situation, by pulling in more people to pay attention to it, and observe it

2. Much higher levels of employee engagement, as people actively choose to participate in problem solving

3. Space for creativity and innovation is created by opt-in invitation, in a way that delegation does not encourage

These days, there is considerable change. That means that in general, less and less is well understood. More and more complexity. That means gaining skills in leadership invitation is becoming a big deal.

When To Eliminate Leadership Invitation as an Option

When the task is well understood, and the information available is mostly complete, and the task is repetitive, delegation is clearly the way to go. And the inviting of volunteers is not necessary.

But when the information is incomplete, and the possible set of solutions is even less clear, soliciting volunteers and tapping into the collective intelligence of the entire group (via whole group process) is the way to go. And leadership invitation is a primary way to do that.

The debate about when to use delegation (a form of imposition) vs invitation is not an black-white, up-down, yes-no, “either-or” issue. Which approach is selected very much depends on the texture of the context, and the completeness of the  information available for making decisions under uncertainty.

Dig Deeper: Actual Real World Examples

Watch and listen: 5 minute executive testimonial on experience shifting from Delegation to Invitation in a complex scenario:
Executive Testimonial:Invitation-Based Change at BENDIX Corporation (Executive Eddie Wilkinson)

Examine this PDF resource: Download the 1-pager from OLN contrasting Leadership Delegation with Leadership Invitation: Click here to download the 1-page PDF


Culture change is almost automatic when decision rights change


Scrum, Kanban, DevOps. Etc. All are best viewed as a pre-fabricated systems of decision rights.

Scrum is a good example. The roles, artifacts and events defined in Scrum are typically implemented fully. But, the rules about decision rights are usually not implemented or honored. This leads to the appearance of “full-on Scrum” to casual observers. But the decision rights by role are modified, or missing.

Implementing Scrum without those decision rights will not get great results, or change your culture for the better.

Example #2: Kanban

Kanban. Same thing. There are specific decision rights defined in Kanban. The Kanban method says that the Team or a representative member of the Team, and the person requesting work, are to discuss the work, at the boundary of the Kanban board. And they are to characterize it by Work Item Type, before adding the work to the queue. Work Item Type also implies “cycle time” which is how long the requester of the work can be expected to wait for it to complete.

Typically, a representative Team member is the one that has the discussion at the boundary, and decides about the assignment of a specific Work Item Type.

Also typically, the dev-Team member has LESS authority overall than the requester of the work does. This can lead to problems: the dev-team member managing the boundary may end up “caving in” and assigning a Work Item Type with a faster cycle time, because that is what the requester pushes for, and wants. This amounts to an override of Kanban decision rights with respect to who owns the decision about what Work Item Type will be assigned.

Kanban implemented like this will not get you great results, or change your culture.

Summing up

Improving value delivery, quality and so on usually involves changes to how decisions are made, and who make them. Aligning changes to decision rights in service to more value delivery usually involves at least some discomfort at first. This is the price of genuine improvement … and genuine culture change… for the better.