Clarifying roles in a team

In the agile world, the ideal team is diverse and egalitarian – different characters with different skills who work together and organise themselves as a group of equivalent and equal individuals. If organisations follow the Scrum Guide, which defines only three accountabilities, teams operate without internal structures, roles or specialists. Accordingly, demands for the designation of responsibilities that are brought to teams from the outside must always be resisted.

For classic, control-oriented management, on the other hand, unclear roles and responsibilities are a horror, a risk that must be eliminated. For every conceivable issue, not only a solution is sought, but also an answer to the question of who will deal with similar issues in the future. “Only when the responsibilities for every issue, every question, every decision are clearly defined can the organisation run efficiently” is the idea behind it. Okay, maybe organisations will then no longer be able to change direction in the event of surprises, but at least they will run straight ahead without significant frictional losses.

Both approaches have understandable backgrounds. When important issues are left undone or fall through the cracks, it is a very unpleasant experience for those who are ultimately held responsible. On the other hand, classic functional roles (e.g. development, test, design) within an agile team create more problems than they solve. However, both paradigms do not really justify their principles satisfactorily, discussions about them therefore often run dogmatically, as experience has shown, instead of revolving around what consequences a decision for or against formalisation has in detail.

The need to define roles

In my work with highly self-organised teams, such as at DB Systel or now at Chili and Change, I have made an interesting observation at this point:

Even if there is no external pressure at all to introduce roles and responsibilities, the need to do so arises within the team anyway.

In stark contrast to the Scrum Guide is the experience from practice: people want to define roles in their cooperation. This starts with questions such as “who actually runs the meetings with the customer”, continues with creeping routines in the assignment of tasks (“Leave the customer meeting to Klaus, he did a great job the last few times!”) and ends with hard formalisation (“Customer contact always goes through Martin, our Customer Engagement Manager!”).

Different conclusions can be drawn from this contradiction between theory and practice. Some psychologise that people simply lack the “maturity” to “already” completely detach themselves from their hierarchically conditioned reflexes. Others separate according to hierarchical level: if management wants to define a role, that is bad because it is externally determined; if the team wants to introduce exactly the same role, that is an example of successful self-organisation.

Both are too shallow for me. I like to work with people as they are, instead of basically assuming that they need development. And self-organisation is a means, not an end in itself – a role defined by the team can be just as useful or nonsensical as one decided by management. Instead, I ask about the systemic function:

• Why is role definition useful for people in organisations?
• What factors contribute to it, and are they within our sphere of influence?
• And: does role definition also create a benefit for the organisation, or does local optimisation in the team end up creating global problems in the organisation?

But lets start at the beginning.

What is a role?

A role is a set of behavioural expectations and decision-making powers. As a role holder, I am therefore allowed to make certain decisions that others are not simply allowed to make. In return, I am expected to do certain things on a regular basis by virtue of my role. I can’t just decide anything either, because that will be interpreted as “exceeding the scope of competence” and discarded. An example of a role is the lookout on a sailing ship – he/she is expected to point out interesting events and problems in the wider vicinity of the ship, and decision-making powers include questions such as “what do I report and what don’t I report?” and “how do I draw attention to an event?”, but not “where is the ship going?” or “how long will our breakfast eggs be cooked?”.

Every decision-making power also has its flip side, namely responsibility for the decisions made. Being allowed to make binding decisions means at the same time that the organisation will also attribute all problems that arise in the context to the role holder (the holder, not the role!). If the sailing ship avoidably hits an obstacle or runs aground on a sandbank, the lookout will get an earful. This has an encapsulating effect for the organisation: if something goes really wrong, in case of doubt, the role holder is dismissed from the role or even the organisation, and thus the problem can be declared solved. Roles are hence useful for the organisation to be able to abbreviate problem analyses. The lookout should have reported the obstacle in time, but he didn’t, so he can no longer be lookout, end of story.

But defining responsibilities can also be an apparently attractive solution for the team itself. For me it was a surprise that self-organised teams, free from any management influence, simply wanted to reintroduce all those roles themselves that I had previously justified and rejected for years with management expectations. Even without any external pressure, there are obviously situations where the introduction of a role is beneficial for all team members.

The reason for this is that in a complex environment, role definition serves several individual solution strategies. On the one hand, if I manage to take on an influential role, I can do what I want within this role and thereby gain more creative possibilities and the ability to react. On the other hand, every role that someone else takes on reduces my personal area of responsibility, making my daily work more manageable. Knowing that someone else is taking care of an issue makes it possible for me to concentrate better on my remaining work. And in many situations it is also important that only one of us is actively working on something, because otherwise there are collisions. For example, in a team we once tried to look after the team mailbox together and very quickly realised that it would be better to appoint a single “keeper of the mailbox” who changes every month.

So introducing a role can benefit both the role holder and the rest of the team at the same time. Both are individually functional and comprehensible strategies. Unfortunately, this still does not mean that this role must then also be a good idea for value creation and thus for the organisation.

Side effects of role definitions

