Photo by Christina @ Unsplash

Congratulations, you have proven yourself capable and have been given the responsibility of providing technical oversight for a group of developers. So what do you need to do to make sure you fulfill expectations?

To begin, “tech lead” can have different meanings depending on the company you work for. Start by having a discussion with your boss so that you fully understand expectations.

Next understand that in this role you are responsible for the technical side of the implementation. This includes decision making, quality, translation, and communication.

As a technical lead, here are some tactics you can utilize to ensure that you will deliver on expectations.

  1. Create a collaborative but guided processes to make design decisions.
    In my experience it’s good to bring a basic design to the table and allow the team to iterate. Understand that 100% consensus is not necessary but your goal is to produce a design that everyone can understand and has been vetted by a group of experts.

    Whiteboarding sessions are particularly helpful for this and investment in a few hours of collaborative design will generally pay off. Keep in mind it is your job to facilitate the conversation and keep it productive. Don’t take sides if argument occurs but rather ensure that the pros and cons of each design decision are made visible. In the end if the group is unable to come to a conclusion it is your job to make the decision.

  2. Take responsibility to add technical documentation.
    Depending on how your team chooses to perform documentation, take it upon yourself to put that work in. Given that you should have visibility into all development tasks you are best suited to produce both context and details on different aspects of the build. This also means you should consider taking responsibility for providing technical specifications within user stories if that is how your team operates.

  3. Make time for questions – encourage questions.
    Your primary function is to to provide clarity to those around you. That is the key to any type of leadership role. If someone has a question it is critical that you make time (if not immediately). You should also find ways to determine if someone is stuck and seek them out to assist. This can be done through casual conversation – make sure it doesn’t come off like they are a problem, try to serve as a sounding board for them to work through any issues they might have.

  4. Assess risks that may impact deadlines or business risks.
    Your responsibility to those above you or those managing a project is to provide regular and clear updates on technical progress and impediments. Also when possible you should be communicating gaps in requirements or other considerations uncovered in technical design and implementation. Consider yourself a translator – taking technical jargon and turning it into something meaningful to stakeholders.

  5. Identify technical roadblocks and focus on helping solve them.
    Attack problems with zeal! They are the enemy of delivering on time and can destroy team morale. Take it upon yourself to understand the problem and find a solution. Certainly easier said than done and to be honest, this is probably the largest challenge with the role. Utilize a pro/con approach to evaluating solutions and be willing to make the hard decisions.

  6. Concern yourself with quality.
    Be proactive on evaluating code quality and adherence to acceptance criteria. Trust your team but also verify that nothing has been missed. If something has slipped through the cracks work with the team in a positive way to address it and be cautious about singling any one person out in a group setting. Your job isn’t necessarily to correct behavior (unless you are also in a management role) but your focus should be helping the team get to the finish line.

For those first starting out as technical lead here are a few recommendations on things you shouldn’t to do.


1. Don’t design everything without some level of team buy-in.
The worst thing you can do is bring a fully baked design to the team and attempt to make converts. They will reject it or at minimum, they will not understand your vision enough to properly implement. In the end you will be frustrated. If you feel you have the right approach, bring the core and let them iterate on it. Or in other words, design the first 25% and let them work out with you the last 75%. You may find yourself surprised at the outcome.


2. Don’t code all the hard stuff yourself.
Ok, you probably have to code some of the hard stuff yourself. You are likely in this role because you have extensive domain knowledge or experience. But you will find quickly that you can’t be a good leader and a rockstar developer at the same time. Learn to delegate – find other developers on your team that you trust and offload some of the challenging pieces to them. The payoff is you will not find yourself coding until 3AM to hit a deadline while everyone else is sleeping.


3. Don’t refactor someone’s work without first having a conversation.
While it’s sometimes necessary to correct a problematic implementation – be cautious about replacing another developer’s work. First try to understand why they made those decisions. It may feel unnecessary or unproductive but you will likely damage your relationship with that developer if you don’t tread carefully. You may also jeopardize your deliverables if you take it upon yourself to do it all. A good approach to take is to work with the original author(s) and identify the problems created by the design and try to do the refactor together.