A Practical Playbook for Software Engineers Stepping into Engineering Management
How to Enable Teams, Build Trust, and Still Ship Real Work
I recently got some thoughtful questions from Vibhor Vibhav about making the jump from software engineering IC to Engineering Manager.
These are the same questions almost every strong IC asks quietly… and then has to learn the answers publicly.
Here’s how I think about them.
🎯 Enabling the Team (Not Just Assigning Work)
"What are the top things a leader should do to truly enable their team? How do I ensure individuals stay motivated, goal-oriented, and take ownership beyond just completing tickets? How do you encourage people to go above and beyond?"
Start by building a culture of ownership not compliance.
Teams do their best work when they’re aligned to 1–3 clear OKRs and can see how their projects move those goals forward. If people don’t know why the work matters, motivation decays fast.
Then reinforce ownership publicly:
Money matters. So do growth, recognition, and bragging rights. Great managers use all of them intentionally.
🟥 Red flag: If your team only cares about closing tickets, you’ve built a delivery system not a team.
👀 Creating Visibility Without Wasting Engineering Time
"What frameworks or lightweight processes do you recommend for ensuring visibility? Also, what are some activities that may seem like a hindrance or a waste of engineering time (e.g., documentation, release notes — which I personally undervalued earlier) but are actually essential?"
Efficient visibility is not only dictated by the quality of the communication but also how difficult it is to generate. I haven't seen this expressed in an equation so I'll be humble and call it Kosowski's Law:
Efficient Visibility = Quality of Communication ÷ Effort to Expose It
A 1:1 has massive communication value but also a massive time cost.
Great documentation? Less context than a 1:1 but near-zero marginal effort with infinite reuse. That makes it extremely efficient for visibility.
As an EM, your job is to make visibility as close to free as possible for engineers:
If work exists but leadership can’t see it, it might as well not exist.
🟥 Red flag: If visibility depends on engineers “speaking up” your system is broken.
🧠 Managing vs. Micromanaging
"Managing vs. micromanaging: how do you draw that line in practice? And what outcome-focused metrics do you find most useful (e.g., number of tickets, story points, ageing, etc.)?"
This may be the hardest IC → EM transition.
ICs come from a world where one wrong line of code can break prod. But management requires letting go and trusting people instead of keystrokes.
The key is expectation-setting not control. Some environments do require managers to groom and size everything. In my experience, that caps high performers.
I prefer teams that size and groom their own work and use sprint retros as real learning tools not blame sessions.
Teams with constant sprint carryover aren’t unlucky. They’re bad at estimation. And estimation skill compounds.
🟥 Red flag: If retros feel defensive, the team will never improve.
🧩 Strategic vs. Tactical Decisions
Recommended by LinkedIn
"How do you differentiate between strategic and tactical decisions?"
Default to practical solutions until they stop working. Abstraction has killed far more startups than bad code.
When possible:
Strategy emerges from reality. Not diagrams.
🧠 Actively Supporting Team Wellbeing
"How do you actively ensure your team’s wellbeing?"
Ask then listen! This starts in 1:1s and scales through your managers as the org grows.
People want to be heard. They want to grow. That only happens through regular, intentional conversations and helping them take real action.
🟥 Red flag: If you only discuss wellbeing during burnout, you waited too long.
🔍 When You’re Out of Your Technical Depth
"What should a leader do when they feel out of their technical depth? How do you make sound decisions in that situation?"
First, learn enough to ask good questions. Then, trust your team. Ask engineers to present tradeoffs with pros/cons.
Then decide together. You don’t need to be the smartest person in the room, you need to enable the smartest decisions.
🧭 Stakeholder Management & Expectations
"Stakeholder management and expectation-setting — one of my biggest challenges."
Stakeholders want to be heard. They’re essential to any project but frankly they’re usually bad at prioritization and conflate urgent with important.
That’s why roadmaps matter, tradeoffs must be explicit, and new ideas should bump existing work.
On deadlines: most engineers and managers miss the ones they set themselves.
The fix isn’t more pressure, it’s smaller tickets, tighter feedback loops, and learning from misses.
Teams that ship small, on-time improvements consistently outperform teams chasing big, late launches.
And stakeholders are happier too.
🗣️ Communicating Effectively
"How to communicate effectively - this is an area I feel I struggle with (and I suspect many others do too)."
Great communicators adapt to their audience. "A great communicator is someone who talks to you in the communications style you prefer." Ask people how they prefer to receive information.
For most teams, a solid baseline is:
Clarity always beats volume.
🧠 The Takeaway
Engineering management isn’t about control, it’s about leverage. You stop writing code and start shaping systems: priorities, incentives, visibility, trust.
If you get those right, the team will outperform anything you could have personally shipped.
Good luck!
Mitchell, This stood out to me: "Avoid decisions that lock you in early" because it's a yes, and there are times to burn the ships and lock in. Overall, this is a great article because it covers a lot of ground on how to operate as an effective EM that had me nodding my head the whole time.
Thank you Mitchell Kosowski. Appreciate it!
This is an excellent set of pointers for early stage managers!