I was very anxious when I first stepped into an engineering management role to lead a small development team. After years of working as a full-stack software developer, I was overseeing all technical aspects of a major client project. No pressure, right?

Although my technical skills were all right, I had no clue what I was getting into on the people management front. All those years head down in code made the soft skills side of things uncharted territory. Communication, delegation, mentoring — it sounded straightforward enough on paper.

My Transition To An Engineering Management

After working for years as a senior full-stack developer, I was presented with an exciting opportunity to lead the development of a client’s large new project. Although I hesitated about moving from a hands-on engineering role into management, I proposed building and managing a small team to tackle the project rather than trying to complete the extensive project solo.

Despite my previous technical experience, I struggled with self-doubt and imposter syndrome, given the increased responsibilities and stakes. The early stages involved a steep learning curve as I strived to let go of lower-level technical details and focus on higher-level leadership, communication, and oversight across the project.

Although I soaked up management books and blog posts, finding a mentor with experience relevant to my situation was challenging — leading a small but mission-critical engineering team over a multi-year engagement. Most available training and mentors targeted early startups or enterprise-level management, which neither matched my needs.

Over time, I learned lots of invaluable skills and experience by taking on project planning, stakeholder communication, resource allocation, and team mentoring. While the road had some bumps, the rewarding challenge of leading the project and the team made the transition worthwhile.

Becoming a First-Time Manager: A Bumpy Ride Worth Taking

Going from coder to manager of a small team was a total game-changer for me. I went from heads-down writing code all day to managing people, projects, and budgets. It was like a trial by fire.

The new role came with plenty of upsides. I was the one defining product roadmaps with stakeholders. I was talking to decision-makers about the technical direction of our work. And I loved mentoring the team and watching them level up their skills.

But wearing the manager hat meant a lot more pressure. Before, if I messed something up, I was the only one dealing with consequences. Now, I’m responsible for an entire team delivering complex work. No more passing bucks — the buck stops with me. I lose sleep worrying about resourcing, keeping projects on track, and drama among team members. I have to deal with way more social interactions, too, from higher-ups wanting progress reports to smoothing irritated team members not getting along. It’s pretty exhausting.

And even though I don’t touch code much daily, I still sweat it out because, in the end, my team’s work falls on my shoulders. Imposter syndrome is real, too, because I’m managing people with more technical expertise than I have now.

While still intimidating sometimes, I’m still glad I took the management leap. Constant growth brings growing pains, but seeing my team thrive is worth all the stress. This ride has a fair amount of bumps, but I wouldn’t trade it for going back to being an individual contributor.

Searching for My “Manager Tribe”

As I mentioned, finding useful material to read, mentors, and training felt like a lonely journey because most of the stuff I found was aimed at startups or corporate engineering managers — neither of which felt applicable. I was just a regular guy suddenly tasked with managing 15 developers to pull off some complex tech magic for a client under a tight deadline. I was flying blind for quite a while.

For some time, I was lost in this sea of management resources clearly written by and for people nothing like me. As I read page after page, I found it hard to relate as the authors recounted tales of leading four rockstar developers working all night to change the world or properly structuring hundreds of engineers working for titans of the tech world disrupting industries. Their worlds felt so foreign compared to my day-to-day worries about resourcing tasks, keeping spirits up, and delivering on time to a medium-sized client.

Many more managers are probably more like me than those high-profile extremes. We’re the silent majority leading project teams that keep the technical world spinning day-to-day.

Finding My Way Through Trial and Error

The transition wasn’t easy. When I first stepped into the management role, I felt like a fish out of water. My decade of engineering experience didn’t fully prepare me for the people skills and big-picture thinking needed to lead a team.

In the early months, I made some clumsy missteps around scheduling and communication that caused hiccups. For example, I gave the client an optimistic timeline estimate without consulting my team first. When we couldn’t meet the unrealistic deadline I set, I had to explain why and reset expectations.

Over time, I started relying on basic project management best practices to right the ship. But more importantly, I focused on building trust and mental safety within the team. I tried to balance empathy, accountability, and support to bring out the best in each person.

In the end, I can say that it all worked out well. The project we started years ago is still running, and our team delivered a successful product that still delivers a lot of value. The hands-on experience proved much more valuable than any generalized management tutorial or mentorship could have provided.

My journey from coder to leader was full of learning opportunities. I expanded my skills and discovered capacities I didn’t know I had — like maintaining grace under pressure. Navigating real-word challenges alongside my team was incredibly rewarding.


Originally published on Medium.com