Being Technical as an Engineering Manager: Evolving Beyond the Code

March 8, 2025
Written By Rahul Suresh

Senior AI/ML and Software Leader | Startup Advisor | Inventor | Author | ex-Amazon, ex-Qualcomm

Explore how engineering and research managers can stay technical, drive innovation, lead teams effectively, and balance coding with strategic leadership.

“How do I stay technical when I’m not writing code anymore?” This was the question that kept coming back to me in 2019 at Amazon, when I began my transition to Engineering Manager (Software Development Manager (SDM) in Amazon). Like many software developers stepping into management, I worried about losing the technical edge I’d spent years building. These questions come up often in my conversations with engineers considering the management path, as we all grapple with how our role and value evolve in leadership positions.

I started reaching out to engineering leaders I admired, seeking their guidance. Through conversations with mentors and peers, a clear pattern emerged: successful engineering managers maintained their technical edge, but not by writing code daily. This insight shifted my perspective on what being ‘technical’ actually means in a leadership role.

Technical Leadership: Why It Matters

Your success as an Engineering or Research/Applied-Science Manager fundamentally rests on two pillars: empathetic leadership and strong technical acumen. Let’s be clear about why staying technical matters:

  • You earn credibility with your engineers and scientists, enabling you to coach them effectively
  • You can make informed technical or architectural decisions and understand their long-term implications
  • You become the bridge between product, business, and tech teams
  • You build more realistic technical roadmaps and identify valuable strategic investments
  • You better support your team during critical technical discussions and challenges
  • You avoid costly technical missteps that could impact business timelines
  • You identify innovation opportunities that can accelerate business growth

For example, understanding the performance implications of different ML model architectures might help you guide your team toward a solution that balances accuracy with latency, directly improving customer experience and business metrics. Or, recognizing the maintenance costs of a particular technology choice might help you avoid technical decisions that would slow down feature delivery in the future.

Building on Your Technical Foundation

The technical depth and breadth I built as a software engineer became my greatest asset as a manager. It meant I could jump in when a team member was stuck with a deployment pipeline, contribute meaningfully to architectural discussions with senior engineers, and understand the real challenges my team faced. These moments of technical connection helped me build trust and rapport far more effectively than any management framework could.

Yet, your learning and growth shouldn’t freeze when you transition to management. On the contrary, your technical skills, knowledge, and judgment should become broader as you step into larger leadership roles. As you become responsible for more complex charters and larger architectures, your organization’s work will make a bigger impact on the business. This evolution demands a different kind of technical acumen- one that builds upon your hands-on experience while expanding to encompass wider technical and business perspectives.

Leading Your First Team

A front-line engineering manager operates at a technical level comparable to a seasoned Tech Lead or Senior/Staff Engineer. At this stage, your focus should be on understanding your team’s technology stack deeply enough to guide architectural decisions and support your engineers’ growth. While you won’t be writing production code regularly, you need to maintain enough technical depth to:

  • Guide system design discussions and architectural reviews effectively
  • Help your team evaluate technical trade-offs and make informed decisions
  • Partner effectively with Product Managers on technical feasibility and trade-offs
  • Represent your team’s technical decisions in leadership discussions
  • Support resource planning and technical roadmap development
  • Understand the implications of technical debt and when to prioritize addressing it
  • Mentor engineers across different experience levels

For example, if your team is scaling microservices, you should understand container orchestration and service mesh patterns well enough to evaluate proposals about deployment strategies and service-to-service communication. For teams launching ML features in production, you need to understand model serving architectures and performance optimization techniques to guide discussions about batch vs. real-time inference.

In my first three years as an Engineering Manager at Amazon, when I was a front-line manager, I had to manage and deliver complex architectures and steer my team through ambiguities. This meant staying current with our frameworks and maintaining enough technical context to ask meaningful questions in design reviews. The key was finding the right balance: being technically engaged enough to provide valuable guidance while giving the team space to own implementation decisions. Even when I didn’t have immediate answers, I focused on learning quickly and using my experience to help the team navigate technical challenges.

Staying Technical as Your Scope Expands

As you progress to managing multiple teams or departments, your technical leadership takes on a broader scope. At this level, you need to develop and articulate technical vision across multiple domains, identify strategic technical investments that drive organizational efficiency, and balance innovation with stability across your technology portfolio. Your role becomes less about specific implementation details and more about guiding architectural decisions that affect multiple teams while fostering technical excellence across your organization.

The challenge at this level isn’t just technical understanding. It’s about seeing how different systems work together. For instance, when evaluating a new ML feature, you need to consider not just the model accuracy, but also how it affects the entire stack: from data pipeline latency to API response times to front-end performance on different devices.

In 2021, when I expanded to overseeing multiple teams spanning core applied science research, ML engineering, backend services, and frontend development in Amazon’s Beauty Tech organization, my technical focus evolved dramatically. Instead of diving into specific codebases and focusing on my team’s technical stack and architecture, I found myself evaluating how end-to-end systems and multiple complex systems interacted with each other, spanning wide domains to include ML and data pipelines, real-time inference engines, on-device compute engines, and customer-facing features.

Be Authentic : It’s OK Not to Know Everything

Credibility is paramount, but it doesn’t mean pretending to be an expert in everything. People see through false expertise immediately. As a manager, you’re not expected to be an expert in every domain and every stack! You need to demonstrate broad architectural understanding, preferably with your own areas of depth.

In areas where you lack depth (remember: no individual contributor is an expert in all domains either!), humility and openness to learning from your team and peers are crucial. I’ve learned to be transparent about my strengths and limitations. For instance, while I have extensive experience with ML systems and core backend engineering, I’ve never been a frontend developer, and my UX development skills, especially regarding visual aspects of customer experience, critical for our organization, are admittedly weak. My team often jokes about this, but I’m comfortable relying on the expert eyes of our UX/product partners and the talented frontend engineers on my team.

Building a New Kind of Technical Excellence

The transition from hands-on engineering to engineering management doesn’t mean leaving your technical identity behind. Instead, it means evolving how you engage with technology. Your value comes not from writing the best code, but from understanding how technology choices impact your team, your products, and your organization’s future.

I’ve found that maintaining technical acumen as a manager requires intentional effort and a shift in mindset. Technology never stands still, and neither should your learning! Stay curious by diving into fascinating research papers. Be the first to try exciting new AI tools. Jump into hackathons with your team. Write code just for the fun of it! This journey of lifelong learning helps you guide your team with both wisdom and excitement for what’s possible!

I’m excited to share more in my next article! I’ll walk through the strategies I’ve developed for staying technically sharp while leading multiple teams. From practical approaches to architectural reviews, to carving out focused learning time, to knowing exactly when to dive deep, we’ll explore more! Stay tuned!

About the article

Disclaimer

The views and opinions expressed in my articles are my own and do not represent those of my current or past employers, or any other affiliations.

Publication Note:

This article was originally published on my Medium publication on Dec 14, 2024. I’ve republished it here as part of my ongoing effort to centralize my insights on themlarchitect.com, providing readers with a comprehensive collection of resources on AI, system design, leadership, and more.

For the original post and additional context, please visit the original article.


Discover more from The ML Architect

Subscribe to get the latest posts sent to your email.

5 thoughts on “Being Technical as an Engineering Manager: Evolving Beyond the Code”

Leave a Reply

Discover more from The ML Architect

Subscribe now to keep reading and get access to the full archive.

Continue reading