Setup Determines Behaviour
or in a more detailed wording, the way a group of people is organised determines the culture, behaviour and results of the group.
If you’re interested in improving teams’ performances, if you’re interested in how people’s behaviour can be adjusted in the workplace or if you’re a person interested in generating better results and how the dynamics of a group is influencing these results, then this article is for you.
I’m sure you heard multiple times in your professional life (such as I did) that a certain group does not deliver what they’re supposed to, or a certain group has a (too) competitive culture or a group has a behaviour that could be improved. Usually in these cases the individuals that form the group are finger pointed, and labeled as not taking enough ownership or unreliable or underperforming or any other minimising terms, when there’s a single simple guideline in treating all these situations: setup determines behaviour.
What does this setup thing mean?
It means that whenever you’re in trouble, and a certain group or unit does not perform as expected, the group dynamics is a consequence of how the group is organised. Smartest thing to do in such a case is to evaluate the issues in an honest way, and take actions that will address those issues.
Some questions to ask yourself
that could apply in such situations are:
- Is the group working well with other groups? If not, maybe you want to read my article about setting common goals.
- Does the group have a clear focus on results, or on competences? Similar to the situation described in the article above, if a multidisciplinary team is focused on competences – we are here to log bugs (for testers) vs we are here to deliver features (for developers) the two subgroups will work against each other instead of for each other. Once the group has a focus on features – we are here to deliver Feature X – then they will work as a team.
- Are there clear roles and responsibilities within the group? Is the boundary between these roles clear or are they overlapping or redundant in some way? For large scale organisations things easily become complex, and it’s easy to generate confusion within teams if things aren’t clearly separated. Who is responsible of what? Whom should be contacted in case of what? Such questions need to have a clear person or role as a response.
- Are the stakeholders aligned? Remember there are people accountable and people responsible for a certain job or group. The ones accountable are those who influence the group’s setup and roles, and the ones responsible just execute within the given setup. This stakeholder alignment means they’re all following the same goal and not send contradictory indications (we need to focus on bugs vs we need to focus on integration vs we need to focus on the main feature).
- Do people have enough time to work? Are the managers allowing people to work? You may want to read the Gallup Employment Engagement questions on this subject, I also have a brief article in Romanian about it. Some organisations have a culture of meetings instead of a culture of decisions – even if something can be debated over and then agreed asynchronous via email, the choice is to have a meeting when everyone is available, probably next week, and then a follow-up meeting to review the open topics of the first one, the other next week, and the third follow-up to make a decision, obviously the other other next week. I already lost you, right? 🙂 True story with these meetings though.
- Does the group have modern collaboration tools? Everyone is remote these days so cloud and video meetings need to be business as usual. My following article underlines the huge benefits of modern collaboration tools.
- Are the teams distributed in too many locations? Usually when a new customer is on-boarded time is crucial from any perspective and compromises are being done. If the situation remains (too many locations), the huge overhead risk is still there and strategic actions need to be taken, such as consolidating the teams, based on hiring potential, available competences or other factors. I did not meet a stakeholder until now that wouldn’t be happy about consolidating their project teams over time. If it’s too complex a 6-months or one-year consolidation plan works like a charm.
- Is the priority list efficiently defined? Are the topics on the list really that important vs the other ones? Are we working on the sustainable topics or just the urgent ones? These are definitely questions worth asking if things are (or not) going the right way.
- Agile theory requires Daily Build and Daily Test. Does the project setup support that? Here’s a link to my witty article on Agile topics.
- Are the right people in the right places? Sometimes a more directive approach is needed to exit a crisis, when an autocratic individual should temporarily run things, while under normal circumstances a strategic approach needs to be taken to overcome a crisis and the above mentioned individual should step down as their approach is usually burning the teams.
And to wrap-up here
as there might be too many directions, remember this: whenever a group has problems, look at the group’s setup, not at the individual members. That’s the place to be fine-tuned, and with the right actions – that usually can be very simple and clearly expressed and explained – the results will quickly improve.
You don’t have to be a genius to define such corrective actions and improve results, but you definitely need to think in terms of cause and effect, where cause is the setup and effect is the behaviour and results. That’s the genius part 😉