Code less to become more of a leader.
You might have heard this before. I admit I was confused when I first heard it.
It almost sounds counterintuitive. But I can say from experience that this is 100% true.
Today I want to answer the following questions:
What does being a tech leader look like?
How do you get leadership support in the workplace?
While this post might be geared more toward software engineers, what I have to say applies to anyone who wants to grow as a leader. It's all about proving your potential. And to do that, you have to act like a leader, which means taking on other duties.
Before I share how I've helped lead teams in the past, keep this in mind:
Every company is different.
That means being a leader looks different from company to company. However, there are many similarities across product development teams. So the following examples should still apply.
Mentoring & 1:1s with peers
One-on-one face time with your peers is priceless. In just 30 minutes every few weeks, you can slowly build a relationship based on trust and empathy with your coworkers and check your team’s pulse. Also, it's an excellent way to practice something all leaders and managers do.
The best leaders in the world listen more and talk less. And there's a reason for that. People feel seen and appreciated when others listen to them. Also, when leaders listen, they gather data and use that information to help their team.
Look for opportunities to mentor junior members of your team. And if that's not an option, schedule a recurring 1:1 with a teammate. Practice your listening skills and help others solve problems and grow their skills.
This is exactly what I did as a Senior Software Engineer. No one told me to meet one-on-one with my peers. But I knew this was a key skill to acquire as an engineering leader.
I started mentoring Junior Engineers and meeting regularly with other Senior Engineers. This gave me a boost of confidence and prepared me for future 1:1s as a Tech Lead and an Engineering Manager.
Project management
Software isn't created in a bubble. It requires planning and cross-functional collaboration. After all, you need to know what and why you're building something. And this is where you can shine as a leader.
Most product development teams use some process to manage their projects. Whether your team has standup and sprint planning meetings or uses Jira or Trello, you can leverage these tools to manage projects.
Ask if you can lead some of your team's meetings. This will put your leadership skills on display and show your coworkers your desire to lead. This will also force you to prepare for these meetings. You'll need to know what's done, in progress, and up next. And you'll have to anticipate questions about your project, which will motivate you to seek answers beforehand.
Documentation
Another way to lead without coding is to embrace your team's documentation process and make it better. Distributed teams must rely on async communication and strong documentation for success. But most teams, especially small ones, usually have poor documentation handling. It can easily take a backseat to building features, which results in outdated and unhelpful documents.
Identify the major documents that your team relies on. This could be new hire onboarding docs or how-to guides for code reviews, deployments, and testing. Review them with fresh eyes and follow the steps. Did anything break? Did you find a gap in the instructions? Update the docs and share the changes with your team.
Research
The research phase in the software development lifecycle is another overlooked opportunity to lead. Most engineers are too busy for spike tickets and investigative tasks.
You can’t write code that integrates with a new API all of a sudden. You have to read the API docs first and understand how the contract works.
You don't start using a new testing framework out of the blue. You have to learn how it works and decide how to connect it with your existing codebase.
It takes time to do this research. It's not very glamorous work, but it can be incredibly helpful for your team. And that's what being a leader is all about—finding opportunities to make your team happier and more productive.
Getting Buy-In and Making Space for Leadership
Before you follow any of my advice, let's get something straight. Please don't start working 10 or 12-hour days just to make this happen. This isn't about working more—it's about adjusting your workload to accommodate new duties. Remember, you're coding less, not the same amount.
I recommend speaking with your manager about your intentions. Tell them you want to grow your leadership skills. Give them a short list of ways you can lead beyond code. You can even use some of the examples I just shared. Having the support of your manager can mean the difference between success and failure.
You should also inform your team. Let them know you'd like to lead a meeting or do some research next sprint. In most cases, they should be thrilled that you want to step up and help the team. If you sense some friction or disagreement, talk about it with your manager or another people leader in your department.
Remember, every company is different.
What if your company already has stellar documentation? Well, then find another area where you can make a difference.
There are countless ways to lead. You just have to look for them.
If you want to be a leader, you have to act like one. And that means taking on activities beyond coding like meeting 1:1 with peers, managing projects, and writing documentation.
You don't have to do this alone. Get support from your manager, company leaders, and peers. Lean on your professional network for guidance.
The transition from individual contributor to leader is challenging and requires a thoughtful approach. But you don't need a title to lead. And you don't have to work more hours.
Identify opportunities to step up as a leader. And communicate your intentions with your team.
What’s one action you can take this week to act like a leader?
This has often been an awkward transition for engineers I've worked with.
What brings them to the job is love for problem-solving, and then when they get more senior, that's when companies often try to shoehorn them into line management/mentorship.
It's often taken quite a bit of coaching to help them to see the value in that and how equally important it is to help support the next generation of coders coming into the engineering community.
I can't think of anyone who's done that successfully though who hasn't found enormous value in it...
> But you don't need a title to lead
A million times this! I'm not sure how many times I've said that in the past. Some people just wait for permission. Just go and do it, lead the way.
Also when you discuss Documentation it really hit home for me. I wish it had more love from everyone.