Engineering leadership is not just about code

If you’re looking to move up into management, programming will only get you so far. Instead, look to hone your prioritization and communication skills.

When people begin their software development career, they understandably focus on the most tangible skill that they’ve spent time honing: programming. But, once you decide that you want to progress in seniority, you begin to find that programming skills become less important. 

Instead, more emphasis is placed on things like prioritization, communication, and how well you can align your team. Advancing your career, therefore, means focusing on honing these skills. 

Clear communication is the key to leadership

In my experience, the number one trait I look for in a peer or report is clear communication across different mediums, including face-to-face, email, chat message, or video call.

Clear communication increases your effectiveness because everyone you work with can understand what you are working on, what your plans are, and how you are thinking about the current topic. Your design documents are easy to follow, you take the extra step to explain your changes in a pull request to aid reviewers, and you help product managers with technical challenges on any given feature. Clear communicators understand their audience and tailor their approach accordingly. For instance, I will go into technical detail when discussing issues with my engineering reports but not when speaking with C-suite executives.

The best communicators I’ve worked with communicate directly. They keep their language simple, making their communication easier to digest and quick to consume. Fewer words are easier to follow, and you can achieve this by adjusting the level of detail you supply in your updates. These elements come together in a more beneficial way for those who may not have English as their first language.

If you need anything from a colleague, be sure to make it clear what you need from them and when. I’ve fallen into the trap of asking someone to “take a look” and not hearing back for a week. Instead, explicitly set your ask up. For instance, you may respond to a peer asking you to complete a task with, “I could do with this by Thursday because I need to present the plan to stakeholders on Friday.” This level of specificity is especially important in distributed or remote teams. 

When you communicate clearly, you remove friction between you and your colleagues and increase the efficiency of the entire team. This is why communication is so crucial; it has an oversized effect on everyone around you. 

Prioritize based on business needs

As you become more influential in your team, your remit will grow, and you may take on the responsibility of collaborating with the rest of the business. At this point, your technical expertise will begin to blend in with business know-how. 

There is always more work to be done than there are hours in the day. People think this is only true at small companies, but in my experience, every team of all sizes wishes they had just one more engineer. Inevitably, once you get that extra engineer, more work appears! A good understanding of your product space and your users is, therefore, crucial at every team size to enable ruthless prioritization. With understanding comes a clearer idea of which proposed features you should focus on and which are nice-to-haves that don’t solve a real user need.

Once you have that context, reach out to your cross-functional colleagues to understand their roles and how you can best work together. These colleagues will give you insight, feature requests, and knowledge that will benefit you greatly in your day-to-day role – particularly when it comes to determining what to invest your team’s time in. As you gain more understanding about the business laterally, you should also make sure that you are aligned and sync regularly with your product manager. Build a shared understanding of how to advance. 

Be willing to be involved in all facets of the product lifecycle; this includes loosening the reigns when it comes to deep coding. Participate in user research sessions, regularly contribute to strategy and planning meetings, and work closely with UX to ensure a great experience for your users. Merging all these avenues of knowledge with your technical experience can be the driving force of decision-making across your team or the org. 

Leadership requires flexibility and pragmatism

A mistake I made early on in my career was focusing on product quality from a purely technical perspective. I regularly petitioned for time to tackle technical debt and rewrite systems from the ground up. Thankfully, my perspective has completely changed since. 

The cold truth is that no one really cares about the codebase outside of engineering. They don’t see the codebase: it is a means to an end, and not front of mind. This means that proposals to invest in the codebase are always going to be hard to sell. That doesn’t mean you should never do them because sometimes they are truly necessary, but the motivation for these projects should be product-led. Tackling technical debt may be personally satisfying, but unless it’s solving a business problem and enabling your team to ship more efficiently, it’s not going to gain the business anything.

Being a pragmatic leader can mean several things. For instance, if the product team wants to ship a minimum viable product (MVP) of a feature by a certain date, you may have to accept some lower-quality code to make that happen. Do this knowing that there will always be room to address problems retrospectively by setting time aside to refine things after the MVP release. Cross-functional team members will appreciate your flexibility and willingness to work with them to find solutions, rather than stubbornly putting your foot down at the behest of technical concerns.

This doesn’t mean you have to be someone who says yes to everything only to end up owning a tangled mess of a codebase. But if you constantly say no, your response loses its weight. Instead, show you’re open to finding the best solution. That way, when you do say no, people will take it seriously. They might not agree, but they’ll respect your reasoning. 

Final thoughts 

Programming skills are important – after all, they got you this far. However, if you’re thinking about your next career move, consider your skills outside of the text editor that will have an outsized impact on you, your progression, and the effectiveness of those around you.