Many of us have travelled the journey from junior developer to senior developer to tech leader. We know and understand where you’re coming from and where you want to go. It’s why we launched CTO Academy, to make it easier to negotiate that journey from the technical to the managerial. But let’s dive deeper into what that journey looks like.
If you’re an ambitious software developer then next step can be tech lead.
A tech lead can mean different things: a team lead (with no direct reports), or a manager. For example, an engineering manager is a person responsible for the team and its projects which 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. Make sure those senior roles are aligned to your core skills and ultimate purpose. What are your core values and what type of role and company will be matched with them? Really important to clarify these fundamentals early in your career to avoid travelling down the wrong path.
It is important to be honest about what drives you — is it writing code and architecting software or 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.
CTO Academy work with ambitious developers around the world, helping them build the skills and execute the career roadmap that help them achieve the career and reward they want and deserve. If you’d like more information then visit the CTO Academy website.
90 Things You Need To Know If You Want to Become The CTO
Vulnerability builds trust and elevates performance. It sits alongside empathy and authenticity as a triumvirate of the soft skills that help leaders to earn the trust and buy-in of those they lead. Research shows that leaders gain much by showing just a little vulnerability and as Brene Brown explains “being vulnerable in the workplace means … Read more
You have responsibilities and power as a leaderthat impacts directly on people’s lives Jack Welch formerly CEO at General Electrictalked about the leader as “Chief Broomer”like those you see at the Winter OlympicsIn the sport of Curling Clearing stuff out of the waySo the people around them can act and do the thingsThat the organisation … Read more