Stop Coding Tasks, Start Designing Systems
How to shift your mindset from "how it works" to "why it matters" to grow your career
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! 🖖🏼
𝘐𝘧 𝘺𝘰𝘶 𝘦𝘯𝘫𝘰𝘺𝘦𝘥 𝘵𝘩𝘪𝘴 𝘱𝘰𝘴𝘵, 𝘵𝘩𝘦𝘯 𝘤𝘭𝘪𝘤𝘬 𝘵𝘩𝘦 💜. 𝘐𝘵 𝘩𝘦𝘭𝘱𝘴!
𝘐𝘧 𝘺𝘰𝘶 𝘬𝘯𝘰𝘸 𝘴𝘰𝘮𝘦𝘰𝘯𝘦 𝘦𝘭𝘴𝘦 𝘸𝘪𝘭𝘭 𝘣𝘦𝘯𝘦𝘧𝘪𝘵 𝘧𝘳𝘰𝘮 𝘵𝘩𝘪𝘴, ♻️ 𝘴𝘩𝘢𝘳𝘦 𝘵𝘩𝘪𝘴
