At the time of writing this I find myself roughly two months into the new position that I wrote about in Another New Adventure. I did not mention in Another New Adventure that my new title is “Tech Lead.” Prior to this position I was a software engineer for almost fifteen years. As a software engineer I relished the joy of diving into problems and creating or fixing a complicated system. In this new position as a tech lead, however, I find myself with a different day to day task: I go to meetings

Just kidding! In reality this means that I spend my time mentoring a software engineering team and helping clear paths to get their work done. The definition of my position as a tech lead has been somewhat flexible. It has evolved into a combination of senior software engineer, technical project manager, software architect, and, most importantly, mentor. My goal for this article is to explain how I intend to serve the members of the software engineering team.

What Does Mentoring Look Like?

Mentoring is, by definition, dependent on what the mentee needs. There is no single best way to mentor that will serve everybody equally. As such, I will give some examples based on the roles of the people that I’m working with.

The New Software Engineer

By “New Software Engineer” I mean someone who is in the first three or so years of their career as a software engineer. This doesn’t necessarily have anything to do with age but with someone new to the software industry and to the process of creating software as part of a team.

The main issue that I find that new developers need help with is communication. Here are several ways I’ve found communication to be a problem.

Diving Into Problems

One of the things I enjoy most as a software engineer is diving into the technical details of a problem to thoroughly understand it. Only then can I come up with an elegant solution to the problem. This, from the software engineers I’ve talked to, is a joy common to many folks. It, however, led me to a problem: I became myopic and only saw the code I was working on and solution I initially thought up.

This myopathy caused me to occasionally miss possible solutions to the problem because I was so focused on one path through the code. It was great having other senior engineers around me to help me see the broader picture and point out things I’d missed. I, however, didn’t get this help until I asked for it. I am working with our engineers to ask questions early and often. I am also reminding them to have several different tasks they can work on so they can keep working when they ask questions instead of disrupting another team member’s work by demanding an immediate answer.

Sidebar: Communication Resources

Effective communication is hard. Here are a couple links to read re: communication:

• The Basecamp Guide to Internal Communication
  • This guide strongly recommends asynchronous communication to avoid disruption of work which I love
• Three Important Points of Communication
  • Full disclosure: this is one of my posts. The short version is that voice communication can be used to resolve problems quickly. But use it sparingly.

Communicating Up

A problem that arose from diving into deeply technical issues is that I lost perspective on how to communicate well with folks in less technical business related roles. Luckily I had the same manager for the majority of my career and he patiently walked me through understanding the pressures faced by the business and those responsible for shepherding it. I’ve found myself now passing on the experience of putting oneself in the shoes of those running projects so that new developers can see what/how much they need to communicate and when that communication is needed.

The Experienced Software Engineer

The experienced software engineers I am working with don’t need guidance so much as they need support in making things happen. I can best serve these folks by being a gofer with any other parts of the company. This includes:

• Being an interface with management so they can focus on work
• Filtering the incoming work so they:
  • Have the info they need to complete the current task
  • Don’t get distracted by noise from management that doesn’t matter to them
• Getting tools or access as necessary to complete their work

In short I do my best to leave experienced software engineers alone so they can work their magic. And I encourage that from others in the company as well.

The Project Manager

Project management is an incredibly hard job. The folks that take on this job are the pulley that multiplies the force of the vision of management and helps engineers enact that vision in a reasonable amount of time. As a generalization this often requires a skill set that includes many people and planning abilities that software engineers stereotypically do not have but doesn’t always require a lot of software engineering skills.

My job is to be the bridge between the software engineers and the project manager. This means helping both sides walk in the other’s shoes to understand what each needs. I help the project manager understand where the software engineers are coming from so we can make them more productive on the current needs of the project. And, on the flip side, I help explain the technical reasons why we need to slow down or pivot on a particular project that the business / users may be clamoring for.

Conclusion

What I’ve talked about here are the ways that I think I can help at the beginning on this new journey. I recognize that I am new to this position and that some of what I’ve said may be too idealistic, too general, or too naive to help. It is my goal to be someone who can help our software engineering team make a great product and grow their careers. Please reach out to me with advice if you see something here that is wrong or could be better!