Many execution problems are delayed symptoms of decisions made before the team ever started working together.
When a project begins to slip, attention usually moves to execution. Meetings increase. Tasks are reassigned. Leaders ask for recovery plans. Individuals are challenged about performance.
Sometimes that is necessary. But the source material on project teams points to an earlier possibility: the team may have been poorly designed from the beginning.
People may have been assigned too late. Roles may be ambiguous. Critical skills may be missing. Seconded staff may be uncertain about career consequences. Functional managers may not support the allocation. The team may be expected to perform before trust, working norms and decision rights exist.
In those circumstances, execution pressure is being used to compensate for formation failure.
The Strategic Context
The supplied course material treats team development as part of project planning, not merely a response to later conflict. It also presents Tuckman's familiar stages of forming, storming, norming, performing and adjourning.
The strategic value of that model is not the labels themselves. It is the recognition that collective performance develops through a sequence. Teams do not become cohesive simply because an organisation chart says they exist.
Temporary project environments make this harder. People can enter and leave across phases, maintain loyalty to functional departments, work virtually or externally, and face uncertainty about what happens after closure.
What Leaders Commonly Misread
The first mistake is recruiting for technical competence alone. A project can contain excellent specialists who cannot collaborate effectively across disciplines.
The second is assuming that role descriptions equal role clarity. Individuals may understand their own tasks while remaining uncertain about interfaces, decision rights and trade-offs.
The third is treating team development as a soft activity to be postponed until "real work" slows down. In reality, weak team formation becomes real work later through rework, conflict and delay.
Reframing the Issue
A project team should be designed as a temporary operating system.
That system requires:
- sufficient capability;
- explicit roles and interfaces;
- a common outcome;
- norms for communication and conflict;
- trust appropriate to the risk;
- practical access to resources and information;
- a credible path through closure and transition.
Performance is an emergent property of that system, not simply the sum of individual talent.
Forming Is More Than Introductions
Early team formation should answer consequential questions. Why does the project matter? What does success mean? Which constraints are real? Who decides? Where are the highest-risk interfaces? What behaviours are expected when disagreement occurs?
A kickoff that spends an hour on slides but avoids these questions has created ceremony without alignment.
The strongest forming work connects people to both task and purpose. It also makes uncertainty visible rather than pretending the plan is complete.
Storming Is Not Automatically Dysfunction
The Tuckman model is often interpreted as a warning about conflict. A better interpretation is that disagreement can reveal hidden assumptions.
Engineering, operations, finance and commercial teams often hold different definitions of success. Those differences are useful if surfaced early. A design team may optimise technical performance while operations prioritises maintainability and finance prioritises capital discipline.
The goal is not to prevent storming. It is to prevent unmanaged storming from becoming personal or political.
Seconded Members Carry Hidden Risks
The supplied material identifies concerns of people seconded into projects: recognition, career prospects, project failure, development opportunities and return to previous roles.
These concerns matter because commitment is shaped by perceived consequences. An employee may be formally allocated to a project while psychologically protecting their future in the functional organisation.
Leaders should not dismiss that as lack of commitment. They should design the assignment so contribution, performance and transition are credible.
Team Design Should Follow the Work
A common team-building error is starting with the organisation chart rather than the work system. The strongest team structure depends on the interfaces, uncertainty and sequence of the project.
A highly interdependent design problem may need close daily collaboration across disciplines. A more modular project can allow specialist teams to work with lighter coordination. A geographically distributed project may need stronger information standards and deliberately designed handovers because informal communication is weaker.
The point is not to choose one ideal team form. It is to match structure to the coordination problem.
Leaders should also distinguish core team members from contributors. If everyone who touches the project is treated as part of one large team, accountability can blur. A clear core team can hold integration responsibility while broader contributors join when their expertise is required.
Psychological Commitment Is Not Created by Allocation
A resource assignment tells someone where their time should go. It does not automatically create commitment.
People judge whether the project is credible, whether leaders support it, whether their contribution matters and whether the assignment will help or harm their future. Seconded staff in particular can experience competing loyalties between the project and their permanent function.
That is why early team leadership should address meaning and consequence, not only task. Leaders should make clear how contributions will be recognised, how conflicts with functional work will be handled and what the transition after the project is expected to look like.
A team that feels temporary should still feel consequential.
Decision Framework
Before execution, test the team across seven conditions.
| Condition | Question |
|---|---|
| Purpose | Does the team understand the outcome and why it matters? |
| Capability | Are critical skills genuinely available? |
| Roles | Are responsibilities and interfaces clear? |
| Authority | Are decision rights understood? |
| Relationships | Have key dependencies been built before pressure rises? |
| Norms | Does the team know how to communicate and handle conflict? |
| Transition | Do people understand what happens as phases change and the project closes? |
A team that fails several of these tests should not be described as "ready" simply because the schedule has reached execution.
From Strategy to Execution
Immediate action: run a team-readiness review before the next major delivery phase. Focus on interfaces and constraints rather than individual personalities.
Medium-term capability building: involve functional managers earlier, improve role and decision clarity, invest in cross-functional working practices and make project assignments meaningful for employee development.
Long-term strategic positioning: build an organisational capability for forming temporary teams quickly without treating people as interchangeable resources. Repeated project organisations should retain lessons about which team structures, roles and interfaces work.
Related article: Conflict Is Information: Turning Team Friction into Better Decisions
Related article: Temporary Teams Should Leave Permanent Capability
Signals to Monitor
Watch for late arrival of critical team members, repeated questions about who owns decisions, seconded staff prioritising functional work whenever pressure rises, conflict concentrating at the same interfaces, excessive dependence on one integrator, and teams entering execution before shared working norms exist.
Positive signs include early challenge, clear interfaces, direct problem-solving, confidence to surface bad news and the ability to resolve disagreements without immediate escalation.
Questions for the Leadership Team
- What assumptions are we making about team readiness because names appear on an organisation chart?
- Which critical interfaces are most likely to create conflict later?
- Are seconded team members genuinely supported by their functional leaders?
- What skills are missing that schedule pressure may hide for several months?
- How will this team handle disagreement when consequences rise?
- What should each person gain, retain or transfer when the project ends?
Closing Perspective
Projects often describe team problems as execution problems because the symptoms become visible during execution.
The deeper leadership responsibility is to ask what system produced those symptoms. If capability, roles, authority, relationships and transition were weak from the beginning, more pressure will rarely create a stronger team.
A project team should not merely be assembled. It should be deliberately formed for the conditions in which it must perform.
About EraNorth Insights
EraNorth Insights publishes practical analysis on strategy, projects, operations, transformation and decision intelligence for professional and organisational use. About EraNorth.