Mentoring Engineers and Leading a Team of Ten

Earlier this year, I was asked to lead an infrastructure engineering team of ten at a major entertainment company. I had been an individual contributor for my entire career up to that point, and the transition from "person who writes code and designs systems" to "person who builds and leads a team" has been the most challenging and rewarding experience of my professional life.

I want to share what I have learned, not as prescriptive advice, but as honest reflection from someone still figuring it out.

The Transition

The first thing that changes when you become a team lead is your relationship with code. As an IC, your output is measured by the systems you build. As a lead, your output is measured by the systems your team builds. This sounds like a trivial distinction. It is not.

In my first month, I kept writing code at the same pace I had been. I reviewed every pull request in detail and jumped into debugging sessions because I was faster. I was doing the work of a senior IC while nominally holding a leadership role.

My manager pulled me aside after about six weeks. "Your team does not need another engineer," she said. "They need a leader. Those are different jobs."

She was right. By continuing to write code at my previous pace, I was bottlenecking my team. They deferred to my technical opinions instead of developing their own and did not take ownership of architectural decisions because I was always there to make them.

I had to learn to step back. Harder than it sounds for someone who derives professional identity from technical competence.

What Leadership Actually Means

After a year of learning (mostly through mistakes), here is my working definition of what engineering leadership means in practice.

Creating Context

Most engineers work hard. The difference between a productive team and an unproductive one is usually not effort; it is context. Do your engineers understand why they are building what they are building? Do they know how their work connects to the company's strategic objectives? Do they have enough information to make good technical decisions independently?

I spend a significant portion of my time translating business context into engineering context. When a product team asks for a new API, I explain who the consumers are, what the traffic patterns look like, and why the timeline matters. This context enables engineers to make better design decisions than they would from a spec alone.

Removing Obstacles

A team lead's job includes identifying and eliminating the things that prevent engineers from doing their best work. These are rarely technical problems. They are organizational friction: unclear requirements, slow approval processes, missing access, unmanaged inter-team dependencies.

I keep a running list of obstacles my team faces and review it weekly. The goal is to ensure that when an engineer sits down to write code, the path from their keyboard to production has as few unnecessary obstacles as possible.

Setting Technical Direction

This is the part of leadership that feels most natural to me. Someone needs to decide the team's technical strategy: which technologies we adopt, which we retire, how our systems integrate with the broader architecture, and where we invest in reducing technical debt.

The key insight is that good technical direction is not about making every decision. It is about making the decisions that need consistency and delegating the rest. I decide that we use Terraform for infrastructure provisioning (consistency matters) but let individual engineers choose their text editor (consistency does not matter).

The framework: if a decision affects other teams or production reliability, I make it or approve it. If it is local to one engineer's work, they make it.

Mentoring Philosophy

I now spend four to six hours per week in one-on-one mentoring sessions with my engineers. This is a significant time investment, and I guard it carefully. Here is how I approach mentoring.

Meet People Where They Are

My team spans a wide range of experience: from a junior engineer six months out of college to a senior engineer with fifteen years of experience. Mentoring is not one-size-fits-all.

For junior engineers, mentoring is largely about building foundational skills and confidence. I pair-program with them, not to write code faster, but to narrate my thought process. "I am looking at this error message and the first thing I check is X, because in my experience, Y is the most common cause." I am teaching diagnostic frameworks, not just solutions.

For mid-level engineers, mentoring is about broadening scope. They can write solid code; now they need system design, cross-team collaboration, and technical communication. I assign them stretch tasks: leading a design review, writing a technical RFC, presenting to stakeholders outside engineering.

For senior engineers, mentoring is about career strategy and organizational influence. How do you advocate for a technical initiative? How do you build consensus across teams? These are leadership skills that require a different kind of mentoring.

Ask Questions, Do Not Give Answers

When an engineer comes to me with a problem, my instinct is to solve it. But solving the problem for them robs them of the learning experience.

Instead, I ask questions. "What have you tried? What does the error message tell you? What would your next step be without any help?" More often than not, the engineer arrives at the solution through this process, and they remember it because they discovered it themselves.

This is slower in the short term and faster in the long term.

Provide Direct Feedback

Honest feedback is the most valuable thing a mentor can offer, and it is the thing most mentors avoid because it is uncomfortable.

I have a simple framework: if I notice something an engineer should improve, I tell them directly within 48 hours. Not in a performance review six months later. Not through hints or passive suggestions. Directly, specifically, and privately.

Direct feedback, delivered with respect and specificity, is a gift. It gives people information they can act on immediately. Withholding feedback to avoid discomfort is not kindness; it is negligence.

Building Team Culture

Culture is not ping-pong tables and free snacks. Culture is the set of implicit norms that govern how people behave when no one is explicitly telling them what to do.

The norms I try to establish:

Blameless incident reviews. When something breaks in production, we analyze the failure mode, not the person. This creates an environment where people report problems quickly instead of hiding them.

Written communication. I require design documents for any non-trivial change. Not because I enjoy reading documents, but because writing forces clarity of thought. An engineer who cannot explain their design in writing does not fully understand their design. The document also creates a record that future team members can reference.

Knowledge sharing. Every other week, one team member presents a technical topic to the rest of the team. The goal is to distribute knowledge across the team so that no single person is a bottleneck.

Sustainable pace. I actively discourage working nights and weekends except during genuine emergencies. Tired engineers make mistakes. A well-rested team that works focused eight-hour days produces better outcomes than an exhausted team that works twelve-hour days.

What I Got Wrong

I want to be honest about my mistakes, because they have been more instructive than my successes.

I waited too long to have a difficult conversation with an underperforming team member. I convinced myself the issue would resolve on its own. It did not. By the time I addressed it directly, the rest of the team had noticed the performance gap and resented both the team member and me for not acting sooner.

I over-indexed on technical skills when hiring and under-indexed on communication skills. I now weight communication skills equally with technical skills in interviews.

I tried to shield my team from organizational politics, thinking I was protecting them. Instead, I deprived them of context they needed to understand why priorities shifted. Transparency, within appropriate bounds, builds trust; opacity breeds cynicism.

The Reward

Despite the challenges, leading a team of engineers is deeply satisfying. Watching a junior engineer grow into someone who designs systems confidently. Seeing a team ship a complex project because they trust each other. Knowing that the infrastructure we build enables products that millions of people use.

The transition from IC to leader is not a promotion. It is a career change. You need new skills: patience, communication, delegation, and the ability to find satisfaction in other people's success. I am still learning, but a year in, I can say with confidence that this is the right path for me.