PART ONE

This is the rule of thumb

In the context of knowledge work and software & digital products development, the rule of thumb is to share all the responsibilities inside a multi-disciplinary team that has all the skills and authority to autonomously do all the work from the concept to when the finished work lands into the hands of the final users, and later for operating, supporting, maintaining and evolving the related product. Therefore, all the responsibilities should remain inside the team.

Traditionally, in industrial mass production, the rule of thumb goes toward a different direction, the direction of specialisation, work divisionalisation in separate functions, outsourcing, commoditization, standardisation, and economies of scale.

When to go beyond the rule of thumb

Even in knowledge work and software & digital products development, there can also be situations where:

• the workload exceeds the capacity of the team, as a whole or for a specialistic knowledge/skillset;
• the cognitive load exceeds the capacity of the team;
• a very specialistic knowledge/skillset is underutilised in the team, nonetheless, it is needed;
• some services, product areas or components may have reached a level of maturity that would allow them to be delegated to another team and shared across multiple consumers;
• any other you can think of?

One way to stick to the rule of thumb under these circumstances is to follow an extreme and continuous knowledge & responsibilities sharing. As described in Transcending Cross-team collaboration with shared work.

There are situations tho’ when it may be convenient or easier to go beyond the rule of thumb. See an example inspired by Team Topologies here: Agile cross-team collaboration How-Tos.

For these situations, we really need to understand when, what, and how to effectively move some tasks and/or responsibilities outside the team. For example, delegating them to a Subject Matter Expert, an external contractor, an Agency, a global/shared function, a Team Topologies’ Platform or Complicated subsystem team.

What does success look like for this

When the work or cognitive load exceed the team capacity or there is a need for a very specialistic knowledge/skillset, or a service/product/component has reached a level of maturity allowing for reuse, the options of moving the related tasks/responsibilities outside the team should be considered only in ways that make such option beneficial and advantageous compared to the status quo.

Below are some general criteria that can help to find ways to ensure that.

A) The work and cognitive load should actually be reduced

This means that moving the task/responsibility outside the team, delegating it, and getting the work done back, should not add more work or cognitive load than doing the work directly inside the team.
For each of such tasks/responsibilities then:
– making an external request for getting the work done should be orders of magnitude simpler than explaining to others how the work should be done, or just asking to get it done,
– the “interface” and “protocol” to ask for each task/responsibility to get done should be simple like it was a black box, therefore should not require knowing or understanding any “internals”.

This requires a clear “separation of concerns” between tasks and responsibilities and knowledge/skills remaining inside the team and those moved outside the team.

B) It should not add hidden costs such as extra-planning and collaboration frictions

Moving a task/responsibility outside the team should not add dependencies other than to that task/responsibility, for example, a dependency of the team on:
– an individual or a knowledge that is not more inside the team,
– a technical dependency on source code, infrastructure, tools or other tech moved outside the team,
– any other resource dependency,
– access and/or authority that has moved outside the team and is not available in the team anymore.
Any of these dependencies would require additional collaboration, coordination and planning that go well beyond what is needed for the tasks/responsibilities moved out, and would typically introduce additional rigidities, complexities and costs that exceed the other expected benefits.

C) It should not add delays and unpredictability

Those taking care of the tasks/responsibilities moved outside the team, must have enough capacity to do the required work without adding delays to the team and without becoming a bottleneck.

The “interface” and “protocol” the team uses to request and obtain the service must remain stable instead of changing over time adding extra work to the team at every request.

The requests must be carried out without the need to change/modify/adapt the “internals” of the service provided overloading the external person or team (especially when they are serving multiple clients) and adding work also to the team, overall causing further delays and adding more complexity.

When it is feasible, the service itself should be automated allowing for self-procurement therefore avoiding all the potential problems just mentioned. Common examples include cloud environment procurement, code integration, final system testing, and deployment.

(Part 1) Part 2 >>