Bridging Engineering and Textiles: Why More Communication Doesn’t Fix Silos
“We’re Communicating… So Why Do We Keep Forming Silos?”
You’re having the meetings. You’re sharing updates. You’re documenting changes. You're even shelling out for the top-tier project management software. And yet, you're still staring at a non-functional prototype. Now you're playing detective, sifting through months of "meticulous" documentation to find the ghost in the machine.
You ask the hard questions: Where did we go wrong? Was it because someone swapped out the old webbing for a "similar" one that was easier to source? Or maybe it was how someone re-oriented the pattern pieces on the grainline to save some money on yardage? Should I change my name, dye my hair, flee the country, and start a new life? But before you go through the bureaucratic nightmare that is updating your passport, I encourage you to ask yourself one more question: have you tried adjusting the way your team communicates, rather than just the frequency?
A lot of the advice for fixing working in silos is the same: increase communication, improve transparency, use better tools, etc. While this advice is completely valid, it assumes everyone speaks the same "language." But in the world of soft goods product development, where teams are cross-functional, that's rarely ever the case. The solution is not to add even more communication, it’s to ensure you’re leaving room for translation.
Why "More" Communication Isn't Working
If you do a quick search for tips on breaking down silos, the advice is almost always the same: Increase transparency. Standardize your processes. Get better tools. Have more meetings. While that’s solid advice on paper, most companies struggling with silos have already tried those things. Often, the result is an over-correction. Instead of fixing the silo, the team ends up buried under "communication debt." They spend more time sifting through Slack threads and "meticulous" documentation than actually doing the work. You haven't removed the silo; you’ve just made it noisier.
Fortunately, the fix isn't about the volume of talk. It’s about the context. Here are three common errors that lead even the best communicators down the lonely road of silos:
1. Only Reporting the "What" but Never the "Why"
2. Filtering Out Updates to be Considerate
3. Prescribing a Solution, Not Describing the Problem
You’re Sharing Updates, Not Reasoning
Most teams are good at documenting what changed. Updates like “foam swapped,” “pattern updated,” or “webbing replaced with alternative” are common and may be sufficient within that team. But from a cross-functional standpoint, they’re incomplete as they only make sense to the person who made them. To everyone else, they’re missing the most important piece of information: why the change happened.
A material swap for something like ease of access or budget might seem inconsequential to your team. But without that context, other teams have no way of knowing what actually changed. Did the compression behavior shift? Did friction increase? Did stiffness change just enough to affect how a component interfaces? Without understanding the reasoning behind the change, they’re less likely to flag that it might influence them, so they don’t think to check.
That also means they don’t get the opportunity to engage with the decision. What looks like a material issue on one team might have been solvable with a small geometry change, an adjustment to load distribution, or a modification elsewhere in the system. But if the underlying problem isn’t communicated, that conversation never happens. Instead, the change moves forward as a neutral update. No one flags it, no one isolates it for testing, and the first indication that something is wrong comes when the full system stops behaving as expected.
The fix isn’t simply more details, it’s making sure those details are usable for other teams. This can feel complicated in cross-functional projects because it’s rarely obvious what changes will impact other teams. Instead of engaging in a guessing game you’ll almost never win, consider anchoring your communication to interfaces. If you’re working on a component that another team interfaces with or depends on, always include three things: what changed, why it changed, and what replaced it.
For example, if you modify the top of a backplate on an exosuit, and you know the soft goods team attaches shoulder straps there, that change needs context. Not just that the geometry was updated, but why it was updated, how it was updated, and what constraint or failure mode drove the decision. That level of detail gives the other team enough information to evaluate whether the change affects their work, even if no one from your side realized it might.
You’re Filtering Out “Irrelevant” Information
No one wants to sit through un-ending meetings or skim through pages of irrelevant updates. You do not want to overwhelm other departments with details that seem unrelated to their work, so you only share the big changes to be considerate. But the road to hell is paved with good intentions. You cannot reliably determine what is irrelevant to another team.
A detail that feels minor within your discipline, like a small change in material thickness, a seam adjustment, or a different surface finish, can introduce a constraint somewhere else in the system. But if that information never gets shared, the other team does not have the opportunity to recognize it or flag it. At the same time, overcorrecting and sharing everything is not a practical solution. When updates turn into a wall of information, people skim. And when people skim, important details still get missed.
So the solution is not to share less or share more. It is to make the information easier for other teams to locate and evaluate quickly. This is where the idea of interfaces becomes important again. If a change touches a component that another team interfaces with, call that out and flag the relevant teams, even if you are not sure whether it impacts them. The goal is not to predict downstream effects on others, but to make it easier for the right people to recognize when something might require their attention.
You can highlight or tag colleagues for the relevant bullet points from meeting minutes, mention those departments directly while presenting at the meeting, or follow up afterwards to make sure the right things are getting flagged quickly.
In a long list of updates, it is very easy for something important to get lost among details that genuinely do not apply. Explicitly signaling who should take a closer look helps ensure that the people who might be affected actually notice the change and follow up. Most importantly, it creates the opportunity to evaluate impact on prototype functionality while the variables are still easy to isolate.
Like all our mothers always said: frequent, low-effort visibility prevents high-effort rework. Your mother didn’t say that? Maybe that was just mine.
You’re Solving Problems for Other Disciplines
Picture this: you’re working on a prototype that’s almost perfect, but there’s a small pressure point because of how the hardware sits against the body. You ask the soft goods team to cover the hardware with foam padding, and they happily oblige. You try the prototype again, and that small pressure point has turned into a bigger one. You’ve just walked into one of the sneakiest silo traps in existence.
If you had instead told the soft goods engineer that the hardware was creating a pressure point, they could have evaluated the prototype and suggested a different approach, like building a foam structure around the hardware so it sits flush against the skin.
When you prescribe a solution in an area that is not your expertise, you are making assumptions about how that system behaves. Those assumptions might be reasonable within your own discipline, but they can be completely off when applied to someone else’s. The most useful thing you can do in these situations is communicate the problem instead of the solution.
That does not mean you cannot make suggestions or explain your preferences. But if you only communicate a solution, you are telling another team how to do their job and limiting the range of options they will consider. When you communicate the problem, you give them the information they need to apply their expertise.
This is one of the most effective ways to prevent wasted time and rework. It also creates space for better solutions, including ones you may not have considered, because the right people are solving the right problem.
Bridging the Gap
Silos rarely form because teams are not communicating. More often, they form because the communication that is happening is not structured in a way that other disciplines can actually use. Throughout development, teams are constantly making reasonable decisions in isolation. They document updates to stay organized, filter information to avoid overwhelming others, and suggest solutions to move things forward. None of these behaviors are wrong on their own. The problem is that they are all local decisions in a system that behaves globally.
When teams operate from different mental models, small gaps in context, filtering, or framing do not stay small. They compound. By the time those gaps show up as a failure, it is no longer obvious which decision caused it, only that something is no longer working. That is how you end up with a prototype that no one can quite explain. Not because any one decision was a mistake, but because no one had full visibility into how those decisions interacted.
Fixing this does not require more meetings or more documentation. It requires being intentional about how information moves between teams. Explaining why decisions are made, not just what changed, sharing details at the points where systems interface even when you are not sure they matter, and describing problems clearly so the right discipline can determine how to solve them all make it easier for teams to work from the same understanding.
These are small shifts, but they change how teams work together. They make it easier to catch issues early, before they are buried in a fully integrated system, and they create space for better solutions because the right people are solving the right problems. At the end of the day, cross-functional work is not just about building a product. It is about building a shared understanding of that product across teams that think about it in completely different ways. When that understanding is in place, silos do not have much room to form.
