So much of what we do as technical leaders is about interaction. Managing smart people is incredibly rewarding, but navigating the sea of opinions can sometimes be tricky. It can sometimes feel overwhelmingly difficult to steer our teams towards building the right things as well as building the things right.
In a rush to create, many engineers feel that they must take a shortcut to a solution. They must be heard because they have the answer.
This can occur in behaviours that are difficult to square in a team setting. People will often take on roles of submissiveness and dominance according to how they feel about certain subjects.
For example, an expert in one functional or technical area may think that they can decide how all areas should be implemented based on their narrow experience. We can call this pattern the Lone Ranger.
Someone who worries about deadlines might decide that things are not progressing fast enough. We can call this pattern, Got To Have It Now.
Others might make decisions based on their knowledge of what worked in the past without considering the current constraints. This is the We Do It Like This or the Blinkered pattern.
Perhaps you’ve seen some of these behaviours in the projects that you’ve worked on. The good news about seeing these behaviours is that this means that the project matters and the people are engaged. The next challenge is to integrate perhaps over-enthusiastic behaviours into those which benefit the project.
Managing Patterns of Behaviour
The good news is that a lot of the time, behaviour patterns which might be dominating a team can usually be eased away by slightly changing the dynamics and giving responsibility to those who are keen to go faster.
A team isn’t a team if it’s being dominated by one type of behaviour or another. It must work together as a collective to perform at its best. That means a few things:
- Having a common understanding of the problem
- Trusting in each other’s way of working
- Able to raise issues without fear of reprisal
- Able to experiment and work independently towards solutions
Many of these ways of working and more have been collectively grouped under the handy phrase “Psychological Safety” in much of the current software engineering literature. But psychological safety doesn’t come for free, and it needs to be created and to do that the dominant behaviours need to be tamed and a common language discovered that the whole team can speak.
This could mean finding things for those with dominant behaviours to own, or sometimes it’s about creating a framework of responsibility which gives everyone confidence in the process they are following. Sometimes it’s about personal responsibility, and sometimes it’s collective responsibility.
In addition to creating an atmosphere of ownership and openness, it’s important to set boundaries both inside and outside the teams. This means learning how to say No nicely to other teams, to individuals in the teams, to business stakeholders.
Boundary setting, collective responsibility, psychological safety. One of the best books I’ve read about enabling these types of organisations is Team Topologies. Your next stop should be there.