The path to technical leadership - 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 he/she is 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 because becoming a manager may or may not align with your long-term goals. For many software engineers, growing as an individual contributor (IC) could be a more appropriate path. Many companies provide IC alternatives to management such as 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, bugs or lack of testing. 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, so take the time to deliver what you committed to or, if necessary, negotiate a better deadline with your manager. Run a project like your own business and actually care about it.
-
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, meaning he or she 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 simply can't participate 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.
-
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.
-
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 just 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, but 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.
-
Vision. For everything they are responsible for, a leader should understand "why". He or she is also responsible to ensure 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.