Over the holidays I started reading Talking with Tech Leads by Patrick Kua. Having just completed reading the novices section of the book and found it spoke to the many challenges that I faced during my first year as a Tech Lead, I though would share some of my own thoughts from my first year as a Tech Lead in the format from the book.

In The beginning of 2014 I was officially named the tech lead for ONTRAPORT’s front end team. The engineering department had grown drastically over the past few years jumping from 3 developers my self included to a dozen. At that point I had been with ONTRAPORT’s engineering team for 4 years and had the opportunity to build and touch a lot of the core features giving me in depth domain knowledge.

Does the role of Tech Lead hold any surprises?

I think that surprised me the most, is how hard it was to switch from “doer” to “multiplier”. The work / tasks I was given was more that I could do all by my self in a given day. Which forced me to learn how to be and effective delegator.

I have discovered that the role of Tech Lead is as much about the tech is its about managing people. During the large project of the year, in which I drafted most of the tech specifications. I found that I communicated the “how” well but failed to convey the “why”, thus failing to get “buy in” on the first time around when presenting the specializations to the team. I found this an interesting challenge because I didn’t think I would have to play the role of salesman.

Over the past year or so ONTRAPORT has been hiring like crazy. We’ve had a goal of doubling the engineering department in a year. Which means I’ve been giving a lot more interviews which has lead to more discussions a long the lines of; “How does this candidate fit with the team?” Or “How do their skill set fit in”. Conversations that I didn’t give much thought when I was just a developer.

The pros and cons

Having more of a say and view of the bigger picture of the product and the department has been enjoyable. I’ve been able to introduce new tools and processes that have made a difference how the workflow of the team and how the department scales as a whole. I’ve always liked teaching and or mentoring other developers, which being a lead has provided me with more time to do so.

The shift from writing code 100% of the time to 50% of the time was really hard. I had been writing code all day every day for the past seven years. I would find my self at the end of the day questioning if I had put in a full days work because I hadn’t solved as many tickets, or churned out as many lines of code. That forced me to reevaluate my daily goals. It kinda felt like trying to break a bad habit. Writing lines of code or solving issues is a bad thing, but I had to start looking at those goals through a wider lens to see how they fit into the department goals.

Any preparation advice?

Read as many books and posts on tech related topics. In the past year, I’ve found the project process articles the most interesting and applicable. This will help you gain the most perspective of all the solutions to a problem.

When you’re holding a hammer, everything looks like a nail - Lorenzo Gangi

I think this quote sums up how I felt some days. Knowing what problems exist and what tool(s) exist to solve a particular problem is half the battle.

I was lucky enough to be able to start IowaJS branch, javascript meetup, in Waterloo, IA. I ran for a little over a year with my co host. During that time I presented a handful of times on a number of front end related topics. I found this experience invaluable. It indirectly exposed me to the roles of a tech lead, leading meetings, presenting Ideas facilitating discussions.

If you don’t have the time to start up a meetup group, I would highly recommend going to a couple different ones and watching how the presenters / hosts lead discussions and answer questions. I’ve found its helped me shape my ideas on the type of Lead I wanted to me.

Has your perspective changed?

I’m not so much concerned with all of the gritty details. This goes for code and the tech specs that I write. The first couple of specs that I wrote I documented all of the method names for both public and private methods and wrote overly verbose paragraphs for each one. I realized that was wrong for two reasons. One, I was writing the code just in plain English, it was my need to “do” just manifesting in another medium. Two it wasn’t communicating effectively the goals of the new feature / project and how it fit with the existing architecture

I used to feel lots of ownership for chunks of code. if there was an issue with it I would think I would be the only one able to fix it. Now, to be successful I need to spend time training my team. Training isn’t something that would be nice to do but something that’s necessary for the success of the team and the department.