Slide 1 — What No One Tells You About Becoming an Engineering Manager

When I first became an engineering manager, I expected it to be a natural step forward in my technical career. But after my first six months — right after all the onboarding — I opened my laptop and saw a calendar packed with meetings and zero time for coding. That moment made me realize something fundamental: becoming an engineering manager isn’t a promotion, it’s a completely different job. No one really prepares you for the emotional shift, the loss of hands-on coding, or the new responsibilities that suddenly land on your plate. That’s why I want to talk about the truths nobody tells you before you step into this role.

Slide 2 — From Engineer to Manager

My journey started as a senior software engineer and later a Tech Lead. I loved solving technical problems — migrations, complex features, code reviews — that was my comfort zone. But then I discovered how decisions were made: projects being moved across countries, budget discussions, strategic choices. I realized there were conversations happening in rooms I wasn’t part of. It felt like there was a hidden layer of the company I didn’t have access to. That’s when it hit me: managers don’t just deal with features — they participate in strategy, business conversations, and decisions that shape the company. And that’s what pulled me toward management.

Slide 3 — Jumping into Management

When I chose to become an Engineering Manager, I believed I was prepared. I read the books, I read the articles, and I told myself: “It’s just like being a Tech Lead… but with more influence.” The reality was nothing like that. Once I onboarded, I was suddenly responsible for people — their work, their growth, their performance. My first instinct during 1:1s was to talk about code, but I quickly learned that my job wasn’t about coding anymore. My job was to focus on people and to take accountability for outcomes, even if I didn’t write a single line of code. That was my first major truth: management is about people, not code.

Slide 4 — My First Days…

My early days were all about building relationships and understanding the team. I introduced myself properly, set up regular 1:1s with everyone, and created private notes so I could remember their goals and challenges. I also started meeting my own manager regularly to align on expectations. Most importantly, I took time to understand the true state of the team — their strengths, problems, and ongoing work — before trying to change anything. These simple steps created the foundation for trust and clarity during my early months.

Slide 5 — Managerial Activities…

As a new manager, there are a few essential activities you quickly learn to master. You’re constantly gathering information from conversations, dashboards, and feedback to understand what’s really happening. You’re making decisions, sometimes small, sometimes huge, and you need to own them. You’re also influencing even when you’re not the final decision-maker — nudging people and discussions in the right direction. And throughout it all, you must lead by example, because people learn as much from your behavior as from your instructions. These are the core muscles of management.

Slide 6 — The Feedback Dilemma

One of my earliest challenges was giving difficult feedback. I had a senior engineer who was underperforming, and I was afraid to hurt his feelings. But avoiding the truth only made things worse. That’s when I learned an important lesson: empathy is not about avoiding hard conversations — it’s about being honest, transparent, and then helping the person improve. Real leadership means telling the truth kindly and working together on the solution.

Slide 7 — What Nobody Told You About Performance Metrics

Performance is changing dramatically in the age of AI. Traditional engineering metrics — lines of code, number of PRs, story points — don’t make sense when AI can generate huge amounts of code in minutes. What really matters now is: impact, engineering health, and team experience. Are we delivering meaningful outcomes? Is our codebase healthy? Is the team empowered or frustrated by the AI tools they use? Faster output doesn’t always mean better performance. As managers, we must redefine what we measure and make sure our metrics truly reflect value in this new era.

Slide 8 — You’re a Translator Between Worlds

As an Engineering Manager, you often stand between two very different worlds: technical teams who think in detail, and business stakeholders who want clarity and fast decisions. You become the translator — the bridge that converts complexity into business language and turns business needs into actionable technical work. It’s not always easy; sometimes it feels like you’re interpreting two alien dialects. But the key is to communicate honestly, clarify misunderstandings, and explain why technical decisions matter for the business.

Slide 9 — Processes Can Kill Innovation

When I first became a manager, I believed strong processes were the key to success. I built structured sprints, dashboards, and check-ins. But instead of helping, the structure slowly killed creativity — people stopped proposing new ideas. That’s when I realized that too much process suffocates innovation. Teams need freedom to explore, experiment, and even fail. So I introduced free exploration time, flexible goals, and a culture where trying new things was encouraged. Because innovation doesn’t come from strict systems — it comes from people who feel free to think creatively.

Slide 10 — Managing Up

I once faced a huge company project: migrating from one cloud provider to another with a strict deadline and no downtime allowed. It required fast delivery without burning out the team. That experience taught me that being a manager isn’t only about leading your team — it’s also about managing upwards. You must set expectations with leadership, communicate risks, negotiate timelines, and protect your team while still delivering. Managing up is just as important as managing down.

Slide 11 — You’re a Juggler, Not a Coder

As a manager, your calendar becomes a circus of meetings, 1:1s, planning sessions, interviews, escalations, and cross-team coordination. You suddenly feel less “productive” because you’re no longer producing code. But that’s because management is a different kind of work — it’s about clearing paths, connecting dots, and keeping the big picture moving. Much of your impact is invisible. The key is learning to balance your time, protect your team’s focus, and reserve moments for deep work when possible.

Slide 12 — Staying Technical

People often ask whether managers still code. The truth is: yes, but much less — maybe 20–30%. I still review code and join design discussions, but most of my time is focused on people and the system around them. At some point, I had to redefine success. It’s no longer about writing features myself; it’s about enabling my team to deliver their best work. As Jeff Atwood once said: “The best code is no code at all.” And as a manager, that becomes even more true.

Slide 13 — The Change

Every engineering manager faces moments of change: shifting priorities, stopping feature work, reorganizing teams, or letting go of certain products. What matters most is how you guide your team through that change. People can handle change if they understand the “why,” feel included in the process, and see a clear path forward. Good change management means communicating early, breaking big transitions into smaller steps, listening, and adjusting. Change isn’t easy, but it’s part of the job.

Slide 14 — What No One Tells You

There are parts of management people rarely talk about. Sometimes you’ll have to give very tough feedback or even let someone go. You’ll sometimes feel useless because you’re not coding anymore. You’ll doubt yourself more often than you expect. But this is all part of the journey. The key is to lead with empathy, create space for people to grow, and communicate with honesty and transparency. As a manager, you’re no longer the hero — your job is to make your team the heroes. Becoming an Engineering Manager isn’t the end of your technical path; it’s the beginning of a new journey where you build not just software, but people, teams, and trust.