6 Things I’ve Learned from My First 6 Months of being a Lead Engineer

At the beginning of 2021, the digital product studio I work for offered me the opportunity to be Lead Engineer on a new social media project we won. Here’s some of my takeaways from the experience!

1. Take the time in the beginning of the project define good practices to focus on and teach others. There are 2 concepts at work here — deciding on good practices and teaching. One thing I really appreciated in our project was the collaborative start we had. We made big-picture decisions and stuck to them throughout the project, keeping each other accountable in our PR’s. This gave us a strong start and consistently high quality code. The other thing at play here is teaching others. One thing I always took for granted in my career was the opportunity to teach others — as an engineer I felt like it took time away from coding and I honestly never gave it much thought. But man, is teaching under-rated! Walking through code with other engineers forced me not only to know the material really well, but also made me question the validity of everything I claimed and solidified concepts more clearly in my mind.
2. Make a plan for how to manage your team’s resources. This is so much easier said than done, right?! But it’s all a learning curve! You have to be in touch with the strengths and weaknesses of everyone on your team but also be aware of the things they want to learn and improve on. If you have time, assign a small data-modelling task to the engineer with less experience but brimming enthusiasm! As long as you’re balancing time and expectations, there’s no reason not to consider other peoples’ aspirations! On the other hand, if time is of the essence and you’ve got an experienced team member that can crank out that feature with little-to-no bugs, there’s no better time to assign that task to them.
3. Remember to take advantage of your team members so you can focus on the bigger picture. Working as a heads-down engineer for almost 3 years, I’ve gotten in the habit of judging my success by the code/features I churn out. But when it comes to being the lead, the project’s successes and failures fall on your shoulders so focusing too closely on bug fixes or a single feature’s improvements instead of the big picture can ultimately lead to your downfall. During times when your product is under QA or will be handed over to the client soon, make sure you are paying attention to vulnerabilities in the project, TODO’s that were never accomplished, or third party dependencies/limits that may blow up in your face.
4. Plan meetings before they happen! This sounds so obvious right? Maybe it’s just me but since all of our team members are so autonomous and amazing workers, I didn’t think to write up an actual agenda for my first couple of weekly check-ins! The meetings started and ended awkwardly and it felt like there was no structure or leadership at all! Man did I FAIL at that! Once that discomfort settled in, I realized the issue was me. I started planning agendas and calling on people to raise points and concerns. Not only did our meetings become less awkward and more structured, but they became quicker and more efficient!
5. Check in consistently with your engineering manager. Talk about the challenges you’re having! Chances are, you’re not the first person to experience them and if your manager hasn’t already gone through it, they still may know a couple of good solutions. The only thing that kept me going through this project was the bi-weekly one-on-ones I had with our Tech Lead. He always had invaluable advice that saved my @$$ multiple times, relating both to technical challenges as well as non-technical ones.
6. Always take note of challenges and failures you experience for the next project/opportunity— every company and person can improve. If you have the awareness to identify areas where you can help the company streamline processes or avoid the same mistakes, take note of them and constantly be thinking of them. The best way to add value to your career and your company is to simply be aware of what is going on and think of ways to improve it. If you always build the same flow for every project, suggest a way to extract it out into an internal library for re-use later. If you notice a project reaching dangerous heights toward an api limit, suggest caching results or upgrading your third party account. Long story short: there’s always room for improvement.