Are Engineering Managers useful? (1/2)
It’s a long-term investment in delivery quality.
This is “Effective Delivery” — a bi-weekly newsletter from The Software House about improving software delivery through smarter IT team organization.
It was created by our senior technologists who’ve seen how strategic team management raises delivery performance by 20-40%.
TL;DR
An EM transforms disconnected developers into a strong Spec Ops unit,
EM’s role didn’t exist 15 years ago, but is now essential for many IT departments,
Some organizations struggle to separate EM and PM responsibilities,
Use these 7 practical scenarios to decide if an IT organization needs an EM.
Contents
Hello!
I’m Marcin Basiakowski, presenting my first piece for Effective Delivery.
I’m the Deputy Head of Development.
Previously, I was the Head of QA at The Software House.
Beginning this year, my organization has transformed all team managers and some department heads into Engineering Managers (EM).
As a result, I had the chance to work closely with EMs.
Many IT leaders notice the EM role appearing in job listings and wonder if they are missing out.
Well, are they?
The rise of the EM
When I started in IT 15 years ago, EM’s role didn’t exist.
Everyone was sorted into silos based on their skills.
At TSH, we had several departments, such as QA, frontend, Node.js, or PHP.
Each manager was responsible only for their own layer,
This created friction because no one owned the whole development process,
When technical issues showed up, the communication devolved into a blame game.
The frontend and backend would see each other as the cause of inefficiency.
At the same time, the QA team was accused of inflating the number of bugs to raise the defect count.
It was hard to improve IT efficiency because these siloed teams lacked shared productivity goals they could strive for together.
The EM role resolved the lack of cooperation between members of an IT team.
What an EM actually does
The EM is a technical manager responsible for:
code quality and technical standards across the entire team
team composition and ensuring the right mix of skills
setting clear technical goals for the team and tracking overall productivity
representing the development team’s interests to stakeholders
proposing process changes that balance business needs with technical sustainability
individual growth and career development of each developer
performance reviews
Many organizations expect their product or project managers to handle these tasks.
Let’s examine when it is possible, and when an organization needs an EM instead.
Do you need an EM?
1. PM’s technical skills
If a product or project manager lacks technical depth, they will struggle to discuss architecture, code quality, or process improvements.
In this case, an EM is a better choice for these tasks.
However, if your PM has strong technical competencies, they can handle these conversations themselves.
I know cases where 1 technically oriented PM led several product teams without an EM.
2. IT team’s maturity
If the feature team has many juniors and mid-level developers, an EM will become their guide and a valuable mentor.
It’s almost impossible not to see any improvement in delivery with an EM.
Some teams with experienced seniors might be able to self-organize.
3. Measured underperformance
If IT’s efficiency metrics, such as lead time or deployment frequency, are declining, an EM can help address these issues.
If you don’t measure IT’s productivity at all, an EM is the one that could introduce systematic measurement of key productivity metrics.
But if IT tracks productivity metrics, and they stay healthy as ops scale, you might be fine without an EM.
4. The organization’s size
There’s no team-size-to-EM ratio that warrants hiring one.
Still, the CTO should know if they can ensure development efficiency.
That’s a good reference point.
If a CTO finds themselves unable to improve IT’s output directly, an EM can take over this responsibility.
At smaller companies, frontline CTOs can handle this without an EM.
5. Hiring plans
When IT plans to scale up or create multiple new teams, bringing in an EM is a good idea.
They’ll build a strong foundation for effective delivery.
In 1 project, our team faced a tight deadline.
They needed to improve their delivery performance to meet it.
The project had an EM from the start, who changed the team’s composition to better respond to the new requirements.
They continued to rally them around shared goals, bolstering morale.
His efforts boosted the team’s delivery by 100% over 4 sprints.
If IT size remains stable in the future, an EM may not make a significant difference.
6. No self-improvement within IT
Many IT teams are stuck in a cycle of continuous delivery — but without any self-improvement.
An EM can guide them out of this cycle.
But if engineers find time for retrospectives and process improvements, they might not need external help.
7. The budget
An investment in EM pays off through faster delivery and better quality in the long run.
Yet, I see that companies on a tight budget are tempted to choose 3 developers over 2 developers plus a manager.
This choice can backfire, but it won’t happen immediately.
Quite often, development remains stable, but there’s no quality improvement.
And that’s what an EM can ensure of.
One of our clients chose to pay for more developers instead of an EM.
They thought it was a money-wise decision.
The project kept struggling with process issues that nobody had time to address.
As the story shows, stacking up engineers won’t help if nobody has time to fix the process.
Next time
If at least 4 of the 7 factors for hiring an EM is true, I’d recommend introducing one.
But how do you know a candidate is a fit and not an imposter?
I’ll explain what makes an Engineering Manager great in the next issue.
Catch you in 2 weeks 👋🏻











This piece realy made me think, Marcin. You're so spot on about the EM role being essential today. Moving past old silos to build cohesive developer units is critical for effective delivery in our complex tech world. Thank you for sharing such valuable insights, it's a vital discussion for the industry.