Hi Optimisters! ๐ฉ๐ปโ๐ป
One of the most common questions I get from Senior Engineers is:
How do I actually prove Iโm ready for a Lead role?
Most people think itโs about writing more code or being the fastest at closing JIRA tickets. But here is the truth:
๐๐ผ Leadership isnโt about the code you write; itโs about the decisions you enable.
The transition from Senior to Lead requires a fundamental mindset shift. You need to stop thinking in terms of โtasksโ and start thinking in terms of โsystemsโ and โimpact.โ
In todayโs email, I share with you 3 pills of knowledge for you to thrive in this ride.
The Mindset Shift: From โHowโ to โWhyโ ๐
When you are a Senior Dev, you focus on the how:
How do I implement this function?
How do I fix this bug?
When you step into Tech Leadership, you must pivot to the why and the what:
The Individual Contributor (IC) builds the bridge.
The Tech Lead decides where the bridge should go and ensures the whole team knows how to maintain it.
This shift is where most engineers struggle, but thereโs a perfect โtraining groundโ to practice this: System Design.
By the way, if you are looking for good System Design learnings, subscribe for free right now to the work done by Neo Kim ๐๐ป
Leadership in Action: The ETL Example ๐ ๏ธ
Letโs look at a practical example weโve discussed in this other email: Designing an ETL (Extract, Transform, Load) architecture.
A Senior Developer might jump straight into the code, picking the trendiest library to move data from point A to point B. But a Tech Lead approaches it differently. They donโt just build an ETL; they make leadership decisions through design:
Contract over Code: They define the โContractโ between systems. They think about how this data pipeline affects the Data Science team or the Frontend.
Trade-offs as Strategy: They donโt look for the โperfectโ tool. They weigh cost vs. scalability. โDo we need real-time streaming, or is a simple batch process enough for our current business stage?โ
Mentorship through Architecture: They design the system so itโs easy for other developers to contribute without breaking things.
When you document these decisions, explaining the why behind your architecture, you are already performing the role of a Tech Lead. You are providing clarity, reducing risk, and empowering the team.
Knowledge Pills for Your Growth ๐
If you want to accelerate your path to leadership this month, try these three things:
Own the โNon-Happyโ Path: Donโt just design for when things work. Lead by defining how the system fails (observability, retries, alerts).
Write for Others: Start writing RFCs (Request for Comments). If you can convince your peers that your architecture is the right one, you are leading.
Stop Being the Hero: If you are the only one who can fix a specific system, you arenโt leading; you are a bottleneck. True leaders build systems that donโt need them to survive.
Wrap up! โจ
๐๐ผ Technical leadership is a muscle.
You build it every time you take a step back from the IDE to look at the bigger picture. Whether you are refactoring a monolith or designing a new data pipeline, ask yourself: โHow does this decision make my team better?โ
Now, I want to hear from you!
What is the biggest challenge youโve faced when trying to move from โdoingโ to โleadingโ? Is it the lack of time, or perhaps not knowing how to start the conversation with your manager?
Leave a comment below, I read and reply to every single one!
Stay optimistic and keep building.
Thanks for your support and feedback, I really appreciate it!
Youโre the best! ๐๐ผ
๐๐ง ๐บ๐ฐ๐ถ ๐ฆ๐ฏ๐ซ๐ฐ๐บ๐ฆ๐ฅ ๐ต๐ฉ๐ช๐ด ๐ฑ๐ฐ๐ด๐ต, ๐ต๐ฉ๐ฆ๐ฏ ๐ค๐ญ๐ช๐ค๐ฌ ๐ต๐ฉ๐ฆ ๐. ๐๐ต ๐ฉ๐ฆ๐ญ๐ฑ๐ด!
๐๐ง ๐บ๐ฐ๐ถ ๐ฌ๐ฏ๐ฐ๐ธ ๐ด๐ฐ๐ฎ๐ฆ๐ฐ๐ฏ๐ฆ ๐ฆ๐ญ๐ด๐ฆ ๐ธ๐ช๐ญ๐ญ ๐ฃ๐ฆ๐ฏ๐ฆ๐ง๐ช๐ต ๐ง๐ณ๐ฐ๐ฎ ๐ต๐ฉ๐ช๐ด, โป๏ธ ๐ด๐ฉ๐ข๐ณ๐ฆ ๐ต๐ฉ๐ช๐ด
