Before we dive into my year of managerial (mis)adventures, let me give you a quick tour of my tech journey so far. Picture a fresh-faced computer science grad, mid 2010s, armed with nothing but macbook air, barely a degree and an unhealthy but strong addiction to both sugar and coffee. That was me, ready to conquer the world one line of code at a time.
Fast forward through a decade of web development, where I became fluent in building stuff with Ruby and JavaScript. Maybe more like fluent in debugging my own mistakes - e.g., I pushed x || true to production and didn’t get fired. This is fine.
Other highlights include systems I’ve architected and built that could handle millions of users, and survived countless production fires. I also mastered the art of explaining technical debt to non-technical folks (hint: it’s the hand-waving and metaphors). I’ve worked at scrappy startups, and at tech giants, but as it turns out, all that coding prowess was just the prelude to my biggest challenge yet: learning to manage people instead of database indices.
Introduction
One year ago, I traded in my comfortable backend engineer hoodie for a shiny new “engineering manager” hat. Okay, there wasn’t actually a hat, but the transition was just as dramatic. After years of cozying up in the zen backend of almost poetic Ruby classes, I suddenly found myself leading a team of frontend ninjas. Talk about a plot twist!
So, grab your favorite caffeinated beverage, and let’s explore the unexpected lessons I’ve learned during this year-and-a-bit-long adventure.
Delegation and Ownership: The Art of Letting Go Without Letting it All Fall Apart
Remember when you used to solve all the problems by furiously typing code until the early morning hours? Ah, those were the days (or all-nighters). But as a manager, I quickly learned that approach is about as effective as trying to put out a fire with my kid’s water pistol.
Meet Sir David Brailsford, Manchester United’s new director. No, he’s not helping me write this post, but his words about ownership hit me harder than a second Red Bull at 2 AM before a morning math exam: “We respond better and perform better with a little bit more ownership.”
The Pitfall of Depth-First Leadership
At first, I fell into the classic trap of depth-first leadership. It’s like trying to play every instrument in the orchestra yourself – you might make some noise, but it’s not going to be a symphony.
Here’s what happens when you try to be the superhero coder-manager:
- You become the bottleneck
- Team output takes a nosedive
- You burn out
Turns out, they need you to, you know, manage a few other things.
The Power of Effective Delegation
As an EM to avoid turning into a coffee-fueled zombie, I had to learn the art of delegation. Here’s my approach. I used what we called the “Feature Leader” framework. Instead of limiting the breaking down of all tasks to only the EM and PM, assign an engineer from the team to take on the responsibility of clarifying and breaking down the project in meaningful dev tasks. Product Manager still brings in the requirements, Engineering Manager is still accountable for the team’s output, and the whole team contributes to the project, but the responsibilities of the Feature Leader drive great ownership and improve clarity. This allows the team to move confidently through busy schedules and tight deadlines.
Who should be a “Feature Lead”? Although senior engineers are usually assigned to the high stakes deliverables, there’s always a project for everyone - including the junior engineers, the QAs and especially yourself - the EM. Create an automated dashboard to visualize who is assigned to each project and how they fit in the timeline or roadmap. I almost always asked for volunteers, but you need to make sure there’s a fair distribution of the efforts and limited context switching in the team.
- Recognize everyone’s superpowers and weaknesses. Especially yours.
- Build trust by being open about the what, why, and how. Overcommunicate like your team’s success depends on it. Because it does. When you mess up (and you will), own it quickly and learn from it.
- Cultivate a Garden of Growth: Create an environment where ideas and people flourish. Listen more than you speak. Be open to perspectives that challenge your own. Encourage calculated risks and celebrate the lessons learned from failures.
Shifting Focus: From Output to Outcome
In the tech world, it’s easy to get obsessed with metrics. Story points, tickets closed, lines of code written (just kidding, we don’t do that anymore, right? Right??). But I learned that most of the time, we need to look beyond the numbers, as they are mere reflections of the actual impact of the work.
The Outcome-Oriented Approach (Or: Asking the Real Questions)
Instead of just counting widgets, start asking the juicy questions:
- Did our work actually make a difference, or are we just digital hamsters on a wheel?
- Are we moving the needle, or just poking it repeatedly?
- How does our work fit into the big picture? “It pays the bills” isn’t the answer we’re looking for.
The Art of Communication: Informational vs. Transformational
Now, let me tell you a story about the time I discovered the power of transformational communication. Picture this: it’s a gloomy Thursday afternoon, and I’m about to kick off our team’s retrospective. I could feel the enthusiasm in the room… or was that just the hum of the air conditioner?
I started with my usual informational intro: “Alright team, we had a great sprint: we achieved the sprint goals and delivered the deliverables as promised in this timeline. What do you think?”
The response? Crickets. And not the excited, “we’re so thrilled we’re speechless” kind of crickets. More like the “is it time for coffee yet?” kind.
That’s when I realized I needed to switch gears. I took a deep breath, channeled my inner Steve Jobs (minus the turtleneck), and tried again:
“Imagine we’re not just building a new landing page. We’re crafting the future of how we work together. This Jira dashboard isn’t just about meeting the deadlines – it’s about pushing boundaries, challenging ourselves, and creating something that will make users’ lives better and maybe even a little more magical. What’s stopping us from getting there?”
Suddenly, the energy in the (zoom) room shifted. Eyes lit up. People started asking questions, offering ideas. It was like I’d flipped a switch from “meh” to “mission accepted!”
Informational Communication
This style is great for:
- Routine tasks (like reminding everyone about the latest survey)
- Short-term objectives (deploy the feature in the morning EU time zone or maybe US)
- Clear directives (please, for the love of all that is holy, label your tickets)
It’s the Slack message. The meeting that could have been an email. Efficient? Yes. Inspiring? About as much as a tax form.
Transformational Communication
This is where the magic happens. As a transformational communicator, you’re not just passing along info – you’re painting a vision, igniting passion, and maybe even causing a few goosebumps. You’re aiming to:
- Paint a future so bright, everyone needs shades
- Connect the team’s work to the big picture
- Encourage thinking so far outside the box, the box is just a dot on the horizon
- Tap into what makes people tick (besides caffeine)
Finding the Right Balance
The key is knowing when to sharpen your logical Spock ears and when to channel your inspirational Captain Kirk. Use informational communication for the day-to-day stuff, and break out the transformational communication when you need to rally the troops, spark innovation, or navigate through the asteroid fields of major changes.
Boosting Team Productivity
As EM your main responsibility should be supporting a healthy team of engineers. Improving just a few areas of their work life will change your team’s productivity dramatically. Improve the productivity boosters and fix the offenders. It’s that simple, really.
- Recognize and limit context switching in the team. Can you move your 1:1s closer to the daily? This will leave your engineers with longer uninterrupted time slots in their “maker schedule”.
- Find the right dynamic between Product Engineering and Design that works for your team - e.g. the Feature Leading described above.
- Make meetings shorter and more effective by having agendas and respecting the time slot allocated. Team meetings longer than 15-30 minutes should be an exception.
- Make the release process as smooth as possible. Is CI unstable? Are E2E tests too slow? Both engineers and stakeholders will benefit from quicker deployments.
Conclusion
This year has been a wild ride, full of surprises, challenges, and more lessons than a semester of Linear Algebra. The leap from backend engineer to engineering manager has stretched me in ways I never expected—it turns out that people are sometimes a lot harder to debug than code!
But you know what? It’s been incredible. By learning to delegate effectively, focus on outcomes, and communicate like a boss (pun absolutely intended), I’ve discovered a whole new way to make an impact. A year after I started implementing the steps outlined in this post, the team output increased, team members grew stronger together, communicated more confidently and collaborated more actively than ever.
So, whether you’re thinking about making the leap to management or you’re already in the thick of it, remember that great engineering management isn’t just about technical know-how. It’s about empowering your team, focusing on what really matters, and sometimes, finding just the right emoji to express your thoughts and feelings in Slack.
So to everyone on the journey ahead — may your meetings be short, your coffee be strong, and your impact be even stronger.
Now, if you’ll excuse me, I have some transformational communicating to do. Has anyone seen my hat?