Scaling Yourself as an Engineering Manager
How to stay effective when your team and responsibilities expand
You’re managing a team of five engineers. You own a microservice and some infrastructure. You know your projects, your team, and your stakeholders inside out. Things feel under control, until…
One day, your manager pulls you aside. Another manager is leaving. Their team of five engineers is now yours.
Overnight, your responsibilities double. Twice the people. Twice the projects. Twice the complexity. But your capacity to handle it doesn’t double overnight.
So, how do you keep up?
Scaling Up As An Engineering Manager
“I don’t want to manage a bigger team or handle more projects,” said no engineering manager ever.
But when it happens, very few EMs have a plan for how to actually scale themselves.
A few months ago, I was handed an additional squad and a “small” project. And boy, did I struggle! I worked longer hours, jumped into every detail, and stretched myself thin. That’s how most of us get thrown into management and the levels beyond — Unprepared!
I had to rethink my approach. Scaling isn’t about working longer. It’s about working differently. I learned a handful of things I can share.
1. Optimize for Asymmetry in Your Impact
It really doesn’t matter how many meetings you attend or how long you work. Your success is not measured by the number of things you personally execute but by the leverage you create. Instead of aiming for 1x efficiency, look for ways to create asymmetrical impact.
I liked
’s LNO framework to quickly assess how much time I should spend on the task.Leverage (L): Tasks that amplify impact (e.g., strategy, vision, coaching).
Neutral (N): Necessary tasks that don’t scale much (e.g., stand-ups, reviewing PRs).
Overhead (O): Time sinks that are required but small value (e.g., administrative tasks like leave approvals).
Example, that “optional” newsletter you need to send to senior leadership. That’s a high leverage task for you as a manager. Even though you prefer to be in the technical discussion with your team (which is a N task)
This doesn’t mean I avoid N or O tasks. I’m mindful of the time I spend on them. Like how much of a perfectionist should I be.
2. Embrace Letting Go
The side effect of scaling is you can’t be everywhere, and that’s okay. When you have a small team, you can probably know every task, review every PR, and be closely involved in execution. At scale, you can’t operate this way anymore.
You need to shift from:
❌ Controlling everything → ✅ Setting clear direction
❌ Tracking every small task → ✅ Measuring outcomes
❌ Fixing problems yourself → ✅ Coaching your team to solve them
Here’s one change I made. Every morning for the past three years, I used to go to the team’s oncall channel and read every support request that came in. It was mostly to be aware of any pesky problems or team members getting stuck.
I recently let that go. I told my team to tag me if they need me. They should bring hard problems to the team channel and daily standup.
Measure your effectiveness by how smoothly things run even when you’re not around.
3. Build a Leadership Pipeline
One of the best ways to scale is to invest in growing new leaders within your teams. Identify engineers who are already informally leading and give them opportunities to take ownership.
For example, I delegated scrum lead duties to someone on the team and setup a weekly staff meeting with the tech leads.
In another cross-team initiative, I let the lead engineer attend the meetings on my behalf to build their visibility and confidence. Besides, they get better understanding of the work by getting information first-hand.
This approach doesn’t just lighten your load, it ensures that leadership is distributed rather than concentrated in you.
4. Optimize for Scalable Communication
As your team grows, the way you communicate needs to evolve. Just last week I got surprised by someone on my team not knowing about a new project that I thought I have been telling about for weeks.
If something is important and everybody should know, over-communicate. Use all mediums available, not just meetings. Half the people are multi-tasking anyways.
Move from one-to-one updates to one-to-many broadcasts via async documentation, dashboards, or Slack updates.
I also setup “office hours” or “Ask Me Anything (AMA)”. This lets the team bring topics for discussions in front of the entire team rather than just 1:1s.
5. Create Systems to Scale
Even after you delegate, you’ll need to be aware of what’s going on in the team. You need to create some systems and processes that give you high-level view of progress and health. Something that helps surface problems before things explode.
Here’s how to do it:
a) Organize the Team’s Work
Some lightweight agile process for planning and a regular short meeting where teams summarize key updates, risks, and blockers.
Make dashboards your friend. Most project management tools will give you ability to create dashboards where you can view at a high-level how things are doing. Create one that fits your mental model and your team’s work.
Assign a Directly Responsible Individual (DRI) for each project who can drive decisions.
b) Build a Problem-Detection Radar
Use your 1:1s to detect early warning signs. Ask questions like “what’s on your mind?” in the beginning to let them open up. You can spot motivational issues, interpersonal problems or even project related problems here.
Encourage teams to reflect on what’s working and what’s not. Organize regular retrospectives.
Setup regular check-ins with stakeholders to spot potential misalignment.
c) Get a High-Level View of System Health
Ensure you have visibility into system health — error rates, latency, uptime, etc.
Weekly summaries of incidents help you spot patterns. I have the oncall present for 30 minutes at the end of their weekly shift.
That’s it!
Wrapping It Up!
Even with these systems, your workload will still grow. More meetings, decisions, and feedback loops. The key isn’t doing more work, it’s doing the right work.
A lesson I learned the hard way: Don’t leave every meeting with a pile of action items for yourself. That only overwhelms you and turns you into a bottleneck.
Instead, “redirect” every time you have thought:
✔️ Who on my team can take ownership?
✔️ Does this decision really need me?
✔️ Can I build a system to prevent this issue from recurring?
The best time to prepare for scale is before you need it. Start shifting your mindset and putting these systems in place now.
When the moment to scale comes, you don’t want to be caught unprepared.
More Resources
More about Directly Responsible Individuals in the Gitlab handbook
I like the first point in "organise team's work". I'm progressing to Senior EM and have started to think about methods to make staying up to date easier, with less overheads for my team. I went from 5, to 10 and soon around 20 engineers and have needed to learn how to scale each time.
Great article Suresh. I liked the DRI and LNO abbreviations. It gives us a sort of framework with which we can scale.
Please keep writing.
One more item I have found helpful in my tenure as an EM is that identifying key strengths of individuals & align them to the initiative or module type. Eg. If one person is very good at let's say Sumo logic or Splunk, they will do much better Job at error analysis and building application health dashboards. But the only caveat, we might create a dependency on that individual so having a backup person who can do that fairly effectively (let's say 85%) & grooming them along with that individual helped me a lot on not creating too much Dependencies.