Two Years Later: Learnings as an Engineering Manager and Lead
It’s a good idea to check in with yourself every so often regarding what you’ve learned, what your goals are, what you wish you’ve done better, etc. And indeed, when I browse through posts on Medium and other platforms, looking at what other managers are posting, they often post similar retrospectives. The cadence seems to vary between every three to six months, perhaps yearly. Given this, it seems my own check-in is long overdue.
Engineering Manager and Lead Engineer are usually different positions with different responsibilities on a team. Due to the size of my team, I often need to fulfill both roles. It’s been lots of work but it gives me ample opportunity to both zero in on key features and bugs but also zoom out to think about our products as a whole, how they fit into our company’s ecosystem, and also look at processes and how to best support my team.
Occupying both roles over the past two years, I’ve learned a lot. Here are some things that I’d to share.
Learn to let go
Some other terms for this can be“trust your team”, “avoid micromanagement”, or as Molly Graham puts it, “give away your Legos”. This was probably the single most important thing I’ve learned, and is something I need to remind myself of occasionally.
As a new lead or manager, one of your first reactions is likely something like this:
“Wow, I’m finally in charge! Time to make everyone do things my way, the right way!”
You’ve spent years begrudgingly participating in redundant ceremonies and meetings, writing in your own descriptions in your Jira tickets, silently changing your coworker’s code to match your coding style, repeatedly attempting to convince your supervisor to let you do two-week sprints instead of three. Now that you’ve been promoted, you can change it all, and make everyone come along for the ride.
I fell into this trap. I’ve been an engineer at my current company for six years now, nearly seven, and when I was promoted to lead, I brought the hammer down. I knew exactly how things needed to be run, and now it was time to make things better. Except it didn’t really work. When others from the team expressed their concern with a way of doing things, I would reassure them it was the right way, but they would often continue to push back (vocally and silently). And practices naturally evolved away from how I’d originally pitched them into something that worked better for the team. That should have been my first clue, but I ignored it.
So I pushed back harder. And when I couldn’t get my way, I just did the work myself. As Zorg in The Fifth Element puts it, “if you want something done right, you gotta do it yourself”. This was my mantra for a long while, and while it indeed yielded the results I wanted, the consequences were horrible. I was overworked, stressed out, anxious and depressed. I felt like my team was out to get me. Workdays were battles.
Eventually, the Kingdom of Robert fell, and I needed a new plan. During a brief vacation, and after seeking out help for my deteriorating mental health, I was able to take a step back and look at my attitude and relationship with my coworkers and my work.
I needed to let go. I needed to trust my team, stop micromanaging them. I needed to share my Legos.
This is easier said than done, and there’s a reason why it’s such a common trap for new managers and leads. You’ve spent years doing the work, so you must know how it needs to get done. This is true to an extent. No one knows the work and how it needs to get done better than the ones doing it. But others are also doing the work alongside you. How do they think it needs to get done? What do they need to feel supported and empowered to do their best work? These are super important questions to ask yourself, and in order to get the right answers, you need to talk to your team.
Instead of mandating programming expertise, I started sharing it via pair programming and “dev syncs” every other week. These were chances for me to both share knowledge with my other developer and allow them to ask me questions.
During code reviews, I stopped nitpicking on spacing, indents, and convention. I limited my criteria for changes needed to only glaring bugs. If something could be optimized, I suggested an alternate approach and mentioned potential consequences/bottlenecks but ultimately left it up to them on whether they wanted to fix it or leave it to be addressed later.
I started giving my other developer more responsibility and more agency. I made them lead of one of our projects. I put them in charge of entire features instead of just one-off tasks. I began inviting them to project meetings and allowing them to answer questions directly about their work. I fostered an initiative-driven environment where they felt comfortable and empowered to deploy hotfixes (and in turn suffer the potential consequences if it broke something), write their own tickets in Jira (to record tech debt or propose new features), and collaborate with others across teams.
The launch of our latest product would not have been possible if I had not learned to let go and trust my team. And I’m proud to say that when I came back from a two week vacation recently, they handled things swimmingly while I was gone and performed beyond expectations.
Don’t forget your humanity
There’s probably a better way to phrase this, but it’s about remembering that at the end of the day, when we put aside the work, we are all human. We have families and personal lives beyond work, we have goals and dreams, and we deserve to be treated with respect and kindness. We experience emotion, and our mental health affects the quality of our work.
This is, of course, obvious, but it’s something we sometimes forget when we’re planning big projects, tackling large goals. When you’re staring at project timelines and drawing up budgets, employees can become assets and resources. They are means of checking off boxes on your quarterly or yearly reports. They are traded like baseball cards when one team needs XYZ competency while another needs ABC.
I’m getting a bit dark here but this is sometimes the case. I think this is especially important to talk about given the ongoing pandemic. Now that we only interact with each other textually or over Zoom, we can fall into this trap more easily than before.
Psychological safety is important for a team. I try hard to promote psychological safety within my team as well as pay attention to my team’s emotional and mental well-being at work. If they stayed quiet during a meeting or seemed distraught after a decision was made, I follow up with them privately to get their thoughts and feedback, and if something needs to be discussed as a team or escalated, I do so. I also follow the “praise in public, critique in private” mantra here. I offer praise amongst my team but more importantly I call out their outstanding work in company-wide and cross-team settings. And when performance-related feedback needs to be given, I speak privately with that team member, framing the conversation as a collaboration on a proposed solution instead of a “talking to”.
It’s also important that I myself am not immune to feedback from others. I encourage my other developer to “manage up”, to give me feedback and ask things of me. In team forums such as stand-ups or retrospectives, I make sure to admit my mistakes and be vulnerable.
I like to talk about non-work topics with my team too, like hobbies or interests or what they did over the weekend (of course, to the extent they are comfortable with). This is a way to form connections and strengthen bonds with your team (and coworkers in general) and keep humanity present in everyone’s minds as we do the work. Other things I do include fun or thought-provoking check-in questions before meetings, Lunch and Learns (opportunities for the team to teach each other new things), and happy hours. Different things will work for different teams, but I find that setting aside time to bond and form connections helps increase morale and team effectiveness.
Be healthy
The last learning I’ll mention is an obvious one so I’ll keep it short, but it’s one I continue to work on daily. Getting enough sleep, eating well, drinking lots of water, exercising, meditating, taking vacations… all these things go a long way in boosting your work performance. Physical and mental health play a huge role in how well you can do your work.
A recent change idea I’ve implemented is taking work apps off of my phone. A friend reminded me that “our work is not open-heart surgery”. Most of my work is incremental and subject to change if needed. And it’s definitely not needed ASAP. When work hours are up, I unplug from work. My emails and Teams messages can wait until tomorrow. The time after work is needed for me to recharge, and filling it with more emails prevents this from happening. I encourage my team to do the same, and if I find someone is working late often, I check in with them to make sure their workload is a comfortable size. Sometimes it is not, in which case I will alter the scope or remove some of their workload in some way. Sometimes they are just passionate about the work and are choosing to work late. In either case, I make it known that I do not expect them to work beyond work hours (we currently do not have an on-call rotation so there is no need for someone to be online).
The same goes with vacations as well. Keeping your recharge time for recharging is vital for good mental health. It also helps clear your mind and let you take a step back from the work to look at things objectively (or at least to be more objective). You may notice a process that isn’t working the way it should, or a blocker preventing you from doing some line of work, that would have been difficult to notice before.
And don’t forget to take vacations! I am trying to aim for one vacation per quarter, even if it’s a short four day trip.
That’s all for now. I’d like to check in with myself in another six months, or perhaps in my next role. “Always be learning” is another mantra I take to heart, and I’m always learning new things from myself and my team.
