There’s an inside joke among software developers that goes something like “naming things is hard.” That’s certainly true. I can’t count the number of times I’ve stared at my screen trying to figure out the perfect name for a variable, document heading, team name or any number of other things over my career. As I’ve moved away from what I lovingly refer to as “slinging semi-colons” (ie: actually writing code) into software engineering management, I’ve realized that same inside joke applies to a lot of things.
Take managing an engineering team for instance. Assembling and growing a group of engineers into a high-performing team should be fairly straightforward in principle. Find awesome people, give them a cool mission, sit back and let them go. The reality however is much more labor intensive. Day to day care and feeding of the “team dynamic” takes a lot of work and a large percentage of that work is just listening. Listening to the engineers when they tell you that some process or tool is making their life more difficult. Trusting your engineers when they tell you that your idea of how things should be done isn’t the best or most efficient idea. Taking that information and figuring out how to solve the problem for them so they can be productive is another difficult phase that needs to be addressed.
One of the things I struggled with as I made the transition from individual contributor to engineering manager was coming to grips with the fact that my people were more technically advanced and knew more about the application than I did. It took a while for me to “tamp down” the sort of hubris that I’d developed over the years as I became a more advanced developer. One of the things that made this somewhat easier is that I have been blessed with an incredible group of team leads that I knew had the best interests of their teams and the projects at heart. I learned to make sure they were comfortable telling me things they thought I might not want to hear. I learned to trust their judgement on things they obviously knew more about that I did. Through that, they learned that I would do everything I could to make sure that they had the tools and opportunities to deliver excellent solutions to the problems we were asking them to solve.
None of this came easily. On several occasions I felt like I was making things up as we went along. I came to realize over the last few years of managing engineers that it’s okay to feel that way. Collaborating with highly-effective teams is worth the effort and the relationships I’ve made with those people are ones that I cherish.