Knowledge Is Not Tribal: The ITECS Open-Border Model

In most IT organizations, an escalated ticket is a door that closes. A support specialist hits the edge of what they know, reassigns the ticket to someone more senior, and moves on to the next item in the queue. The problem gets solved — but the specialist who escalated it never learns how. The next time an identical issue lands in their lap, they escalate again. The knowledge lives with one person, the queue keeps moving, and nobody notices that the same door closes in the same place, over and over, for years.

We built ITECS to work the opposite way. When one of our technicians receives a ticket that sits outside their current scope — a problem they don't yet know how to resolve, a service they haven't yet implemented for a client — they do not simply escalate it and never see it again. They stay with it. They sit alongside the person it escalates to, whether that's a Level 2 specialist or one of our engineers, and they watch how it gets solved. We call this the open-border ticket, and it is one of the most deliberate cultural decisions we've made. Because at ITECS, knowledge is not tribal.

The Hidden Tax of Tribal Knowledge

Every service business runs on knowledge, and most of them lose a fortune to the way that knowledge is stored: in people's heads, undocumented and unshared. The research on this is stark. Industry analyses estimate that roughly 42% of the knowledge employees need to do their jobs is unique to an individual — it exists nowhere else in the organization [Speakwise]. When that person is on vacation, in another meeting, or gone for good, the capability leaves with them. Poor knowledge sharing across organizational silos has been linked to productivity declines of around 40%, and even a small business can quietly bleed millions in lost productivity to the friction of information that won't move between people [Speakwise].

In an IT services context, tribal knowledge has a specific and damaging shape. It looks like the one engineer who is the only person who understands a particular client's environment. It looks like a category of ticket that always routes to the same two people because nobody else has ever been shown how. It looks like a queue that appears efficient right up until the moment the wrong person is out of office, and suddenly a routine issue becomes a bottleneck. Compartmentalization feels organized. In practice, it builds a fragile organization stacked on a handful of irreplaceable individuals.

We look at those numbers and we see a choice, not a fact of nature. The 42% doesn't have to stay locked in one head. The productivity tax doesn't have to be paid. But avoiding it requires a system that treats every escalation as a teaching moment instead of a transaction — and that system has to be built on purpose, because the path of least resistance always runs the other way.

What Compartmentalized Skills Actually Cost

The conventional tiered support model exists for a reasonable operational reason: route work to the lowest-cost person who can handle it, and escalate only when necessary. On a spreadsheet, that logic is airtight. In a culture, it has a corrosive side effect. When escalation means "this is no longer your problem," you are implicitly telling your Level 1 technicians that the ceiling of their job is the edge of their current knowledge. You are asking them to recognize what they don't know, hand it off, and stay exactly as capable as they were yesterday.

Do that for a year and the gap between your tiers hardens into a caste system. Your senior people become the permanent owners of everything difficult, perpetually buried because nothing difficult ever gets distributed. Your junior people plateau, because the most valuable learning opportunities — the hard, novel, real-world problems — are precisely the ones taken away from them the moment they appear. Morale on both ends suffers. The seniors are overloaded and the juniors are bored, and both groups start looking at other companies. It is a slow, self-inflicted wound that never shows up as a single dramatic failure, only as a steady erosion of capability and retention.

The Open-Border Ticket

Here is what actually happens on our team when a ticket lands outside a technician's scope. Say a Level 1 support specialist receives a request to implement a service for a client that they've never configured before, or diagnoses an issue whose root cause is beyond what they currently know how to fix. In a compartmentalized shop, that ticket would vanish up the chain. At ITECS, it triggers the opposite motion: the specialist brings in the right escalation partner — a Level 2 specialist or one of our engineers — and then stays in the room.

An open-border ticket in practice: the technician who escalated sits alongside the person resolving it, learning the how — not just receiving the outcome.

They sit alongside the person resolving it. They watch the diagnostic reasoning, the configuration steps, the judgment calls that don't appear in any runbook. They ask the questions that only surface when you're looking at a real client's real problem. And critically, the ticket remains theirs — a shared responsibility, not a discarded one. The escalation partner isn't taking the problem away; they're demonstrating the solution while the original technician absorbs it. By the time the ticket closes, two people know how to solve it instead of one.

