Leadership
Leading without authority: build working agreements
Lead a cross-functional project without relying on a reporting line. Clarify dependencies, negotiate commitments and escalate competing priorities fairly.
You own the launch date. The people who can make it possible report to other managers. Your project board says the work is assigned, but the reviewer has a different priority and the engineer has never accepted the deadline.
Leading without authority starts by noticing that difference. Recording a task does not create a commitment. You need agreements that the people doing the work, and those controlling their priorities, can actually support.
This is common in product launches, agency programmes and internal change projects. The useful skill is to make the purpose, dependency and request clear enough to negotiate. Persuasion cannot manufacture capacity or override a decision you do not own.
Identify the authority you do have
Without a reporting line, you may still have authority over a budget, a project scope, a decision record or a defined programme process. Clarify what your sponsor has authorised you to decide.
Write three lists: decisions you can make, commitments you can negotiate and conflicts that require another owner. Ask the sponsor to confirm the boundary. A project title is a poor substitute for that conversation.
For example, you might choose the order of discovery activities but not reassign a security specialist. You might recommend a launch scope but need product and legal owners to accept it. Treat these as real boundaries, not obstacles to work around discreetly.
The leadership guide explains why decision rights matter. Delegation and accountability covers the related problem of responsibility without enough authority. Here, the task is to coordinate people across those boundaries.
Understand the other person’s work before asking
A request competes with commitments you may not see. Ask what the other person is responsible for, which deadlines are fixed and who resolves conflicts.
This is not a ritual of empathy before repeating your original demand. The answer should be allowed to change the request. If a reviewer cannot cover ten pages this week, perhaps the first review can cover the two pages that determine the launch decision.
Also ask what a usable input looks like. A specialist may be willing to help but unable to review a changing brief, a broken prototype or claims without supporting evidence. Fixing the input may unlock progress more effectively than another reminder.
The organisation psychology guide helps distinguish behaviour, incentives and process conditions. A slow reply can reflect overload, a missing decision or a request that has never become actionable.
Make an explicit, bounded request
A workable request answers six questions: why is the work needed, what is needed, what is ready, when is it needed, what trade-off is possible and what happens if the request cannot be accepted?
Compare “Please prioritise the launch” with “Can you review the two consent screens by Thursday so the product owner can choose the release scope? The copy and interaction notes are ready. If Thursday is not feasible, which smaller review or later date can you commit to?”
The second version gives the person something concrete to assess. It also makes room for a truthful refusal. An agreement extracted through embarrassment may look useful today and fail when a competing priority becomes visible.
Research by Yukl and Falbe examined influence tactics in upward, downward and lateral attempts. It reminds us that influence occurs across different relationships. It does not establish a script that guarantees agreement in your project or justify pressure disguised as collaboration.
A hypothetical launch with three owners
Imagine a fictional subscription service preparing a new onboarding flow. The project lead, Sam, coordinates product, engineering and customer support. None of their team members reports to Sam. This example is hypothetical.
The initial plan says “Support review: Friday”. The support manager has not accepted that task because the team is handling an incident. Engineering is waiting for the review before finishing the help messages.
Sam first checks the dependency. Does engineering need a full support review, or only the answer to one question about account recovery? The latter turns out to determine the release path.
Sam asks the support manager for a short review of that question, provides the exact screen and offers to defer the wider help content. The manager can commit to the smaller request but needs the incident response to remain the first priority.
The product owner accepts the revised scope. Sam records the decision and the remaining limitation. No stakeholder has magically gained time. The agreement works by reducing the request and assigning the trade-off to an authorised decision-maker.
Use a dependency and agreement map
Create a small table for the decisions that block progress. This is an original planning aid, not a validated leadership instrument.
Swipe or use the arrow keys to see every column.
| Dependency | Person who can act | What they need | Accepted commitment | Conflict owner |
|---|---|---|---|---|
| Recovery guidance | Support reviewer | Final screen and specific question | Review the recovery message, subject to incident duties | Support manager |
| Release scope | Product owner | Options and remaining gaps | Choose full or reduced release after review | Programme sponsor |
| Implementation | Engineer | Approved scope and stable copy | Estimate work after the scope decision | Engineering manager |
Use actual acceptance, not assumed availability, in the commitment column. Where no agreement exists, write “not yet accepted”. That is useful information, even if it makes the board less reassuring.
Map the smallest relevant dependency. “Legal approval” may hide three separate decisions with different owners. “Final wording for the renewal disclosure” is easier to route and prepare.
Keep the map accessible to the people using it. If the agreed details live only in your private notebook, the team has to depend on your memory and availability.
Negotiate scope, sequence and timing
You often have more flexibility than the original plan suggests. Separate fixed constraints from preferences.
A fixed regulatory deadline, a customer commitment and an internally preferred launch date are different constraints. Establish which one applies before using urgency in a request. Do not describe every date as immovable.
Explore three options: reduce the scope, change the sequence or move the date. Explain the consequence of each option. A smaller launch may leave an explicit limitation; a later review may delay implementation; parallel work may increase rework risk.
Avoid solving the conflict by assigning hidden overtime. The person may agree publicly while the workload becomes impossible. Ask which current commitment would move if your request took priority.
If neither person can authorise that change, the issue belongs with the priority owner. The next step is a decision, not a more persuasive message.
Escalate a decision, not a complaint
Useful escalation presents an unresolved trade-off and asks an authorised owner to choose.
A concise note might say: “The release needs a support review before implementation. Support is committed to the incident response. We can delay the release, reduce its scope or move another support task. These owners can confirm the consequences. Which priority should govern?”
This explains what remains unresolved without turning a colleague into the problem. Invite the relevant owner to check the summary before it is escalated when feasible.
Do not quietly copy senior people into a reminder as a punishment. Make the route explicit: “We cannot resolve these priorities within our authority, so I will ask the sponsor for a decision.”
If the sponsor will not decide, record the dependency and revise the forecast. Repeatedly presenting an impossible date as achievable conceals the organisational problem and transfers the risk to the delivery team.
Build credibility through predictable behaviour
Influence depends partly on what others have learned to expect from you. Do your briefs stay stable? Do you close the loop after a review? Do you credit the contribution? Do you disclose changes that affect a commitment?
Mayer, Davis and Schoorman’s model of organisational trust distinguishes trust from risk-taking and examines perceived ability, benevolence and integrity. Use that as a lens for your conduct, not a score for ranking colleagues.
You can act on ordinary behaviours: send a prepared input, keep an accepted promise, explain a changed deadline and avoid blaming someone for a decision you made. These actions do not entitle you to a yes. They make the next negotiation less dependent on guesswork.
There is a similar evidence boundary in online consumer psychology: a visible signal may inform trust, but it does not reveal every motive or guarantee a decision.
Hold a disagreement without personalising it
When a colleague refuses a request, clarify what the refusal means. Is the work outside their remit, is the timing impossible or is the proposed solution unacceptable?
Those answers require different responses. The wrong owner needs routing. Missing capacity needs a trade-off. Disagreement about the solution needs evidence and decision criteria.
Use difficult feedback when you need to discuss an agreed behaviour that did not occur. Do not use a performance conversation to punish somebody for declining a commitment they never accepted.
If the disagreement becomes personal, return to the work question and the decision owner. You do not need to win an argument about character to clarify the next dependency.
A weekly coordination check
At the end of the week, review only the commitments that affect the next decision.
- Which requests were explicitly accepted?
- Which inputs are ready and accessible?
- Which assumptions changed after acceptance?
- Which competing priorities need an authorised choice?
- Which owners need to know that the forecast changed?
- Which completed contributions need a clear closing message?
Do not measure leadership by how many reminders you sent. Look at whether the next person can act and whether the unresolved trade-offs are visible.
If you repeatedly need influence to compensate for absent sponsorship, the solution may be a clearer project mandate. Ask for explicit decision rights, resource commitments and an escalation route. A working agreement needs an organisational foundation as well as a well-written request.
If your digital project depends on teams with competing priorities, tell me where the work gets stuck. We can map the requests, dependencies and decisions that need a clearer agreement.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
Decision-making under uncertainty: expose assumptions
Make a work decision with incomplete evidence. Separate facts from assumptions, compare options and define a review trigger with a practical record.
Delegation and accountability: clarify who decides
Delegate with a clear outcome, decision authority and review points, so accountability helps the work instead of creating another approval queue.
Difficult feedback: prepare a useful conversation
Prepare difficult feedback with observable behaviour, fair questions and a clear next agreement. Use a practical worksheet without labelling the person.