A project plan can show every workstream, milestone, and dependency while telling you almost nothing about how the people doing the work will function together.
Who raises a concern when the room seems confident? Who can turn an uncertain design into a useful decision? Who needs advance notice of a meeting because their working day overlaps only briefly with everyone else's? Who will ask for help, and who will keep trying alone until the problem becomes urgent?
I have learned to spend more time on those questions at the beginning of an engagement. The architecture deserves attention, but relationships and working habits shape whether people can deliver it together. When several teams are involved, a small misunderstanding about availability or ownership can travel a long way before anyone recognizes its cost.
In soccer, a formation gives you a starting structure. It does not tell you whether the players understand each other's movement, know when to offer support, or trust a teammate to receive the ball under pressure. An engineering organization has the same gap between the arrangement on paper and the team in practice.
Closing that gap is leadership work. It starts before the first difficult delivery conversation.
In Ted Lasso, the fictional coach explains:
It’s about helping these young fellas be the best versions of themselves on and off the field.
I take that as an invitation to see the person beyond the immediate task. At work, that means supporting professional growth while respecting the boundary around someone’s private life.
Learn the people behind the roles
Introductions usually cover titles, responsibilities, and previous experience. That is a useful beginning. It leaves out much of what makes collaboration work.
Someone may be especially good at finding the assumption hidden inside a design. Someone else may help a tense discussion reach a decision without silencing disagreement. Another person may be strongest at translating technical consequences for people outside engineering. These contributions matter even when they do not appear in a staffing plan.
I look for strengths that help the whole engagement move, alongside technical depth. Then I try to understand where people want to grow. If you assign every responsibility from someone's current reputation, the person known for fixing difficult problems can become permanently responsible for emergencies, while the quieter person never gets a chance to lead.
A useful opening conversation covers four questions:
- What kind of work brings out your best contribution?
- Where would you value support or more context?
- What do others need to know to collaborate well with you?
- What responsibility would you like an opportunity to develop?
These are invitations, rather than a personality assessment. Listen for what will change a practical decision: the pairing you create, the review you ask someone to lead, or the support you arrange before assigning unfamiliar work.
Keep revisiting your understanding. Avoid letting an early impression become a permanent label.
Make room for real lives
Working hours, time zones, and recurring commitments influence how a team coordinates. Ignoring them does not create more capacity. It creates assumptions about why someone missed a message or could not attend a meeting.
The useful question is what arrangement makes the work dependable. People should be able to describe availability without explaining a private family or health situation. A calendar boundary is enough. Ask about the impact on collaboration and let the person decide what else to share.
For example, an engineer might be unavailable during a regular afternoon window. An illustrative agreement could be that routine reviews happen earlier, written decisions are available asynchronously, and a named colleague covers genuinely urgent questions during that window. That arrangement makes a constraint visible without turning personal circumstances into team property.
Be equally careful with flexible hours. Someone choosing to work later does not establish an expectation that everyone should monitor messages all evening. Make response expectations explicit and distinguish ordinary work from agreed incident coverage.
I have found that understanding these realities early prevents misunderstandings later. It also improves planning: the team can make commitments against the capacity it actually has.
Give the team a shared purpose and clear roles
A shared mission should help people choose between competing demands. “Deliver the program successfully” rarely gives enough guidance.
What must become easier or more reliable for the people using what you build? Which constraints matter most? What would count as a technically impressive result that still missed the point?
An illustrative mission might be: “Make the core workflow reliable enough for users to complete it without manual intervention, while keeping the service supportable by the team responsible for it.” That statement can inform choices about scope, operability, and when an attractive feature should wait.
Next, clarify how each workstream contributes and where responsibilities meet. The boundary is often where confusion lives. A component can have an owner while the decision about how two components work together belongs to nobody.
Agree who owns the outcome, who needs to contribute, and who can resolve a disagreement. Include a backup for responsibilities that would otherwise pause whenever one person is away. Make this visible to the people affected, especially when they have different reporting lines.
A soccer team needs players who understand both their position and their obligations to the players nearby. In engineering, a lead's responsibility also extends beyond the work inside their own boundary.
Shared purpose should never become a demand for unlimited loyalty. A team can be committed, supportive, and ambitious while respecting professional boundaries. Calling it a family adds no clarity about workload, compensation, or the right to disagree. Say what you expect, provide the conditions to meet it, and discuss trade-offs honestly when capacity is insufficient.
Write a short operating agreement
When a team first comes together, it can inherit routines without examining whether those routines suit the people or the work. A short operating agreement gives everyone something concrete to question and improve.
The following is an illustrative template. Complete it together, keep it brief, and make it easy to find.
Purpose. We are trying to achieve [outcome] for [users or stakeholders]. When priorities conflict, [named role or forum] resolves the trade-off using [agreed criteria].
Responsibilities. Each workstream has a lead and a backup. Shared dependencies have an explicit owner for the next action. We record decisions that affect other workstreams where those teams can see them.
Availability. We use [shared overlap] for conversations that need live participation. We respect published availability and agree separate coverage for incidents. Routine messages do not imply an immediate response outside working hours.
Communication. We use [place] for decisions, [place] for routine updates, and [route] for urgent issues. A request includes what is needed, from whom, and by when.
Disagreement and help. People can challenge assumptions and flag uncertainty early. If a disagreement blocks progress, the people involved first clarify the decision and options, then use [escalation route] when they cannot resolve it.
Commitments. When a commitment is at risk, the owner explains the likely impact and asks for support while there is still time to respond. We revisit open actions and acknowledge when changing priorities require changing the plan.
Review. We revisit this agreement at [checkpoint] and whenever the team, workload, or operating conditions change materially.
The blanks matter. Choosing a channel is easy; agreeing who responds and what happens next requires a real conversation. Resist the temptation to solve every hypothetical situation. Start with the coordination problems most likely to affect this team.
Earn trust through ordinary behavior
An agreement is useful only if people see it reflected in what you do.
I think about trust as something built through small, repeated interactions. Arrive prepared. Follow through. Admit what you do not know. Explain when a commitment has changed. Give people accurate information even when the information is uncomfortable.
Your response to the first problem will carry more weight than a kickoff statement about openness. If someone raises a concern and receives public blame or an interrogation about why they did not solve it alone, others learn from that exchange. Ask what is known, what remains uncertain, and what help would make a difference. Accountability still matters. It becomes more useful when people can describe reality accurately.
Consistency also means staying present after the team begins running well. Your contribution may shift toward listening and removing obstacles. Make that shift explicit. People should know when they can decide independently and how to reach you when they need support.
Attendance itself is not proof of commitment. Keep the conversations where your presence helps and change the ones where it slows decisions. Explain the new arrangement so that stepping back feels dependable rather than like a withdrawal of interest.
Give relationships some real work to do
People learn about one another by working together. A welcome session helps, but it cannot substitute for a shared task that requires listening, negotiation, and follow-through.
Early in an engagement, look for a bounded piece of work across workstreams: a design walkthrough, an integration exercise, or a focused problem-solving session. Choose something useful enough to deserve the team's time. Avoid adding a compulsory social event to an already overloaded week and calling it trust-building.
Pay attention to what the exercise reveals. Does everyone know whom to approach? Can a less experienced colleague question an assumption? Do decisions reach the people who must implement them? Use those observations to improve the working arrangement while the cost of adjustment is still low.
Before the next kickoff
Review the plan with three practical questions in mind:
- Do people understand the outcome, their responsibilities, and the responsibilities beside them?
- Have we agreed how availability, decisions, and requests for help will work?
- What have I done that makes my promise of support credible?
You still need milestones, architecture, and a delivery plan. Give those things a team capable of using them together. That is the foundation I want in place before pressure tests it.
Sources
1. Ted Lasso, season 1, episode 3, “Trent Crimm: The Independent.” Episode transcript; quotation corroborated in CNN’s guide to the show’s lessons, republished by KTVZ.