25 Ways to Demonstrate Technical Leadership

 25 Ways to Demonstrate Technical Leadership

 

 

In the engineering team at LinkedIn, we value Leadership, Execution, and Craftsmanship, and measure performance based on it. Although engineers typically have a strong sense of how to execute and a high internal craftsmanship bar, leadership can sometimes be a trickier business.  How to exhibit notable leadership can feel like a much fuzzier goal. At a high level, you want to focus on the following:

Adopt a growth mindset and be extremely pro-active in every aspect of your role

 

To get more concrete, here are some specific ways to demonstrate technical leadership, in no particular order:

1. Own a project end-to-end – not just the code and the architecture design, but a deep understanding of why we're building this project, what impact it's going to have, (if any), and how to measure that impact. Monitor that project operationally and from the product metrics perspective and keep your manager and other stakeholders informed. 
2. Push improvements into lower layers of the stack or into horizontal or open-source libraries. If you're working in the UI layer, add to the component library when you need to build something new. If you're building an API, make sure you push any general instrumentation improvements into the underlying middleware. If you don't know the owners of those libraries, reach out to them. 
3. Build tools and have other engineers use them. Building tools to do your job more effectively is a craftsmanship pursuit. The leadership part enters the picture when you start showing others how to do the same, you start sharing the value of the tools you've built and help others to leverage them too. This can have secondary benefits for your personal brand.  
4. Act as the point person to a key manager or contributor from another team. If they can rely on you as a go-to person for all things related to your team, they'll view you as a leader. When you work with other functions like designers, product managers or data scientists, help them rely on you as someone who can bridge their context and your own. For example, help the data science team understand how your team uses their output.
   
5. Own a service – either create a new service, or act like an owner whenever you make changes to an existing one. Identify opportunities to make improvements that will pay off in the future. Anticipate infrastructure requirements and help prioritize and advocate for doing the work. 
6. Keep stakeholders informed that a new feature roll-out is happening, what its impact is, and what you're learning as it rolls out. Do this in a way that clearly articulates the value of what is occurring and why that’s important and relevant. If needed, learn how to talk to non-technical senior managers. 
7. Come up with a new technique that enables smoother cross-functional collaboration and increases the shared understanding. eg. if you need to build data visualization features, start using a tech like Angular to prototype those features: do whatever it takes to reduce the iteration times between app development and data science teams. 
8. Provide meaningful code reviews to other engineers repeatedly and consistently. Do this in an area you know well, and do it in areas where your knowledge is weak. Repeat this often enough and people will seek you out for specific feedback. 
9. Form an opinion, and share your point(s) of view on relevant new product ideas, on work-in-progress product specs, on the specific initiatives in your team's backlog. Do this in meetings, in casual conversations, and with anyone that's interested. If you're missing enough information to form a point of view, reach out to the people that do. 
10. Understand early or nascent work of the engineers from other teams, and help advocate for its use. For example, if another team has built a shared component or a new library, understand how your team can get leverage from it even if it wouldn't be you doing the work. 
11. Become a person of recognized authority in a specific area. If there's a closed technical advisory board, be the person that represents your team on that board, and use that to keep your own team informed. 
12. Be the first person on the ground when production issues are discovered, help to solve them and understand the most effective ways to triage them. Own the communication and its post-mortem where applicable. If you're not sure how to do this, tell the person who already does it that you want to shadow them. After doing this a few times, be prepared to be the person leading post-mortems. 
13. Get involved in architecture review sessions. Present your own work for review and help others improve theirs. If your team doesn't already have a forum to facilitate this, start one.
14. Get the team excited about something. It could be something you've built, or something a tools/infrastructure team has just shipped that unlocks a new capability. For example, a new build system or internationalization process, or a way to reduce cross-team review times by collaborating in a different way. 
15. Do something 10x better than anyone else on your team can. This can be technical or cross-team. One engineer I knew could debug any issue even if it spanned 5+ service and team boundaries, enabling him to lead the most complex debugging sessions. This is often about focus and practice – it's not always rocket science – and by definition typically has a massive impact. 
16. Exhibit strong project management of your work. Communicate directly with stakeholders and pre-emptively send out updates. Don't wait to be asked how your projects are progressing, send out high-clarity updates when needed or on a weekly basis. 
17. Help your team raise the bar by sharing internal tribal knowledge, writing articles, running knowledge-transfer sessions, or just sharing your pro tips with productivity tools like IntelliJ, iTerm2, etc.
18.  Take ownership of something unmaintained that you think should be important to the team. If the creator of an essential plugin is leaving the company make sure you do a hand-over and then act like the owner, learning as you go. If there are scripts or libraries that are pretty broken, roll up your sleeves, lead the small fixes and improvements and over time become the maintainer. 
19. Present your work/team/product in a sizable forum and own the narrative as people ask questions. If you're nervous or not sure where to start, learn how to give a successful technical presentation. 
20. Be the person that resolves conflict. When you're collaborating with several other people and a conflict arises, help everyone see each other's point of view. Often this is because of a lack of shared information or understanding. Once everyone sees why they're disagreeing with each other, it should be much easier to identify a path forward, and you'll have led them in that conflict resolution. 
21. Infect others with your documentation obsession. Start off documenting the gaps you encounter in your team processes like on-call and feature rollouts. Over time, turn that into a dedication to accurate documentation that materially improves the team's knowledge base.
22. Help your team bridge the technical gaps in their knowledge. Your teammates may not strictly need to understand your area of expertise, but help them understand it anyway. For example, help a UI engineer build an API endpoint, or help a backend engineer deeply understand a core library that s/he uses all the time (so they can then start improving it as well). Everyone's perspective will be widened.     
23. Get another team to do something that they don't really want to, and won't be doing by default. If you're confident it's important, will help them or your own team, and might even help other teams, then they'll thank you later.     
24. Insert yourself into relevant conversations where your perspective or experience can add value, especially if the people involved don't realize you can help. For example, if someone doesn't know about a service you own, or an API you know well, help them understand why they should be using it.     
25. Dramatically improve your communication skills. Are you intimidated by group settings? Are you a non-native speaker that sometimes tunes out? Have you never given a presentation before? Do others say you mumble? If the answer to any of these questions is yes, then commit to improving your communication skills. Look for your company's presentation training resources, join a Toastmasters club and give a short lightning talk at a meetup group or conference. Rinse and repeat.  

If you're an engineer and you're not sure if you're demonstrating leadership yet, pick two or three from the list that you might find interesting. Commit to pursuing them for 3-6 months and be sure to share your intentions with your manager.This list is by no means exhaustive. What do the engineers on your team already do that inspires you?

The Author: Lee Mallabone

 

                                        

About: 

A passionate engineering leader and product creator with years of commercial web and mobile software development experience. I work at all levels of the technology stack, having successfully built countless sites and apps in ruby, javascript, java and a wide range of front-end web and mobile languages and frameworks. I bring a pragmatic, product-centered and data-driven approach to the teams I lead and the software I build. Having previously founded two companies, I have a strong awareness of how to directly contribute value to the company, not just the code. I demonstrated this when I joined Rapportive, subsequently acquired by LinkedIn.  With a strong academic background and a keen interest in new technology, I never stop learning, but above all, I love building things and inspiring others to do the same.