Don’t let engineers waste time on pointless work
Developers can spend days on over-engineering, endless meetings, or bug fixes. Help them reclaim that time for delivering actual business value.
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
1. Recognize & deal with team inefficiency
What’s up?
Andrzej here with some chilli sauce for you 😀
Your IT team is probably wasting 40% of their time on tasks that contribute zero to the company’s bottom line.
Think about your feature team’s last sprint.
How much time did the team spend debating code formatting while actual architectural issues went unnoticed?
Have you ever heard of standups where 10 developers each drag on for 10 minutes?
I've seen teams spend weeks perfecting their service's DX while a client was waiting for that very service to be released.
IT managers must redirect all this wasted energy toward shipping things to production.
The stakeholders rarely value anything else, as they don’t dare to enter the backend.
Recognize and deal with team inefficiency
Your IT team is likely burning money on 1 or many of these 7 habits.
Each problem has clear warning signs you can spot today and solutions for tomorrow, most of which we’ve tested in commercial projects.
The difference between teams that ship and teams that talk is knowing which activities actually drive revenue.
1. The meeting trap
The problem
Each hour spent in a meeting is one hour less for feature delivery.
I can’t make this simpler.
Please, defend yourself and the team, and don’t get roped in.
Developers really don’t need to be up-to-date on the project.
They just rarely speak up.
Some international clients might be protective of dailies.
Knowing that a development team shows up each workday signals accountability to them.
We once pleaded with a client to cut out dailies
They cost them $4,000 per month.
They didn’t budge because "that's how Scrum works."
Solution
Replace marathon dailies with async Slack updates of just 2 sentences.
The PO or EM can still keep them responsible when the time calls for it.
Hold a 5-10 minute sync only for actual blockers with the engineers who work on it, and no one else.
Our average feature team at TSH saves around 8 hours weekly thanks to these rules.
2. Overengineering
The problem
When asked to explain their choice of technology, many developers will drift into a monologue about the specs.
Choosing a framework for its superior performance sounds smart.
But what’s smarter is to say that this framework can reduce checkout abandonment.
That’s what actually matters for the business!
The solution
Show developers how their work ticks off specific business metrics.
To feel that business value matters, they need to see that shipped features increase conversion or save money.
So, connect every technical decision to revenue impact.
Standardizing technology choice also saves hours — or weeks — of low-level debates.
3. Overplanning
The problem
IT teams also tend to spend hours on refinement to document every single edge case.
Sure, that ends with a perfect estimation in story points down to the decimals.
Then what happens? The CEO DMs asking for a "quick change" 😀
They’ve just lost 8 hours.
In one project, I witnessed developers fight over a 2-pixel code indentation in the comments section.
The business logic of the feature they were building had critical bugs that nobody caught.
Because of these battles, the project shipped three weeks late.
Management had no idea why the velocity dropped until we audited the review process.
The solution
Managers can add a "definition of value" for each task to specify what business value it delivers.
When the team gets to refinement, the debate should center on understanding the user problem.
If priorities change frequently, planning should cover a maximum of one week.
Some ambiguity is better than wasting time on plans that become obsolete.
4. Overdocumenting
The problem
See if developers spend more time documenting than coding.
You're wasting money if you require documentation for every function and class.
Documentation that nobody reads is expensive fiction.
The solution
Code should document itself through clear naming and structure.
If developers can't understand code without a manual, the code needs rewriting.
Document only critical business logic and edge cases.
And if compliance needs everything on the record, let AI generate routine documentation.
Our team once inherited a 50,000-line code base.
The class names seemed random, like “Manager1” and “Helper2” everywhere.
The documentation had 200 pages. Yikes.
We had to rewrite the code with proper naming, which took 2 sprints.
Now, it needs no documentation at all.
5. Code review wars
The problem
Just in this one project, I witnessed developers fight over a 2-pixel code indentation in the comments section.
The business logic of the feature they were building had critical bugs that nobody caught.
Because of these battles, the project shipped three weeks late.
Management had no idea why the velocity dropped until we audited the review process.
The solution
Limit code reviews to a maximum of 2 hours.
Reviews must focus only on architecture, potential bugs, and business logic.
Ban all formatting discussions completely and use automated formatters instead.
You can also implement a double-check system where reviewers verify both code quality and feature completion.
Engineering managers should monitor code review times and step in when they exceed limits.
6. Manual testing dependency
The problem
Watch how long regression testing takes before each release.
The team’s wasting time if QA manually clicks through the same scenarios for days.
Each release delayed by manual testing could cost thousands in lost business opportunity.
Solution
Automate all main business flows and repetitive test scenarios:
registration,
login,
purchases,
critical paths.
Manual testing should focus on exploratory testing and new features.
When we automated 180 test scenarios, testing dropped from 5 days to 4 hours.
QA engineers then had actual time to pray for bugs instead of clicking around.
7. Code perfectionism
The problem
Prioritizing code refactoring while features are delayed is a red flag.
Similarly, optimizing products with minimal traffic is just dumb.
Perfecting code that already works is expensive procrastination.
The solution
Feature teams should always focus on shipping functional features first.
Business value beats technical elegance, and perfect code that never ships generates zero revenue.
Save refactoring for when the product has a revenue-positive number of users.
Ask your CPO or PO for the count.
Measuring success
Let’s be sure your gang won’t get hypnotized by story points or code coverage 😉
In the case of refocusing your engineers, use these 4 metrics.
Lead time to production
We aim to deliver new features in less than a week.
If it takes longer, we comb through the grass looking for blockers.
% of reworked tasks
Spending 30% of a sprint on bug fixes means the process is broken.
Actual deployment frequency
Commits or pull requests don’t count.
If your IT deploys less than once per week, please contact The Software House.
We’ll help. Seriously.
The best IT teams deploy multiple times daily.
Meeting efficiency ratio
Divide the hours in meetings by the number of decisions made.
Aim for 1 decision per 1 hour.
One client’s IT team needed 8 weeks to deploy.
Shocking. 5 departments had to approve the changes.
When the code reached production, the requirements changed.
Developers joked they were building for the past.
Next time
Adam will reveal why only four metrics actually matter for delivery in the next issue.
Lead time, cycle time, deployment frequency, and production bugs are the only numbers that matter.
I hope you enjoyed that bit of spice today 😋
Thanks for reading!
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|