Firsthand Experience Leading an Engineering Team 1Featured
Having graduated with an undergraduate degree in math, I would have been surprised - to say the least - if someone were to tell me back then that I would one day be leading an Android engineering team. My first programming class wasn't until my first year of university, and I don't even use an Android phone as my primary mobile device. Needless to say, I've learned a lot since attending school, both on the technical side as well as the leadership side, which was mostly earned through academic, work, and especially volunteer opportunities.First and foremost, engineers are not all alike. When they (we) join a company and a team, they come with their own sets of skills and experiences, built up over the years from their past roles, education, interactions with others, and much more. As such, their present motivations would vary, as well as their future short-term and long-term goals. Therefore, the approach to take in order to lead these individuals successfully may differ.I am still relatively new to the role of engineering lead, "officially", but here are some lessons I have picked up along the way so far. I am also continuing to learn from my own experiences on how to become a better leader.One-on-one MeetingsI currently have weekly one-on-ones with my teammates. As much as possible, we try to keep these scheduled meetings as a way to stay connected during the work week. Some days, the meetings are as short as five minutes, while other days they can be as long as 45 minutes!. And some days, it doesn't feel like we discussed anything of substance at all - and that's okay. Regardless of how the meeting ends up progressing, I try to make it clear beforehand that I have a loose agenda in mind, but my own agenda would be secondary to anything that the engineer wants to discuss first. With my own manager, these meetings are bi-weekly instead; this cadence seems to work well since it gives me the opportunity to escalate team concerns as needed.If the teammate doesn't already have an agenda in mind, I typically like to use these meetings more as an opportunity to get a pulse of the team - how they're feeling (especially given the current situation in California with shelter-in-place), what challenges they're facing, and generally how I can help better support them - and less as time to talk about features or projects that they're currently working on. I also find it useful to periodically use these meetings to set goals (both short-term and long-term ambitions) and check in on the progress of these goals. For a more junior-inclined engineer who may be stuck when setting their own goals, I try to reword or redirect the request to make it sound less final and instead provide some direction, and/or draw on my own experiences and knowledge of the industry to help. For a more senior engineer (more senior than I am), I may realize that their experiences and knowledge surpass my own in some respects, but also recognize that I can still provide help and value with my diverse viewpoint.Accepting HelpIt's okay to accept help. This is an age-old lesson that I'm sure many of us have heard before. As a way to help protect the team from overwork or burnout, I found in my personal experience (and from observing other leaders and managers) that I tended to take on more work than I had to, sometimes leading to ineffective multitasking practices or overcommitment of time or deliverables. This may be fine in the short-term, but it builds up very easily and quickly in an undesirable way. So I'll say it again - it's okay to accept help. It may be for help needed on a feature or project, perspective on resolving conflicts between colleagues or clients, advice on just stopping or slowing down work altogether to reset and take some time for self-care, etc. As a follow-up, it may provide personal value to assess the situation afterwards. Was the help needed due to a lack of time management to meet the deadline or to gain insight from a new perspective? Was the help needed due to lack of specific knowledge or experience or to provide a coaching and mentorship opportunity for another engineer? It's important to view both negative and positive lessons from this to adopt good practices in the future.There is so much more I could write on the topic of firsthand experience leading an engineering team, but these two sections have been on the forefront of my mind lately to address the needs of engineers (on the same team or not) of different levels and experience. Regardless of their level, however, it comes down to what I am able to share and teach them as well as gain and learn from them in turn. ResourcesHoffman, Reid. The Start-up of You: Adapt to the Future, Invest in Yourself, and Transform Your CareerLarson, Will. An Elegant Puzzle: Systems of Engineering ManagementScott, Kim. Radical Candor: Be a Kickass Boss Without Losing Your HumanityBianca works as an Android/iOS Engineer and Fleet Android Lead at Postmates in San Francisco. Although she is currently located in the Bay Area, she is originally from Canada and earned her B.Math and M.Eng. degrees there, with a focus on business systems management and code generation research respectively. Outside of work, Bianca is an active member of the tech community and particularly enjoys working with and mentoring students, early-career professionals, and people newer to the tech space. She is also a certified yoga and lyra instructor and circus enthusiast, so you can almost always find her at the studio.