Ever noticed how many OSS decisions are made by people who have never set foot on site?
What if your single most powerful OSS upgrade this year is a day riding shotgun with field techs in a hi-viz vest?
This article digs into the quiet damage that OSS experts with a total lack of field time does to our processes, tools and data.
.
Introducing the hi-viz gap
In most OSS teams there is a hidden fault in the system. We have architects, designers, business analysts, product owners, product users and vendors making high-impact decisions about networks they have only ever seen as diagrams or data models. They work hard, they mean well, but they are desk-only by design.
The result is a hi-viz gap.
On one side you have the people in hi-visibility vests and steel-capped boots, opening pits, climbing ladders, tracing cables, dealing with access issues and customers in the field. They’re also the ones who turn network designs into reality.
On the other side, we have people in meeting rooms defining user interfaces, processes, schemas and workflows. When too few people have lived on both sides, your OSS drifts away from physical reality. If they haven’t worn hi-viz, then they often don’t have hi-viz context over the OSS they’re building and using.
It sometimes scares me how many OSS experts have never spent a day in the field or in a NOC and are missing important contextual awareness.
Here are 12 reasons why simply putting more people in hi-viz vests and taking them into the field makes your OSS noticeably better.
.
The hidden hi-viz gap in today’s OSS teams
- You have a better context of what you’re building
There are a lot of acronyms and technical descriptors in the telco world. From joints to pits; from poles to ducts; from cabinets to racks; from lead-ins to catenary wires; from joints to nodes; from cables to splices; from amplifiers to taps. Just seeing each of these equipment types, how they’re connected, commissioned and tested, adds context to the data and processes that you observe in the digital twins we call OSS. Even the concept of size and how they fit into their surrounds (eg a splice joint mounted inside a pit, where three cables are terminated and spliced)
- You see physical constraints that never show up in workshops
Workshops are full of clean whiteboards and idealistic assumptions. Sites are full of mud, noise, cramped racks, sun glare on screens, poor lighting, tight corners, weather, traffic, obscure faults and customers. All those customers. The moment an OSS person squeezes into a tiny equipment room or works beside a busy road, they start reconsidering all the “simple” steps or designs they created. That experience alone kills a lot of invisible assumptions that back-office workers make about usability in the field
- You stop treating techs like data-entry clerks
From a desk it feels harmless to add “just one more field” or “just one more approval” to a workflow. On site you watch a tech juggle tools, test gear, a ladder, a tablet, safety equipment whilst being engaged in a customer conversation. Suddenly that extra mandatory field is not a rounding error, it is a genuine drag on the job. All those extra points of friction mean they only get 4 jobs done in a day, not 5 (oh, and did you know they’re paid by the job, not the hour in many cases?). After a day in hi-viz, you naturally strip away non-essential capture and focus on what truly matters to get the work done
.
How field blindness corrupts processes, data models and tools
- Your data models finally match how networks are actually built
From the office, a network model is boxes and lines (which might not represent connected, structured data BTW). In the field, it is trays, splices, non-standard labels, ad hoc joints, legacy gear, creative mounting choices and odd one-off fixes from the last twenty years (it might even use a plastic Coke bottle instead of a splice enclosure – I wish I had a photo of that one!!). When designers see real pits, ducts, splice closures and racks, they start to get a better understanding of the entity models that reflect what is really there, not what the original standard said should be there
- Your processes start to streamline
A bit like #3 above, “field blindness” can lead to bloated processes. Every exception that pops up in governance gets handled by adding another step, another role, another approval. Once you have watched three or four real jobs end to end, you can see which steps can be logically combined (ie are noise), which can be automated and which are genuinely critical for safety, quality or billing. The process becomes leaner because reality forces you to
- Inventory accuracy stops feeling impossible
From behind a dashboard, bad inventory looks like a data quality problem. Standing in front of a rack with a tech, comparing what is patched versus what the OSS thinks is patched, you see the real story. You see where data is lost in close-out, which tasks do not capture changes, how “misc” and “unknown” creep into records. That experience gives you very specific ideas on where to redesign workflows so that accurate inventory is a natural by-product of doing the job, not an optional extra
.
Why design quality jumps after you have seen real sites
- You prioritise the right features on the roadmap
Backlogs built from meeting-room conversations tend to prioritise highly visible but low-impact features. After a day in hi-viz, priorities change and become higher-viz too. You have seen where techs are flipping between three apps, where connectivity drops, where they are forced to call the NOC because the OSS does not show what they need. Those moments stick in your mind, and suddenly the next release is about a small set of friction-killing improvements instead of yet another dashboard. You can be assured that the techs will tell you what’s annoying them about the solution you’ve built and will give you a rev-up to fix it, regardless of what else is in the current roadmap!
- Adoption and change resistance drop sharply
Techs know when a system has been designed by someone who understands their world. The language is right, sequences makes sense, screens match the flow of the job. That familiarity builds trust. When they realise that architects, designers and product owners have “hi-visibility”, they are far more willing to adopt new tools (instead of bypassing them with workarounds such as fake photos that get entered later)
.
Why your next OSS project should start in the field, not in a workshop
- Has your team ever been in the field?
If they’ve never spent any time in the field, regardless of role, I’ve always believed that new starters should be taken for a field walk (even if just around the local streets when you aren’t able to shadow any techs). It’s important to give context to all that telco infrastructure they’re surrounded by, but totally oblivious to. It gives a context to the amount and type of infrastructure that goes into building and maintaining a telco network
- Testing finally includes real-world failure modes
Lab-based testing is tidy. Data is clean, connectivity is stable, access is granted, everything is in the expected state, or at worst, equipment is either on or off. Real jobs are not like that. Field-aware teams write different tests. Service or network health is often degraded or intermittent, so root-causes aren’t always quite so clear-cut (no pun intended). They experience incomplete data, delayed access, dropped coverage, customer interruptions, half-done tasks, unexpected inventory / plant, absent property owners and much more. These are the conditions that actually cause defects during rollout, delays in processes, revised designs (with or without redline markups) and/or alternate decision paths. You only think to test them after watching how messy a normal day in the field really is
- Product, architecture, NOC and field start speaking the same language
When everyone has at least some shared “hi-viz experience,” there’s greater situational awareness and conversations change. Those shared experiences and terminology and context helps cut through ambiguity. Product people understand why a seemingly small change matters. Architects understand why a particular field has to be visible at the right time. NOC understands why a specific workflow is painful at 3am. Alignment becomes easier because everyone has touched the same reality
.
Making hi-viz first part of business as usual
- You grow a different kind of OSS talent
Over time, organisations that normalise hi-viz time end up with a different flavour of OSS practitioner – one with a higher level of contextual visibility. Their architects are quicker to cut complexity. Their designers naturally think about safety, travel time and device ergonomics. Their business analysts ask better questions about exceptions. Their product owners anchor roadmap decisions in operational reality (and priority!). That compound effect is a genuine strategic advantage, not just a nice cultural story
You do not need a massive transformation programme to get started. You can begin with one simple rule on your next initiative: nobody writes requirements until they have spent at least one day riding along with a field crew (or at least done a street walk with someone who knows how the network hangs together).
If we want OSS that genuinely supports the people who build, maintain and repair our networks, we cannot keep designing it from ivory towers. The cheapest, fastest way to close that gap is simple. More of us need to put on a hi-viz vest and go experience the network for ourselves.
.
PS. If you are interested in building more OSS/BSS/telco foundational context awareness, you might also like to take advantage of our Black Friday OSS/BSS Foundations Starter Kit. It contains two important e-books and an OSS foundations training course.
