Six months in

Introduction

Stepping into the role of a software technical lead is both exciting and challenging. It’s a journey of balancing technical expertise with leadership, guiding teams toward success while learning to grow alongside them. As someone new to this role, I’m diving into uncharted waters and discovering what it truly means to lead effectively. In this blog, I’ll share insights, lessons learned, and the occasional misstep as I navigate this transition. Whether you are a fellow tech lead, an aspiring one, or simply curious, I hope these reflections resonate and provide value.

Disclaimer*

At the start of this blog, I am already six months in to the role. At some point, I will circle back and do a post on my first six months in the role, but for now, my posts will focus what I am facing currently. Also, I will not share any of my project details. I believe a can explain my journey without that information.

Brief History and Current Status

Six months ago, I was brought on as a technical lead for a modernization project. Modernization is typically where you take an old product and redo it with newer technology. With my current company, I had been a full-stack developer for three and half years and worked on a couple of different teams, primarily on a Angular/Spring Boot/AWS stack. I told my boss that one of my goals was to be a tech lead. Within a couple of months, I was moved into the position. (I definitely thought it would take longer)

At the beginning, there was little guidance or expectations given for what success looked like. I guess I probably should have asked more questions, but nevertheless I pushed forward. Coming from a previously failed entrepreneur venture, I knew how to be a self-starter and forge my own path.

For more context, the older product or “legacy application” is built using Visual Basic .NET; I am converting this to a web application in Angular, but it has huge backend (which is handled by a different team). Early on, I spent a lot of time learning the front end, since that was my product. Recently though, I’ve made more an effort to learn more of the backend data. After driving many meetings with stakeholders, minimum viable product(MVP) planning, solo development, onboarding new team members, and extensive solutioning, my product is now close to the first production release.

First Major Roadblock

Now, those of us in the technology space know [very well] that there is almost never a smooth path to production. Around Thanksgiving, I got hit with some news about a planned upgrade from Windows 10 to Windows 11. After some testing on a provisioned Windows 11 machine, it was discovered that this update would break two major features in the legacy application. On top of that, the VB.NET developer, who was on the team when I joined, was rolling off the project in about a week and nobody on the team had VB.NET experience. The good thing was that the update was not schedule to happen for another seven months.

I was hoping I could quickly focus on getting the first production release for the modernized version out and then pivot to solving the legacy issue. However, this issue had too much attention on it, and instead I had to pivot earlier to help provide level of effort (LOE) estimations and timelines. For me, it was the first time I had to make a shift like that. Up to this point, others projects I worked on were strictly focused on building the newer product. But in this position, I have to balance two products now, especially since the .NET developer left the project.

What frustrates me is how slow I was to make the pivot. I should have shifted the focus to the legacy code a “sprint” earlier and gave everyone the peace of mind they were looking for. Nevertheless, the priority has completely shifted to fixing this legacy issue. What do I do about production?

More to come…