Episode 31 — Collaborate and Promote Visibility to Break Silos and Surface Reality
In this episode, we take up a principle that sounds friendly on the surface but becomes much more serious once you place it inside real service work. Many beginners hear collaborate and promote visibility and assume it simply means people should be nicer to each other, share updates more often, and avoid working alone. That is part of it, but the principle goes much deeper because modern services often fail not because people are lazy or careless, but because useful knowledge is trapped in separate places and important realities stay hidden until they become expensive. The Information Technology Infrastructure Library (I T I L) uses this principle to push organizations away from isolated decision making and toward a more connected way of seeing work, users, risks, and outcomes. When collaboration improves and visibility grows, teams stop guessing so much about one another, hidden dependencies become easier to spot, and the service starts to reflect what is actually happening rather than what each group assumes is happening. That is why this principle matters so much. It helps break silos and surface reality before reality forces its way into the room through failure, confusion, or repeated disappointment.
Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.
The first part of the principle is collaboration, and it is worth defining carefully because people often reduce it to meetings, polite behavior, or vague teamwork language. Real collaboration means the right people are able to share understanding, contribute perspective, coordinate action, and influence decisions in ways that improve the service as a whole. It is not just about being included in a conversation. It is about bringing together the knowledge needed to make better choices about outcomes, tradeoffs, dependencies, and risks. In service work, no single team sees the entire experience from beginning to end, which means every team is holding only part of the truth. The support team hears user frustration, technical teams understand system constraints, business teams see policy goals, and leaders shape priorities and boundaries. If those perspectives remain disconnected, the organization makes weaker decisions no matter how talented the individual teams may be. Collaboration matters because it combines partial truths into a fuller picture, and services almost always improve when choices are based on a fuller picture instead of on a single viewpoint pretending to be complete.
The second part of the principle is visibility, which is just as important and often even more misunderstood. Visibility means making important information, constraints, progress, risks, dependencies, and real service conditions easier to see for the people who need to understand them. That does not mean every piece of information must be shown to everyone all the time. It means the organization should not allow the real state of the service to remain hidden behind local assumptions, incomplete reporting, or separate departmental stories that never get compared. Visibility helps people see how work is actually flowing, where it is getting stuck, what users are experiencing, and what tradeoffs are already shaping the service. Without visibility, collaboration becomes shallow because people are trying to work together while looking at different fragments of reality. With visibility, collaboration becomes much more useful because shared facts and shared observations make shared judgment possible. The point is not simply to increase awareness in a general sense. The point is to help the right people see the conditions that matter so that action becomes more informed and less distorted.
Silos are what form when collaboration and visibility are weak, and they are more common than new learners often realize. A silo exists when a team, department, or function works mainly from its own local view, local incentives, and local information, with limited connection to the wider service experience. Silos are not always created by bad intentions. They often appear because organizations divide work for sensible reasons, such as specialization, efficiency, or accountability, and then fail to reconnect those divided areas around the actual service journey. A support team may understand user pain but not know why technical changes are delayed. A product team may improve features without realizing support staff are creating workarounds to compensate for unclear messaging. A leadership group may receive reports that show activity and progress while missing the fact that users still feel lost and frontline staff still feel overwhelmed. The deeper problem with silos is not just separation. It is distortion. Each group sees enough to feel confident, but not enough to understand how its decisions affect the whole. That is why the principle matters. It is trying to reduce distortion by reconnecting separated perspectives around the reality of the service.
Surface reality is an especially useful phrase in this topic because services often look healthier from a distance than they feel up close. On a dashboard, a service may appear stable because uptime is high, response times are acceptable, and change activity is moving forward on schedule. Yet users may still find the service confusing, staff may be inventing manual workarounds every day, and certain types of requests may be bouncing between teams without ownership. Reality in service management is not just the official report. It is the lived experience of the people using the service and the people carrying the work behind it. Promoting visibility helps surface that reality before it becomes a crisis. Collaboration helps the organization interpret what it finds instead of allowing each group to explain away the evidence from its own point of view. This is one reason the principle is so practical. It acknowledges that services fail quietly before they fail loudly, and it encourages organizations to make that quiet strain visible while there is still time to learn from it and respond intelligently.
Imagine a community college trying to improve its digital student portal for registration, financial aid updates, and course deadlines. Students say the experience is stressful because reminders arrive at odd times, status messages are hard to interpret, and it is never fully clear which next step matters most. The support team feels the pressure immediately because students contact them in large numbers during peak registration periods. The technical team believes the platform is functioning well because system performance is stable and login success remains high. Advisors think the real issue is that students do not read instructions carefully enough, while leadership sees reports showing that several improvement projects are already underway. Each group holds part of the picture, but the service still feels weak because the parts are not being connected. The organization is living inside silos even though everyone is working hard. Collaboration and visibility would not magically remove the portal’s problems overnight, but they would create the conditions for a more truthful diagnosis. Once teams compare what students experience, what support hears, what the system reveals, and what advisors observe, reality becomes much harder to ignore and much easier to respond to wisely.
In that college example, collaboration changes more than the tone of conversation. It changes the quality of decision making because people begin to understand how their local observations connect to the wider service journey. Support can explain where students become uncertain, technical teams can show which functions are actually reliable, advisors can clarify where process language becomes misleading, and leaders can see whether current improvement work matches the real pain in the service. This does not mean every meeting suddenly becomes productive just because more people are present. Collaboration becomes valuable when it is tied to a shared goal, a shared problem, and a willingness to listen across boundaries that usually keep work separate. Once that begins, teams often discover that what they thought was a technical problem is partly a communication problem, or what they thought was a user discipline problem is partly a design problem, or what they thought was a staffing issue is partly a process visibility issue. Breaking silos works this way because collaboration exposes the limits of isolated explanations. It helps people move from defending their slice of the truth to contributing it toward a more complete understanding.
Visibility strengthens that process by making the service more knowable in daily life rather than only during formal reviews. A team should not have to wait for a quarterly meeting or a major complaint to learn that users are repeatedly misunderstanding a key step or that support staff are spending hours compensating for unclear notifications. Promoting visibility means surfacing those patterns in ways that are understandable and timely enough to influence action. In the college portal case, that might mean making recurring support issues easier for improvement teams to see, helping advisors understand where communication is causing confusion, and showing leaders how user uncertainty is affecting the wider service experience. Visibility is not the same as surveillance, which is an important distinction. The goal is not to watch people more closely so they feel controlled. The goal is to understand the service more clearly so people can improve it. When organizations confuse visibility with surveillance, they create defensiveness and fear. When they treat visibility as shared understanding, they create the conditions for learning, coordination, and trust across teams that no longer have to guess what is happening elsewhere.
This principle has a strong relationship to value because services create value through connected experiences, not through isolated departmental success. A team can meet its own goals and still contribute to a weak overall service if its work is disconnected from what happens before and after it in the user journey. The student portal technical team may achieve strong performance targets, yet students may still feel lost if the wording of alerts is unclear and support guidance is inconsistent. The support team may answer questions quickly, yet the overall service may still feel poor if repeated confusion is never visible to the teams responsible for design and process improvement. Collaboration and visibility bring service work back to the full journey, which helps the organization focus on what users are actually trying to accomplish instead of on what each function can claim as a local success. This is why the principle matters inside the wider ITIL model. It helps organizations think and work holistically, because it is very hard to see the whole or improve the whole when the truth about the service is scattered across separate teams that rarely compare what they know.
The principle also works closely with several other guiding principles, which makes it easier to understand why it matters beyond simple teamwork language. Focusing on value gives collaboration a purpose, because people come together not merely to exchange opinions but to improve meaningful outcomes. Starting where you are becomes stronger when visibility reveals the true current state instead of a polished summary that hides friction. Progressing iteratively with feedback becomes far more useful when the feedback is not trapped inside one team but shared across the parts of the service that need to learn from it. Thinking and working holistically depends on collaboration and visibility because the whole cannot be understood from isolated fragments. Keeping it simple and practical also benefits, because many layers of waste remain hidden until people compare how work actually moves between teams and where confusion is being created. Even optimizing and automating become safer when collaboration and visibility are present, because organizations are less likely to automate broken or poorly understood work if the full service reality is visible before major change begins.
Now picture a different situation in a neighborhood health clinic that offers digital appointment booking, automated reminders, and follow up messages after visits. Patients report that reminders are inconsistent, some preparation instructions arrive too late, and appointment changes are not always reflected clearly across the service. Administrative staff believe the biggest issue is patient behavior because many patients seem to ignore messages. Technical staff believe the platform is functioning because messages are being sent on schedule according to system rules. Clinical staff believe the deeper problem is that preparation instructions are too complicated and too late in the journey to be useful. Leaders see complaint numbers rising but do not fully understand where the weakness begins. This is a perfect example of why collaboration and visibility matter. Without them, each team can keep telling a believable local story while the patient experience keeps degrading. With them, the clinic can discover that timing, wording, workflow ownership, and patient expectations are interacting in ways no single group could see alone. The service becomes easier to improve once the organization can see the reality it was previously living inside without fully understanding.
Leadership and governance matter here as well, because collaboration does not sustain itself automatically and visibility does not appear just because people say they want more of it. Organizations need decision rights, expectations, and routines that encourage truth to travel across the service instead of remaining locked inside functional boundaries. Leaders help by clarifying that shared service outcomes matter more than local image protection, and by creating an environment where surfacing risk, confusion, or recurring failure is treated as useful information rather than as a personal embarrassment. Governance contributes by making sure the right questions are asked about service health, user experience, ownership, and dependencies, rather than only asking for tidy progress reports that reward surface success. This is important because many silos survive not through malice but through incentives. If teams are rewarded mainly for looking good within their own lane, they will be less likely to surface messy truths that make the wider service easier to understand. Collaboration and visibility become much stronger when leadership and governance make reality safer to reveal and more worthwhile to act on.
There are also several traps that organizations can fall into while trying to apply this principle. One trap is mistaking more meetings for better collaboration, even when the meetings are unfocused and add very little shared understanding. Another trap is creating status theater, where visibility means polished dashboards and selective updates that hide the most important problems behind attractive formatting. A third trap is confusing openness with overload, as if promoting visibility means every person needs every detail all the time, which usually creates noise rather than clarity. There is also false collaboration, where teams attend shared sessions but still defend narrow positions without genuinely adjusting their understanding. These traps matter because they allow an organization to look collaborative while remaining siloed in practice. Real collaboration is purposeful and tied to service outcomes. Real visibility makes meaningful realities easier to understand and act on. When those qualities are missing, the organization may feel busier and more communicative while still failing to surface the truths that actually need attention.
For a beginner, one of the most useful ways to apply this principle is to start asking simple but powerful questions whenever a service problem or improvement effort appears. Who sees the user experience directly, and who only sees it through reports. What important knowledge is trapped in one team and not reaching the teams that design, support, or govern the service. Where are people compensating for weak process or unclear communication without anyone treating those workarounds as service evidence. What part of the reality is still hidden because no one has connected the separate views. These questions do not require advanced technical knowledge, which is why they are so valuable for brand-new learners. They train you to notice fragmentation and ask how understanding could become more shared. Over time, that habit helps you hear service work in a more connected way, and it makes it easier to spot when an organization is mistaking local confidence for genuine end-to-end understanding of the value it is actually delivering.
By the end of this discussion, collaborate and promote visibility should feel like much more than a call for friendliness or a general preference for communication. It is a practical response to one of the deepest causes of service weakness, which is the separation of knowledge, decisions, and lived experience across teams that rarely compare what they know. Collaboration brings those partial truths together so decisions improve. Visibility helps surface the real state of the service so those decisions are grounded in what users and teams are actually experiencing. Together, they help break silos and surface reality before reality arrives in the form of repeated failure, avoidable rework, or loss of trust. In modern digital products and services, where no single team sees the full picture on its own, that is an essential discipline rather than a soft extra. When you understand the principle this way, it becomes much easier to see why ITIL treats it as a serious guide for better value creation. Services improve when truth moves more freely across the people responsible for creating, supporting, and improving them.
