Most contemporary organizations operate by placing their employees within certain frameworks called positions. In this article, I will present an alternative approach tailored towards companies that aim to be self-organized: “roles”. I will compare the characteristics of positions with those of roles, and study the practical aspects of implementing roles in an organization. Let’s go!
How do traditional positions work?
The mechanism of changing the scope of responsibilities of a position is “slow”, and controlled by a superior. In practice, it often does not change at all. Employees don’t act in areas other than those defined by their position, even if they see the need to do so. If they decide to take action outside the scope of their responsibilities, the process is not transparent, the fact can get lost in information overload, and the benefit of said action for the organization is (at least partially) squandered. Much needed actions are usually taken too late, and it’s hard to say if and when they were taken or they are not taken at all. The flexibility of the entire organization suffers. The company reacts to shifting requirementsslowly or not at all (1). Employees with good ideas who want to show initiative are “locked into” their positions, which prevents them from offering their full value to the organization.
On the other hand, positions also carry the expectation that if you’re doing well with “A”, you will be equally successful with “B”. Which does not have to be the case. Because we are dealing with positions, i.e. entire bundles of competences and responsibilities, some people might beunable to pursue the type of work they are actually passionate about (and therefore develop much more slowly).
It’s similar with the seniority of a position. A JavaScript Developer can be very experienced with React, but only a beginner at Angular. Or perhaps they are an experienced programmer but don’t know any of the abovementioned frameworks? In one capacity they are a senior… in another, they’re a junior. This system can be demoralizing, which results in a less engaged team. A less engaged team yields inferior products, and inferior products translate into an organization that is not achieving its goals (2).
Because the responsibilities assigned to a position change rarely, or not at all, there is also an issue with transparency. The more general the position, the bigger and more pronounced the problem. Let us look, for example, at the area with which I’m most familiar: what does a Technology Director do? What does a Team Lead do? How about a Managing Director? Is a front-end developer responsible for creating JavaScript programing standards, or for picking the right framework for his team?
In order to actually reflect reality, descriptions of positionsare sometimes several pages long (3) and we get a situation in which numerous “varieties” of front-end developers are needed. These long and complicated position descriptions soon become outdated, because the way we do our job is always evolving to fit the current needs of our organization, our know how, and our experience. This lack of transparency makes an organization less efficient. Sometimes teams do overlapping work. Sometimes no one knows who is responsible for what. And sometimes things aren’t happening at all (because someone else should have taken care of it).
To sum things up, the position system does not lend itself to creating an efficient organization – it limits the flexibility and reaction time of the entire company. It does not support efficient action. It creates unattended areas, which in turn makes it harder for teams to create good products.
But what if we could approach this issue from a different angle?
Lo and behold, I give you…
Roles
Small disclaimer: the way I define roles in this article is not the gold standard, but rather a collection of practices inspired by solutions developed by other organizations.
Alright, let’s get to the point. First, let us compare the key features of positions and roles:
Example of a defined role for practitioners
What are the consequences of switching to roles?
They are the inverse of the consequences ofusing positions.
Due to the fact that roles can (or even must) be created and modified by the people doing thework, the organization’s flexibility is increased. You don’t have to wait for a hierarchical system to allow you to act. If a new role is needed, it can be created relatively easily. The organization reacts to changing conditions and emerging needs more quickly.
A fact that everyone has to make sure a description of their role is up to date means that those descriptions are closer to reality (in comparison to positions), which in turn means that everyone has a better idea of what they can expect from their co-workers. A positive pressure mechanism is created. Communication is improved. The company becomes more efficient.
Roles can be better tailored to the predispositions of individual employees. Released from the shackles of hierarchy, employees have a bigger chance to do what they do best, in a way that is best suited to their actual skills. Seniority is not defined by a label, but by the role’s accountabilities. Which leads to more efficient teams.
There are also interesting side effects of having to individually define one’s role in a company. We often find that some areas are completely unattended, or that insufficient thought was put into what we actually need to do to “push things along”.
A deeper understanding of the role in the organization
The first brush with roles is behind us, but that’s not all. Like nearly all concepts in this world, roles have layers (see also: ogres, onions).
Above all, every role has a clearly defined purpose (4), a goal which motivates all actions undertaken within its accountabilities. This goal explains in a single sentence what a particular role brings to an organization (or a team).
Peeling off the layers of the onion, we can get into more detail regarding creating roles and defining their accountabilities:
- we create a new role when an action is repeatable (it’s possible to perform one-time actions in a given area even if we don’t have the appropriate role),
- each role concerns a relatively narrow and specific area(ex. Team Lead is not a good role, because too broad and too general an area is being condensed into a single role),
- the accountabilities of a role are defined in a way that avoids empty platitudes, so that it’s clear what the person is actually responsible for,
- roles can be performed within the context of the entire organisation or smaller groups (ex. just one team),
- a “role master” oversees the proper implementation of roles.
Conditions to create or change a roles
There’s a “tiny issue”. The fact that roles are not assigned by a superior begs the question: in that case, can any old role be created? Can you just become the team coffee-maker? As you can probably guess – no. The following conditions must be met in order to introduce changes to roles:
- the thing you intend to start doing is needed by the organization or team (a “role master” makes sure that this process is clear and that it is not abused),
- you actually can do it,
- you want to do it (no one can be forced to perform a specific task),
- you are accountable for the task.
Continuing the exploration of our role-onion, we come to the question of the abovementioned accountability. What does it mean? Well, it means that:
- you are going to do the thing for which you assume accountability (or will make sure that it is done, in case of delegation),
- in case of failure, you will fix the causes and results of that failure.
The subject of roles can be explored in even greater detail, but for now we let us move on to…
Practice (as in: well, that looks great on paper, but…)
The most important thing is understanding the essence of the shift and implementing the changes evolutionally.
At SYZYGY Warsaw, we have reached the conclusion that we must get rid of positions altogether. We use them only in contact with the outside world. However, this was a decision taken by our team and it does not affect the operations of the organisation.
It is also important to remember that roles are not static and that they have to evolve. We modify them in accordance with the current needs of individual teams and the company as a whole. We are discovering ways of improving their performance, which affects the scope of accountabilities assigned to each role. What’s more, even the rules of creating new roles evolve as they are expanded with new practices (5).
What practical conclusions did we come to after defining our roles? Mastering the delineation of role accountabilitiesrequires time and experience. The key element of roles is defining accountabilities, as they are the driving force of the entire approach. This forces us to ponder what it is that we actually do, whether it is needed, and if we could be doing it better.
We are also learning communication based on roles. While discussing a given topic, we underscore the role we play in the discussion. This improves communication, defines the scope of the conversation, and immediately contextualizes it.
We are also writing down our roles in an easily searchable format. Currently, we are working on an online text-based list, but having noted the limitations of this approach, we are considering using, for example, the GlassFrog app.
A cure for all ailments?
Are roles the perfect solution to every problem? Obviously, they’re not. Roles create conditions for creating more efficient, more motivated teams that will go on to make better products. But how (and if) they benefit the organization depends on whether they are deployed in a way that takes full advantage of their potential.
Bonus: difficult questions
What if I want to take a one-time action that does not fall within my accountabilities? Does this mean I have to switch my role for a week, and then restore it to its previous state?
As you might suspect – no, it does not. One-time actions are more than welcome. You just have to consider how they might interfere with the accountabilities of other roles.
Can I become the Managing Director after we implement roles?
First of all, Managing Director is not a role. Secondly, if you want to start performing a certain role, pursuant to the rules of this system, you must first consider whether It is needed (what if someone else is already performing this role?)
- Option A. Roles are great. All our problems are over.
- Option B. Who needs roles? They won’t change a thing. They’re just adding confusion.
Neither is true. Every change brings us closer to improvement, step by step, and the role mechanism is a step towards self-organizing teams.
Meh. I don’t get it.
Then let’s look at it from a different angle. Roles work like this:
- do you feel that something should be done differently and want to take responsibility for it? Go ahead (within reason and in sticking to the rules)!
- do you see an unattended area? Go ahead (as long as you follow the rules 😋)!
Follow the rules, and change them when needed
Footnotes
- We’ve all seen companies miss an opportunity on the market, or release a dud that didn’t match their general profile. When was the last time you saw a smartphone running a Microsoft system? One of the reasons might be the structure of Microsoft at the time.
- And just bleakness far as the eye can see.
- We went through this when trying to define some of our positions, creating entire novels in the process.
- Bonus points for the astute readers who wondered about this when studying the provided example.
