Keeping everyone busy can stall delivery

In one product and engineering team, developers start new tasks as soon as their part is done, while earlier items wait for QA.

Why it matters: Keeping people busy can lengthen the queue for QA and add reviews and decisions across the team while delivery remains unfinished. The team wants to deliver sooner and with higher quality, but people may feel they only contribute when advancing their own tasks.

What people feel responsible for: Managers consider overlapping tasks efficient. The squad accepts a shared goal, yet engineering and product culture still organises responsibility around individuals and departments.

When work is blocked, people may wait or look for their next assignment. Helping outside their role can feel like stepping onto a colleague’s territory. Task preferences and habits of working alone can also matter.

One developer explained the pressure: “I’m paid to work.” To him, working meant having a visible task of his own.

He knew he should avoid starting something else, but could not find a way to help. He felt unproductive, then felt pressure to start something.

That expectation can come from a manager or an inherited norm nobody questions. Someone supporting the team can make waiting work visible and encourage collaboration, but finishing one’s own part may still mark the end of individual responsibility.

In a field study of self-managing teams, well-designed teams benefited more from effective coaching. That finding points to examining organisational conditions alongside coaching. Engineering and product leaders need to make helping others finish a recognised contribution.

How to help across roles: Some colleagues can support specific tests with QA’s guidance, yet still respond: “That’s QA’s job.”

In Deliveritis Aguda, his talk for CTOs, Carlos Buenosvinos compares software development to basketball: everyone attacks and everyone defends. He also proposes sharing QA and architecture capabilities to avoid bottlenecks.

T-shaped people bring depth in one specialism and the ability to contribute elsewhere, learn and ask for help. QA can guide exploratory testing or identify checks others can perform.

The first step is to look for a useful contribution beyond the usual assignment. When a task requires expertise someone lacks, the specialist should handle it. There may be another way to help.

That flexibility lets people retain their specialisms while sharing responsibility for finishing the item.

What AI changes: In other cases, I’ve seen AI reinforce individual ways of working. Greater capability can create the feeling of being a “one-person band,” making collaboration seem less necessary. These are observations from specific cases.

Delivering a complete product still needs shared product, engineering and quality decisions. Fast execution can outrun shared understanding. People need to understand, review and integrate AI’s output so colleagues can continue the work.

In an early AI adoption experiment, changes concentrated on activities people could adjust individually, without significantly reducing meeting time. Fewer meetings alone tell us little about coordination; collaboration still needs conversations and reviews.

AI can also help across specialisms. In a P&G innovation experiment, individuals with AI produced proposals comparable in quality to pairs without AI and combined technical and commercial perspectives more effectively. Those were innovation workshops, with limited applicability to ongoing software teamwork.

Individual autonomy can coexist with shared responsibility. Additional capability should help finish existing work and broaden contributions across roles. Starting more work by default can reinforce the culture of keeping individuals busy.

What to change next: Prioritise helping finish or unblock work already underway, especially items closest to completion.

Parallel work can make sense when priority and capacity across the workflow justify it. Limit work in progress across the full flow, including validation. When that limit is full, new items should wait.

• Recognise helping as work. Leaders need to question the assumption that contribution always means advancing a personal assignment.
• Count work assigned to AI agents as unfinished while it awaits review, validation or integration. Use saved time to resolve a wait or understand the pending work.
• Prepare exploratory scenarios with AI and work through them with QA. Share assumptions and review the reasoning so others can understand and continue the work.
• Assess delivery through completion time, the age of unfinished items and quality. Individual activity alone cannot show whether the team is improving.

This case remains open. The effect of changing those expectations on delivery is still to be tested.

What do you expect someone to do when their part is done but the team hasn’t delivered yet?