I learned the meaning of slack time years back in the context of Kanban. Once we start managing workflow for effectiveness, we necessarily create these moments when we want to stop the work. Otherwise, we’d overload the bottleneck.
When we design the slack time in the system, the natural question is, what’s next? How do we use it?
The Use of Slack Time
My first natural, although with the benefit of hindsight simple, answer was to optimize the teamwork.
There’s always a colleague who would appreciate help. There’s always a stage of the process that no one loves (code review, anyone?). There’s always an improvement task that just never makes it the top priority (like paying technical debt back).
Then, there’s a whole another context. Individual. Slack time creates a perfect opportunity to invest in oneself. Catch up with what’s new with technology (with the AI race, it seems like there’s something to catch up with almost every week). Learn something outside of the immediate context of the project. Sharpen one’s saw.
But then, when we start considering the value of slack time in a more generic context, we realize that it goes way beyond the team level.
Think of a fire station. Their whole system is designed around slack time. We don’t try to optimize the work for fire brigades for utilization. It would mean that we want firefighters fighting fires all the time.
Thus, we’d either have an excess of fires or firefighters moonlighting as arsonists.
Cross-Team Slack
We can then abstract away the idea of slack time and consider how it applies in different contexts.
The most basic context would be individual. Slack time helps me to get better.
Going just a bit further, we have the team level. Slack time helps the team to become more effective. We achieve that either by coordinating around the ongoing tasks (short-term help) or working on improving the long-term performance (continuous improvements, paying technical debt back, etc.).
So far, it’s all the basics. But what if we take another step into a broader context?
Then we end up in cross-team/cross-project land. We start considering coordination problems. We look at interdependencies. We analyze an entirely different layer of work design.
As much as we have a bottleneck within a development team (let’s say it’s testing), we will have one if we consider a cross-team initiative (let’s say it’s passing the security acceptance).
Once we understand this high-level picture, we can use slack time to help the entire initiative become more effective. It’s likely that one team being able to deliver more features or deliver them more predictably will not move the needle of the whole product by a millimeter.
The actual bottleneck may be in the design, or release, or even grand product-related decisions.
That’s where cross-team slack time can be redirected. It would mean we’re asking the question: what’s the best way to help when I see the big picture?
Organizational Improvements
Can we go further up, though? Once we consider individual, team, and cross-team levels, is there more?
But of course, there is.
Once we strip the context from the product/project work, we look at the bare bones of any company—its organizational design. And there’s always plenty to do around these parts.
At this level, we wouldn’t ask questions about improving my project/product. We’d look for ways to make the whole company improve.
Think of any novel initiatives. Of course, “novel” is in the context of this company; I don’t expect us to routinely do world-changing stuff. Starting a self-help group. Running a new product experiment. Looking for fellow folks to challenge existing management paradigms. Opportunities are almost endless here.
The more extravagant you become with the ideas, however, the less likely you’d be allowed to implement them. And here comes our culprit.
Role of Autonomy
We established different levels of slack time:
- Individual
- Team level
- Cross-team
- Organizational
The further down that list you go, the bigger the potential impact of the changes. But most people wouldn’t even consider going beyond the team level. Why?
Simplest answer? They don’t have enough autonomy.
The degree to which we can impact our organization depends on our sphere of influence. And that is strongly correlated with how distributed autonomy is in any organization.
It’s not binary, of course. It’s not that I can or cannot make a decision in a cross-team context. Sometimes, even when I can’t call the shots, I can influence the decision-maker.
But if I don’t have autonomy on a team level, I shouldn’t expect to have influence on a cross-team level. Thus, we can use the autonomy distribution as our measuring stick.
Limited Autonomy, Limited Impact
Whenever I teach that stuff during workshops and university courses, I ask people a series of questions to assess how much their organizations distribute autonomy.
The questions are separated into groups, roughly referring to the three levels mentioned above: team, cross-team, and organization. The outcome is the same every single time.
We see a lot of autonomy on a team level. Teams can freely decide about many things. I think we have Agile to thank for that.
But then, it breaks. Once we get to cross-team, the perceived autonomy goes from “significant” to “barely there.” And it won’t be a surprise that when we touch the organizational level, it’s non-existent.
In such an environment, we shouldn’t expect to get that much out of slack time.
So, the next step after introducing slack time to our systems is to get more autonomy in it as well.