First of all, we should get away from the naïve idea that introducing a role brings “additional clarity” to the team without having any side effects. In the first place, new roles only concentrate existing expectations. Undesirable side effects are, for example, that

• a topic is left undone when the role holder is absent (“sorry, that’s the colleague’s responsibility, and he’s sick this week”),
• no one feels responsible for a topic (“Klaus does that, I don’t interfere with him”),
• defining, reviewing and sharpening the role is additional work.

It is also underestimated how much additional work is necessary simply because there is now a “single wringable neck”, i.e. a single person who can be held responsible in the event of an error. Whether the error ever occurs or the person then has to justify himself or herself for it does not matter at all. It is enough for the role holder to expect that it could happen to bring additional work into the system. Let’s look at an example of this:

In a self-organised start-up team, the issue of occupational safety has so far been treated with optimism and ownership. The office is in good condition, everything is in view. When the Corona pandemic causes all team members to move to the home office, the team wishes that a single team member would please take care of the issue “so that it doesn’t get left behind”.

One colleague – let’s call her Anna – finds the issue important and is happy to offer her services. She realises that she is not well versed in the regulations and starts to read up; it could be that the others will have questions for her now that she is the occupational safety officer. In addition, she attends a paid training course to be really well versed in the subject. After the training, she goes to the office to check it against the newly learned guidelines on site. Let’s assume optimistically that there are only a few small things to do in the office. She takes the time for all these things from her normal value-adding work.

According to Anna’s assessment, the office is in a good condition in terms of safety, but no one works there anymore. So she starts by systematically surveying the status of the team colleagues who work in the home office and schedules individual meetings for this purpose. For some of them, she finds that additional purchases are necessary to make an ergonomic workplace at home possible. Others, to Anna’s dismay, simply work on the couch with their laptops on their knees! She is always told that there is no room for a desk in cramped city flats. Because the looming costs are starting to become significant, a team meeting is called to discuss the workplace situation. There Anna makes it clear that although she knows the guidelines, she is not confident of making a legally sound assessment. It is decided to call in a lawyer….

My point is not to question Anna’s actions or the need for a proper home office. But hopefully it is clear that there is a lot of new work for the team as a result of the new role definition. At the same time, Anna is visibly building up a knowledge advantage over her colleagues, which will make it more difficult for her to hand over tasks to her colleagues in the future when she is overloaded. This is exactly what happens when software development teams make a strict distinction between front-end and back-end developers. Or when there are dedicated designers and testers in the team. Or when certain tasks are simply done by the same person over and over again. Knowing that you are solely responsible for a topic creates extra work and sooner or later a bottleneck. Bad if this bottleneck lies precisely in the value creation process.

Conclusion

Does this now mean the definition of roles is a bad thing? No, certainly not. In my opinion, human needs for focus and clarification of expectations must be taken very seriously. However, we should move away from the naïve idea that “more clarification” is basically the right direction. In the role clarification workshop itself, it feels great to have clearly defined responsibilities down to the last detail, but when a new task suddenly crosses our beautiful new role model the following week, the anger is great.

It’s about finding the right balance between formalisation and spontaneous self-organisation and making conscious decisions about it again and again. Leaving things undefined and undecided is often a good thing! In particular, questioning and deleting existing roles is, in my opinion, considered far too rarely. There are quite a number of indications that point to problems with a role model in the team:

• A classic is the “football coach syndrome”, where the same role is filled every few months after the previous role holders have fallen out of favour.
• No team member wants to take responsibility for certain topics because there are already fixed role holders (e.g. testers in the team, so no one else tests).
• The workload occurs in waves for individual team members, i.e. phases of boredom alternate with phases of overload.
• And due to illness or holidays, there is the threat of a complete standstill in topics for which individual team members are responsible.

If you observe such things in your team, it is high time to take a closer look at the roles and responsibilities together.

I have been working with agile working methods for over 10 years and believe that when it comes to clarifying roles, the team should carefully observe its own structures and, above all, the consequences of its decisions. There are roles in my teams too. Before clarifying expectations and decision-making powers, we always ask two questions:

1. What are the advantages and disadvantages of a new role?
2. And are the advantages worth the disadvantages?

We make sure that the roles are and remain accessible to everyone – so Klaus can be responsible for project A and Anna works for him, and then Anna is in charge of project B and relies on Klaus’ support. If appropriate, we rotate roles on a monthly basis so that they do not become ingrained over long periods of time. It is normal for different levels of knowledge on a topic to build up over time, but this should not tempt you to keep giving a topic to the person who already knows it best. In the short term, this may seem more “efficient”, but in the long term it leads to specialisation, uncertainty and rigid work routines.

And last but not least, in my view it makes a lot of sense to always work on important topics at least in pairs, because this significantly reduces the risk of failure, spreads knowledge more widely and improves results through the dual control principle. Here, the simple question “Shall we take care of this together?” often works small miracles.

Notes:

Other articles in German by Kai-Marian Pukall can be found at Inspect&Adapt and on LinkedIn.

In the t2informatik Blog he has published more posts:

What does t2informatik actually do? One click and you'll know.