Years ago as an IT project manager I found myself in a difficult position on a new assignment. The team I’d been given was completely dysfunctional. In terms of the five phases of group development, they were in perpetual storming, unable to resolve conflicts about roles and responsibilities within the team. As a result, this team was broadly considered to be one of the most difficult to work with in the entire business unit and had a history of slow deliveries and project failures.
My first few months with this team were awful. Everything I asked them to do was met with resistance. They didn’t want to continue as they were, but they also could not agree on what to do to fix their problems.
Whenever I am faced with problems like this, I try to dig deeper and understand what values are driving the conflict. If I can figure out the underlying values creating the conflict I can generally figure out ways to address those values in meaningful, helpful ways.
In this particular case I realized there were two fundamental value clashes driving the conflict: inclusion and contribution.
Inclusion
Some members of the team believed that inclusion in technical discussions should be determined based on role, title, and experience. My first clue happened on my first day with the team, when the team members told me that, as a project manager with a software architecture background, I was not “allowed” to contribute to technical discussions. I soon found that this sort of thinking was applied to other members of the team, and that opinions of “junior” engineers were not “allowed”.
Contribution
Everyone on the team wanted to contribute in meaningful ways. They wanted to prevent future project failures, and many of them had ideas for adapting the way they worked to reduce risk, eliminate bottlenecks, and collaborate more effectively with the rest of the business unit.
Unfortunately, most of these ideas either came from junior engineers or they required junior engineers to make decisions that were considered “above their pay grade”, so these ideas were not allowed.
This combination of values led to a state of constant bickering. Junior engineers pushed for change, and senior engineers told them to stay in their assigned seats. They spent all their time building coalitions and sabotaging each other instead of shipping working software.
It took me a few weeks to understand what was going on, but once I had a handle on the value conflicts behind the team dynamics, I was able to come up with a plan. I introduced two things to the team: a set of rules and a feedback game designed to enforce the rules in a playful, friendly way. I’ll talk about the rules today, and perhaps in a later post I’ll describe the feedback game.
Four Rules for an Inclusive Culture
The rules I introduced were crafted for this specific team, but they have stuck with me in the years since. I don’t always prescribe them for my teams, especially if we don’t have inclusivity issues, but I always try to follow them personally.
- Anyone who can contribute is allowed to. This rule emphasizes everyone’s responsibility to LISTEN. To illustrate this rule, I like to use the example of a janitor overhearing a conversation between two engineers and making a suggestion. If this happens, we listen carefully, we discuss the idea, and we aren’t dismissive simply because it came from a person holding a broom. If I can create a team that will listen to the cleaning crew, they will also listen to the junior engineers and the project manager.
- Be title-blind contributors. This rule emphasizes everyone’s responsibility to SPEAK, regardless of who is in the room. A junior engineer with important information about a project risk should share that information. That’s true in a team setting, in a large group setting, and even if the CTO is in the room.
- Know the difference between different and better. This rule emphasizes the importance of JUDGING and CARING. People will argue the most when it matters the least - I often use the example of a couple purchasing a car. They will spend more time debating the color than aspects of the car that really matter, such as how many people it will hold. This is because seating is easy to create a value for, but color is nothing more than a preference. They will often acknowledge that their preference is not important by saying things like “I don’t care but…”. People who say they don’t care almost always do, and I like to call them on it. So when that happens, I ask them if they are sure they don’t care, and if they say they are I vote for the idea of the person who does care. When two options are just different, and boil down to a preference, don’t debate. Go with the one that has a supporter who cares and you are much more likely to succeed.
- Have thick skin, shed no tears and bear no grudges. I think it’s okay to cry at work when disappointing things happen. That’s not what I’m referring to here. What I’m really trying to emphasize is that we shouldn’t get so wrapped up in our own opinions that we can’t let them go for better options. We shouldn’t view discussions about what to do as competitions, instead we have a responsibility to set aside our own egos and do what’s best.
I was surprised by the reaction of the team. Everyone on the team embraced our new rules, with one exception. The exception saw the new rules as the last straw and he left the company soon after.
Everyone else saw the new rules as the light at the end of the tunnel, a mechanism they could use to get out of the unhealthy cycle they were trapped in. They followed the rules and they used the feedback game I introduced to help enforce the rules. Within a week we could see tangible improvements internally. Junior engineers were given stretch assignments and were full participants in technical discussion. Senior engineers listened to them and created plans to deal with the risks they brought to light. We started having little successes, then big ones. Within a few months my colleagues across the business unit were expressing admiration for the turnaround in the team and much of the friction of working with the group was gone. Within a year the team’s reputation as a bottom dweller was forgotten.
Even though I came up with these rules more than fifteen years ago, they are more important now than they have ever been, especially as organizations work to improve diversity and inclusivity within.
If you made it this far, I hope you have found some value in these rules and have a takeaway to apply them in your own space. If so, I’d love to hear from you! Please leave a comment and let me know.
Dave Christiansen
Writer. Maker. Programmer. Leader.
Writer. Maker. Programmer. Leader.