Tech Lead - Lessons Learned in First 60 Days

I was given my first project two months ago. Five developers, myself, and a support staff of three QA. We're building an MVC app from the ground up. It's exciting and scary all at the same time. Here are a few things I've learned so far.

First, one-on-ones really do make a difference. I spend every Wednesday morning from 8:30-11 doing one-on-ones with all five of the developers on my team. If you aren't familiar with the concept, start with this podcast. I know each of those guys much better as a result of the time spent together. We talk about each of their user stories and how it's coming along. But I also find out that Matt is buying a car and a house this week, Maina is taking the review boards on Friday, Jacob's girlfriend is coming in town this weekend, Tomin is looking to travel to India in June, and Victor's in-laws are in town helping him remodel his house. As a result of those conversations, I'm actually getting to know my team.

Second, as with every position I've held, the difference between doing good and doing great is fine tuning the processes I use. I've learned how I like to track and view team status, that a brief fireside chat in the morning helps get us all on the same page, that code review once a week doesn't cut it, and that I need to have flags go off in my head when a dev doesn't schedule a design session with me.

Third, being tech lead is less about always having the right answer and more about empowering those around me. If you want to read a great article/video on this, check out my buddy Robert's post. We're a small team but I've set up positions within that. I have a senior developer who I've made my lead on all things UI/UX. He decides where we keep our css and js in our solution, how we structure those files, and recommended we use Less as a pre-processor. I have another senior developer I've given charge of all things integration. There are several other apps we're integrating with and he's handling all those contact points. With those two guys leading the way, I can put in place informal mentoring where they code review with the junior developers every day. Think about all the decisions I don't have to make now; there's no way I could be doing all that on my own! This frees me up to keep my eye where it should be: on the big picture.

Fourth, mistakes are going to happen. It's a new position for me and I'm still ironing out some of the kinks. The best way I've found to limit the backlash is to go with my heart in my hands, admitting that I missed something and here is a suggestion on how to mitigate the consequences. Honesty plus a solution is always the best policy.

Fifth, people will assume they need you in every meeting. I had a one-on-one with one of my guys the other day and he commented that it seems like I'm not around much anymore. I pulled up my calendar and showed him the harsh reality: before being tech-lead, I had one to two meetings a day; after becoming tech-lead, I have three to seven meetings a day. The worst part is, the meetings that usually fall by the wayside are the most important ones: the design meetings with my devs. They get tired of waiting and go ahead and start coding. I don't have a magic bullet for this suffice to say I need to start protecting my schedule more.

Sixth, technical debt happens fast. You unleash a team of five devs and, without the correct processes in place, things can get sloppy fast. A commitment to diligence is key. We started with formal, team-wide code review every Thursday for an hour and informal, buddy code review every Tuesday for an hour. We soon found ourselves using that hour on Tuesday for formal code review just so we could get through everyone's stuff. The next revelation was that doing so every couple days wasn't often enough. Too many things were needing to get refactored but the user story was supposed to already be done. We now buddy code review on Monday, Wednesday, and Friday and team-wide code review on Tuesday and Thursday. This should help shorten our feedback loops and get a second pair of eyes on everything we write.

Seventh, know when to step in and when to let them struggle a bit more. One of the biggest benefits I can give my team is to help unblock them if something is in their way. One of the biggest disservices I can give my team is to rob them of the experience of solving their own problems. There will always be tension between these two forces. If it's an issue that's blocking a single developer, I'll let him spin on it for an hour or two to see if he can find his way out. If it's blocking the entire team, I'm more likely to jump in, figure out a temporary measure to unblock them, then go off by myself and solve the root issue. The goal is both productivity and developer growth.

So far it's been a great experience. Looking forward to learning more in this challenging new role.

portrait title

About Scott

I am a software engineer from Bozeman, MT enjoying the slightly warmer climate of Colorado. I think code can change lives. I think lives are worth changing. I write code.

You can find me on Twitter, LinkedIn, , and Github.