Hurdles of a team lead that writes codes

It's my first sprint as the team lead of the application team, and it isn't a smooth ride. There are a couple of hurdles that sprang right to my face, that I started writing this blog article mid-sprint.

As a background, I've been a technical lead before, but that title is a prettified title for a senior software engineer with specialized domain knowledge on some of the company's projects. I never had to lead a team, on the people side of things. My soft skills aren't great, on top of me being an introvert. This is one of the reasons why I always shy away from such opportunities before, with the other being that there was a lot to learn in software engineering that transitioning to a people-person role would mean less time to do and learn things that I love.

I took up the challenge of being a team lead as this was one of the reasons I gave my previous employer, Mike, as to why I decided to leave my previous work. I specifically told him that I wanted to work on a team again, where I can practice my soft skills, and mentor others. I wanted to challenge myself to work on something that I am not comfortable with. My mentality is "challenges is what makes life a little less boring".

Now with that said, this new challenge is an actual challenge for me. I do have to note that I'm not in a 100% management-only role. In my official letter, the expected distribution of my workload is 80% hands-on dev, while the remaining would be as a team lead. Looks easy on paper, but is hard to do in practice, well, at least in my first week in this role.

Context switching

One glaring issue I found out is context switching. On a normal day, the team and/or the higher-ups would contact me about a particular ticket or issue that isn't related to the hands-on dev work that I am currently working on. This isn't an issue when the day is just starting, but it is certainly an issue when it's mid-day and it is supposed to be my "in the zone" moment.

Coupled with the fact that I'm working from home with two kids, this is an issue that I'm struggling with figuring out how to resolve. I'm less productive when working on my programming tasks, compared to before I picked up this role.

Often, it takes quite a bit before I really get in the zone where my productivity would be at its peak. With me having to switch context whenever someone messages me about different tickets, that warm-up period resets back to zero, and it really hits my productivity.

Pair programming

A new team member just joined before my first sprint as a team lead started. I expected that the onboarding might take time and there would be a little handholding to do since he's joining a project that is already built, but only just recently started requiring design documents for large features. So, there is not much of a reference for the new member to refer to when working on the few tickets assigned to him.

I might've made a mistake in assigning some large tickets to him, with the thought that the isolated features would be easier to work with rather than tickets that would require him to modify existing tightly coupled code.

This resulted in frequent calls (we're all WFH due to the pandemic), and screen sharing sessions. This obviously meant that I had to set aside what I'm currently working on to help the member to deliver the ticket.

Another mistake on my part is that I assigned him a ticket that has a sort-of-fixed deadline. In hindsight, I should've assigned tickets that aren't expected to be delivered in a week or two.

Pair programming worked well in the sense that we were able to roll out the changes quicker than it would have been, but that meant that I had to sacrifice my own tasks.

Hopefully, moving forward, these pair programming sessions would be less frequent, or I should factor this in when planning for the next sprint.

Communicating priorities

I had a tough time balancing being bossy or a pressure cooker (ie. pressuring the members to deliver a specific ticket ASAP) and communicating the urgency of a particular ticket.

I'm not yet sure as to how to resolve this, and I might need to check out some management books to get this right.

As a developer, I do get irked when my team lead pressures me to deliver a task, especially if the tasks were change requests that weren't documented in the original ticket.

Most of the time when upper management asks me about ETAs, it is usually for change requests for a ticket that has been deployed to staging/QA, and the feedback is from the QA phase. The root cause of why there were a couple of change requests stems from insufficient requirement analysis when fleshing out the ticket, which is the next issue on my list.

Insufficient analysis

On my first sprint as a team lead, I had to join the sprint planning without much preparation for the tickets. The estimation and discussions about each ticket were done at the same time, during the sprint planning session on a weekend.

What this meant was that it was unavoidable for some tickets to have details that aren't fleshed out. In fact, there was a ticket assigned to an engineer that referred me to this company (ie. an engineer that is much more senior than me) that had a lot of missing details. If there was sufficient time for the analysis of the requirements, it would've been possible for us to detect those missing details and clarifications before development.

Granted, it isn't uncommon in software engineering that there are some details unearthed while working on a task that would need clarification during the development phase, but this could've been kept to a minimum if the ticket were fleshed out properly before the sprint started.

Assigning tickets that overlap across different members

I assigned some tickets that modified the same piece of code between two members, and this caused one ticket to block the other ticket, putting unnecessary pressure on the member that was first to work on the ticket.

Moving forward, I would need to identify such tickets that would modify the same part of the code and assign them to a single person.

Conclusion

Overall, the management aspect of my work certainly impacted my responsibilities as a hands-on engineer. As I had to juggle between remedying the mishaps that I made during planning and writing code for my own tickets, it caused my day job to be a little more stressful than I anticipated. Not to mention when upper management starts asking about ETAs, and I couldn't get a proper ETA from the member that was assigned to the ticket. What was worse was when I couldn't contact some members for some time, probably since they were out for dinner, and upper management is there waiting for an answer.

I'll have to formulate some action plans for our first retrospective to try to alleviate the problems I encountered during this first sprint.