Leading Engineers, Not Just Engineering
Leading Engineers, Not Just Engineering
I came up as an engineer, Core Java, Web Services, the architecture diagrams. For a long time I thought leadership was just engineering with more meetings. It isn't. Somewhere in the move from writing code to leading the people who write it, the job quietly changed from solving problems to building the people who solve them.
Architecture is a teaching tool, not a trophy
Eight-plus years of architecture experience taught me that the best architecture decision is often the one your team actually understands. A clever SOA or microservices design that only the architect can reason about is a liability waiting to happen. I'd rather ship a slightly simpler system that every engineer can extend confidently than an elegant one that creates a single point of human failure.
So I treat architecture reviews as teaching moments. The diagram is the excuse; the real output is a team that now thinks one level deeper about scalability and high availability than they did last quarter.
Mentorship compounds in a way features don't
A feature ships and eventually gets rewritten. An engineer you helped grow goes on to mentor three more. Over twenty years, the work I'm proudest of isn't a particular release, it's the people who started on my teams unsure of themselves and left able to own systems end-to-end.
Coaching isn't a soft add-on to the technical work. In a domain as deep as telecom, where it takes years to really understand FCAPS, OSS/BSS, and the protocol stack, growing people *is* the technical strategy.
Aligning technology with business is a translation job
Sitting between architects, business stakeholders, and clients, my job is to make sure the technology we build actually serves the outcome someone is paying for. Engineers optimize for correctness, business optimizes for delivery and value, and someone has to hold both in the same conversation.
That means saying no to gold-plating, yes to the unglamorous reliability work, and being honest about trade-offs in language each side understands. The roadmap only feels calm when everyone agrees on the why.
What I keep coming back to
Delivery, mentorship, and architecture aren't three jobs, they're one job seen from three angles. Build systems that scale, build teams that grow, and keep technology pointed at the outcomes that matter. After two decades, that's still the work, and I'm still not bored.
Narendra skipped presentations and built real AI products.
Narendra Billakanti was part of the April 2026 cohort at Curious PM, alongside 18 other talented participants.