Our small consulting firm has been transitioning to self-management for about 6 months, and working with a functional circle and role structure over the last month. One of the struggles we are seeing is that because everyone is very enthusiastic and really taking ownership over their work, it has become a challenge to keep workloads manageable for some people who keep volunteering to do more work. In our old system, a manager would have not assigned work to someone who was reaching maximum capacity workload, but now there is no one with that authority. While the circle could object to a role nomination, we are not clear on whether that objection is valid if the potential rolekeeper wants to do it, despite the the advice from others. What has happened is that the more experienced circle members are advising others to curb their aspirations a bit in the name of managing workload (its is also a lot of work setting up all the circles, roles, and governance agreement etc, so we are hoping the number of meetings will decline over time), but we are interested in suggestions from the forum on how to deal with something like this and how to ensure that people are a bit more enthusiastic to say no and recognise their limits.
I think the most developed system for this is something inspired by agile. It’s very compatible with sociocracy and has been merged in many implementations.
The specific component that helps people manage workloads as things like WIP limits on tasks. That stands for work in progress limits. However, agile is specifically designed for sort of repeatable tasks in a certain way, such as support tickets or publication workflows. It doesn’t quite lend itself as well to more complex one-off projects.
Another thing that’s useful from agile is the idea of scrum Masters, scrum Masters coordinate the team’s work. Even though you’re in a self-managed environment it might be that the team works better when they have someone who’s looking at the bigger picture, assigning roles, making sure things don’t get dropped. Again, the scrum Master usually work specifically with the kanban in agile which is designed for repeatable tasks and workflows or a specific process that’s going to be run often of called a Sprint.
However, I think similar principles could be applied more creatively. If you’re work environment or tasks is less compatible with conventional agile practices. There can be a bit of a challenge if people are working across departments and things like that.
Basically though the takeaway is even in my self-managed environment, it still makes sense to create roles or guidelines for people to do their work. For instance, a limit on the number of tasks somebody can hold at a time or number of maybe “task hours” they can be responsible for. Or alternatively, having somebody who assigns tasks could still be something that is implemented even with a self-managed consent-based process. The main thing that you would do is include everybody in the decision making process around how the management and support happens and make sure that that process has a term for review.
Let me stop you right there. That should not happen. If you assigned them by consent then someone should object. The basis for objection is that if they take on another thing, something else doesn’t get done. (–> problem for the aim)
I can see how you’d think that but I see the circle where the roles originate as the “boss”. So there IS someone with the authority, it’s the circle.
The objection “this is too big of a workload” can be integrated by measuring the concern - how will we know what “too much” looks like. Then you track whatever you came up with, as peers.
Remember you’re in the same boat - you want your operations done and your aim achieved.
How does “going over the limits” manifest?
Thanks Ted… this is helpful. I suppose what we have to get used to is being able to understand one another’s work load as a basis of objection. In the past, each person’t manager understood their workload and could help them to make a decision about it, but now that it is the circle’s authority, it assumes the circle has the understanding of each person’s workload to consent or object. All of this should come out in the information parts of discussion and the circle will need to know how to evaluate this information. This is something that we will learn together.
Thanks for this… some great pointers there… yes, the agile scrum master role is not really for us, but we are launching a system that helps to identify task hours and yes, we will use that as an indicator of hitting maximum capacity. Some people feel that hours is too crude a measure and we have done some work exploring task intensity to add a multiplier to hours for particularly intense tasks, but that needs more testing.