Growing Your Career Towards Technical Leadership

Updated 5 May 2026

There is no checklist for becoming a technical leader. I wrote those words back in 2020 when I first published this article, and after five more years of career shifts, from innovation lead to senior software engineer at Microsoft, from managing teams to leading through influence across distributed organizations, that statement has only become more true.

What has changed is the landscape you’re growing into. The role of the engineer is evolving faster than at any point in my career. The skills that got you here, deep technical expertise and shipping reliable software, are still necessary, but they’re no longer sufficient. Technical leadership in 2026 demands something more: the ability to learn faster than the tools change, to create opportunities where none exist, and to multiply your impact by lifting others.

This article has been updated to reflect everything I’ve learned since 2020. The core pillars remain the same, keep learning, seek opportunities, share with others, but the depth behind each has grown considerably. If you’re an engineer wondering what “growing into leadership” actually looks like in practice, this is what I’d tell you.

Where My Technical Leadership Journey Started

Before 2010, I’d never written a line of code. I had a passion for computers and gadgets, and when it came time to pick a degree, Computer Science felt right. I studied at the University of Hull where one lecturer in particular, Rob Miles, changed my career aspirations. Rob didn’t just teach us to code, he taught us that anything you learn is worth sharing with others.

I started this blog in 2012 as a university student, posting tips and code samples that maybe five or six people read. What mattered was building the habit of expressing myself publicly, of making my thinking visible. That habit has built over the years into speaking engagements, open-source contributions, consulting opportunities, and eventually a role at Microsoft.

Here’s my first piece of advice, and it hasn’t changed since 2020: once you start sharing your voice, you will be heard.

Never Stop Learning

Nobody is perfect at everything. I’ve been building software professionally for over a decade, and I still encounter technologies, patterns, and problems that are completely new to me. That’s not a weakness. If you never reach beyond your current capabilities, you’ll find it difficult to grow.

What has evolved in my thinking is how to learn effectively as you become more senior.

Learn Deliberately, Not Reactively

Early in your career, learning is key. You learn because you have to ship. As you grow, the challenge shifts. Nobody assigns you learning anymore. You have to seek it out, and you have to be deliberate about what you invest your attention in.

I keep a personal knowledge management system, a Second Brain, where I capture, organize, and distill everything I learn. Not because I have a perfect memory, it’s quite the opposite. The act of writing something down in your own words, connecting it to what you already know, and revisiting it later is the difference between consuming information and learning.

Learn from People, Not Just Documentation

Technical leadership comes from understanding your weaknesses and learning from the strengths of those around you. Asking for help is not a sign of weakness, it’s one of the most underrated skills in any profession.

The best engineers I work with at Microsoft aren’t the ones who know the most. They’re the ones who find the right person to ask, synthesize what they learn, and share it. There is a wealth of knowledge in your team, your extended network, and the broader community. Your job is to tap into it and pass it on.

Sucking at something every once in a while is how you achieve greatness in the long run

Tony Horton, The Big Picture: 11 Laws That Will Change Your Life

Learn How to Learn with AI

This is a new dimension that didn’t exist when I first wrote this article. AI tools have fundamentally changed the speed at which you can acquire knowledge. GitHub Copilot can explain unfamiliar code. ChatGPT can summarize complex papers. AI agents can prototype ideas in minutes that would have taken days.

But using AI to skip understanding is not learning. The engineers who will thrive are the ones who use AI to accelerate their learning, asking it to explain concepts, then verifying, then teaching what they learned to others. Are you learning with AI, or are you outsourcing your growth to it?

Seek an Opportunity

We all have a drive that keeps us moving forward. Mine revolves around helping others achieve great things, and in order to do that, I have to keep learning. It’s the self-reinforcing pattern. But learning alone isn’t enough. You need to put yourself in positions where learning translates into impact.

Volunteer for the Uncomfortable Thing

Opportunities rarely arrive gift-wrapped. They show up as ambiguous problems nobody else wants to own. The messy cross-team coordination. The proof-of-concept that might not work. The internal presentation to a leadership audience. The migration nobody wants to touch.

Every significant career inflection I’ve had, from being asked to lead a team for the first time to driving AI innovation inside Microsoft, started with volunteering for something that felt uncomfortable and uncertain. I’ve learned to treat that discomfort as a signal.

Moving forward without knowing a specific destination can lead to some pretty remarkable adventures.

Rhett McLaughlin & Link Neal, Rhett & Link’s Book of Mythicality

Create Opportunities, Don’t Just Wait for Them

This is the biggest shift in my thinking since 2020. Back then, I wrote about “seeking” opportunities. Technical leaders go further, they create opportunities by identifying problems and proposing solutions before anyone asks.

At both Razor and Microsoft, I shaped my own approach to this, building and iterating on it over time. I learned that the engineers who grow fastest aren’t waiting for something appear on their plate. They’re experimenting. They’re identifying business problems, coordinating a hypothesis, building the prototype, gathering the evidence, and presenting the case. They don’t ask for permission to innovate, they earn the right by showing results.

If you can see a better way to do something, like a process that could be automated, a system that could be more resilient, a team problem that nobody is addressing, don’t wait for someone to create a project for it. Write up the idea, propose it, and start small. The ability to identify and frame valuable problems is one of the most distinguishing traits of a technical leader.

Build Your Network Intentionally

You need to surround yourself with people who challenge your assumptions and expose you to different perspectives. Whether that’s joining communities on GitHub, LinkedIn, Discord, or attending conferences and user groups, your network is your leverage.

