Becoming a Technical Lead: Working on Your Leadership Skills

Leadership, particularly but not exclusively technical leadership, becomes the key component of every business structure in the current digital environment. Possessing the definitional understanding of leadership, however, will only get you so far. The harder questions to answer are whether you understand the implications and limitations of a role and a deeper perspective of an impact the role can have on the business development and the relationship between the members of your team.

In this piece, we’ll attempt to define technical leadership, describe the responsibilities of a tech lead, skills you should work on to become a lead developer, and finally, how exactly you should develop your leadership skills to advance in your career.

What is technical leadership?

Technical leadership, like any other type or form of leadership, infers the ability of an individual or a team to lead other individuals or teams in the field of software engineering, web development, and IT (since it’s the technical leadership we’re talking).

Who is a technical leader?

Chances are, you’ve been working as a software developer for a while and have been exposed to some sort of technical leadership; moreover, you might have even led a team ‘de facto’ without anyone assigning a new role to you or paying extra. However, in most progressive companies or large organizations with dozens of developers under their belts, there would be a special person assigned to fulfill a leadership role.

A technical leader is more often than not a software engineer, who’s responsible for leading a development team and the quality of its deliverables (working software, readable code, etc).

What are the responsibilities of a tech lead?

Depending on the number of technical leads within the team or organization, lead developer responsibilities will vary. However, there’s usually one person managing the team, and thus they are most probably accountable for:

• Figuring out the requirements and constraints of any given project; understanding and defining the end goals.
• Achieving the project’s goals by developing a software engineering methodology, choosing the technical stack, defining software architecture, determining non-functional requirements and service level indicators, as well as internal milestones and rollout schedule.
• Communicating with team members, assigning tasks, construing code of conduct and code review policies, conducting retrospectives, resolving conflicts, and guiding the team by showing a clear direction of where the company or business is heading.

The skillset of a tech lead

Technical leadership requires practical hands-on experience with programming, relational and non-relational databases, high load systems, and debugging. Good technical leads read a lot of code, technical documentation; write loads of engineering proposals, design pages, assignment tickets; discuss work-related issues with the teammates; negotiate contract deals with other teams; and finally make individual contributions to the code.

Everything from the above requires a deep understanding of the software engineering and development processes to be able to come up with reasonable engineering decisions; nevertheless, the skillset doesn’t just end there.

More often than not, being a tech lead is more about leading and less about being technical (however, your environment and the context of your work might be different). Leading, in this respect, is about building trust and relationships with your colleagues and subordinates, providing guidance by explaining your tech choices, allowing people the freedom to experiment and supporting them on their learning journeys, communicating the clear vision of the business direction, answering your teammates’ questions, hearing them out, and amplifying their voices.

The role of a tech leader is, thus, less dependent on individual contributions but more on the overall output of the team as a whole, meaning that the lead developer’s mission is to provide the team with necessary tooling and information to be as productive as they possibly can. Moreover, what all of this essentially implies is that the team of a tech lead deserves the laurels when the project’s successful, and conversely, the tech lead deserves all the blame when it fails.

One of those few important realizations that some people come to terms with throughout their careers is that you can’t really be good at two things simultaneously: being a good engineer and an effective manager is truly an effort; some people, though, can excel in both domains, but those ones are rare and should be treasured.

Now, if you’ve chosen the managerial path, let’s look at what you can do to develop and train your leadership skills.

How to work on your leadership skills

Firstly and foremostly, if you’re interested in promotion, it’s best to start doing the job (you aim at having) now. Don’t steal assignments and responsibilities from others, though, that’s unethical and won’t lead you that far, conversely — do so constructively.

Another important note is, however strange or inadequate it may sound, to try and make people love you. Whenever you hire engineers, think of the ways they can contribute to the team and, ultimately, the business, make them trust you so they perform their best.

There are several things you can do to make people love working for you (it takes time, you’ll make mistakes, but you’ll make it, eventually):

• Let people grow: allow people to try new languages, embark on their own side projects part-time, contribute to open source; instead of handing a particular spec — ask a designer to come up with their own feature just as they envision it; put some of the staff in direct contact with customers, trust them to represent your company; delegate some of the decision-making process to those who deserve it.
• Grow yourself: be humble, ask questions, trust your team, encourage your colleagues, advice rather than instruct, attend tech conferences together, and more importantly, demonstrate your enthusiasm and willingness to grow.
• Fight for your team: advocate your team’s interests, push for some changes from the top to bottom if your team doesn’t seem to work well under present unfavorable conditions, speak up and defend your colleagues.
• Reward accordingly: instead of pushing rewards to the point when no one needs them already (like when a person threatens to leave) — reward just in time when the person most deserves it.
• Break things down: prevent big projects from becoming big headaches by breaking them down into smaller discrete pieces — decompose tasks into subtasks and iterations; ship all these subtasks as you go lest they turn into the huge monolithic daunting chunk of code.
• Don’t pretend to be someone you’re not: if someone’s on your team more knowledgeable or experienced than you, don’t deny the reality of the situation, accept it, seek advice when necessary and move beyond it; in case, you face resistance, explain and demonstrate how your skills and your help can help people grow.

In the meantime, prepare yourself for transitioning:

• Conduct regular one-on-one meetings with all engineers — these meetings are a low-risk function of management and serve a solid foundation for building good relationships between you and your team
• Add/embark on new responsibilities gradually if you can
• Establish deadlines for transitioning, so you have a clear action plan in mind with significant milestones to check against

In conclusion, it’s worth reiterating three golden rules of coaching: delegate more, supervise less and let people develop their potential. Delegating means giving your team members responsibility to achieve goals, which you have already agreed upon. Supervising less means showing the trust that your team members can do the job on their own. Letting people develop their potential means allowing them to take on new challenges and helping them find their strengths and weaknesses.