by Alex Bachuk

The path to technical leadership: how to go from developer to team leader

If software development feels like it is only part of your professional purpose, perhaps you should consider becoming a tech lead. A tech lead could mean different things: a team lead (with no direct reports), or a manager. For example, an engineering manager is a person who is responsible for the team and its projects. That means they are also responsible for peoples’ careers, business growth, deliverables, deadlines, culture, code standards, technical debt, and more.

If you’re a developer, it may not be clear how to get from where you are to a technical leadership position. If your goal is to become a manager soon, you will need to ask yourself why you want this role. Becoming a manager may or may not align with your long-term goals.

I got into software development because I felt more comfortable working with computers than people. But after a while I found myself helping other developers more and more. I enjoyed leading projects and pushing for better code standards. It was an obvious choice for me personally.

For many software engineers, growing as an individual contributor (IC) could be a more appropriate path. Many companies provide IC alternatives to management. These alternatives include a staff engineer, distinguished engineer or fellow engineer. These are very senior technical roles, but no one reports to them as they would to a manager.

So, do you want to become an engineering manager or another type of team leader? It is important to be honest about what drives you — is it writing code and architecting software? Or, is it helping others to get better results, negotiating deadlines with stakeholders, and convincing your business team that code refactoring is not a waste of time? Your answers to these questions should help you determine which path is more appropriate for your desired outcomes.

If you’re still convinced a technical leadership path is right for you, then you have some work ahead of you. Consider working with your manager or a mentor to have them help you in areas where you are less familiar. Here is an outline of ten key areas of focus:

Stepping up. A true leader can lead without the title or authority. Anyone with a fancy title and enough authority given by the organization chart can give orders. But that’s not what leadership is — it is about what you do.

Therefore, you should start small. Take on more responsibilities during difficult projects. Help your peers by providing feedback in pull requests. Volunteer to present on the project updates. Propose improvements to your team or product workflow. Mentor a colleague.

There are enough opportunities that people either don’t want to see or don’t have enough expertise or confidence to take on. Determine what your colleagues are struggling with, and then step up and do them.

Ownership. When taking on responsibilities, be accountable for everything you do or don’t do. A leader takes responsibility and avoids blaming others for mistakes, missing deadlines, or bugs.

Rather than complaining about a bug someone introduced, just help them fix it and explain how to avoid it in the future. Coming up with excuses doesn’t help anyone. Take the time to deliver what you committed to. If necessary, negotiate a better deadline with your manager. Run a project like your own business and actually care about it.

Recently, one of the tech leads on my team pulled the latest master branch. They saw a big drop in unit test coverage. Rather than complaining, he added missing test coverage. And then presented how to properly check for the coverage and how to write a unit test for complex features. He offered to help if anyone needs it without blaming anyone. The team appreciated that.

Relationships (or politics). Sometimes people misinterpret relationships and call them “politics”. They are the same things. If you don’t want to deal with “politics” then perhaps think again if you want to get into leadership in the first place.

Building meaningful relationships is one of the responsibilities of engineering managers. Management is making things happen through other people. Start building good relationships with other engineering managers. They are your future peers.

There are a few ways to do this, such as presenting at tech talks, doing workshops, and mentoring developers outside of your team. Engineering managers will appreciate the relationships you build through these tasks.

Technical expertise. An engineering manager should be an engineer first. They must have a strong software engineering background and hands-on experience. Becoming one of the strongest engineers on the team is a requirement. A manager who can’t code or doesn’t understand the technical details can’t take part in technical discussions. Once you become a manager, you should always keep your skills sharp enough to be competent at higher level architecture.

Mentorship. Any “really good developer” on the team who’s not a team player is more harmful than helpful. If you’re technically strong, then you should be helping others to get to your level. Pair programming, code reviews, presentations, open source or inner source projects are all great examples of how to get started in mentoring others.

It is rare for someone to come to you and ask you to mentor them. Yet, by branding yourself “the expert” and proactively doing the things mentioned above, people will naturally start coming to you for advice. By helping others you build meaningful relationships and gain people’s respect. Hopefully, they do the same in return and mentor others as well.

Project management. Delivering projects on time is one of the core responsibilities of any leader. If, as a developer, you’re constantly missing deadlines and underestimating tasks, others can’t trust you. You have to be organized and be on top of your tasks.

We all know estimating software projects is hard as there is a lot of uncertainty. However, with the right process, it’s not impossible. Constantly communicate the progress and expectations of the project with your manager or stakeholders.

For example, my team is doing a weekly status report, where the project tech leads have an opportunity to communicate the progress, mention any blockers or raise a major concern of not delivering on time.

Communication. Communicating clearly and concisely is a very important characteristic of any leader. If you can’t explain clearly what you want from your team, then you have failed as a leader before any work even begins.

Communication comes in many forms, including verbal, written and even body language. Always work on improving all of your communication skills.

My team missed a few deadlines because I failed to communicate the requirements clearly and on-time. There were few instances where the lack of communication created confusion on the team who was supposed to do what. I learned that relying on project managers or business stakeholders to explain the project details isn’t working. An engineering manager has to understand the project and then explain it and sell it to the team. And motivate them to want to work on it.

Managing up. Manage your manager (and sometimes their manager). This means constantly communicating with them and managing expectations. Managers rarely like surprises, good or bad. Establish trusting relationships with your manager. Be the go-to person for important and high profile projects, and actually get them done on time and on budget. Then more projects will follow and you can repeat the process.

Conflict and crises. Production issues happen, no matter how many unit or integration tests you have. Yes, you want to minimize the number of bugs your projects have. What matters more is how you handle production issues. A person who starts panicking under pressure is immediately disqualified as a leader in the eyes of others. The team and other managers want to see a calm person who has everything under control, even in the most stressful situations.

A tech lead I used to work with was always calm. There was no conflict or pressure that could make him snap. At least nobody saw him stressed out. When it came to handling a production issue at 3 am, he didn’t disappoint. The issue was fixed in minutes and he showed up to work as if nothing happened.

Another tech lead got so stressed out with the deadline he called in sick on the day we were supposed to launch the feature. He was so anxious, it made everyone else around him uncomfortable to work with him.

Even though these are 2 complete opposites, you can guess which one was more successful as a tech lead.

Vision. For everything they are responsible for, a leader should understand “why”. They are also responsible for ensuring everyone else understands “why” they are working on a project. A leader must explain (often many times) why the project is happening, why the specific people are working on it and how this project fits into the “big picture”. A team has to believe in what they do, only then can they can be effective.

Lead the Way Forward, Starting Today

Leadership is not limited to one or two people, so don’t wait for permission, step up today. Be an expert in your field and start helping people when they are stuck. Work on your communication skills, even something minor like technical documentation. Build great professional relationships with your current and potential future peers. Make sure you manage your time wisely and be on top of your projects’ deadlines. And don’t forget that leadership is about people, so genuinely help people grow and do their best job.

You can find me on Twitter https://twitter.com/netxm if you have questions or just want to say “hi”.