This is a deliberate trade. Yes, it is momentarily less "efficient" to have a second person present at a resolution they could technically handle alone. We make that trade every single time, on purpose, because the second person's presence is not overhead — it is the single most effective form of training we have. No classroom, certification, or documentation library teaches like watching an expert solve a live problem while you hold the context of how it got escalated. The open border converts the most expensive moments in our business — hard tickets — into our most valuable ones.

Why This Makes Our Clients' Service Better

It would be easy to read all of this as an internal HR nicety — good for morale, nice for the team. But the open-border model is, first and foremost, a client-service decision, and our clients feel its effects directly even though it happens entirely behind the scenes.

Start with speed. In a compartmentalized model, the pool of people who can resolve any given class of problem stays small and stays constant. In ours, it grows with every ticket. A problem that required an engineer last quarter can be handled by a Level 2 specialist this quarter and a Level 1 technician the quarter after — which means faster response, shorter queues, and senior specialists freed to focus on genuinely novel work instead of repeating resolutions they've already performed a hundred times. Depth on the bench is not an abstraction; it's the difference between a client waiting for the one available expert and a client being helped by the next available capable person.

Then there's resilience. Because we actively refuse to let any capability live in a single person, we carry far fewer single points of failure. When knowledge is shared by design, a technician being out sick or on vacation doesn't turn a routine request into a stalled ticket. This is the same discipline we bring to the infrastructure we manage — eliminating single points of failure — applied to our own team. It's a core part of why clients choose ITECS and stay for years: the service does not degrade because one person was unavailable, and it gets measurably better over time as the whole team levels up together.

Why This Makes ITECS a Place to Grow

The other half of the story is about the people who choose to build their careers here. We are candid with every technician we hire: your job is not to stay in a lane. Your job is to get better — continuously, visibly, with the direct support of the most experienced people on our team. That promise is not a perk we advertise and quietly ignore. It is structurally built into how work flows, because the open-border ticket guarantees that our most skilled people are regularly, deliberately teaching our newest ones on live problems.

The data on why this matters for retention is overwhelming, and it aligns exactly with what we see in our own team. Providing learning opportunities is consistently ranked the number-one employee retention strategy, and 94% of employees say they would stay at a company longer if it invested in their career development [LinkedIn Learning]. Employees who experience real internal advancement are significantly more likely to stay for the long term. People do not leave places where they are visibly becoming more capable and more valuable every month. They leave places where they've plateaued — and compartmentalized skill structures manufacture plateaus.

Knowledge moves along open pathways, not into silos — every technician is a node that both learns and teaches.

We would rather invest the time it takes to grow a technician's skill set than protect the illusion of efficiency that comes from keeping them in a narrow role. That investment is the whole point. We are not trying to extract a fixed amount of output from a fixed set of skills; we are trying to make every individual on our team more capable than they were last quarter, so they can bring more value to their colleagues and to the clients who depend on them. That is what it means, in practice, to say that we value each technician's skill set — not as a static asset to be slotted into a queue, but as something we are actively responsible for growing.

Knowledge That Compounds

The phrase we keep coming back to internally is simple: knowledge is not tribal. It does not belong to the person who happens to hold it today. It belongs to the team, and our job — as leaders, as colleagues, as a company — is to move it, share it, and multiply it at every opportunity. The open-border ticket is the mechanism, but the philosophy behind it is bigger than any single process. We look at every ticket, every project, and every escalation as an opportunity to improve an individual on our team, and we organize the work so those opportunities are never wasted.

Compartmentalization is the default that most organizations drift into without ever choosing it. It's easier in the moment, it looks tidy on an org chart, and it slowly makes an organization more fragile, its people less engaged, and its clients less well served. We chose the harder, better path on purpose — because a team where knowledge compounds is a team that gets stronger every day it operates, and that is exactly the kind of partner our clients deserve and the kind of place our people deserve to build a career.

Sources

• Speakwise — Information Silos Statistics (tribal knowledge concentration and productivity impact)
• LinkedIn Learning — Workplace Learning Report (development as the top retention strategy)
• Process Works — The Hidden Costs of Tribal Knowledge