Development processes can’t fix low ownership
Managers see processes as a quick fix. But they don’t really improve efficiency.
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
Managers choose processes over trust because metrics are easier to show,
Teams optimize for process compliance instead of delivering features,
IT managers can rebuild ownership by removing approval steps,
A client required developers to self-test without QA… and no. of bugs sunk.
Contents
1. A new process is like a painkiller
2. How process worship destroys collaboration
Hey there.
Andrzej here again!
In many IT projects I worked on, IT managers responded to delayed releases or production bugs by adding more processes.
They created approval flows, mandatory checklists, and pushed for new metrics.
IT teams stuck to these new processes perfectly, but the problems actually worsened.
Funny, huh?
These managers rarely invested time in fixing the core problems with engineers.
New development process rules only gave them an illusion of control.
I’d say there’s only one solution for that paradox.
Replace unnecessary processes with stronger ownership from the IT team.
A new process is like a painkiller
If you have a headache, you can pop a pill.
In reality, you stared at the screen too long or got dehydrated.
IT leaders lean towards quick fixes instead of deep teamwork because:
building a culture of responsibility takes months of teaching developers to care about business outcomes,
implementing a checklist from another project takes one day,
process success is easy to measure
they can prove that the team completes their story points every sprint.
Measuring real ownership presents a different challenge.
IT managers can’t put a number on developers caring about the product.
The results only become visible months later when the product works and brings in revenue.
Sadly, the issue of low team ownership can only be delayed, never avoided.
How process worship destroys collaboration
The approval bottleneck
One project had an approval flow that required 3 sign-offs for every deploy.
Product manager, QA lead, and a technical architect all had to approve.
Getting them to agree took days or even weeks.
The feature team might stop suggesting improvements when the added overhead is too restrictive.
One developer showed me a task to add a discount feature to the shopping cart.
He knew it would conflict with an existing system but built it anyway because “that’s what the task said.”
The synchronization problem
In one project I consulted on, engineers worked perfectly in line with the manager’s process.
Frontend was a sprint ahead, building forms without API endpoints.
Backend was a sprint behind.
Each team tended to their field instead of caring about delivery together.
Regardless, everything seemed fine on paper, as both teams hit their velocity targets consistently.
Task completion mattered more than business value delivery.
IT leaders cannot hope to overcome an isolation mindset without deeper involvement.
Gaming the metrics
Developers know exactly what gets measured and what gets rewarded.
A developer who needs to increase commit frequency will split one change into ten tiny commits.
The velocity chart then looks amazing, but work quality doesn’t improve.
What if a manager asks for faster code reviews?
Developers can skim through the code and hit approve.
Still, bugs will slip through.
I call this KPI-driven delivery, where metrics are more important than outcomes.
Sprint frustration
Retrospectives can often become rituals of frustration.
A feature team might keep listing the same problems each sprint.
If the process doesn’t allow any bottom-up changes, engineers will feel disempowered.
That’s when they drop initiative.
The process taught them that following instructions matters more than delivering value.
Strategic process removal
In my experience, IT managers can rebuild a culture of ownership in 3 to 6 months.
Here’s how one of our partners did it.
At an e-commerce company, Developers wrote code, and QAs tested it.
The client made a radical decision.
He taught developers to test their own code, then fired all the QAs.
2 months later, bug reports from users dropped to record lows.
Without the QA safety cushion, developers knew each bug would point back at them.
This forced them to care about quality in a way that no process ever could.
The client never hired QAs again because the team finally understood what taking responsibility meant.
Personally, I wouldn’t recommend such drastic measures.
Consider an alternative.
Month 1: Process audit
Audit all development processes and decide if each increases or decreases team responsibility.
Build up a list of such to simplify or remove.
Months 2-3: Building trust
Remove one approval step in the development process.
Grant developers permission to change implementation details without approval.
They’ll constantly ask for confirmation at first, but this behavior will fade as they gain confidence.
Months 4-6: Business thinking
Instead of asking “Did you complete those tasks?” try “How did the team’s work support the business this sprint?”
Feature teams need time to develop this new perspective, so give them at least 2 months of consistent practice.
Month 6: Increase feature ownership
We made a stream-enabled team responsible for features instead of separate tasks.
A form wasn’t considered done when the frontend looked pretty.
It was done when users could submit data successfully.
After a few sprints, team members started planning together and reviewing each other’s code regardless of their roles.
Signs of growing ownership
Developers suggest improvements without being asked
Lead time decreases without management’s intervention
Bug counts drop without additional QA
IT teams self-organize around problems
Next time
Adam Polak will return to expose why AI implementation for development teams often fails.
Apparently, giving developers Copilot access doesn’t automatically improve productivity.
Who would have guessed? 😏
Our own experience with rolling out AI tools for 330 technical employees will teach you how to do it right.
Thanks for reading today 👋
Published with a smirk by The Software House
Twarda 18, Warsaw, Poland
tsh.io →
 | A guest post by
|