Event-Based Leadership

The concept of event-based leadership is a cornerstone of Agile 2 and Constructive Agility. It means that planning is continuous, rather than on a recurring basis. But let’s first explain why we need this approach.

The motivation behind event-based leadership is to:

1. Be able to respond to cross-cutting issues that arise. Issues that cut across organizational domains are not easily handled by standard processes, which tend to be owned by a single domain; and,

2. Free up calendars, so that when issues arise, people have time to go deep on those issues and reach a well informed but also timely decision.

Agility results from numbers 1 and 2 above: being able to rapidly detect issues that arise, and being able to rapidly reach a clear understanding and decision, no matter if the issue involves stakeholders spanning the organization. This is important today more than ever, because today’s product issues often cut across product lines and even business areas. This is increasingly true as products become more digital and interconnected. Also, today’s fast pace makes yesterday’s quarterly and annual planning too slow; and waiting for cross-cutting issues to bubble up to higher management is also too slow: today, an issue needs to be resolved as soon as it is identified.

Issue Surveillance

For event-based leadership to work, leaders need to become aware of issues as soon as they arise. Awareness of an emerging issue can result from observing the issue firsthand, or from being informed by a team member. To observe issues firsthand requires being personally involved in the work, or closely observing on a frequent basis. We view that as a form of Gemba walking: paying close attention to the actual work, and asking those doing the work what they think.

Being informed of issues requires being approachable. A leader who makes people uncomfortable when they bring bad news is a leader who will not be informed about emerging issues. The culture needs to be one of transparency and honesty—traits that are characteristic of a Constructive culture.

A Dashboard Culture

One way to observe an emerging issue is to notice a negative trend in a performance dashboard. That requires that each team and team of teams maintains a dashboard that summarizes the metrics that matter.

There needs to be a dashboard culture. There needs to be a standard online location in which every team has a link to its dashboard. For example, it might be the top right of each team’s Confluence page, or their Sharepoint page. The location needs to be standardized so that anyone can easily find a team’s dashboard.

The culture must also ensure that people (1) maintain their dashboard, and (2) look at the dashboards of other teams who they depend on. Coming into a discussion without having examined the appropriate dashboards needs to be viewed as unprofessional: it needs to be seen as being unprepared. Management must evangelize that over time, so that people get the message that dashboards must be maintained and looked at. This is important because event-based leadership dispenses with status meetings: people get status online. Meetings are for discussion and decisions.

Flash Collaboration

Instead of using meetings to trade status, we believe that a meeting should be called when it is really needed: when there is a new issue to discuss or a decision to be made. That means that someone has to realize that a meeting is needed, and call one.

• Cross-domain

• Dialectic, goes deep

• Transparent, honest, and non-competitive

• Driven toward a decision

Criteria for a meeting to be recurring:

• Team members feel that it would help at this point in time; or,

• Its purpose is to maintain a relationship or team spirit.

• Continuously evaluate if the recurring meeting is still needed.

All non-recurring meetings exist for a purpose, which should be to either,

• Have deep discussion to reach a better shared understanding of an issue; or,

• Collectively decide on a course of action.

Meeting “def of ready”:

• For going deep - to either make a decision, or to attain a deeper understanding:

• People have had a chance to think about the issues on their own.

• The main points of contention have been uncovered.

For brainstorming - do not make a decision in the meeting.

If someone plans to present, send the info ahead of time.

Work in a shared doc during the meeting.

Don’t invite too many people.

Purpose of meeting should be clear: to discuss a proposal, to brainstorm and find intersections, or to discover a root cause and thereby reach better understanding.

Related Topics

Gitlab’s CEO on Meeting Guidelines