Manager.dev is proudly sponsored by Unblocked!
Stop babysitting your coding agents. Cursor, Claude, and Copilot are fast and capable - but they're context-blind. They generate code that compiles but misses your conventions and past decisions. You end up with ballooning token costs and review cycles you didn't need.
Unblocked gives your agents the organizational knowledge they're missing. It builds context from your engineering stack, resolves conflicts, and delivers only what agents need for the task at hand.
Every Engineering Manager has 5 jobs, but most of us only care about 2 or 3 of them.
In my first engineering management role, I basically did two things: I made sure we shipped fast, and I talked to customers. I didn't give real feedback, didn't run team meetings, didn't think about my engineers career progression or what the codebase would look like in two years. This was what I felt the team needed at that point (we were working on an ambitious greenfield project).
But somehow, this became my “playbook”. The team’s needs changed, but I continued to focus only on the delivery and customer support.
2 years later, when I was promoted again to Management in my next company, I was lucky to have a great manager who challenged my “playbook”, and helped me see parts I was neglecting.
Here’s the analogy I’ve been using since then:
Every EM has 100 ‘attention points’ they can distribute across 5 main areas:
Delivery
People
Support
Technical direction
Team Future
Note: “Points” capture depth of engagement, not just time. How much mental energy, ownership, and active effort you're putting into an area.
Some come naturally, others we avoid. Most EMs operate like I did, distributing their points without real intention, just by inertia based on what they are used to doing.
But every team needs something completely different from you (and even the same team needs different things at different times). A huge part of being a successful EM is adapting yourself to what your team needs, not just rerunning the same playbook.
When I started managing my current team of 7 engineers back in October, I planned to spend 6-8 weeks slowly understanding the codebase, with the blessings of my director. But after just 2 days it became very clear to me that it was not what the team needed from me right now. They didn’t have a manager for 6 months, and they missed feeling like a team (everyone was working on different things with different PMs).
So I postponed my ‘technical onboarding’ and focused mainly on the people and delivery parts:
Since then, I’ve adjusted my ‘dials’ many times, almost on a weekly basis. I’ve dialed up customer support to 50 for a couple of weeks, and spend another one mainly focused on the team’s future. Today, I’m roughly 20 points on people, 30 team’s future, 10 customer support, 10 delivery and 30 technical direction.
Throughout the changes, I try to follow the “10-60” rule:
The 10-60 rule
You can distribute your 100 points in endless ways. An even split of 20 each is NOT the goal - from my experience, you’ll achieve nothing that way, just spreading yourself too thin. On the other hand, just putting 80+ points into a single area will harm the other ones.
If you put less than 10 points in an area, it will not stay stable - it will get worse. In addition, going over 60 usually means you became too obsessed (which might be ok for a short time to achieve a specific goal, but becomes harmful if continues for long).
Here’s how the range looks in each area:
People
This one feels natural to most EMs - it's why many of us got into management in the first place. The risk is going too far in either direction: ignoring your people entirely when things get busy, or making their happiness your single measure of success.
The 10 points minimum:
Weekly or bi-weekly 1:1s, 30 minutes
Knowing their career aspirations
Knowing how they feel, what bothers them
Knowing what they are working on
Under 10 points is when engineers start feeling invisible. No one checks in on them, no real feedback on their work. You find out someone is unhappy or disengaged only when they quit.
How additional attention can look like:
Working on a promotion package for an engineer
Fighting for salary increases
Mentoring
Doing a project with an engineer together - they lead a feature, you give high-touch feedback
Building team culture - organizing team meetings, fun events, hackathons (those can take LOTS of attention points)
Trying to do it all at the same time will definitely bring you over 60%. I’ve seen managers like this, who desperately want their team to love them, putting their needs above everything else in the organization. Long term, this hurts the team too.
Delivery
This is the obvious one. It's what you get evaluated on, and what takes up 80% of most EMs' mental energy. The risk usually isn't that you ignore it, it's that you’ll obsess about it and forget the other four exist.
The 10 points minimum:
Everyone has work to do
It's aligned with the PM
You know what people are actually working on
Under 10 points usually looks like this: engineers drifting toward whatever interests them, a shadow backlog forming where the PM goes directly to engineers with ad-hoc requests, and you being the last to know something is slipping.
How additional attention can look like:
Working closely with the PM to understand the problems behind the roadmap, not just the tasks
Connecting engineers to those problems early, getting them involved in brainstorming
You and your engineers meeting customers for direct feedback
Watching session recordings to understand what's actually happening
Over 60% is when you're reviewing every PR yourself or deep in coding tasks. Nothing wrong in doing a bit of either - but if you solely focus on delivery (like most freshly promoted EMs do), the other parts suffer.
Customers & Support
Most engineers don't enjoy this part. Tickets are often poorly defined, context is missing, and the areas that generate the most issues tend to be the oldest and least understood parts of the codebase. There's a lot of activation energy just to get started on one. So if you're not actively managing this area, it slowly degrades.
The 10 points minimum:
There's always an assigned hotfixer responsible for tickets
On average, tickets closed ≥ tickets opened, no snowball effect
Under 10% looks like tickets treated as optional, requests sitting for weeks without a response, and you not even knowing what's currently open (and what bothers your customers the most)
How additional attention can look like:
Doing hotfixer shifts yourself
Shadowing support engineers to understand their challenges firsthand
Working on your team’s communication with customer support - not just whether you respond, but how
Analyzing ticket patterns and fixing root causes, not just individual issues
Over 60% is when you become the permanent hotfixer, personally reviewing every issue, treating everything as urgent. Or, when you treat every customer problem as urgent, constantly causing context switches for your team.
Technical Direction
This is the how of building - the processes, the tools (yeah, AI tools too), the tech debt you're accumulating or paying down. It's the area where EMs often either abdicate ("the seniors own this") or overclaim ("I need to be in every architecture decision").
The 10 points minimum:
You understand the tech stack being used, and you're involved when there are decisions to change it
You know what the main tech debt areas are and can advocate for them
Under 10% looks like not being involved in technical decisions at all - and worse, not being able to explain them. You agree to every product request without pushing back on what it'll cost technically.
How additional attention can look like:
Actively leading a refactoring project
Researching a new technology
Contributing to design review meetings and docs - both being capable of it, and spending the time
Working with other teams and org guilds to improve shared tools and infrastructure
Over 60% is the "we have to do it the right way" manager - constantly fighting the PM for refactoring time, nitpicking every design doc, getting satisfaction from beautiful code while customers wait.
The team's future
This one is not about just managing what the team is doing now, but about figuring out what it will be in 6-12 months. Especially now, with all the AI-craze out there, it’s important to be part in the conversations your leadership team is having.
The 10 points minimum:
You’re thinking about gaps in the team (skills, ownership, seniority)
You know what your team owns today, and it’s clear to others
You have a point of view on what your team should own next
Under 10 points looks like this: you focus solely on sprint after sprint, reacting to product requests. You wake up one day and realize your team is working on things that don’t really matter anymore to the company.
How additional attention can look like:
Expanding (or narrowing) your team’s ownership intentionally
Positioning your team around high-impact areas (not just what you historically owned)
Re-shaping the team to match that direction - skills, roles, responsibilities
Over 60% is when you’re living too much in the future, constantly reinventing the team, thinking about “the ideal team” instead of the current one. The team feels unstable, like the ground is always shifting.
How to distribute those points
What a great question! :)
seriously though, it’s quite a challenge for me. My simplest tip is to periodically (weekly/monthly) look backward and see which parts you didn’t give enough attention points too.
Next week, I’ll share my experiences from the past 6 months on how I shifted between those parts and what caused the shift.
