In software development, I strongly believe that making things visible is one of the most important practices for building the right solution.
By “visible,” I mean things that people can see, discuss, and react to — not only written requirements or ideas kept in documents or in our heads…etc.
Very often, developers start with abstract designs or detailed internal structures. But in my experience, it is usually more effective to begin with UI fields, API contracts, or integration models. More visible parts…These parts of the system interact directly with users or other systems. Because of that, they provide real and early feedback. Making interaction channels more open in the beginning, helps software solutions to be more effective. When something is visible, misunderstandings appear faster. Gaps become clearer. Learning starts earlier.
Visible Assumptions
Assumptions are another area where visibility matters a lot. In an ideal situation, we would always work with real data and facts. We aim to create deterministic solutions. But in reality — especially in agile environments, where things change quickly — data is often incomplete or missing or changes a lot. In such cases, assumptions are unavoidable to start doing something.
I don’t like making assumptions, but I evolve by time and learn also. The real risk is not making assumptions. The real risk is hiding them.
When assumptions are written down and shared, they become open for discussion and validation. Even wrong assumptions are useful if they are visible, because they can be corrected early. This reduces rework and improves decision-making over time. Sometimes even product owners/managers cannot have a clear view. Making assumptions visible also helps people to ask correct questions and clear the view.
Visibility for Safety
Making things visible also creates safety within teams. When work, decisions, and uncertainties are visible, teams understand not only what they are building, but also how and why. This clarity increases self-confidence. And when confidence grows, ownership naturally follows. Teams that feel safe and confident tend to take better care of quality. Visibility supports this by reducing surprises, fear, and hidden expectations.
Visible Communication
Visibility is equally important in communication with stakeholders.
A common example that I see a lot is capacity planning. Many teams plan with 80% capacity instead of 100% to allow time for support, meetings, and operational work. This is realistic. However, often only the planned work is visible, while the remaining capacity is hidden. When this invisible work is not communicated, stakeholders may misunderstand progress or delivery speed. Making this work visible — or at least explicitly stating that it exists — helps everyone align around reality instead of assumptions.
At the same time, visibility must be useful and intentional.
Not everything needs to be visible to everyone. Too much information creates noise. What matters is:
- The right information is visible to the right stakeholders
- Stakeholders share a same understanding of the situation
- If something cannot be shared, people are at least aware that it exists
This kind of visibility builds trust without overwhelming people.
For me, making things visible is not about control or micromanagement. It is about shared understanding, safety, and ownership. I believe that those are some big key values for a effective software development team.
When things are visible:
- Feedback comes earlier
- Assumptions are challenged faster
- Teams feel safer and more confident
- Ownership and quality improve
That is why, in solution, project, and product development, I always try to encourage teams making things visible in software development — even when it feels uncomfortable.
Because visibility is where learning, trust, and better software begin.
