Team Collaboration Patterns Part 1: The Enabler

The concept of market facing teams is at the core of Agile Organizational Design. But not everyone in the organization is going to be a full time member of a single team. If we want to support agility at any scale we need to complement the idea of full time team members with other ways people can engage with teams.

I use Team Collaboration Patterns as a means to represent these different ways people can can engage with teams. These patterns provide us with options, and I have seen them enrich conversations focused on agreeing on how teams can interact with each other.

Today. I'll provide an overview of the Enabler Pattern

Like this article? Download my book on Agile Organizational Design.

Enablers

Summary

You are responsible for enabling multiple teams to use an organizational cross cutting capability, by providing guidance, a platform, relationships, and/or knowledge.

Problem

You have a small number of people that possess a core set of capabilities and you want these capabilities to serve as foundational building blocks for as many teams as you possibly can.

You want to provide these capabilities in ways that give your organization a strategic advantage in the market, perhaps increasing safety, security, or speed of value creation across your teams.

You want to provide these capabilities in way that allows teams to spend more time delivering market value, and less time reinventing “infrastructural” concerns.

Solution

The small group that possess these capabilities collaborate with other teams as Enablers.

As an Enabler you are responsible for bringing your knowledge to team members. Where you can you also provide a platform so that teams can use the capability in a self serve fashion. An important distinction of an Enabler is that you are not responsible for doing the work of teams, you are responsible for helping team members be more effective at doing the work.

Discussion

Enablers often are members of a capability specific Enablement Teams that sits in the Core of the organization. Often members of these Enablement teams are focused one a subset of the organization, like the Jedi Council or the Green Lantern Core (yes I am geek, quelle surprise), an Enabler can be assigned to watch over a closely related set of teams or larger organizational grouping such as a program or mission, helping to bring order to their sector of the galaxy.

Enablers help value-delivering teams be effective in a certain capability, but empower them to operate in a self-service mode. Technology platforms, bodies of knowledge, teaching aides, etc are all tools of trade for enablers.

HR, Legal, Security, DevOps, Data/Reporting and Agile Coaching teams are all good examples of enablers, positional leadership, when acting as servant leader can also be thought of as Enablers. One of the biggest challenges with Enablement is that it is confused with authority. In traditional organizations many of the functions listed above maintain coercive power over Edge teams. When using an Enablement pattern, the services of an Enabler are voluntary. Teams are not mandated to use the services of an Enaber. We cannot effectively enable others through command and control as it will never lead to a durable change in behaviour. Coaching people who are in enablement functions to approach the way they work from this point of view is no easy task. It required constant focus and reminder.

Example: HR recruiting Function

An example would be the recruitment and hiring function in HR. In a traditional many teams would be mandated to go through an HR rep to perform the initial screening, setting pay bands, writing job descriptions, and engaging with talent firms. When acting as an enabler HR would provide a platform to make this job easier for teams. Outside of some minimal rules to ensure compliance with laws and avoidance of reputational risk, HR would not mandate its involvement in hiring, but rather it would offer help including:

• advice on how to effectively navigate the hiring process
• technology that streamlined the logistics of interviewing, assessing, and finally hiring a candidate
• sharing hiring assets (ie job postings) that other teams had created
• coaching on practices related to hiring candidates

The Enabler focus puts the the team being enabled in the position of being a customer of HR, as opposed to a subservient position. This ensures that HR services stay healthy, and suited to the needs of team!

Pattern Options

Enabler who Travels and Provides Services

It can be a struggle for people providing services to other teams to move into Enabler mode, at least at first. Until the organization reaches a certain level of maturity, teams will likely ask or even demand services from Enablers in a variety of ways that do not fit the Enabler pattern.

Sometimes this means working closely with teams and pitching it to do the work, either for a short or longer period of time. Sometimes it may even mean doing some of the work for the team, treating the requester as a client team, and presenting a finished deliverable back to requester.

As an example, a team of Agile Coaches should operate as the archetype of an Enabler. Yet coaches may need to temporarily play the role of Product Owner or Scrum Master if there's a desperate need. A Data enabler may be asked to help the business by creating reports rather than teaching them how to use the reporting platform. None of these activities lead to enablement of those teams. Enabler time is better spent enabling not doing the work, but sometimes what is practical trump what is pure.

On a positive note, teaching others is often accomplished through a do it, teach it, pair, and then coach model. So doing the work can be thought of as a tip of the enablement spear so to speak. The Enabler who Travels and Provides Services provides a path for teams that are doing work that they would like requesters to start doing for themselves. Service Provider Teams can start reserving capacity to build up platforms / knowledge to help requester teams self serve take on the work on their own. Travellers can be deployed to customer teams to first do and show, then pair, then advise, and finally step back and allow the team to do the work themselves

Getting agile teams comfortable with using Devops is an excellent example of how an infrastructure team can graduate from a Service Provider team, to Travellers, and then to a team of Enablers by thoughtfully increasing the level of self service that teams can perform through a combination of platform, permission, and coaching. The Devops team can use a highly visible agile style backlog to shape their demand to march the enablement model. This includes allocating capacity to do the ground work required to providing services as an enabler. This groundwork can include getting permission, aligning with providers, marketing the offering, rolling out a platform, and building a body of knowledge.

Stay tuned for more on Team Collaboration Patterns

That's it for the enabler pattern. I'll go over the remaining patterns in upcoming articles.

Like this article? Download my book on Agile Organizational Design.