The quick version: Technical writers depend on cross-functional communication more than almost any other role in software. In distributed teams, that communication breaks down in different ways. Cultural conditioning around hierarchy can make it hard for some team members to speak up, ask questions, or flag problems. Separately, remote tools like Slack can erode communication quality even between people who work well together. And underneath both of those, organizational culture often treats documentation as an afterthought, making it nearly impossible to get buy-in for the practices that would actually help. These are different problems with different fixes, and treating them as one generic “communication issue” is why most solutions don’t stick.
Technical writing is one of the most cross-functional roles in software. Roughly 90% of the job is tracking down subject matter experts, asking them questions, and turning what they know into something a user can actually follow. That’s not an exaggeration. You can be the strongest writer on the planet, but if you can’t get the information out of the people who have it, you’re stuck.
When everyone’s in the same building (same timezone, same hallway, same lunch spot) that information-hunting process has natural momentum. You overhear things. You catch someone between meetings. You read the room when an engineer hedges on an answer and you know to push a little harder.
Distributed teams don’t have any of that. And while most conversations about remote work friction focus on tooling and timezone math, the real barriers often go deeper. In my experience, they fall into two distinct categories: cultural conditioning that shapes how people communicate, and logistical friction that erodes communication quality even between people who work well together.
These get lumped together constantly. They shouldn’t. The causes are different. The fixes are different. And if you don’t diagnose which one you’re dealing with, you’ll keep throwing “better communication” advice at problems it can’t solve.
When The Problem Isn’t Skill, But Conditioning
Early in my career, I worked on a small documentation team. Two of us, US-based, in a fast-moving department. A third person was hired internally to join us as a technical writer. She’d been an instructional designer and was smart, capable, experienced in her own right. She was based in India.
Within the first week, something felt off. Days were passing and she hadn’t reached out to any of the SMEs she’d need to work with. The features she was assigned to document had product managers, senior engineers, and other engineers at various levels attached to them — the people who could explain what was built, why it was built, and how it was supposed to work. She hadn’t contacted any of them. No Slack messages or questions about the product areas she’d been assigned. No “hey, I’m stuck” flag to me or our other teammate. Just silence.
I checked in. Gently at first, then more directly. The work wasn’t happening. And it became clear that the issue wasn’t that she didn’t know what to do, but that doing it required behaviors she wasn’t comfortable with.
What does cultural conditioning actually look like on a distributed documentation team?
Technical writing demands a specific kind of assertiveness. You have to “cold-ping” product managers and engineers you’ve never met, including sometimes senior ones who outrank you on any org chart. You have to interrupt their day and say “I need 20 minutes of your time to understand this feature.” You have to ask questions that might sound basic to someone deep in the codebase. And when you’re stuck, you have to say so, out loud, to people across teams who don’t report to the same manager you do. That’s the job. There’s no way around it.
In hierarchical work cultures, which are common in India and parts of Southeast Asia, those behaviors can feel like overstepping. Reaching out unsolicited to a senior engineer? That can register as presumptuous. Admitting you don’t understand something? That can feel like exposing weakness. Telling a peer that you’re falling behind? That can feel like a confession.
A 2020 study published in the National Library of Medicine (Šmite, Gonzalez-Huerta, and Moe’s “When in Rome, Do as the Romans Do”) examined exactly this dynamic. They studied distributed DevOps teams with members from a mature agile company in Sweden and an offshore vendor in India. Even when the Swedish management was empowering and non-hierarchical, many offshore engineers still defaulted to hierarchical behaviors. They agreed to unrealistic timelines instead of pushing back. They stayed quiet about blockers. They waited for direction instead of self-organizing.
Why silence gets misread as disengagement
The silence, from the outside, looks like disengagement. Or worse, incompetence. But from the inside, it may be closer to paralysis because the person is caught between what the role demands and what their professional conditioning allows.
My colleague didn’t last in the role. I flagged the situation to my manager, and we moved forward. I was empathetic to what she was likely going through, but I also had a full workload of my own and wasn’t in a position to carry someone else’s onboarding on top of it. That’s an honest answer, even if it’s not a comfortable one.
When structural decisions make cultural problems worse
Here’s what made the situation worse: she was hired without any input from me or my teammate. At every other company I’d worked at, the existing team was part of the hiring process. We’d assess not just writing ability but communication style, comfort with ambiguity, willingness to chase people down. None of that happened here. And no one accounted for the a 13 hour timezone gap either, on a two-person team in a department that moved fast. That’s not a scheduling inconvenience. That’s a structural problem.
Cultural Barriers Are Layered. One Workshop Won’t Cut It
I want to pause here because there’s something underneath these stories that’s worth naming.
When we talk about cultural barriers in distributed teams, it’s tempting to treat “culture” as one thing — usually national culture. Indian engineers are hierarchical. Nordic teams are flat. South American communication styles are expressive. These generalizations aren’t useless, but they’re incomplete. In practice, cultural barriers are layered. National culture is one layer. Organizational culture is another. And gender dynamics in technical environments are a third, and they intersect in ways that aren’t always easy to pull apart.
A former coworker once told me about a previous job where her content department started running cultural awareness workshops. The team had recognized that people were struggling to communicate across cultural lines, and the sessions were meant to address that. For her, it was eye-opening. She hadn’t fully considered what her Indian colleagues were experiencing in trying to fit in. But she’d also been dealing with something murkier: Indian male engineers who came across to her as dismissive when she asked questions that required them to think beyond the boundaries of their specific feature. She couldn’t tell if it was a gender thing, an ego thing, or a cultural communication pattern around hierarchy and expertise. Probably some of each.
That landed hard for me because I’ve felt the same thing and not only with Indian male engineers. Male engineers more broadly, across cultures, can be dismissive of questions from non-engineers, especially when those questions challenge their framing or expose gaps in how a feature connects to the larger product. The pattern isn’t purely national. It’s also about how engineering culture, gender, and hierarchy tangle together.
What’s the difference between cultural awareness and cultural sensitivity?
This is where cultural awareness and cultural sensitivity diverge, and why treating them as the same thing doesn’t work.
Awareness is informational. It tells you that differences exist. That someone from a hierarchical work culture might not push back in meetings, or that directness varies across regions. You can cover this in a slide deck. Sensitivity is what you do with that awareness in real time. It’s the ability to hold multiple interpretations of someone’s behavior at once — to consider that dismissiveness might be cultural, or gendered, or both — without defaulting to the most generous or most cynical read. Sensitivity requires self-reflection, not just information. And it cuts in every direction: the same way my coworker needed sensitivity toward her Indian colleagues’ experience, those colleagues also needed awareness that their communication patterns were landing as dismissive to the women around them.
One workshop doesn’t build this. A single session on cultural awareness might check a box, but it won’t change how people actually interact day to day. The same way a single annual security training doesn’t make anyone meaningfully more security-conscious. If you want cultural awareness and sensitivity to actually shape behavior, they have to be systematic and repeated. Built into onboarding. Revisited in retros. Reinforced by managers who model it. Not a one-time event that everyone sits through and forgets.
The onboarding and training I advocate for later in this article would be stronger if it accounted for this intersection (national culture, organizational culture, and gender dynamics) rather than treating cultural awareness as a single checkbox. These layers don’t exist in isolation, and the friction they produce in distributed teams won’t respond to solutions that pretend they do.
When The Relationship Works, But The Medium Doesn’t
Not all communication friction has the same root cause. Sometimes the problem has nothing to do with cultural conditioning and everything to do with the tools and circumstances you’re working within.
At another company, one of my favorite SMEs was a lead engineer originally from South America. He spoke English well, but he had a habit of reaching for American idioms and sayings. I think as a way of bridging the gap when the exact phrasing in English wasn’t coming to him. It was charming and effective. I always knew what he meant.
That was when we were hybrid. I could see his face, read his body language, catch the little hand gestures he’d make when he was trying to land a point. If an idiom didn’t quite track, I’d ask “wait, what do you mean by that?” and we’d sort it out in two seconds flat. The agile dynamic between us was never the problem. He was open, collaborative, easy to approach.
Technical writers don’t just need what an SME says. We need how they say it.
Then COVID hit and everything went remote. The company leaned heavily on Slack, a text-first communication as the default. And suddenly, the dynamic shifted. His idioms, which landed fine in person, became confusing in a chat window stripped of all context. Audio calls on Slack were better, but I still struggled to follow him at times. Video was the best option, but as things went on he got busier, harder to pin down, and more distracted even when we were face-to-face on screen.
Nothing about our working relationship changed. He was still one of the best SMEs I’d ever worked with. What changed was the medium and the medium couldn’t carry the weight of what the communication actually required.
What do technical writers lose when everything moves to text?
This matters because technical writers don’t just need what an SME says. We need how they say it. The pauses. The hedging. The “well, actually…” that signals the first answer wasn’t quite right. The way someone’s face shifts when you ask a question they weren’t expecting. That’s where the real information lives, and it’s the first thing you lose when everything drops to text.
What Actually Helps
If you’ve read this far, you might be expecting a tidy list of solutions. I can offer some things that worked for me. But I want to be honest: some of these problems don’t have clean fixes, and the ones that do require buy-in from people who aren’t always paying attention.
I should also say that I’ve been on the other side of this too. I’m not always perfectly articulate when talking to SMEs. I’ve fumbled questions, lost the thread in technical conversations, and walked away from calls unsure whether I actually understood what was explained to me. Communication friction in distributed teams isn’t something that only happens to other people. It shows up differently depending on the context, but it shows up for all of us.
For Cultural Barriers
Include the existing team in hiring. A two-person docs team knows what the role demands better than a hiring manager three levels removed. Communication style, comfort with ambiguity, willingness to initiate. You can’t assess those from a resume. Let the people who’ll work alongside the new hire weigh in before the offer goes out.
Make the implicit explicit during onboarding. Don’t assume a new hire from a different cultural background understands that cold-pinging a senior engineer is expected. Say it directly: “Your job requires you to interrupt busy people, and that’s not just okay, it’s how this works.” Say it more than once. And model it, ideally by pairing new hires with someone they can shadow so they see it in action before they have to do it alone.
Assess for communication approach, not just writing samples. In an interview, try a scenario: “An engineer hasn’t responded to your questions in three days and your deadline is tomorrow. What do you do?” The answer will tell you more about how someone will function in the role than any editing test.
Account for timezone realities before hiring. A 10-hour offset on a small team in a fast department isn’t a detail to figure out later. It’s a constraint that shapes everything.
For Communication And Medium Barriers
Ask for video walkthroughs. This was the single most effective workaround I found, and it worked across every team and cultural context I encountered. Instead of deciphering written notes or chasing answers through long Slack threads, I’d ask engineers and PMs to record a short video walkthrough of the feature they’d built. It changed a lot. The explanation was in their own words, at their own pace. I could replay and re-listen. It sidestepped accent and language barriers because I wasn’t relying on real-time comprehension. And it cut scheduling pressure. They recorded it when they had time, I watched it when I had time.
Default to video for high-nuance conversations. Slack and Teams are fine for status updates and quick questions. They’re terrible for the kind of detailed, nuance-heavy exchanges that documentation depends on. If you’re working with someone whose first language isn’t English or whose communication style relies on expression, gesture, and emphasis, text chat is the worst possible medium. Push for video whenever the conversation matters.
Normalize rephrasing. Make it safe to say “can you say that differently?” without it feeling like a judgment on someone’s English. This is a small cultural shift, but it prevents a lot of quiet misunderstanding.
Follow synchronous conversations with async summaries. After a call with an SME, send a quick recap: “Here’s what I understood. Did I get this right?” Three sentences of follow-up can prevent hours of rework.
For Both
Diagnose before you prescribe. When communication breaks down, ask why before you reach for a fix. Is it a power dynamic? A language barrier? A timezone gap? A tooling mismatch? The answer changes the approach entirely, and lumping everything under “communication issues” helps no one.
The Hardest Barrier: Getting Buy-In For Solutions You Already Have
Here’s the part that’s difficult to write without sounding bitter, so I’ll try to just be direct.
I’ve worked at a massive enterprise SaaS company and a much smaller mid-market B2B company. At both, I pushed for the same thing: require video walkthroughs attached to Jira tickets when engineers close them. At both, the response was the same: nodding, agreement, “yeah, that makes total sense.” And at both, the follow-through was inconsistent at best.
Some engineers would do it, while others wouldn’t. Some PMs and scrum masters agreed it should be required but never actually made it a requirement. The pattern repeated regardless of company size, team structure, or how many times I made the case.
When docs are treated as something that happens after the real work is done , any process that requires engineers or PMs to do something for the docs team becomes optional in practice.
A video walkthrough takes an engineer five to ten minutes. The absence of one can cost a technical writer hours in Slack threads, follow-up meetings, guesswork, and rework. But that asymmetry is invisible to the people who’d need to enforce the practice. They don’t see the hours I spend untangling what a three-minute Loom could’ve prevented.
This is its own kind of cultural barrier, separate from national culture or language. It’s organizational culture around documentation as a priority. When docs are treated as something that happens after the real work is done , any process that requires engineers or PMs to do something for the docs team becomes optional in practice. No matter what people agree to in meetings.
And this friction compounds in distributed teams. If getting department-wide buy-in is hard when you’re in the same building, it’s significantly harder when you’re coordinating across timezones and cultures and everything is mediated through Jira comments and Slack messages that scroll off the screen.
What This All Points To
Technical writers are often the first people to feel when a distributed team isn’t working. The role sits at the intersection of every communication pathway (engineering, product, design, and support) and depends on all of them functioning. When something breaks down, we feel it before most people even notice.
The “new era” of documentation isn’t only about AI tools and docs-as-code pipelines. It’s about a workforce that’s more distributed, more culturally varied, and more dependent on asynchronous communication than it’s ever been. The challenges that come with that aren’t going away. If anything, they’re deepening as companies expand their distributed footprints.
Understanding the type of barrier you’re facing is the first step to doing something about it. Cultural conditioning, communication medium, timezone logistics, and organizational buy-in are four different problems with four different solutions. Treating them as one undifferentiated “communication issue” is a setup for frustration.
And sometimes the biggest barrier isn’t cultural or logistical at all. It’s the gap between what an organization agrees is a good idea and what it’s willing to actually enforce. If you’ve worked in documentation long enough, you know that gap well. You probably live in it.
Reference: Šmite, D., Gonzalez-Huerta, J., & Moe, N. B. (2020). “When in Rome, Do as the Romans Do”: Cultural Barriers to Being Agile in Distributed Teams. Agile Processes in Software Engineering and Extreme Programming, 383, 145–161. PMC7251615.
Leave a Reply