Lessons from a Developer Turned Team Lead | Notitia
TL;DR
Notitia’s Senior Web Developer, Brett Earle, says stepping into leadership isn’t just a promotion, it’s a split identity. One half still builds, codes, and solves problems. The other leads, mentors, and communicates. This authored blog post by Brett explores how developers can balance deep work with people leadership, structure their days, redefine value, and lead without losing their edge.
I’ve come to terms with the fact that I have two very different roles. One is the ops hat: team growth, knowledge transfer up, reporting, scoping, meetings, comms and all the small chaotic tasks.
The other is the deep work hat: getting back into projects, solving problems, delivering projects, solution architecture and carving out much-needed focus time.
Moving from a strong individual contributor into leadership isn’t a straight path. You don’t just level up, you split into two people.
One is still the builder, solving technical problems, writing code, diving into architecture. The other is the manager, the mentor, the communicator. And neither role waits for the other.
Myth of multitasking in tech leadership roles
One of the first lessons I learned is that multitasking is a myth. You cannot focus on two tasks and do them well.
That’s why I structure my day into distinct pieces. Focus blocks in the mornings, where I can dive into technical work without distraction. Open office hours and “manager hat” tasks in the afternoons, where I’m available for mentoring, meetings, or just being interrupted.
This separation is what keeps me sane. Without it, the context switching kills deep work, and I’d spend my whole day reacting instead of producing.
Redefining value: "Individual Contributor" vs. "Leader"
The harder part wasn’t time management — it was identity management.
When you’re an individual contributor, your value is obvious. You can point to a bug you fixed, a feature you shipped, a deliverable you ticked off. Your impact is measured in concrete outputs.
But when you move into leadership, you have to let go of that internal scoreboard. My value to the organisation shifted into less measurable units of work: upskilling a teammate, creating space for others to succeed, building resilience into the team.
Those things don’t show up in Jira (how we at Notitia log and project manage tasks). They don’t get logged in the sprint report. They don’t get measured in dollars and cents at the end of the quarter. But they matter.
And that’s the uncomfortable part. Learning to value what isn’t immediately visible.
Putting on the leadership hat success vs. problems
A phrase I keep coming back to is: success is for the team, problems are for you.
As a leader, when the team succeeds, it’s theirs. They own it. They should get the recognition. When there’s a problem, though — that’s yours to carry. You step in, you take responsibility, you shield the team from unnecessary fallout.
It’s not always easy on the ego, but it’s the difference between a manager who just coordinates work and a leader who builds trust.
Learning from tech leaders
One of the best ways to accelerate this journey is to model your favourite leaders. Think about the ones you’ve had who really stood out. What did they do? How did they handle mistakes? How did they communicate?
You don’t need to reinvent the wheel. You can borrow from their mistakes and their achievements, speed up your own growth, and adapt their approach to your context.
On the flip side, bad leaders are just as instructive. Sometimes seeing what not to do is the fastest way to learn.
The role of feedback in leadership
The other cornerstone is feedback. But not just waiting for it — asking for it.
I’ve learned to ask specific questions: Did that approach help you? Was that explanation clear? Is there something I could do differently in how I run these sessions?
General “how am I doing?” questions don’t get useful answers. Specific ones do.
There’s a catch though: this only works if you don’t lead with fear. If your team is scared of you, they won’t give you real feedback. They’ll tell you what they think you want to hear.
The real growth comes when people feel safe enough to tell you what you need to hear.
Takeaways for developers moving into leadership
If you’re a web developer moving into leadership, here’s what I’d tell you:
- Accept that you wear two hats, and don’t try to do both at once. Structure your time.
- Stop measuring yourself only by output. Value the impact that doesn’t show up in dashboards.
- Remember: success is the team’s, problems are yours.
- Model the leaders you admire, and learn from the ones you don’t.
- Always ask for feedback and make sure people feel safe enough to give it.
Leadership in tech isn’t about doing more, it’s about doing differently. It’s about redefining what matters, structuring your time around it, and valuing the intangible impact you create.
You don’t stop being a developer when you step into leadership. You just learn how to wear both hats without losing your head.
Read our client case studies to find out about some of the projects that Brett and his team have worked on.
