# Cross Team Communication When You Have No Authority Canonical URL: https://headwayskills.com/knowledge/communication/cross-team-communication/ Markdown URL: https://headwayskills.com/knowledge/communication/cross-team-communication.md Entity type: Article Last updated: 2026-07-07 Language: en Primary audience: professionals improving communication at work Owner: Headway Skills Contact: https://headwayskills.com/contact/ ## Short answer Cross team communication fails at the request, not the org chart. Nine things you can do without authority to get another department to actually respond. ## Key facts - Title: Cross Team Communication When You Have No Authority - Category: Communication - Primary skill: Communication - Related skills: Teamwork, Influence - Primary keyword: cross team communication - Source page: https://headwayskills.com/knowledge/communication/cross-team-communication/ ## What this page covers - Cross team communication fails at the request, not the org chart. Nine things you can do without authority to get another department to actually respond. - Practical guidance for cross team communication - How this topic connects to Communication ## Detailed explanation You sent the request eight days ago. It was clear, it was polite, and it is still sitting there unanswered while your own deadline keeps moving closer. Cross team communication works better when you stop treating it as an organizational problem and start treating it as a request problem: name one owner instead of a department, say exactly what you need and by when, tie it to something that team is also measured on, then follow up on a schedule you set in advance. Almost none of the advice you will find says this, and there is a straightforward reason why. ## Why cross team communication is harder than it looks Search this topic and you get Asana, Slack, Atlassian, Teamwork and a dozen others, all resolving it the same way: break down the silos, standardize the channels, define shared goals, adopt the tool. That advice is not wrong, it is simply addressed to someone else — the person who gets to redesign how two teams work together, rather than the one waiting on a department that does not report to them. A quieter set of practitioner sources gets closer to what an individual can actually do, and everything below comes from there. ## Find the actual person, not the department "Can someone in design take a look at this?" posted in a shared channel is addressed to nobody, so nobody feels responsible for answering it. Hiver and ActivTrak both name unclear points of contact as a bottleneck in its own right: work stalls because neither side is certain who to approach for what. Spend the ten minutes it takes to find out who actually does the thing you need, and write to them by name. A request with a name on it is much harder to leave unopened than one addressed to a function. ## Say what you need, by when, and what "finished" looks like Global Integration's guidance on cross-functional working is blunt about this: before you ask for support, be clear on what support you need and what an acceptable output looks like. Vague requests are rarely refused outright. They get opened, half-understood, set aside until there is time to work out what is being asked, and then forgotten. Nobody can estimate what they cannot picture. Say what the deliverable is, what format you need it in, and what would make it good enough — "good enough" is a real specification, and it is usually smaller than the other person would have assumed on their own. The date belongs in the same breath, and it has to be a real one. The other team is ranking your request against work their own manager will evaluate them on, and "as soon as possible" gives them nothing to rank it with, so it settles at the bottom by default. A specific date makes a request schedulable; a specific date plus one line explaining what happens on that date — the launch, the board pack, the customer waiting on an answer — makes it defensible when they have to choose between your work and somebody else's. ## Drop your team's shorthand Ticket prefixes, campaign codes, internal system names, the abbreviation everyone around you has used daily for two years: one desk over, that is invisible jargon. A request the reader has to decode before they can act on it is a request they will come back to later. Write it as though the person has never sat in one of your meetings, because they have not. This also removes the reason people quietly stay confused instead of asking — few of us want to ask a basic question in front of a team we barely know, which is why misunderstandings survive far longer between teams than inside them. ## Lead with what the other team gets out of it Asana and Mural land on the same reframe: move from "how do I get them to do this" to "how do we succeed together," and say plainly which shared goal your request serves. This is not a rhetorical trick, it is priority arbitration. When a request visibly connects to something the other team is also measured on — the same launch date, the same complaint, the same quarterly number — it stops being a favor to you and becomes part of their own work. Look for that connection before you write. Sometimes there genuinely is not one, and knowing that early is worth something too. ## Choose the medium the topic deserves Write when the thing needs a record, when it is one-way information, or when the other person needs time to sit with it. Talk when it is sensitive, complex, contested, or when you are really negotiating whose priority wins. Cross-team disagreements conducted in a chat thread escalate for structural reasons rather than personal ones: nobody hears the tone, nobody can correct course mid-sentence, and everyone is aware of the onlookers. Distributed teams make this harder still, since messages across a boundary default to asynchronous, which means the medium usually gets chosen by accident rather than on purpose. ## End every cross-team meeting with names and dates Slack and Teamwork both flag the same failure: cross-functional meetings that end without anyone knowing their next step. Spend the last three minutes restating who is doing what by when, then send it in writing afterward. Inside your own team, that ambiguity gets caught at tomorrow's standup. Across teams there is no standup, no shared manager, and nobody who will notice that an action item quietly evaporated. If you are not the one running the meeting, you can still be the one who writes the summary. Nobody has ever objected to that. ## Build the relationship before you need it Leadership Circle argues that cross-functional initiatives fail less often for want of process than for want of relationship capital — the accumulated trust that makes collaboration across a boundary possible at all. In practice that is unspectacular. The person you have spoken to once answers faster than the person who has only ever received demands from you. Fifteen minutes asking someone how their team takes in work, what their busy weeks look like, and what usually goes wrong will pay for itself the first time something is genuinely urgent. It is also the only item on this list that is easier to do when nothing is at stake, which is exactly why it tends to get postponed until something is. ## Follow up on a schedule, not on frustration Silence almost always means their queue is ordered differently from yours, not that they have decided your work does not matter. The trouble is that following up at the moment you finally get annoyed produces messages that read as accusations, and those cost you standing you will need again next month. Decide in advance when you will check in — three working days, a week — and check in on that date with something short and neutral that restates the ask and the deadline. Scheduled follow-up is persistence. Frustrated follow-up is a complaint with a question mark on the end. That is the uncomfortable part of a list like this: most of what is on it sits on your side of the exchange, which means the answer to "why won't they respond" is sometimes yours to change. That is better news than it sounds, because your own habits are the only part of this you can adjust without anybody's permission — and a private read on [which habits are actually yours](https://assessment.headwayskills.com/) costs a good deal less than another month of waiting. ## Escalate late, openly, and about the work Escalation is not a failure, it is a step with a place in the sequence. Zestfor's material on influencing without authority puts it after repeated genuine attempts rather than as an opening move: if the work is at real risk and you have done the things above, bringing in your manager or a project sponsor is legitimate. Two rules make it survivable. Tell the other person you are raising it, before you raise it, so it never arrives as an ambush. And frame it around the deadline and the deliverable, never around their responsiveness or their character. ## What these nine habits are actually made of Read the list again and notice how little of it is about being articulate. Writing an unambiguous ask, working out what another team is measured on, and staying steady when a message goes unanswered for a week are separate capabilities that happen to surface in the same place. **Communication** is narrower and more mechanical than the word suggests. The parts doing the work here are the ordinary ones: state the main point first, be clear and direct, be brief, and adapt to how the receiver takes information in — which, across a boundary, means someone whose defaults are nothing like your team's. It also governs the medium decision, and the exchanges people tend to avoid: disagreeing, admitting a date has slipped, telling somebody their answer did not actually answer the question. **Teamwork** has an awkward property once a boundary is involved. Two teams with genuinely different purposes will disagree, and they are supposed to. What makes the disagreement survivable is putting the common purpose above your own team's agenda, being the person who does exactly what they said they would do, keeping the argument on the topic rather than on the people, and telling another team promptly and specifically when a commitment was missed instead of absorbing it and quietly resenting it. **Influence** covers the part with no authority in it, which across teams is all of it. The shape is preparation, pitch, persistence: work out what is genuinely in it for them before you ask, learn how that team actually decides what to work on, keep the request simple, listen an objection all the way through instead of arguing over the top of it, take the small yes when the full one is not coming, and follow up on what was agreed until it is done. This is the unpolitical version — credibility earned by delivering, not by maneuvering. There is a particular difficulty in getting better at any of this: across a boundary, nobody tells you why. A request goes unanswered and you never find out whether it was unclear, badly timed, or simply outranked, so the feedback that would normally teach you never arrives. That leaves self-assessment as roughly the only source you have. These three sit inside **a wider set of twelve that keeps surfacing across working life**, and the free Job Skills Test is the quickest way to see [where yours actually stand](https://assessment.headwayskills.com/). None of them is a trait you were issued; each is a behavior, which is why a gap is something you have not practiced yet rather than a verdict. Some of the nine will have read as obvious, which usually means you already do them. Others will have landed differently, and you may have recognized a specific message you sent last week while reading one of them. That recognition is the whole of the diagnosis, and it is the step most people never reach — they stay with a general sense that the other team is difficult to work with. Nothing here asks you to become louder, more senior, or a different sort of colleague. Naming an owner, writing a date, asking what another team is measured on: these are things you do, not things you are, and they get practiced by whoever you already are. They also count for more as you go, since the further into a career you get, the more of your work runs through people who do not report to you — a fair argument for starting while the requests are still small. What is left is deciding which one to start with. ## Start with a look at your own side You do not have to fix how two teams talk to each other. You only have to decide which part of your own side to look at first. The Job Skills Test is a **free** self-assessment of the twelve work skills this article has been circling, communication, teamwork and influence among them. It shows you which are already steady and which one is quietly costing you the most right now, so that whatever you change next is aimed at something real rather than at communicating better in general. Plenty of people find work across teams genuinely hard; this is a private read on your own position, not a verdict on it. Have a look, take whichever part of it is useful, and pair it with one thing from the list above on your next cross-team request. **[Take the skills test](https://assessment.headwayskills.com/)** *Free, seven minutes, and your results appear as soon as you finish.* ## Who this is for - Professionals building practical workplace skills - Readers looking for specific, usable work advice - Managers, educators, and coaches supporting career readiness ## Common questions ### What is this guide about? Cross team communication fails at the request, not the org chart. Nine things you can do without authority to get another department to actually respond. ### Which Headway skill does this connect to? This guide connects primarily to Communication. It also relates to Teamwork, Influence. ### What is the recommended next step? Use the free Work Skills Test to reflect on which work skill to improve next. ## Related pages - https://headwayskills.com/knowledge.md - https://headwayskills.com/knowledge/communication.md - https://headwayskills.com/knowledge/teamwork.md - https://headwayskills.com/knowledge/influence.md - https://headwayskills.com/work-skills-test.md ## Citation guidance Use the canonical page when citing this content: https://headwayskills.com/knowledge/communication/cross-team-communication/ Preferred summary: "Cross team communication fails at the request, not the org chart. Nine things you can do without authority to get another department to actually respond." ## Change log - 2026-07-07: Content collection version published.