Three and a half years into my engineering career, I found myself as the most senior engineer on my team. Of the 5 non-manager engineers on my team, I had the most years under my belt. When I first realized this, I was nervous, intimidated, and more than a little scared that I wouldn’t become a better engineer without a more senior peer pushing me to be better every day like they had in the past. Over the course of the following year, I learned how to be a good leader to my peers and still find ways to accelerate my own technical growth.

Acknowledge your role

The first and biggest change for me was realizing that I had become not only a technical lead on the team, but also a morale leader. When I was on a team of people that all had the same or more experience than I did, I could vent about problems without swaying them. But when I vented to people that looked to me for leadership, I noticed that they became frustrated by things that I was frustrated by -- even if they weren’t before I said anything. If I thought leadership was making a great decision, so did the engineers on my team! But if I thought leadership was making a decision I didn’t agree with, so did the rest of my team. I was still the same person talking to the same people, but becoming a leader caused my words and feelings to carry more sway. While I still brought my whole, authentic self to work and shared my opinions, I became more mindful and tactful about when I expressed them. I encouraged my more junior peers to share their perspectives before I shared my own, and I saved my less-productive frustrations for my manager and mentors on other teams.

Find a mentor

Gusto has a formal mentorship program, so I signed up and got matched with a more senior engineer on another team. They helped me think about new technical patterns to try and how best to coach the junior engineers on my team. They also let me share opinions about things without consequence, which is always helpful. I reached out to more senior engineers I had worked with in the past and asked to meet, and sometimes set up recurring monthly 1:1s. I did this with both engineers still at Gusto but on new teams, as well as engineers that had moved on to new companies. I found these conversations most useful when I went into them with an idea of what I wanted to get out of them, like career coaching, goal-setting, or technical ideas.

Source new technical patterns

Without a senior engineer always giving you new ideas and design patterns to implement, you’ll have to find new sources. Books and conference talk videos are both great options, though I personally struggled to carve out the time to really engage with the content regularly. Conversations with my mentors helped a lot, and they were often able to connect me with other engineers that had ideas to discuss too. At Gusto, we have “guilds” -- groups of people that meet on a regular basis to talk about performance, testing, architecture, frontend best practices, and more. These guild meetings were a great way to find what technical patterns other people were interacting with.

Push for your team’s technical growth

Remember the senior engineers that you used to work with, and how they were always suggesting new design patterns and advocating for tech debt cleanup? Well, that’s your job now! Even if the design patterns aren’t originally your idea -- maybe you sourced them from a book, mentor, or guild meetup -- they may be new to your team and require a champion to push forward. At first, I felt like I didn’t know what I was doing. I was way too junior to know which patterns were good! But I pushed to try out new patterns and ideas as experiments, so that the team and I could learn from the experience and decide if we wanted to incorporate them into future projects or not. This way, I still got to learn new things hands-on, and I dragged my team along with me for the journey.

It can seem intimidating to ask for the team to try these patterns out, but I was surprised by how supportive my manager was whenever I asked for more time to try out new things. It turns out that they wanted the team to grow technically as much as I did! I also made sure to review every tech spec that my team wrote and suggest patterns and tech debt opportunities as early in the planning process as possible. No technical planning document got past a review with me without a “how we’re going to improve the codebase” section -- even if I had to pair with the engineer leading the project to help them write it.

Ask for feedback

I met with every one of the engineers on my team on a regular basis, either for a pairing session or just short 1:1. I did my best to ask for informal feedback at least once a month. Most of the time, the feedback was pretty generic, like “you’re really helpful!” In those cases, I tried to prompt for something constructive. I asked questions like, “What about my code reviews are helpful or unhelpful for you? Am I giving the right amount of direction when we pair? Do you think we meet too frequently or not enough?”

I once got some really incredible feedback from an engineer on my team when I asked. Because I was also the most tenured engineer on the team, I knew a lot more than anyone else about how the obscure parts of our code worked. I thought this was fine, because I really liked pairing and talking through all the problems when they came up. However, my teammate told me that even though they liked pairing with me, they didn’t like that they were always forced to, and they wanted more documentation so that they could sometimes figure these problems out for themselves. Because of that feedback, I helped write so much documentation that a few months later, engineers on our team went from having to ask for help on almost every single on-call ticket to only needing help on about 10% of them.

Biggest learning

My single biggest learning was that as a team’s senior engineer, both the team manager and your peers will be looking to you for technical leadership by default. I figured this out eventually, but in retrospect I wish I had done more sooner to help the team grow. Instead of asking for permission to do more technical excellence work (like trying out new patterns or cleaning up tech debt), I eventually just started putting tickets in our sprint and adding additional effort to the technical plan for each project. I know it can be intimidating at first, but the whole team really grows when you just try stuff -- even if (especially if) it doesn’t end up working out.