How to Lead a Cross-Functional Project When You Don’t Manage the Team

You are responsible for a project that depends on several teams, but none of the contributors reports to you. Each has other commitments, a different manager, and a reasonable view of what should happen first. To lead a cross-functional project, make the shared outcome, decision rights, commitments, and tradeoffs explicit. Then keep those agreements current as the work changes. You do not need to become everyone’s unofficial manager. You need a working agreement the contributors and their managers can actually support, plus a clear way to handle the decisions that your own authority cannot settle.

Get a mandate before building a detailed plan

Ask the person requesting the project what you are authorized to coordinate and what still needs their decision. Can you propose dates, request a contributor’s time, choose between options, or only gather recommendations? “You own the project” can mean any of these. Clarifying it early prevents you from making commitments that other teams never accepted.

Name a sponsor who can resolve a conflict between priorities. A sponsor is useful when two managers have both assigned their teams urgent work and neither can release capacity. You should bring the options and consequences; the sponsor should make or secure the priority decision. Repeatedly asking a contributor to work harder will not resolve that conflict.

Confirm the mandate in a brief note: “I will coordinate the rollout and propose the sequence. Each team will confirm its own capacity and delivery owner. The operations director will decide if the launch conflicts with another committed priority.” Ask the named participants to correct it before it becomes the basis for the plan.

Define success in terms every team can understand

A shared project name is not a shared outcome. Product may be trying to launch a capability, Support may be trying to reduce confusion, and Operations may be trying to avoid manual work. Bring those concerns into the goal rather than assuming that the launch date settles them.

Consider a fictional customer-onboarding project. “Launch the new handoff” sounds clear until each team interprets it differently. A more useful goal is: “For the next pilot group, each account reaches the support team with an agreed owner, complete setup information, and an exception route.” The team can now discuss what must exist before the pilot starts.

Write down what is outside the project. Perhaps the pilot will not replace the CRM or resolve every historical account issue. When someone proposes an addition, compare it with the agreed outcome. This gives the group a fair basis for deciding whether the extra work belongs in the current scope.

Separate the person driving a decision from the person making it

Some stalled projects have plenty of meetings and no agreed decision owner. A coordinator collects opinions, revises the plan, and waits for agreement that never arrives. Identify which decisions require a final call and who is authorized to make each one.

Atlassian’s DACI framework distinguishes a Driver, an Approver, Contributors, and people who need to be Informed. The driver moves the decision process along; the approver has final decision authority; contributors supply expertise; others receive the result. You can use those roles without adopting a new tool. The point is to remove uncertainty about who supplies input and who settles the choice.

For the onboarding pilot, you might drive the decision about the exception process, ask Support and Operations to contribute their requirements, and have the operations director approve it. Engineering needs the final decision because it affects the form. That does not mean Engineering needs to attend every conversation about the support workflow.

Create a one-page working agreement

Use the agreement below to begin the project. Keep it in the place the contributors already use for shared work. A document that nobody returns to will not help, however complete it looked during kickoff.

• Outcome: What will be different for the customer or team?
• Scope: What is included, and what is explicitly deferred?
• Sponsor: Who can resolve conflicting priorities?
• Work owners: Who owns each deliverable, and has that person confirmed capacity?
• Decisions: Who drives and approves each unresolved choice?
• Dependencies: What does one contributor need from another, and by when?
• Definition of ready: What must be true before the next milestone can start?
• Updates: Where will changes, blockers, and decisions be recorded?
• Escalation: Which situations need the sponsor, and how quickly?

Review the agreement with contributors individually when needed. Some constraints are easier to surface in a short conversation than in a large kickoff. Ask, “What have I assumed your team can do that has not actually been agreed?” This invites a useful correction before a missed milestone becomes the first sign of a problem.

Keep the agreement light. A small pilot may need only a few lines for each category. A larger project may already have a formal process; use that process and make missing decisions visible within it. Creating a parallel system can give contributors two sets of updates to maintain.

Turn dependencies into explicit commitments

“Waiting on Design” is too vague to act on. Name the required input, its owner, the date needed, and what happens if it arrives later. “Support needs the final error messages by Thursday to finish the pilot guide” gives both teams something concrete to discuss.

Ask the contributor to confirm the commitment rather than treating silence as acceptance. If Thursday is impossible, find out which part is needed first. A draft of three critical messages may allow Support to begin while the rest remain open. Splitting a dependency is often more useful than sending another reminder about the full deliverable.

Record changed commitments where the affected contributors will see them. A revised date shared only with you can leave everyone else following the old plan. After an adjustment, ask the downstream owner whether it changes their own commitment. This is the coordination work that keeps a plan credible.

Handle disagreement by identifying the decision underneath it

When two teams disagree, restate each concern in language its owner would accept. “Support needs a predictable exception route; Operations needs to keep the pilot manageable” is a better starting point than “Support is blocking the launch.” Ask the participants whether you have captured the constraints correctly.

Then narrow the choice. Can the pilot use one exception route while the team observes demand? Is there evidence that would settle the disputed assumption? Does the decision exceed the authority of the people in the room? A smaller question often reveals what needs to happen next.

If a priority conflict remains, escalate it with options. “We can keep Friday’s pilot with manual exception handling, or delay until Tuesday to automate the route. Support can cover the manual work for one week; beyond that, another priority must move. Which option should we plan around?” This is a request for a decision, with consequences attached.

Keep updates focused on changes and decisions

Use a short update that answers four questions: what changed, what happens next, what is blocked, and what decision is needed. Contributors should be able to see whether they need to act. Avoid making every update a history of the project.

For example: “The pilot form is ready for testing. Support will run two sample accounts tomorrow. The exception route still needs approval; without it, we can test the standard path but cannot start the pilot. The options and recommendation are in the decision note for Thursday.” This is both concise and honest about the remaining risk.

After the milestone, compare the result with the original outcome. Did accounts arrive with the information and owners the teams needed? Which exception surprised you? Give each contributor credit for the work they owned. Your own leadership evidence is the coordination, decisions, and improvements you enabled, described accurately alongside the shared result.

Start by making the mandate and shared outcome clear. Confirm who owns the work, who can make the decisions, and what happens when priorities collide. Keep dependencies specific and communicate changes to the contributors affected by them. These habits give you a practical way to lead across teams without relying on a title. They also leave a useful record of how you helped a group move from separate commitments to a result it could deliver together.