Informal networks in organizations are the trust-based relationships that form parallel to official structures, connecting people across teams outside of assigned roles or reporting lines. They determine who people actually turn to when challenges arise. In software development, these networks shape collaboration, resilience, and product quality more directly than formal processes can.
Key Takeaways
- Informal networks run parallel to formal org structures and carry more weight in crises because they are built on trust, which formal processes cannot manufacture.
- Remote and hybrid work scale existing cultural problems rather than create new ones: teams that already had trust adapted more easily, teams that lacked it struggled harder.
- Product discovery improves when people from different backgrounds, including newcomers who carry no product history, learn from user feedback together and then return to their teams already aligned.
- Explicit alignment conversations, where team members openly discuss what good collaboration looks and feels like for them, prevent misunderstandings that would otherwise surface as conflict under pressure.
- Introverted team members form fewer but often higher-quality relationships, and a well-designed environment such as a hackathon gives them space to connect on their own terms without forced participation.
What informal networks are and why they decide team performance
Informal networks are the relationships that grow alongside the official org chart. They form not because a manager assigned them, but because people choose to talk to each other.
The starting point is simple. Given the choice between working with a person assigned to you and a person you picked yourself, most people prefer the one they chose. That is human nature, and it shapes how well the work goes.
When the environment makes it easy to communicate with people you trust, the chances rise that you enjoy the work and do it well. For testers this matters directly. A tester is not someone running routine checks on a factory line. Quality work is complex, and it runs on communication with other people.
The official structure tells you who reports to whom. The informal network tells you who you actually go to when something draws your attention. Often that is not your direct teammate, and not every teammate is someone you would approach. That gap is where informal networks make the difference.
How informal networks form
They form through ordinary contact, and they form faster when someone deliberately opens space for it. Both routes work, and the second is the one teams underuse.
Yuliia Pieskova points to a moment that changed how she saw this. She was onboarding a friend, a junior developer, into a small startup. He had a talent for organizing people, even if he did not yet know much about the product. Instead of the usual hand-holding, introducing him everywhere and protecting him, she gave him more freedom.
She connected him with a newly formed HR department the team had barely worked with. Go talk to them, shadow them, see how they do things. He came back, and the result was effective. From that point he started initiating other activities, and the level of involvement across the team shifted.
The lesson she drew: informal networks are not just an organic side effect you watch from a distance. You can influence them. You can build environments where people explore and connect, and an open format like a hackathon does that better than a closed, tightly facilitated session.
Trust is the real currency, and no process can install it
Informal networks matter because they carry trust, and trust is what lets a company adapt when conditions change.
Formal networks fall short for two reasons. First, you cannot define them well in advance, because you do not know what will happen, so you cannot optimize for it. Second, they do not carry enough trust. When something goes wrong and you feel uncertain, you need to be able to talk to someone, and acting on a risk needs even more trust and closeness.
Adapting always involves risk. You take on something new without knowing whether it will succeed. With people around you that you rely on and trust, you become more able to act. That also takes pressure off the organization, which no longer has to obsess over whether the formal structure is perfect and whether the right two people are connected on the graph.
A company can declare that everyone trusts each other. In practice, trust is not something a process pushes into people. Some leaders believe they can mandate it. The teams show otherwise.
How remote work scaled the problems that were already there
Remote and hybrid modes did not create the trust gaps. They exposed and amplified problems that already existed.
Where the culture of trust was already in place, the move to remote went more smoothly. If you trust a developer and they say they are not feeling great and turn the camera off, it does not matter. Without that trust, someone working off-camera feels uncomfortable to everyone involved.
The unplanned interactions that used to happen on their own now need a substitute. The water cooler, or for some the coffee machine, was where those moments occurred. When that disappears, you have to compensate, and you have to find something people actually want to join, not a forced coffee chat that feels like one more hour at the screen.
Remote also brings real advantages. It flattens location differences. A person in Munich and a person in Berlin meet on the same footing, and silos between sites become easier to break. People who never had the same in-office rituals can mix and organize around shared topics.
Events like hackathons let people self-organize around the work, collaborate with someone for the first time, and pet their cat between sessions. That combination was close to impossible before.
Why product discovery belongs to more than the product owner
Product development gains from informal networks when discovery becomes a shared activity rather than the product owner’s solo task.
Discovery used to sit mostly with a product manager or owner: talk to clients, review analytics, work out what people want. The shift now is to pull people from different areas into that work.
That does not mean the whole development team interviews every new client. It can mean reviewing metrics together, watching how users interact with the website through session recordings, or joining a product review. What fits depends on the product itself.
The point is to put people with technical depth and people with a product view in the same room while they learn what users actually do. They brainstorm together, then carry that shared picture back to their own teams already aligned with everyone else.
Newcomers add a specific value here. They are unbiased and carry no history of the product, so they ask open questions precisely because they do not know the answers. By feedback from users, Yuliia means the broad sense: not only what people say in an interview, but how they behave with the product.
When people from marketing, UX, and other areas work through discovery together, they leave with relationships, not just contact names. Back in their own teams they know who to reach, and a first layer of trust is in place. Repeat that, and the networks compound.
Introverts do not need four relationships each
The goal is not that everyone holds the same number of connections. People who are more introverted at work may keep fewer ties, but those ties can run deeper.
The wrong move is a target like “every person needs a relationship with this department and that one.” People differ. Forcing relationships into yearly objectives misses how trust actually grows.
The better path is to ask and then step back. Ask how someone feels, what would make collaboration easier, what support helps. Then create an environment where working across teams is rewarded, invite people to the hackathon or the gathering, and trust them to connect in the way that suits them.
You design the space and the invitation. You do not drag people into it.
Alignment is the cheapest way to build team trust
Before any process, start with alignment: an open conversation about how people want to work together.
Ask the direct questions. What does good teamwork look like for you? Which way of communicating works, and what is hard? How should we handle the moments when something goes wrong? Technical people often stall on these questions until you give real examples, so use concrete ones rather than abstractions.
Culture shapes how feedback lands, and naming that upfront prevents damage. Yuliia comes from a very direct culture where imperative requests are normal. Working with people from Great Britain, she flags this in advance, because direct feedback that feels ordinary to her can read as rude to them. In the other direction, feedback wrapped in soft words can leave her unsure whether it was positive or negative.
If it doesn’t make sense to you, then we are wasting our time here. Yuliia Pieskova
Agreeing on these things in advance saves the back-and-forth later. You spend less time talking and more time doing the work, because the misunderstandings got handled before they happened. The exercise is most useful with new people, in new teams, or when an old way of working is being replaced.
Organizational structure should still enable all of this. It should be easy to message someone and easy to see who works on what. That layer is harder to influence. Teamwork, at the team level, is the part you can shape directly.
Name the pink elephant before you run the workshop
When you join a team, address the resistance openly instead of papering over it with a polished workshop.
A new person often arrives carrying change, and the team knows it. A flashy session full of glitter and unicorns ignores the real situation in the room. Saying out loud what people are already thinking builds the first piece of trust and opens an honest conversation about what you plan to do.
The wider business culture still leans toward the “I” rather than the group. Doing something as a pair or a trio is not yet the default, even though it works. Pairing with someone who has a good reputation in the team, and translating your workshop into that team’s language, makes the whole thing easier to land.
So when you bring new people in, consider pairing or a trio of mixed experience rather than handing out isolated tasks. For a single workshop a trio might be overkill. As a habit for how teams take on new people, it is worth trying.
