Working in the Open

I’ve been thinking recently about what makes technical work successful over the longer term. We tend to recognise progress through the things we can point to: a new platform, a completed integration, a faster pipeline or a system that has finally gone live. Those achievements matter, but they don’t always tell us much about the way the work was done or whether the organisation is better equipped to maintain it.

Some of the most useful progress I’ve seen has happened in conversations that never appear in a delivery plan. Someone questions a definition that everyone else has accepted. An operational colleague explains why a process behaves differently from the way it was documented. Two technical teams discover that they’ve been solving related problems independently. None of this looks particularly impressive on a project dashboard, but it can change the direction of the work considerably.

Making thinking visible

I recently heard a line that stayed with me: “The power in technology does not come from the code that we write or the systems we build. It comes from bringing the right people together to solve the business problems that matter.” I don’t take that as a dismissal of engineering. If anything, it places greater responsibility on engineers to understand what their work is intended to achieve.

Collaboration is sometimes mistaken for consensus. In my experience, the two are quite different. A productive team doesn’t need everyone to agree at the outset. It needs people to be able to explain their reasoning, expose assumptions and challenge decisions without turning disagreement into a personal contest. That is particularly important in data work, where two people can use the same term while meaning quite different things.

If those differences remain hidden, they eventually surface as conflicting reports, unexpected system behaviour or arguments about which figures are correct. Making the thinking visible early gives us a chance to understand whether we’re dealing with a genuine disagreement about the business or simply different interpretations of the same requirement.

The conditions for good collaboration

Psychological safety is often discussed as a matter of culture, and rightly so, but I think the structure of our work contributes to it as well. When important logic exists only in one person’s head, asking questions can feel like questioning that person. When decisions and assumptions are documented, the discussion can move towards the evidence instead.

Clear ownership, accessible documentation, versioned definitions and testable assumptions make it easier for people to contribute and easier for others to pick up the work later. They don’t remove the need for trust between colleagues, but they help create conditions in which trust can develop.

This is the kind of approach I want MycoFlow Systems to represent. Building connected systems is part of the work; building a shared understanding of why those systems exist is just as important. The most durable outcomes rarely come from one person having all the answers. They come from creating an environment in which different people can contribute to a better answer together.