A team misses a deadline.
The natural reaction is usually predictable.
"Why aren't they working faster?"
So the company adds more meetings.
More tracking.
More status updates.
More pressure.
Sometimes even more people.
And then the same problem happens again.
The deadline slips.
The team works late.
Everyone gets frustrated.
The company concludes:
"We need a more productive team."
Maybe.
But maybe the team isn't the problem.
Maybe the system is making good work difficult.
Look at what happens before blaming the team
Imagine an engineering team is expected to deliver a feature in two weeks.
The work itself requires five days.
Sounds reasonable.
But the actual journey looks like this:
Requirement
↓
Product clarification
↓
Design
↓
Design approval
↓
Engineering
↓
Code review
↓
Testing
↓
Security review
↓
Release approval
↓
ProductionNow look at the waiting time.
Product clarification takes two days.
Design approval takes one day.
Code review takes one day.
Testing takes two days.
Security review takes two days.
Release approval takes one day.
The engineering work is five days.
The system takes fourteen days.
So what exactly is the productivity problem?
The engineer?
Probably not.
Activity is not the same as progress
This is where many organizations get confused.
People are busy.
Calendars are full.
Messages are flying.
Tickets are being closed.
Meetings are happening.
But the desired outcome isn't moving.
That should make you uncomfortable.
Because:
Busy people do not necessarily produce a fast system.
A system can be full of activity and still be slow.
Team output is influenced by much more than individual effort.
Think about:
People
↓
Process
↓
Information
↓
Decisions
↓
Technology
↓
Dependencies
↓
Customer
↓
OutcomeA problem anywhere in this chain can affect the final result.
Suppose an engineer spends three hours waiting for an answer.
That is not necessarily an engineering productivity problem.
Suppose a tester cannot begin because the environment is unavailable.
That is not necessarily a testing productivity problem.
Suppose the sales team keeps changing requirements because customer feedback isn't reaching product quickly enough.
That is not necessarily a product productivity problem.
The work is connected.
The five system questions I would ask
When a team appears slow, don't immediately ask:
"How can we make them work faster?"
Ask these instead.
1. Where does work wait?
People often focus on working time.
Systems thinking also looks at waiting time.
A task might require two hours of actual work and spend two days waiting for someone else.
Find the waiting.
2. Where does work get repeated?
Repeated work is often a system signal.
For example:
Requirement
↓
Development
↓
Testing
↓
Requirement changed
↓
Development again
↓
Testing againThe team may look slow.
But the real problem may be late decisions.
3. Where does information get lost?
A team can only make good decisions with good information.
If customer feedback reaches engineering three weeks late, the team may build the wrong thing.
Then everyone works harder to correct it.
More effort.
Same problem.
4. Where is the constraint?
This is the question I care about most.
Imagine:
Product → Engineering → Testing → Security → ReleaseIf Security can process only ten releases per week while Engineering can produce twenty, adding more engineers may make the problem worse.
You create more work for the constrained part of the system.
Find the constraint before increasing capacity.
5. What outcome are we actually trying to improve?
This is where productivity discussions often go wrong.
The company might measure:
• Number of tickets completed
• Hours worked
• Lines of code
• Meetings attended
• Features released
But the business may actually care about:
• Revenue
• Customer activation
• Successful transactions
• Retention
• Reliability
• Time to market
The activity metric and the business outcome are not necessarily the same thing.
The productivity trap
There is a dangerous loop that appears in many organizations.
Deadlines missed
↓
More pressure
↓
More overtime
↓
More defects
↓
More rework
↓
Less capacity
↓
More deadlines missedNow the company says:
"We need people to be more productive."
But the system is creating the conditions for lower productivity.
This is why some teams become exhausted without becoming faster.
What should you fix?
Not everything.
That's another common mistake.
If you find ten problems, you don't need ten projects.
Find the problem that is most strongly restricting the outcome.
For example:
Problem:
Features take too long to reach customers.
Possible causes:
Requirements change
↓
Code review delays
↓
Test environment instability
↓
Security review backlog
↓
Release approvalDon't immediately fix all five.
Find out which one is creating the largest restriction.
Then test an intervention.
Change the question
Instead of asking:
"How do we make the team more productive?"
Ask:
"What is making productive work difficult?"
That question leads you somewhere completely different.
You start looking at:
Waiting
Rework
Dependencies
Decision delays
Information gaps
Technology constraints
Process design
Incentives
Customer behaviour
And now you're not simply managing people.
You're improving the system in which people work.
A simple exercise
Take one team that you believe has a productivity problem.
Don't talk to them about productivity yet.
Map one piece of work from beginning to end.
For example:
Idea
↓
Requirement
↓
Approval
↓
Development
↓
Testing
↓
Release
↓
CustomerFor every step, ask:
How long does the work take?
How long does it wait?
What causes rework?
Who or what does it depend on?
What information is missing?
Where does the flow stop?
You may discover something surprising.
The team wasn't slow.
The system was.
The bigger lesson
Good leaders don't only ask people to perform better.
They ask whether the system allows people to perform well.
Because sometimes:
A better engineer won't fix a broken process.
A larger team won't fix a constrained system.
More meetings won't fix missing information.
More pressure won't fix rework.
More features won't fix a broken customer journey.
Before asking people to do more, understand the system producing the outcome.
That is systems thinking.
Map the problem before you solve it
If you have a problem that keeps coming back, don't jump straight to the solution.
Use the Problem Map.
It helps you identify:
The desired outcome
The visible symptom
The system
The assumption
The constraint
The dependencies
The intervention
The measurement
One question for you
What looks like a people problem in your business today, but might actually be a system problem?
Reply to this email and tell me.
I'll be reading the responses.
Think in Systems
Complex problems.
Simple systems.
Better outcomes.
— Abhijeet
Think in Systems