Myth: An IT team is always responsible

Responsibility must be taught rather than expected.

Oct 31, 2025

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%.

🔔 We’ve reached 100 subscribers because of smart readers like you! Thank you for keeping us employed!

TL;DR

Successful PMs and EMs treat responsibility building as a continuous process starting from day one,
Watch out for subtle signals where team members deflect ownership,
There are 6 responsibility-building techniques to use throughout a project’s lifecycle,
Distributing leadership across many team members prevents single points of failure.

Hey there! My name’s Jakub.

I’m the Delivery Manager at The Software House.

I started as an Agile Project Manager, and after 7 years between clients and feature teams, I’ve learned a bit.

Before writing this, I’ve been asked what the biggest lie about team responsibility in Scrum is, and why CTOs still believe in it.

Well, believing that IT teams act responsibly by default is that lie.

But they can. If they’re taught.

A developer can tell a stakeholder a task “isn’t important right now.”
The stakeholder could hear their feature doesn’t matter.
Seniors might watch the exchange without stepping in.
And if the PM is absent, projects might go into YOLO mode.

You’ve witnessed such situations, right?

In this issue, you’ll learn to spot signs of irresponsibility and how to build up the team’s sense of ownership without being controlling.

Why collective responsibility is a myth

Even when you form a new feature team, its responsibility must be grown through continuous effort across multiple sprints and milestones.

If that’s not done, delays, production bugs, cost spikes, or ignored support tickets shouldn’t be so surprising.

Let me simplify this:

As a manager or a lead, your perspective centers on the stakeholder or the end-user,
If they’re satisfied, you hope the project succeeds,
In contrast, each engineer will think of the piece they add to the pile,
Unless they’re specifically taught the business value mindset, they won’t feel like a part of a greater effort.

I’m not trying to criticize anyone.

People simply aren’t mind readers and want what is expected of them to be explained clearly.

If you want to see end-to-end ownership that goes beyond contracted tasks, invest way more time in discussions of what you want engineers to do.

Soon, you’ll learn the 6 responsibility-building techniques that will support the process.

But first, practice recognizing irresponsibility.

How team members dodge ownership

Several signs show a lack of shared project responsibility.

Blink, and you’ll miss them, as what’s being said or done might seem reasonable.

• “This isn’t important right now.”

Engineers who say this might be prioritizing their own tasks over the needs of stakeholders.

At the same time, their task might not offer the most value to the company.

• Explaining the code and not its impact

I’ve witnessed demos where the speaker explained what’s happening with the code as it was compiled on the screen.

300 lines of new code aren’t the point.

The potential frontend speed boost that improves the checkout rate is.

Help engineers grasp that stakeholders want to hear about the business value, not another report entry.

• “There was no ticket for that.”

This has a nice ring after the infrastructure fails overnight on the weekend.

Waiting for requests shows a fundamental misunderstanding of teamwork.

Ultimately, the feature team’s success ensures that each engineer keeps their role.

In a project I managed, cloud costs suddenly jumped by 7000%.
No one in the feature team noticed.
That’s because no one created a ticket for DevOps to set up project monitoring.

• Team members keep waiting for QA

In some of our clients’ projects, deployment would take weeks.

Unattended pre-deployment tests were one of the top bottlenecks.

Engineers hesitate to get involved in feature tests, but they should push for their completion in line with the DevOps mindset (build, test, maintain).

• Nobody challenges stakeholder requests

Businesspeople often have great insight into market dynamics.

But they really aren’t UX experts.

Frontend developers or Designers might hesitate to challenge requests or changes that could hurt the product experience, even though they know better.

6 tools to build team responsibility

1. Micro-reminders shared through Slack

Address any deflections in responsibility in real time instead of waiting for formal meetings.

Problems should be flagged before they occur.

In time, when the PM goes on leave or faces unexpected circumstances, developers will make fewer critical mistakes thanks to this training in proactive communication.

They will also feel obligated to uphold the development process.

For one project in the sensor industry, our feature team built a dependency map.
We used it to signal when our EM and PM would require a stronger presence of the client’s team in the project.

2. Demo ownership rotation

Encourage developers to explain what their code does in business terms during stakeholder demos.

It’s the IT manager’s duty to help team members explain how backend validations impact revenue or security.

Their goal is to have stakeholders have an “aha” moment when the value of IT work is crystal clear.

3. Reframe careless statements

Hunt for any statements that downplay the importance of critical work.

Anytime you hear “we can do it later” or “it’s not our job”, explain how stakeholders experience such.

This is not a call to take in new orders like a McDonald’s drive-thru staffer.

Even tech-unsavvy stakeholders deserve careful listening and responses.

Train engineers to respond thoughtfully to project discussions, even if they’ll backlog or decline tasks later with the PO.

4. Mini task forces

When a blocking issue arises during sprint planning and the team can’t answer it, create a mini-team to work through it in the background.

As the manager, assign to it engineers who are capable — but not entirely proactive — to power up their autonomy.

The approach teaches developers that complex problems don’t stop progress but get handled through focused effort.

5. Daily lead rotation

Giving team members the option to run meetings prepares them to step in when project management gets derailed.

Most of our senior developers can lead dailies and planning for the PMs.

Just in case.

If that foundation is in place, the manager should teach less experienced members to step in.

You want the team to understand the PM’s challenges through direct experience.

6. Multiple support pillars

You never want to depend on a single expert — like me, or a PM, or anyone else.

Most projects rely on a single person for deployments, integrations, or production fixes.
One person seems enough until, inevitably, something like the infrastructure or an API fail.

Think of the critical tasks within your project.

The idea is to prepare less experienced developers to take them on under the guidance of seniors.

To build such a foundation, a manager really can’t skip that paperwork time:

rotate critical tasks among team members,
insist on having key processes documented,
don’t skip skill gap audits.

The transformation from a fragile, single-point-of-failure process into a robust, multi-pillar structure creates camaraderie that benefits everybody.

Next time

In Effective Delivery 11, Andrzej Wysoczański will perform surgery on processes in development that don’t really support feature delivery, which is what the business pays us for.

I hope I entertained you today!

Thanks for reading 🙏🏻

🟣 Substacks we read

🤯 Context switching. Endless meetings. Competing demands. Conflicts. AI disruption.

It’s no wonder so many managers feel overwhelmed.

That’s why thousands turn to Thriving in Engineering.

Written by 25+ year industry veteran Alex Ponomarev, every issue gives you tools to stay grounded, lead with confidence, and grow your career on your terms.

👉 Start with Alex’s guide on How to Master One-on-Ones — then subscribe to get new tactics and playbooks every week.