Being A Team Norms Chameleon

Team norms are the often unspoken rules, values, or behaviors that a team operates under. Every team has team norms. Some teams even document them (recommended if you can nail them down). Whether someone is new to a team or has been there for some time, it's important to learn how to adapt to these norms. Those that don't learn to adapt to these norms will often find frustration or at worst, termination. Those that can adapt to these norms are what I'm going to call a "Team Norms Chameleon".

The last several teams I have been on practiced pair programming on all production code. I feel like we had the best setup for pairing: two sets of monitors, keyboards, & mice hooked up to a single computer that is the team's. This is great because you don't have personal space issues, it's easier to swap pairs, and you don't have to worry about personal accounts getting in the way on the box (for the most part). It also means that most if not all the team need to agree on the same tooling and in most cases, the same shortcuts. This kind of environment is where a Team Norms Chameleon can really shine.

First let's talk about what not to do. Someone joined my team and had 👏 very 👏 specific 👏 ways 👏 of 👏 doing things. For example, when it was their turn to type, they needed to run their macro that switched out to their shortcuts. When it was the other pair's turn, they needed to run the macro to switch the shortcuts back. When it was time to debug things in the browser, they pulled things up in their browser of choice.

Whether these tools or shortcuts are "better" is debatable. These are minor tool changes & preferences but they slowed the team down. They caused friction within the team.

Now for another example. Someone else joined my team. They weren't used to the team's IDE of choice, they weren't used to the framework we used, they didn't even really have experience using the OS we used! I don't know if they disliked working with the tools we used but they worked using those tools and became proficient with them.

Later on this team member asked during retro if we were interested in trying out their favorite IDE for while. I was skeptical because I was pretty handy with what we were using at the time but we tried it out. Turns out everyone liked this other IDE better and we installed it on all the pairing stations. The team had to learn new shortcuts but we quickly became more productive with this IDE than the previous.

Let's look at the differences here:

• Team Member A didn't give the team's tools a chance. Team Member B tried out the team's tools enough to develop an opinion about them.
• Team Member A pushed their tools on team members (albeit indirectly). Team Member B asked for a limited trial run with their desired tool.
• Team Member A's approach slowed the team down. Team Member B's approach sped up the team.

While these examples are a little trite, they actually happened. Nobody got fired over any of this but who would you rather work with?

I like the visualization of being a "chameleon" but really the key word here is adaptability. When you start on a new team, it's easy to see potential mistakes or what you believe to be inefficient ways of doing things. This is good, write that stuff down and bring it up later. Experience the team's way of working and the tools they use. Ask why they use the tools they use or why they do the things they do. When people feel like they've been understood, they're much more likely to entertain your way of doing things.

If after experiencing these tools & ways of working, you feel that there are better tools or methods, look for opportunities to share them. Retrospectives are an excellent place to do that. Your company or team may even offer opportunities to share these things through semi-formal learning sessions.

If you try your best to be an adaptable member of your team, you'll find more empathy for others on your team and they'll find more empathy for you. I promise that you'll be more successful in general and you'll enjoy being with your team more.