Leading Development Teams through Mistakes and Disagreements

Here are a couple strategies that helped maintain high morale:

1. Giving praise publicly and often, even for the little things. If this isn’t your natural leadership style, you can empower the team’s natural cheerleaders to help maintain positive morale. People are usually mirrors. Compliments not only require confidence but also inspire it. Each act of recognition fosters a culture of mutual support and can ignite passion. Under the surface, this becomes contagious and spreads resilience throughout the team. This positive feedback loop insulates against the uncertainty we face in software engineering.
2. Humor, as obvious as it is, can be extremely powerful in diffusing tension. There are many great articles on how well-placed humor and wit can bolster comradery. Turning on humor is not easy unless you are a Director of Software Engineering and do comedy gigs on the side. (Shameless plug for one of my mentors and the best boss I’ve ever had – Michael Holloway). Just like with compliments, if you have engineer(s) that were class clowns in high school, look for ways to empower them. There are a variety of ways to spark humor, here are a few examples: Maybe start weekly team meetings with a programming joke or let that class clown engineer drive the demo at the end of the sprint. On my team, we always ended our sprint cycle with a Happy Hour. The team would create an AI generated image. Each engineer would add a random word or phrase to the prompt, Mad Libs style. To this day, I still laugh about the imagery we created together. Some of the best memories people will take away from their careers are the funny moments.

Even with high morale and embracing the power of vulnerability, disagreements will happen, and they should. Often leading to positive change, efficiency gains, and innovation, it’s crucial to coach the team beforehand. Disagreements usually arise when perspectives and/or experiences are not in alignment. Despite opposing parties having the same goal, one party doesn’t have the subjective experience that the other has. When teammates tiptoe into a disagreement and you start to see their heels dig in, acknowledging it publicly by asking a question. Here are some questions I remember from real life disagreements:

“Whether we use Github CoPilot Enterprise or ChatGpt Enterprise, company data won’t be used for training new AI models but you mentioned privacy. It sounds like you have strong feelings around that, what are we missing?”

“Even though Tailwind is popular, are there drawbacks or risks that you’ve experienced that may be unique to our team or applications?”

“I agree that converting this Ruby on Rails application into our “New World” React.js/Next.js stack first, would make the migration easier. Since our next roadmap milestone is to lift and shift the legacy Ruby on Rails application to AWS first, what specifically can we propose to the product owner and leadership?”

“I see both sides, our premium users probably prefer Github as their Oauth provider. I also agree that implementing Google as an Oauth provider would serve a wider audience. Can we do both?”

Neutral questions like these, subtly suggest that both parties think like an owner. They also carry an assumption that each engineer is looking out for the entire team’s best interests. One well placed question can lower everyone’s gloves at the same time. By rebooting the conversation and shifting the goal from being the “winner” to “I am missing something, let’s get in alignment.” It can be hard when you are passionate but it’s important for both engineers to lean into the other’s perspective. Actively listening to their perspective helps shore up blindspots and better understand the other viewpoint. On my team at AMU, discussions around Team Standards were primed for having disagreements. I referenced the quote in this mantra, often.

Human mistakes will happen even with 98% test coverage. The mantra below, helped our team not only make fewer mistakes but also spawned numerous improvements from the wakes of problems. When joining calls, read the room for heightened vulnerability. Observing this is like watching a guilty engineer on top of an elephant as they slowly walk into the room. The mantra below has a quote that offered many of my engineers and I a ladder to dismount from the proverbial elephant in the room:

Tying a quote/question to a mantra is powerful because it can weave a whole aspect of culture and all of the previous related experiences into an easy one-liner. Every time anyone on the team says it, that aspect of culture is reinforced. Asking that mantra question out loud, changed the game for us. Here are three main reasons it works:

1. It can offer safety to the vulnerable party – By giving the vulnerable person an off-ramp from collective scrutiny it quickly shines a bright (constructive) light on the door that the elephant came in through and not the elephant or the engineer. It also allows the engineer a chance to vent and offer important context on the situation. Here is an example keeping with our storybook regression example:
   

   “It’s so frustrating! My daughter dropped my iPhone in the upstairs toilet right before we were on the call so I was completely flustered and forgot to update the secrets for NextAuth in our AWS Secrets Manager. Since the name of the secret changed our application was looking for a secret that is no longer in the project. I digress, I don’t know if it can be prevented. We have playwright tests for logging in as part of the 12-point Continuous Integration/Continuous Delivery pipeline. If there was a way to check to see if any of an application’s secrets aren’t actually referenced in code, that may have prevented this. Thoughts?”

2. Problem + Lesson(s) Learned = Innovation – A link appears in the team’s slack channel and another engineer unmutes:
   

   “Dotenv-Linter lints against that! About a month ago, Jennifer and I created a branch to research spike if we could easily enable that in our megalinter. I linked the codespace for it in our chat. See if you can recreate your mistake with that linter enabled. It auto-corrects if you type a secret like: SUPER_SECRET-KEY to be SUPER_SECRET_KEY. That would prevent it even before the Next.js application builds!”

3. Accountability – Sometimes a spade is a spade. The answer to that mantra question may be “No, I just messed up.” As long as it’s not a frequent occurrence, it’s noble to apologize upfront and own it. Consider the earlier mentioned: people are mirrors metaphor. During a team discussion where we asked the mantra question, everyone has the opportunity to self-reflect on if they contributed to that mistake. On too many occasions to count, another engineer will jump in and says “No, I should have caught that on the PR. I missed it, too.” This cascade of ownership and servitude starts with the leader of the group. An incredible book on this concept is called Extreme Ownership. This mindset makes the whole team better, cohesive, and growing as a single unit.