Passing the Torch

Prior to taking on the responsibilities of leading a team at Fender, I worked as a software engineer across a variety of industries — entertainment, social networking, financial institutions and ad-tech. Throughout those years I had gained engineering experience as part of a large team and also being a one person show. That wide variety of industries and team sizes taught me quite a bit, including how important it is to make the effort to mentor less experienced engineers. Passing on the lessons I learned and demonstrating the importance of those lessons to others is not just part of my job as a leader, it is key to the success of my team.

As odd as it sounds, when I was a team of one I learned much more than being part of a larger team. Being responsible for development, testing, deployment and production monitoring taught me lessons I did not learn as part of a larger team where that responsibility was divided and spread across a variety of specialized teams. That hyper-specialization served to focus my effort to dramatically improve the quality of the software I was writing, but from another point of view it actually limited my technical growth with such a narrow focus. Being aware of hour your applications impact other applications and the context in which they operate is critical.

As an experienced engineer it can be easy to fall into a trap of taking care of issues yourself, as in the short term it can be faster than working with others to share that knowledge. While triaging a production issue is something that is best done as quickly as possible, afterwards it is critical to review what you did with others on the team. Being the only person with knowledge of a given system that is always called on to address issues can be an ego boost, keep in mind that it is not fun to get called about an issue when you are taking some well deserved time off. It’s the ‘hit by a bus’ problem — if you are removed from the equation can the team succeed? If the answer is no you are not fulfilling your responsibilities as a leader.

As a leader I have the opportunity to observe behavior in engineers that I myself once exhibited. This allows me to help others on the team, passing on my knowledge without them having to learn those lessons the hard way through downtime and firefighting. Lessons I learned that come to mind include:

• Time boxing problems. If you are stumped on an issue after an hour, ask for teammates opinion as it is easy to overlook an obvious issue that you are blind to.
• Observability and instrumentation. This was an important one for me, and I consider it critical to creating quality software. A good question to ask yourself is that if a customer is reporting an issue, do you have enough information to determine what the issue is?
• Documentation, documentation, and documentation. The first time you need to explain a process to another engineer should be your last. Write up the details and refer others to the documentation when they ask in the future. Remember that documentation must continually be updated to ensure it is relevant as systems evolve.

When in a senior engineering role or when transitioning to leadership it can be tempting to ‘just take care’ of an issue or quickly add a new feature, that does not do anyone else on the team any favors as they just think ‘someone else will take care of that’ and it does not provide them the opportunity to improve their skills. It is significantly more important to pass your knowledge and experience on to others, allowing them to learn and grow, strengthening your team in the process.