Over the past few months, a situation developed on my team. Work that was prioritized was being avoided in favor of more appealing work. There was a growing lack of results. There was constant complaining. And morale felt low. I knew as the tech lead on the team I had to figure out what was going on and how to address the problem. This is how I approached it…
I spent some time meditating on this and a few threads came together. Over the past year, we have been integrating with a larger business unit. With that integration came the inheritance of some legacy codebases. This code was largely written in Ruby on Rails. My squad had a negative attitude towards Ruby on Rails. We would rather build in virtually any other language or platform.
As I thought through this, I realized something. This situation was my fault. I took a note from Jocko Willink1 and decided to embrace extreme ownership. For over two years, I had allowed my negative attitude towards this tool to take hold and voiced it throughout many of my exchanges. I didn’t properly respect and appreciate the influence that my voice had; especially with more junior developers. And now that I was in the role of tech lead on my squad, this was even more important. I felt a responsibility to do what I could to turn the ship.
So how did I do this? I knew I had to have a heart-to-heart conversation with my developers. So I called a short meeting together with them. I started by walking them through my history of thinking which I shared above. I then admitted that while my opinions on the technology haven’t changed, my attitude towards it had affected our ability to work effectively. I said that I was sorry for allowing my attitude to affect the team and said that I was committed to improving it. I then appealed to them to join me in that effort. I reminded them, and myself, that the tool wasn’t as important as the mission and the work that was in front of us. That we can improve everything that has been handed to us if we only embraced ownership of it.
The team needed time to process the conversation, but overall it seemed to be well received. Within a couple of weeks, one of them even improved our workflow with our Rails repos by introducing dev containers. This stabilized our environment and eliminated a lot of headaches we were experiencing. We’ve also continued to add documentation to the project and practiced the boy-scout rule, making improvements as touched it. I’m very proud of my team for the progress we’ve made. Overall, the vibe is much much more positive. Work is more fun.
In hindsight one thing I could have done better is establish psychological safety at the beginning of the conversation. I launched into the talk immediately without simply establishing that no one was leaving and no one was getting fired. These two assumptions are the first places people naturally go when called into a meeting like this. The safety needed to have a difficult conversation well can be threatened without those kinds of fears allayed from the outset.
Looking back, I can see a progression of steps that allowed us to correct our attitudes and start getting the results we wanted. These are:
Recognized there is a problem.
Meditate on the root cause. Be curious. Are there any common themes?
Recognize and admit your part in creating the problem. This is especially important as the leader.
Call the team together to address the issue directly.
Invite your team to join you in fixing the problem.
Follow up. Check-in with the team, and individually. Treat it as a continual discussion.
Recognize and celebrate progress.
J. Willink and L. Babin, Extreme Ownership: How U.S. navy seals lead and win. Macmillan, 2018.