Informal networks in a company are the relationships of communication and trust that form alongside the formal structure and can’t be planned. They determine who people turn to when things are uncertain and how quickly an organization can adapt. In product development and software testing especially, they make possible the kind of cross-department collaboration that no process document can force.
Key Takeaways
- Informal networks grow alongside the formal structure and decide who people actually turn to when a problem comes up: not just any colleague, but someone they trust.
- Trust can’t be enforced through processes. A company can define formal communication channels, but whether people really trust each other and act on that trust is beyond any instruction.
- Organizations with well-grown informal networks adapt faster to changing requirements, because trust is what makes it possible to take the risk of trying something new.
- Cross-functional product discovery, where people with technical and product backgrounds analyze user feedback together, also strengthens the informal ties between departments.
- Introverts don’t need a target number of relationships. They need open spaces such as hackathons, where they can connect with others without pressure.
What Are Informal Networks in a Company?
Informal networks are the lines of communication that form alongside the formal organizational structure. You won’t find them on any org chart, yet they decide who you turn to when something happens.
That also answers the question of how formal and informal networks differ. The formal network is the org chart and the official reporting lines. The informal network is who actually talks to whom, based on trust rather than position. Informal communication is everything that travels along these paths: the quick question, the heads-up, the conversation that never goes through official channels.
Yuliia Pieskova explains the mechanism with a simple observation: working with people you’ve chosen feels different from working with people you’ve been assigned. This has to do with intrinsic motivation, not with any flaw of character. The better the conditions for communication, the more likely the work is to succeed.
When you have a real question, you rarely go through official channels. You ask the person you trust. And that often isn’t the colleague next to you on the org chart, but someone from a completely different part of the company.
Trust Is the Foundation of Any Collaboration
Informal networks only work if there is trust. Without it, nobody talks openly about what they’re unsure of, and nobody takes a risk.
Formal structures lack exactly this trust. When something goes wrong and you’re stuck, you need someone you can talk to without having to justify yourself. You need even more trust to act, to try something new and to take the risk that comes with it.
Trust can’t be prescribed by a process. Some organizations believe they can order it. In practice, you can say “of course we trust each other,” but you have no direct control over whether that’s true. Trust grows from working together, not from an announcement.
This matters a great deal for testers. Reporting bugs depends on a relationship in which the person reporting isn’t seen as an attacker. A culture where the tester is labeled the bearer of bad news before saying a word blocks exactly the collaboration that quality depends on.
Informal Networks Decide How Well an Organization Adapts
Informal networks are the best test of an organization’s resilience. The faster a company can adapt to new requirements, the more it relies on these channels rather than on the org chart.
Formal networks hit two limits here. First, you can hardly define them in advance, because nobody knows what will happen next. Second, they lack the trust it takes to act when the situation is unclear.
People who have colleagues they trust at their side are better able to act. That also means less stress for the organization. Otherwise the familiar game starts: the org chart gets redrawn again and again because two units that ought to be talking simply don’t.
Remote Work Exposes Existing Problems, It Doesn’t Create Them
Remote and hybrid work have made visible problems that were there all along. Teams with a working culture of trust found the switch easier, because the foundation was already in place.
Take an example. If you trust a developer and they say they don’t feel like turning their camera on today, that’s fine. Without trust, the same switched-off camera immediately becomes an issue. The behavior is the same. How it’s read depends on trust.
Distributed work has real advantages too. Silos between locations are easier to break down, because on a call it makes no difference whether someone joins from Munich, Berlin or another country. The chance encounters at the coffee machine are gone, so you need deliberately designed opportunities to replace those unplanned contacts.
A mandatory coffee call is not the answer. Being asked to show up for compulsory small talk after eight hours at the screen feels like one more burden. What works are formats where people find something interesting and join voluntarily.
Product Development Benefits from Mixed Teams
Modern product discovery depends on people with different backgrounds analyzing user behavior together. It used to be the product manager’s job alone to talk to customers and go through the analytics.
Today, people from different areas can take part. That doesn’t mean the whole development team goes to visit the customer. It means going through the metrics together, watching recordings of people using the product or working directly with users as part of a product review.
User feedback here doesn’t just mean what users say in an interview, but how they actually use the product. Watching that brings technical knowledge and the product perspective together.
When these people go back to their teams, they bring a clear, shared picture with them. They’re on the same page as everyone else, and the relationships they formed along the way keep working. An abstract department turns into a person you’ve worked with and can call.
Newcomers are underrated in this. They don’t know the product’s history, so they ask unbiased questions, precisely because they don’t know any better. That openness is worth using on purpose.
How to Include Introverts Without Forcing Them
Give introverts room and trust them to build relationships in their own way. They often have fewer contacts at work, but deeper ones.
It makes no sense to give everyone the same quota. Nobody needs “four relationships with this department and four with that one” as an annual goal. People are different.
A better approach is to create an environment where collaboration is rewarded, and then let people find their own way. Ask how someone is doing and how you can help. Invite them to a hackathon or an informal get-together. People who feel comfortable will make the connections themselves.
The attitude behind this: create spaces, invite, trust. Don’t force people into a structure.
Alignment Is the Concrete First Step
Alignment means talking openly about how you’ll work together early on, before the work starts. What does good teamwork mean to you? What kind of communication works for you, and what do you find hard?
Technical people often push back on this, because it sounds like soft stuff with little substance. That’s why real examples work better than abstract appeals.
Yuliia uses her own. She comes from a very direct culture where phrasing a request like an order is completely normal. Working with people from the UK, this led to misunderstandings again and again, because direct feedback came across as rude there. The other way round, their feedback seemed too vague to her, wrapped in so many friendly words that she couldn’t tell whether it was praise or criticism.
“If it doesn’t make sense to you, then we’re just wasting our time here.”
(Yuliia Pieskova)
Naming these differences up front takes the sting out of them. If both sides know a reaction may come out direct or vague, they can talk about it instead of taking offense. After that, the work itself takes over and less needs to be said.
Alignment is something you can do at team level. The organizational structure is hard to influence. How your own team works together is not.
Addressing the Elephant in the Room
When you join a new team, say out loud what everyone is thinking and nobody is saying. Often a team doesn’t want change, and the person who is supposed to bring it knows that.
A polished, elaborate workshop feels out of place in that situation. The team would see whoever runs it as out of touch. Saying openly that you see the skepticism is the first step toward trust.
It helps to bring in someone the team respects, someone who speaks the group’s language. That way you don’t prepare something on your own that misses the team’s culture.
Yuliia adds a broader observation: the working world is still dominated by a “me” culture. Doing things together is rarely treated as the default. If it were more normal for new people to learn how to work together first, rather than just their task, getting started would be easier for everyone.
Frequently Asked Questions
Can a company mandate trust among employees through a process?
No. Formal communication channels can be established, but whether people actually trust one another and act accordingly is beyond the scope of any directive. The statement “Of course we trust each other” does nothing to change the reality on the ground. Trust is built through working together. Only then will someone speak openly about uncertainty or take the risk of trying something new.
Why do testers in some teams find it difficult to report bugs openly?
Because reporting requires a relationship in which it isn’t perceived as an attack. Where a tester is already seen, even in passing, as the bearer of bad news, this culture blocks precisely the kind of collaboration that quality requires. Anyone who is stuck needs someone they can talk to without having to justify themselves.
Why aren’t formal structures enough when requirements change rapidly?
They run into two limitations. First, they’re almost impossible to define in advance because no one knows what will happen next. Second, they lack the trust needed to take action at all in an unclear situation. Otherwise, you end up in a cycle where the organizational chart is constantly being redrawn because two departments aren’t communicating with each other.
Has working from home worsened collaboration within teams?
No, it has brought existing problems to light. Teams with a functioning culture of trust adapted more easily because the foundation was already in place. Here’s an example: If a developer says they don’t want to turn on their camera today, that’s not a problem when there’s trust. Without it, the same behavior immediately becomes a burden.
Do virtual coffee breaks replace spontaneous encounters in the office?
The forced “coffee call” isn’t the solution. Anyone asked to participate in a mandatory chat after eight hours in front of the screen perceives it as an additional burden. What’s needed are formats where people voluntarily find something interesting. Remote work has its own advantage here: silos between locations break down more easily because location doesn’t matter during the call.
What are the benefits of involving developers and testers in product discovery?
They bring a shared perspective back to their teams and forge connections that have a lasting impact. An abstract department becomes a person you can call. This doesn’t mean the entire development team travels to the client’s site, but rather that they go over metrics together, watch user videos, or interact directly with users during a product evaluation.
Do quotas for the number of cross-departmental contacts make sense?
No. Setting an annual goal of “four relationships with this department and four with that one” doesn’t make sense because everyone works differently. Introverted colleagues often have fewer contacts, but deeper ones. A more effective approach is an environment where collaboration is rewarded, along with invitations to hackathons or casual get-togethers. People who feel comfortable will make connections on their own.
How should you proceed if a team is skeptical about a change?
Address the elephant in the room: what everyone is thinking but no one is saying. A lavish, high-profile workshop seems out of place in this situation and makes the newcomer appear out of touch with reality. Openly acknowledging that you see the skepticism is the first step toward building trust. It also helps to have an ally with a good reputation within the team.
