Capability Traps
“We can’t spend time improving because we need to focus on the work itself.”
For a deeper read I recommend Repenning, N. P., & Sterman, J. D. (2001). Nobody ever gets credit for fixing problems that never happened: Creating and sustaining process improvement.
I’m not sure, but here’s how I understand Capability Traps.
A Capability Trap is a causal loop that decentivizes us from increasing our capability, thus “trapping” us in a capability status quo.
Usually it involves a recurring decision to spend time directly performing in place of improving capabilities, balancing the loop by “working harder/more”.
Example - Automate a Repetitive Task
Scenario: The team runs a manual regression test suite before each release. Some of this manual work could be automated.
Notice that automating the task is an example of improving the team’s capabilities.
Decision: Should the team automate the task?
Pros:
- Once the task is automated the team will have more available time for other productive things, which will increase performance. Or, the newly found available time could be used for other things. Ideas?
- Increased sense of autonomy, agency, ownership and maybe even mastery
Cons:
- Automating the task will take time which will decrease performance, going directly against the expectations.
- This will change the way we do things. This involves dealing with unknowns.
The team decides it cannot afford to invest in automation, trapping itself in an ever increasing effort of carrying out the task manually in an attempt to meet performance expectations.
Delayed Improved Capabilities
In many instances of capability traps there’s a delay between the investment in building better capabilities and the actual gains.
This delay is more pronounced for some kinds of capabilities, for example capabilities that require learning.
Example - Learn to Automate a Repetitive Task
Scenario: Maybe the team doesn’t really know how to automate its regression test suite.
Decision: Should the team learn how to automate the tests?
This is even harder.
Delayed Pros:
- Once the team knows how to automate the task, it will be able to do it, which will in turn create more available time to increase the team’s performance. (Or other things?)
- The learning might transfer to other areas. (Are there more similar tasks that need automating?)
- Ownership of the learning process.
Cons:
- That sure seems like a very large and unknown investment of effort and time, for which we will suffer decreased performance.
- True learning is hard.
- For learning to occur, there has to be a condusive environment in place: a psychological safe environment, vulnerability, etc.
The team is in a deeper trap. It’s better to just continue doing it manually.
Example - Establish a Learning Practice
Going even more meta.
In the previous scenario we assume that the team has some mechanism in place for learning new things.
But, I think some teams might be in the following situation.
Scenario:
- The team is doing something manually that could be automated. For example regression testing before release.
- The team doesn’t know how to automate it
- The team doesn’t have a space nor a practice of learning new things
A deeper trap.
Decision: Should the team establish a space for- and practice of learning?
I leave the pros and cons discussion as an exercise for the reader.
Capability Erosion
To make things worse, capabilities tend to erode with time.
For example, regression testing might become more and more involved with the system’s continued development, which renders our effective capapability to do so less and less effective, especially if done manually.
Is There a Way Out?
If we are to get out of such traps at all, I propose it is by finding ways to continously invest in capabilities. One approach that I found helpful is combining Dedicated Learning Time with regular Reflection Time (aka Retros). A team might decide to spend an hour a day learning in the morning, and reflecting back on the work at the end of the day in a Retrospective. I learned this from the Mob Mentality Show.