The Key To Unlock Developer Productivity
Is not more surveillance tools, tighter deadlines, or return-to-office mandates.
Developer productivity has dropped to the floor.
Okay, maybe that’s a bit of an exaggeration, but isn’t that the buzz? Social media is flooded with debates, articles, and viral threads about how engineers aren’t shipping enough code. New terms like “quiet quitters” and “ghost engineers” are being coined every day.
On the other hand, surveys reveal that developers are increasingly disengaged and stressed. I see that many ICs lack the clarity and direction to do their best work. There’s a clear gap between what executives expect and what developers experience.
The solution to this problem is not more surveillance tools, tighter deadlines, or return-to-office mandates. It’s you, the Engineering Manager! Here are four things you should do well to unlock developer productivity.
1. Ensure Focus On the Right Work
Metrics like lines of code, commits, or tickets closed might tell you how much work is done but not if it’s the right work. As an EM, your job is to ensure your team is solving real problems, not just staying busy.
I’ve been on both sides of this. Once, I was in a product team where things were on auto-pilot mode. Engineers picked their stories from backlog and work seemed to happen magically. In one sprint demo, I proudly showed some refactoring work. My team member pointed out that the work wasn't necessary as the library is being deprecated. Ouch! My hard work turned into throwaway work.
As an EM, I remind myself of that feeling and make sure nobody in my team has to go through that. Here’s how you can catch that early:
Think critically about the stories in the sprint. What impact does it have on customers? Does it address any real problem? It’s ok even if it’s not solving a user issue as long as it improves your own quality of life, e.g. better alerting.
Do not add random vague stories in the sprint. Set separate time aside to review stories in the backlog and add as much detail as possible. Like what’s expected, why it’s needed, and how will we know it’s done. Add a spike to research a bit if no one knows the answers to these questions.
Spot invisible but useful work. Engineers often spend time on crucial but invisible tasks like learning, mentoring, or improving docs. Account for that work into your estimates. Also celebrate and highlight them so your team doesn’t think it’s thankless work.
When developers understand their work better, they stay engaged and motivated. Productivity and metrics will follow.
2. Be the “Shit Umbrella”
When you allow stakeholders and other managers direct access to your developers, you might feel proud for “enabling” a partnership but you destroyed your devs ability to focus. If a PM gets access to an engineer, they will drive them crazy with their requests and start putting unreasonable timelines on them.
Then when they come back to you for help, you think they’re cribbing about some minor interpersonal issues. No, dude, you let a fancy titled product person loose on your senior engineer and they’re not able to do anything useful. So, does it occur to you that maybe you’re not doing your job?
I’ve been guilty of that. Here’s how you can protect the team:
Filter and handle requests at your level. Funnel all external requests through you. Evaluate what’s urgent and what can wait. If you need to connect them to your team, make sure it’s not a free pass.
Set boundaries and expectations. Just because some important stakeholder messaged you at 7am on a Tuesday you don’t have to drop everything and attend them. Inform them when you’ll get to their request and what you can commit to.
Manage your managers. If some VP is asking for constant updates, summarize progress yourself instead of passing the stress onto your team. Avoid temptation to pull in your engineer immediately to get “accurate status”. Say that you don’t know the latest status and if it’s ok to get back later.
By shielding your team from unnecessary interruptions, you’ll allow them to focus and make progress towards a singular goal rather than being pulled in all directions.
3. Spot and Remove Blockers
Blockers don’t come in the form of big rocks written “BLOCKER” on them. Often they come in the form of “I ran the build three times and get the same error, I’ll try running again the fourth time.”
It seems like your developer is stuck on the local build. Maybe they need a second pair of eyes to figure out an issue. If you don’t take any action, you’ll hear them say the same thing in a couple of days. And you’ll start forming an opinion on their competency.
Instead, spot and remove these blockers early:
Ask probing questions to confirm it’s really a blocker. “Do you know what the next steps are?” or “Do you have a path forward?” or “Do you want someone to take a look?”. Note that “I’ll wait” or “I’ll try again” are not the right next steps.
Set some rules around common blocker patterns. If you’re waiting for a reply from another team for 24 hours, tag their manager and me please.
Encourage collaboration in your team. Create a culture where team members feel comfortable asking for help and offering support. Nudge senior engineers to help out on issues brought up in team meetings.
The sooner blockers are addressed, the smoother the team operates. Your job is to catch them early and ensure no one feels like they’re stuck on an island.
4. Being a Coaching Partner
Even the best developers can get frustrated or stuck. There may be something really trivial or major that just prevents them from moving forward. This is where you put on your coaching hat.
Even small moments of coaching can have a big impact:
Encourage reflection and thinking. “Hey, you said yesterday that you’re frustrated and really don’t know what else to do. Would you like to brainstorm some ideas with me?”
Give regular meaningful feedback. Focus on behaviors, by telling what they should do more of and less of. For example: “I really liked how you jumped in to help the intern with debugging. Keep doing that.”
Guide without dictating. I don’t do this well but don’t be me. Instead of saying, “This approach is wrong,” try “What do you think could go wrong with this approach?”
I talked in depth about coaching for Engineering Managers here.
Final Thoughts
Developer productivity discussions are going to continue in 2025 and beyond. I really think companies cannot solve this problem just by tracking some numbers and pushing developers harder.
Engineering Managers are the key to unlocking developer productivity. They are closest to the developers. They understand the developers and speak their language. Instead empower them with tools and training. Give them some space.
If you’re an Engineering Manager, don’t just manage tasks and rely on simplified numbers. Be the leader your team needs - help them organize, remove blockers, and coach them.
Because when your team does their best work, it'll make everyone productive!
As a manager that I fully embrace transparency and support other leaders, I've been always a bit skeptical about the "Shit Umbrella" concept. In fact, I wrote a dedicate article about it.
That said, we need to find the balance because there are tricky situations where one cannot be transparent. And also it's not only about that, but about protecting the team so they can focus without having to deal with the "shitty" distractions.
Great article, Suresh!