Responsibility inversion is an extremely common management anti-pattern, present in many organisations. It occurs when a person in a more senior role (in terms of hierarchy or experience) does not delegate sufficient responsibility to those more junior than themselves, even though they possess the relevant skills, ability or experience.
With the following diagram in mind, consider a typical career progression progression path, with a manager and their report(s) as an example:
In the Venn diagrams above, the upper circles represent the more senior role, their skills and experience and the lower circles represent the more junior role. The intersections represent the overlap in skills and experience.
The Responsibility Inversion Principle asserts that if you prevent someone from using their abilities they will begin to lose them (shown on the left). Whereas, when they are allowed to exercise their ability, under the guidance of someone senior, they’ll actually grow their ability.
One common example of an inverted responsibility situation you may encounter is the much lambasted “ivory tower architect“. Instead of focusing on higher-level concerns outside the logical scope of the senior developer role, they’ll spend time dictating all but the lowest-level aspects of their skill set. They do not trust or empower developers to make use of their experience – removing the opportunity for them to create or influence solutions, designs or to make any related decisions about the software they will be expected to deliver – instead they’ll be spoon fed the results of the architect’s own (isolated) activity.
If you’ve employed talented people, this inversion will be a massive source of frustration which will slowly erode their skills (through lack of use), quality of work and output if left unchecked. The more astute will leave to pursue opportunities elsewhere long before it comes to that…
Talent retention aside (although you’ll be aware how big an issue that can be), the inverted approach doesn’t scale! Taking on as much as possible and delegating as little as possible creates a huge bottleneck that isn’t always very obvious from outside the team. Time that should be invested in important areas is rushed to continue to feed work to their reports (compounding the frustration of those who could have done a better job, given the chance).
There are many potential reasons for this situation. It can emerge from a perceived lack of skills in the more junior employees – or from a lack of trust. It can also come from a desire of the senior person to (continue to) be seen as valuable or irreplaceable to the business – or simply as a result of unconscious actions (in ignorance of what they’re doing). Whatever the root cause, the result can be toxic in the long term.
Regardless of the role within an organisation, you will usually find that there is a substantial amount of overlap in the overall skills and experience required to carry out the related day-to-day responsibilities, yet many organisational structures place people in silos – as if the entirety of those skill sets are mutually exclusive. Whilst this loses some economy of scale in larger structures, some delineation is required for effective coordination of activity – “somebody’s gotta be the ensign“.
Some career paths have evolved to avoid this pitfall fairly naturally – such as the route from junior to lead software developer. One might expect to begin their career as a support developer then progress in to a senior developer role and (eventually) beyond – leading teams or perhaps moving into architecture. In a healthy organisation, there’s usually an implicit requirement in their senior development roles to support and mentor more junior developers. They’ll be coached and assigned progressively larger and more difficult pieces of work. All the work they produce is reviewed by the senior, who will then give appropriate and constructive feedback to the junior – demonstrating areas that they can improve. Over time they will grow to fill the shoes of their mentor.
It’s important to note that using the delegation approach in no way diminishes the more senior role. The skills you learn by communicating your experience, explaining complex concepts and being able to divide and distribute large undertakings of work help set you up for your next challenge.
So how does this relate to Agile software development or scaled Agile? An Agile self-governing team not only promotes the vertical progression described above, but can also provide a great way for people to expand their skills horizontally – from the additional experience gained in embedded team roles, rather than being limited by a traditional silo position. You’ll find that people naturally gravitate to areas where they have the aptitude and interest. When people are given the opportunity to grow like this, you may be pleasantly surprised how much your team starts to achieve.
Setchu - Agile at Scale 