Accounting for Experience in a Holacracy
I get asked a lot about how Holacracy accounts for varying levels of experience & skill within roles. Not long ago, I got to answer that question on Quora, and I wanted to share what I said here in case any Salt & Pepper readers were curious as well :)
An important distinction needs to be made when addressing this specific question, and it’s the source of much confusion around this topic — When we talk about levels of experience or skill within roles (things like “Junior Designer, Designer, Senior Designer, Director of Design,” etc.), what you are describing is a people-classification issue, not a work classification issue.
At first, this might seem like an immaterial distinction (or even a false one), because most companies build their different job descriptions — and therefore, accountabilities — around the people that they envision filling the roles. For example, in a traditional org the actual work that a Junior Designer does truly is different than that of a Senior Designer. The position was engineered that way. This is why job titles serve such a vital role in the traditional job marketplace; they not only tell us how far we’ve come, but they often outline the work that we have done and that which we are equipped to do. In the traditional workplace, a title and a role are one and the same.
However, when you enter a Holacratic org, crafting of roles is intentionally thought of separate from what person/people might be able to actually execute the role. This is because the way in which each role is filled (a.k.a.- figuring out who is assigned to the role) is up to the Lead Link of the circle, but this can only be done after the role has been designed. That’s because it might be one person, it might be multiple people; and beyond that, how those people actually divide-out, prioritize, and execute on that work is up to the role-fillers. By structuring this way, the system doesn’t burden itself with concerning how to stack-rank people based on abilities. It simply outlines the work that needs to get done under the role’s purpose. It also removes the mental constraint we often put ourselves in when we try and mold positions around people, kind of in the same way that the best brainstorming sessions don’t allow participants to shoot down each others’ ideas, creating a more focused & free environment. This is what makes a Holacracy so flexible. It doesn’t build a complex system of ranks, titles, and processes to mandate how work gets done — that’s up to the people and cultures at each business. Holacracy simply organizes work.
Another way to envision this is by thinking of it in terms of inputs and outputs. Role accountabilities in a Holacracy are essentially the expected outputs that are needed to bring the role’s purpose to life. Qualifications, experience levels, and necessary skills are all inputs, or what you’d need to bring to a role in order to create those outputs. Holacracy only concerns itself with the outputs. Whatever systems you build to manage the inputs (essentially, a progression structure) is up to the individual org. This is where a lot of companies hit a roadblock with transitioning to a Holacracy. Most companies don’t know how to build a progression structure that decouples person and role. That’s probably because it’s a relatively new problem to which few people have even attempted to create a solution (and I have yet to see a great solution out of the ones that have been thrown out thus far).
If you’re someone who has struggled with this concept at a newly (or even not-so-newly) Holacratic org, don’t worry. You’re not alone! It’s a major paradigm shift that essentially forces everyone in the system to try and undo the lifetime’s worth of programming that has built up around what we believe progression to be. The best advice I can give you is to keep an open mind. Accept the challenge that this blank slate is providing, and maybe you’ll create the progression structure of the next generation!
