Perhaps you were hired into the role — or you were already on the project and the role opened up — or you were promoted and assigned to the project. However you got the job, you’re now in charge of the technical direction for a project. And in fact, this is the first time in your career that you’re heading up a project. Now what?
Take a deep breath, and dispel the self-doubt!
You’ve been a developer for several years now, which means, you’ve seen some crap. Over the years, you’ve experienced effective and bumbling managers, seen indecipherable code — often written by yourself, been a victim of rocky project management, and you’ve occasionally even pulled off projects and made clients happy. So are you ready for your new role?
Take a deep breath. Someone in your company has seen the above and has given you a vote of confidence. Barring the most Dilberty organizations, your managers feel you have the skills to pull this project off. So let’s take a quick run-through of what you should and shouldn’t do!
What you’re NOT expected to know/do
Let’s start with the inverse. You are…
1. …not expected to know everything
After ramping up on your project, you will hopefully have a decent understanding of the project. However, when someone inevitably asks you a question that you don’t have the answer to, be honest — it’s far better than making up some fact or rashly promising a deadline. Let the asker know that you will find out the answer and when you find out, follow up.
2. …not expected to do everything
You are one of the stronger coders in your organization. When others come to you for help, definitely provide advice — help them talk it out (i.e. rubber ducking), point them to the right resources, etc. — but resist the urge to code for them. Similarly, when the project is in some trouble, don’t be a “hero” — don’t be the guy staying until 11pm to rush a feature through. There are better and other ways for you to help…
What you will need to do…
1. …Communicate, Communicate, Communicate
In any organization of a sufficient size, meetings are a necessary evil. You will be meeting with your client, management, and your own team to coordinate work. If you haven’t done so, learn to speak tech with business people — a good tech lead knows how to describe your project tasks to a non-technical audience without “dumbing it down” and losing important details.
Remember — you’re doing all this so your team can work effectively. They don’t want to be sitting in meetings all day, nor do they want to be working on the wrong feature because they weren’t sitting in that meeting. You’re the person who translates all those requirements into tasks and shields your team from changing requirements and stakeholder inquiries.
2. …Know the Timing
You will need to stay aware of overall project timelines. Beware of risky or time- consuming feature sets scheduled for the last week of a project. Push project management to schedule a QA/release week so your team has time to fix high priority bugs. This will help you decide if your project is on schedule.
During development sprints, be aware of your team’s progress through the tasks. Be aware of features that take longer than expected to develop; be prepared to demand time-boxing on that work.
3. …Know Your Team’s Strengths
You’ll most likely be involved with assigning tasks to your team. Therefore, you will need to familiarize yourself with your team and their skill sets. As an example, on an Android team, you might have a programmer skilled in video rendering, another in automated testing, a third in user interface (UI) flows… Knowing this information will allow you to assign tasks to the best team member. If your team has opportunities to pair program, you can help match team members for effective knowledge transfer.
4. …Learn from other Tech Leads
Talking to your new peers is one of the best ways to learn about your new role and responsibilities. Get their tips and tricks. Take the time to learn what they think of the company’s expectations of tech leaders, and what sort of project management processes are in place.
5. …Be Transparent
Even on the smoothest projects with the least demanding clients, things will inevitably go wrong. Perhaps a feature was under-scoped, or your client is slow to respond to your requests for feedback. When snafus happen, be open and transparent with your organization. The more accurately you report your project status to your higher-ups, the better they can allocate extra resources for you to pull the team through.
Similarly, be an advocate for your team members. Encourage speaking up when small issues pop-up so they can be quickly addressed. You are your team’s bridge to clients and management, take advantage of these relationships to resolve issues.
6. …Be a Role Model
As the representative of your project, you’re not just accountable for the code you write, but your team will also look to you to set the tone in terms of culture and work ethic. If your team has required core hours or mandatory meeting attendance, apply them consistently across the team and to yourself. When you hold yourself to these same standards, you will inspire confidence in your team.
Demonstrate positivity in your reactions to any project and/or company issues. Nothing tanks a team’s morale faster than a leader who doesn’t believe in the mission, or who takes opportunities to disparage others. By showing a realistic, optimistic energy level in the face of project challenges, your team will know they have a leader determined to deliver.
Of course, every organization will have different expectations of a tech lead’s roles and responsibilities. Many may not even have a clear idea of what the role entails! I believe that your top task is to identify and manage expectations. Talk to your client, set expectations for your delivery and feedback processes. Talk to your manager and define their expectations for project reporting.
Most of all, talk to your team members, find out what their expectations are. For example, as an individual contributor, I relied on my team lead to field questions from management and clients, and I didn’t over-promise features or timelines. So, let your contributors know your expectations for the project’s architecture, version control, delivery process (CI/CD), etc.
When you listen to what support other people need and enable them to receive it, you’re well on your way to becoming a great tech lead!
Alvin Fong is an Agile Software Engineer at TribalScale. He develops apps on Android and FireTV platforms, and is changing his mindset every day to better accommodate TDD. His current interests include learning Kotlin testing and architecture patterns, applying them to projects as appropriate.