Loading...

When/How to move effectively tasks/responsibilities outside the team (2-part)

Posted on

Whether it is to a Subject Matter Expert, an external contractor, an Agency, a Global/shared Function, a Team Topologies’ Platform team or a Complicated subsystem team, when and how can some tasks and/or responsibilities be effectively moved outside the team?

PART TWO

(Optional) sources of inspiration

Whether the tasks/responsibilities are to be delegated to a Subject Matter Expert, an external contractor, a global/shared function, an agency, a Platform team, a Complicated subsystem team, or similar, these models below have inspired me to reflect on ways to identify when the three criteria are met and so the move is going to be really beneficial and advantageous.

For criteria #A (about the clear separation and simplicity) and #B (about the dependencies), I have found it useful to think about:

  • the Encapsulation property of Object Orientation where a clean simple public interface and protocol allow to access the service in a simple way, without the need to know or understand the internal implementation details;
  • the low coupling property of good Object Oriented design where only dependency between the object and the code using it goes through the public interface and it is limited;
  • the Domain Driven Design and Event Storming workshop that provide ways to apply the two points above also in complex scenarios.

While these thinking tools are specific for code and are naturally useful when moving the ownership of parts of a codebase outside the team, the same concepts can be applied to tasks/responsibilities, to the way the service is provided through an “interface” and a “protocol”, and the non-technical dependencies as well.

For criteria #C (about the stable interface and the service provided), I have found it useful to think about:

  • the stages of evolution of a product/service in Wardley Mapping, where the product/service reaches the required level of stability at the Product + Retail Services stage and the later Commodity + Utility Services stage;

  • the social learning cycle in Max Boisot’s I-Space that shows how knowledge (as that related to the tasks/responsibilities to be moved outside the team) requires going through a process of codification and abstraction before being ready for public diffusion (as moving that knowledge outside the team). Therefore, moving that knowledge outside the team has, as a prerequisite, a certain level of maturity and understanding of the related knowledge.

Both these models have general validity and can be applied to code whose ownership is to be moved to a Platform or Complicated subsystem team, as well as other tasks/responsibilities.

To summarise: The Guidelines

Putting it all together, here are the guidelines that summarise when some tasks/responsibilities can be effectively moved outside the team to a Subject Matter Expert, an external contractor, an Agency, a global/shared function, a Team Topologies’ Platform or Complicated subsystem team. When an organisation cannot meet these guidelines, will be better off keeping those tasks/responsibilities inside the team.

1) IT MUST LEAD RIGHT AWAY TO A FASTER FLOW.
The moving of tasks/responsibilities outside the team must increase right away the speed of the flow of work. As a result, the bottleneck currently hindering the flow of work should be mitigated and the overall lead time reduced right away. Frequently used services such as cloud environments procurement, automated testing and deployment, and similar, should be fully automated before moving them outside the team, to allow for self-procurement.

2) THE STEWARDSHIP OF TASKS/RESPONSIBILITIES MOVED OUTSIDE THE TEAM MUST BE EFFECTIVE.

2.1) Accessing the moved tasks/responsibilities must remain simple, practical and convenient
The individual, function, external agency or internal team taking ownership of the moved tasks/responsibilities must serve the client team via an “interface” and “protocol” that shield them from the “internals” of the work and that is orders of magnitude simpler than the work to be done. As a result, the cognitive load and workload of the client team must decrease.

2.2) All technical and non-technical dependencies should be removed before moving the tasks/responsibilities outside the team
The client team won’t have to pay hidden costs in terms of planning constraints and collaboration friction with the new owners of the tasks/responsibilities, costs inevitably resulting from any existing dependencies other than the public access to the service itself.

3) THE MOVE MUST BE DONE GRADUALLY ENSURING AT EACH STEP ALL THE POINTS ABOVE ARE FULLY MET.
The tasks/responsibilities in order to fully meet the points above and therefore be conveniently moved outside a team, need to reach a level of maturity, stability and a level of codification of their knowledge and understanding that requires a certain amount of time and work.
Only a small portion at a time of the tasks/responsibilities that reached this stage should be moved outside the team. Even such a smaller move should be treated as an experiment where the outcomes should be tested against the points above and fixed or reverted as necessary.
The delegation of the following portions of tasks/responsibilities should follow the adage “First, make the change easy, then make the easy change” instead of the adage “It will get worse before it gets better”.

Conclusions: my personal experience with this

I have seen many delegations of tasks/responsibilities outside the team introduce long delays, reduce productivity, and make the life of the team much harder. After all, that’s why the rule of thumb in knowledge work and software development says ‘don’t do it’ and suggests as an alternative the Shared work.

In many cases, I have observed that the expected benefits of moving tasks/responsibilities outside the team were overestimated because of the widespread beliefs from the industrial mass production era on the economies of scale that do not apply equally to knowledge work and software development. At the same time, the hidden costs were underestimated because only the teams were feeling the pain, that was otherwise ignored by the decision-makers.

In a few other cases, where the potential benefits for the delegation were there, the problem has been a big-bang transition to the new structure, and the lack of experience and skills to approach it gradually in an effective way. The big-bang approach:

  • it is often rushed before the time the tasks/responsibilities have reached the required maturity stage necessary to be effectively moved outside the team, and before the necessary work to remove the accidental dependencies is completed;
  • when it does not succeed on the 1st try (as most things do) it does not allow us to learn what is not working, why the expected benefits are not there, and which bottleneck is still causing the delays.

In some of the cases where it did not work, moving tasks/responsibilities outside the team was just another silver bullet to avoid facing the really hard problem they had in front of them.

I have also seen cases where it worked well. This brings me back to the reality that every technique has its tread-offs, pros and cons that need to be weighed under the specific context and circumstances that one is facing. These decisions cannot be faced following a trend, an ideology, or an oversimplified vision of the world, instead, they require professionalism, patience and time to explore the context, an open mind and a gradual empirical approach.

This is where I hope the criteria and guidelines that I have shared above might help.

Suggested readings:

<< Part 1 (Part 2)

Elevate the Agility in your organisation.


See how we can help.
You, your department, your organisation.

Advising, Mentoring, Coaching As A Service