From Chaos to Clarity: Lessons from Leading Diverse Tech Teams as a First-Time Tech Lead

When your team is learning, you lead by doing first—and explaining right after...

Introduction: Wearing Many Hats

Stepping into the role of a Tech Lead is a rewarding milestone. But no one tells you how tough it gets when you’re juggling multiple teams across domains you’re still mastering yourself.

In my last role, I was entrusted with leading three diverse engineering teams:

1. A DevOps team deploying CI/CD infrastructure on cloud for European and North American automotive OEM . This team was also responsible for web app development and deployment for internal as well as customer facing applications.

2. A tool development team building proprietary tool for automotive domain to simplify the integration, test generation and system testing.

3. A PoC team experimenting with wide variety of techs including Adaptive AUTOSAR on QEMU and Raspberry pi.

   
   

Each area came with unique challenges—and none of my engineers had substantial prior experience. Most were fresh graduates or new to software development. While I had to rapidly upskill in unfamiliar tech stacks like Flask, Docker, Kubernetes, and Adaptive AUTOSAR, I was also the one guiding, mentoring, and delivering under customer pressure.

The Early Challenges: Overwhelmed but Accountable

Those first few months were anything but smooth. We couldn’t show any tangible progress for two to three sprints. My boss began asking tough questions. I felt embarrassment creep in. It wasn’t that the team wasn’t working—it was that we were all climbing the learning curve together. I was responsible for delivery, training, architecture, and firefighting at the same time.

There were nights I sat alone debugging logs and Flask apps, only to coach a teammate the next morning on writing their first Python function.

Below are few core challenges:

• DevOps team lacked web/backend experience, yet had to deploy a CI/CD solution for OEM using Jenkins/GitHub, along with understand how Flask work, and stich working solution and deploy it on Kubernetes cluster using Docker container.

• Tools developers had limited exposure to diagnostics or AUTOSAR and requirements were unclear but needed to deliver tools using Python, CAPL, and C. To make matter worst, existing project repository was mess, full of defects, and with non existent code quality and testing.

• Adaptive team was exploring QEMU and Adaptive AUTOSAR with C++, with little past exposure to POSIX or memory-managed environments.

  
  

And then there was me—learning everything one night and mentoring team it the next day.

You can’t delegate what you don’t understand. So I learned it all—CI/CD, AUTOSAR, Kubernetes.

Learn → Teach → Delegate: The Loop That Saved Us

I adopted a loop that became my mantra:

• Learn fast: I immersed myself in documentation, online courses, and trial-and-error deployments. I spent countless evenings watching videos on Youtube, Udemy about DevOps topics like CI/CD, Docker and Kubernetes, and web development.

• Simplify and teach: I’d break down the essence of what I learned and create mini crash courses, cheat sheets, and walkthroughs. I still remember scheduling few weeks OOPs and python programming session for whole team to ensure core concepts are clear to each and every developer of the team.

• Delegate smartly: I assigned tasks not by complexity, but by learning value—making juniors take ownership, not just orders. For example, EC2, VPC and other cloud based services were assigned to few engineers who will be primarily responsible of those topics but another set engineer will also ensure they know sufficient enough to full fill the same responsibility in case primary owner is absent. Once the engineer mastered assigned tech area, they are encouraged to pickup next topic.

• Prioritize, prioritize, prioritize: I've learned this lesson after few burnouts. Only after my boss taught me that not all projects you handle have same priority and impact. As client facing projects was facing delays, I started logging time spent on each project every day. After analyzing the data, I've tweaked my calendar and delegated task to ensure high priority/impact projects get more attention.

Pic: Field Marshal Sam Manekshaw

For example, in projects I created a lightweight CI pipeline that enforced code reviews, linting, and test execution to overcome lack of senior engineers in my team to enforce better code quality—allowing us to catch bugs early while subtly mentoring the team on quality expectations.

We also held short, focused internal reviews where juniors could demo even the smallest progress. That brought confidence, accountability, and curiosity.

The Turning Point: From Blank Screens to Deliverables

One key milestone stands out. Our tools development team delivered a demo to an OEM client that generated diagnostic functional test suite for HiL (Hardware in Loop) setup in 10–20 minutes, a process that typically took engineers weeks to do manually. The client was delighted, and that demo turned the tide in terms of both morale and credibility.

The DevOps team, once struggling with Kubernetes and webhooks, was now running full deployments using Jenkins pipelines on cloud with auto scaling to balance the incoming traffic. Even the Adaptive team was simulating PoC workflows on hardware —something they weren't confident six months earlier. From there, momentum built on its own.

Managing Time, People, and Self

With three teams, customers, and shifting priorities, I had to build a discipline for:

• Time blocking: I used simple calendar based event blocking, excel sheet and few productivity tools to track team status, personal learning goals, and meetings.

• Context switching: Switching from Jenkins debugging to AUTOSAR diag issues needed mental reset techniques—quick walk, short notes, or visual outlines.

• Setting boundaries (which I often failed): I overworked, especially in the first 6 -8 months. Customer-facing pressure combined with slow junior ramp-up meant I spent nights learning and weekends building PoCs.

  
  

Every demo or release day felt like a battle—full of unknowns, last-minute bugs, and fear of failure.

Lessons Learned: Leading Is About People

Here’s what I’ve learned, and what I’d tell any new tech lead:

• Start with trust, not pressure: Juniors blossom with belief and guidance, not commands.

• Own the learning curve: If you expect your team to grow, you have to grow twice as fast.

• Structure beats speed: Build repeatable systems—CI, templates, scripts—to buy peace of mind.

• Celebrate the small wins: Whether it's a successful webhook or an internal demo, highlight every milestone.

  
  

And most importantly:

You can’t lead if you’re running on empty. Take care of yourself—mentally, physically, emotionally.

Conclusion: You're Not Alone

Leading multiple teams in diverse domains—especially when you’re learning and teaching simultaneously—is one of the most humbling leadership experiences. It requires resilience, empathy, and relentless self-growth.

If you're in a similar boat—burning the candle at both ends to make it work—know this: You're not alone, and your efforts are planting seeds that will grow in ways you can't yet see. In this journey, I've relied on a few books, and the notable mentions are:

Extreme Ownership: How U.S. Navy SEALs Lead and Win by Jocko Willink and Leif Babin

The 7 Habits of Highly Effective People by Stephen Covey

The Mythical Man-Month by Fred Brooks

Deep Work by Cal Newport

Ramayana and Mahabharat Unravelled series by Ami Ganatra

Have thoughts or similar experiences? I’d love to hear from you—drop a comment or connect on LinkedIn.