But networking isn’t about collecting contacts. It’s building genuine relationships with people whose work you respect. Help them before you need anything. Share their work. Engage with their ideas. Over time, these relationships build into the kind of trust that opens doors.

Share With Others

Want to know what’s more rewarding than learning something yourself? Sharing that knowledge so others don’t have to struggle the same way you did.

This is where the technical leadership flywheel starts. The more you share, the more approachable you become. The more approachable you become, the more people come to you with interesting problems. The more interesting problems you work on, the more you learn. And the cycle continues.

In learning, you will teach, and in teaching, you will learn.

Phil Collins, Son of Man (Tarzan)

Share Your Voice Publicly

I started blogging in 2012 and nobody read those early posts. That didn’t matter. What mattered was the ability to take something I’d learned, structure it clearly, and put it out into the world. Over time, that muscle produced articles like my series on building an AI-augmented Second Brain, which has become some of the most rewarding work I’ve published.

Your platform doesn’t have to be a blog. It could be GitHub contributions, conference talks, internal tech talks at your company, or even well-written design documents that your team references months later. The medium matters less than the consistency.

If you’re a student or early-career engineer, start now. Build your portfolio while you’re studying, it will pay dividends faster than you expect.

Share Within Your Team First

Not all knowledge sharing needs to be public. Some of the highest-impact sharing happens inside your team. When you solve a tricky problem, write up how you did it. When you learn a new pattern, demo it in your next team meeting. When a teammate is stuck on something you’ve encountered before, sit with them and walk through it.

This is the heart of what makes a technical leader. Not the person who knows the most, but the person who makes everyone around them more capable.

Overcome Imposter Syndrome by Doing

Many engineers hit a wall where imposter syndrome tells them they’re not qualified to share. I’ve been there multiple times. The fix isn’t waiting until you feel ready. It’s sharing anyway and discovering that your perspective has value, even when (especially when) others have a different way of doing things.

On many occasions, I’ve shared something openly and learned that someone else had a better approach. That’s not a failure, it’s one of the most valuable forms of learning. It’s the kind of growth you can only achieve through open interaction with others.

What Technical Leadership Looks Like in the AI Era

AI is reshaping what it means to be a technical leader. When AI agents can generate, test, and deploy code autonomously, the value of a leader isn’t in writing code faster, it’s in knowing what to build and why. Technical judgment, system design, stakeholder communication, mentoring. These human skills become more valuable as AI handles more of the implementation.

Here’s what I’ve observed in the engineers who are thriving:

• They use AI as a multiplier. They pair with AI tools to move faster, but they understand the systems deeply enough to catch when AI gets it wrong.
• They focus on architecture and design. The higher-order decisions, what to build, how systems interact, where the trade-offs are.
• They invest in communication. The ability to explain a complex system to a non-technical stakeholder, write a clear design document, or mentor a junior engineer is becoming the ultimate differentiator.
• They stay curious. The engineers who are struggling are the ones who’ve decided they know enough. The ones who are flourishing treat every new capability as something to understand.

Technical leadership has always been about influence more than authority. In the AI era, that’s truer than ever.

Common Mistakes on the Path to Technical Leadership

Over the years, both in my own journey and in mentoring others, I’ve seen a few patterns that consistently hold engineers back:

• Waiting for permission to lead. Leadership isn’t a title. It’s a behavior. You don’t need to be promoted into it, you can start practicing it today by mentoring, proposing improvements, and taking ownership of outcomes.
• Optimizing for technical depth. Deep expertise matters, but if you can’t communicate it, collaborate across teams, or translate it into business impact, you’ll plateau. The best leaders are V-shaped: specialists with deep knowledge in one or two areas, while gradually building knowledge in adjacent ones.
• Avoiding vulnerability. The instinct to “look like you know what you’re doing” is strong. But the leaders I respect most are the ones who say “I don’t know, let me find out” and then follow through. Vulnerability builds trust faster than confidence does.
• Treating career growth as a solo pursuit. Your career is shaped by the relationships you build as much as the code you write. Invest in your team, your manager relationship, your network. Growth is a team sport.
• Skipping the “share” step. You learn something, apply it, move on. But if you don’t share it, write it up, teach it, or document it, that knowledge disappears with the context. Sharing closes the loop and multiplies the value of everything you learn.

What do you need to do to grow into technical leadership?

There is no single right path to technical leadership. Only you know what it takes to get there. But reflecting on my own journey, from a student who’d never coded to a senior software engineer at Microsoft, through team leads and cloud solution architecture, and everything in between, the same three pillars keep holding true:

1. Keep learning. Read, listen, explore the unknown, and learn deliberately. Build systems to retain and connect what you learn.
2. Seek (and create) opportunities. Don’t wait for the perfect moment. Volunteer for the uncomfortable thing. Comfort zones are where careers go to stagnate.
3. Share what you know. Write, teach, mentor, contribute. The act of sharing creates a flywheel that accelerates everything else.

If I were to add a fourth pillar, one that I didn’t fully appreciate in my early career, it would be lead through influence before you have authority. The best technical leaders I know earned their leadership long before their title reflected it. They did it by making the people around them better, consistently, without being asked.

You’ll learn and reflect just as I have. You’ll understand more about what it takes to lead and you’ll grow into it naturally. It’s not something that will happen overnight, you’ve got to be ambitious.

The only difference between you and the technical leaders you admire is time and deliberate practice. Start now.