From Developer to Engineering Lead
When I joined Solutech as a software development intern in late 2017, my entire world was the code in front of me. Good pull requests, clean functions, fast APIs, that’s how I measured my impact. Eight years later, sitting in an engineering lead role, I’ve had to completely rewrite that definition.
This is what I wish someone had told me earlier.
The hardest part isn’t the technical problems
The thing nobody tells you about engineering leadership is that the hard problems stop being technical almost immediately. You’ll still write code, I still do, but the decisions that actually move things forward are the people ones.
Who’s close to burning out? Who needs more challenge? When is the right time to push back on a deadline with product? These aren’t problems you can debug with a stack trace.
My first month as Lead Mobile Developer, I spent most of my energy trying to be the best individual engineer. I reviewed every PR personally, unblocked every question, wrote the most critical features myself. Within six weeks, the team was faster but I was the bottleneck.
The shift that actually worked: instead of solving problems, I started asking better questions. “What do you think the right approach is?” moves faster than “here’s the right approach.”
Multiplying vs. contributing
There’s a useful mental model I picked up: your job shifts from contributor to multiplier.
A contributor’s output is their code. A multiplier’s output is the team’s velocity.
In practice this looks like:
- Writing the spec, not just the code
- Building the review culture, not just reviewing
- Unblocking decisions by giving context, not answers
- Protecting the team’s focus from everything that isn’t the current goal
None of this is glamorous. A lot of it is meetings, documentation, and saying “I don’t know, let me find out” more often than you’d like.
Communication is the actual skill
The biggest thing I’d tell my 2017 self: invest in written communication early.
Engineering leadership is fundamentally a communication job. The clearer your thinking on paper, the clearer it becomes in your team’s execution. Write the architecture doc. Write the post-mortem. Write the quarterly engineering update even when nobody asked for it.
The discipline pays compound interest.
The second thing: learn to be comfortable with incomplete information. Shipping decisions require judgment, not certainty. Good engineers make good calls with incomplete data, that’s the skill to build, not the ability to gather perfect information before acting.
The code is still there, and it still matters. But it becomes one input among many rather than the entire output.