This page was translated from the original by AI.
Three months ago, I wrote a post about my upcoming promotion to Engineering Manager. Back then, I was equal parts excited and anxious, and I made a list of preparations: read management books, create a team snapshot, write handover docs.
Now that three months have passed, looking back at that post, some of it was genuinely useful, and some of it was…
Two brand-new projects
The biggest change after the promotion wasn't "no longer writing code"—though that did take some getting used to—but rather that I took on two projects I'd had zero exposure to before.
Note, it's not the tech stack that's unfamiliar. On the technical side, I still feel confident. What really made me uneasy was the business domain. As a Team Leader, I knew my projects inside out—the backstory of every feature, the context behind every historical decision. Now, facing two new projects, I'm the person in the room who understands the business the least.
It's a strange feeling. You're the team's Manager, but your understanding of what they do every day might be worse than a developer who joined three months ago.
My unglamorous approach
There's no sophisticated methodology here. What I did was pretty plain:
Show up to daily standups. Not the kind where you're just going through the motions, but actually listening to what everyone says. When something unfamiliar comes up, I'd go read up on it afterward.
Read Jira. It sounds boring, but it works. By looking at everyone's assignments and progress, I could gradually piece together the full picture of the projects: what features are being built, what issues keep recurring, who owns what. Jira won't tell you everything, but it's a decent starting point.
Ask people. When I hit an unfamiliar business question, I'd go directly to colleagues who knew these projects well. It sounds simple, but it takes a bit of courage—after all, you're the Manager, and admitting "I don't know" always gives you a moment's hesitation. But I quickly found that most people are happy to explain, and they view it positively when you take the initiative to understand.
None of these methods are cool, and none of them came from a management book. But they work.
Priorities: the biggest challenge
If you ask me what was hardest about these three months, it wasn't adjusting to the new role, and it wasn't not writing code. It was making priority calls with incomplete information.
The two new projects being top priority was clear. But not all my team members are on those projects—there are other tasks and projects that need attention. The problem is, for work I don't yet understand well, it's hard to judge how urgent or important it is.
My current approach: when I'm unsure about something, I first gather background information, then make a call. It sounds obvious, but in practice, there's always pressure to give an answer on the spot. Learning to say "let me look into it and get back to you" has been one of the key skills I picked up these three months.
Management books: an honest take
Before the promotion, I read *Become an Effective Software Engineering Manager* cover to cover. That book did give me some frameworks and concepts, giving me a starting point when I had zero experience.
But after finishing it, I didn't go looking for the next management book.
It's not that I think I don't need to learn anymore. I just found a method that suits me better: when a specific problem comes up, I ask AI directly. For example, "what should I watch out for in a first performance review" or "how do I handle disagreements between team members"—for these concrete, situational questions, AI gives highly targeted advice, way more efficient than reading a whole book.
The value of books is in building a foundational framework, and I've already done that step. What follows is more about encountering problems in practice and solving them. Of course, if I come across a book that fits a current need particularly well, I'll still read it—I just no longer feel anxious about the idea that "I should be reading more management books."
Lately, I've actually been reading *Our Hakone Ekiden*. A book about a relay race—how teams coordinate, how they push through under pressure, how they pass the baton well. I didn't deliberately go looking for management insights, but while reading, I occasionally think: yeah, isn't this exactly what I do every day.
Three-month summary
If I had to sum up these three months in one sentence, it'd be something like: the hardest part of management isn't managing itself—it's keeping moving forward amid uncertainty.
Unsure if my understanding of the business is correct, unsure if my priority calls are sound, unsure if my "let me look into it" comes across to the team as indecisive.
But after three months, I've confirmed at least one thing: admitting you don't know and honestly going to learn is far better than pretending you know everything. A team doesn't need an all-knowing Manager. They need someone who's willing to understand their work.
The road is still long. For the next three months, I hope to move from "understanding the business" to "making judgments with more confidence."
I'll write another post then.
- * *
This is the second entry in my Engineering Manager journey. The first one covered my feelings and preparations before the promotion—if you're also considering moving from development to management, that post might give you some useful reference.
Loading comments…