OSS isn’t just a Battle. It’s a Quest. And every Quest needs more than Just Dragon Slayers

You’ve already got your dragon slayers. Your team is filled with seasoned OSS professionals who’ve faced complex, high-stakes problems and lived to tell the tale. They’re reliable, sharp, and tested.

But if you’re the King / Queen, the one responsible for building the team, then you need more than just experience. You need adaptability. Perspective. The ability to see what even your veteran dragon-slayers don’t or can’t.

OSS isn’t just a battle. It is a quest. And every quest needs more than just dragon slayers.

.

More Than Dragon Slayers: Expanding the OSS Adventure Party

In our previous article, we explored the retained relevance of OSS veterans as dragon slayers. These are experienced professionals who have faced down the industry’s toughest problems and emerged with the scars, context, and insight that only time fighting OSS/BSS dragons can earn. They remain essential, especially in critical, high-stakes environments.

This article is that article’s counter-point.

OSS is not just a single battlefield. The battlefield keeps changing, so it becomes a journey of constant reinvention. And almost every OSS transformation journey I’ve been involved with has needed a full questing team.

This article is primarily written for the King / Queen, the person who builds and leads the team. However, it will hopefully provide a few take-aways for anyone embarking on a journey of OSS/BSS transformation.

Let’s be 100% clear from the outset. Not everyone needs to be the veteran dragon slayer we discussed in the previous article. In fact, if everyone in your team is, you’re likely missing important perspectives. Let’s take a really quick look at the world of OSS through the lens of the following archetypes and strengths they bring to the table compared with dragon-slayers:

Archetype Description Strength
Apprentice Knights Learning from slayers but asking different, often naive, questions that vets no longer even think about Fresh-eyed, curious, making their own sense of the world of OSS, seeing the OSS landscape through a different lens
Scouts Exploring edges, spotting what’s next Agile, observant, ahead of the curve
Alchemists Mixing what doesn’t normally go together Inventive, bold, unbound by legacy
Squires Asking the most basic of questions that experts have long stopped asking Humble, revealing otherwise obvious blind spots
Mapmakers Challenging outdated models and frameworks Strategic, conceptual, forward-looking, re-plotting old and new paths

In this article, we’re specifically highlighting the value of new-starters and non-traditional hires from other industries. Their lack of entrenched thinking helps them (us?) notice what others overlook.

Here is what your “new” archetypes bring:

  • They question your inherited maps. What was true five years ago might not be now. The mapmakers notice when the landscape has shifted, even if the path still looks familiar
  • They experiment freely. Alchemists and apprentices are not afraid to test new ingredients. They are not scarred by past failures, so they try combinations others gave up on
  • They force the experts to simplify. When squires ask basic questions, slayers must explain. That often reveals where logic is outdated or never clearly defined
  • They reignite curiosity. Scouts and apprentices bring energy, wonder and fresh urgency. Their momentum often reawakens it in the veterans around them

They don’t replace experience. They can’t. But if well structured, they can expand it.

.

When Mastery Becomes a Cage (for the Master and their Team)

Veterans are fast because they recognise patterns and can use learnings from past projects. But that speed can also come at a cost. The more experienced your team becomes, the more they can tend to default to what worked before. It becomes harder to see alternatives. Harder to hear objections. Harder to be surprised. Harder to reconsider old assumptions. Harder to re-imagine or re-frame.

If they believe “their” way works, then they’re not going to consider any other ways.

That is when mastery turns into muscle memory. And muscle memory, when misapplied, reinforces old problems instead of solving new ones.

When a master begins to identify their self-worth via their product or methodology, it can be really difficult to try something new. If a newbie questions their thinking or designs, it can feel like their entire self-worth is being questions and needs to be protected at all costs.

No matter how strong our mastery, we have to ensure we have a team that collectively never stops asking. The environment is always changing. The dragons have changed. So is the terrain. Despite spending 25 years in this industry, I still see it like an iceberg. For what I know (above the surface), there’s vastly more than I don’t, that’s still left to learn. This is both exciting and scary at the same time, knowing that even the earliest of OSS beginners already know certain things that I can learn from them.

I spent a year advising the board of a T1 telco on their first-ever OSS transformation. They’d engaged a vendor which had done dozens of transformations before (but in a totally different region). The vendor claimed their implementation model was “world’s best practice” and “had worked for every other client.” Unfortunately, the vendor’s approach would’ve required an overhaul of the carrier’s entire organisation chart and ways of working. Even when presented with evidence that their model would cause upheaval of an 80,000 person organisation, this vendor’s 10 person project team would not adjust their approach, insisting that the carrier must change. Sigh!

.

Designing Mixed Teams on Purpose

Most OSS teams are assembled based on past experience and existing capability. As James Sinclair says, “Has done. Can do. Will do.”

That’s a great paradigm for most industries. But that’s not enough anymore. Diversity is important in OSS, so we need to assemble based on contrast too. We have to find ways to build teams that blend mastery with inexperience, speed with exploration, execution with challenge, talking and doing.

Every OSS requires an apprenticeship. Not just OSS in general, but every unique OSS requires a period of hands-on learning before you can really progress to mastery.

I’d previously spent years working on and with network inventory solutions. But with one new network inventory solution, it still took around 6 months before I really felt comfortable using their tools. The use-cases and the data sets didn’t change from the other solutions I’d used before, but the UI/UX and workflows all did. Their were so many nuances and pre-requisite activities that only came from being very hands-on, making mistakes and learning along the way.

You’ve probably also heard plenty of stories where head-count reduction has slashed the number of veterans on OSS teams. It achieves the aim of significant cost reduction, but also often sheds so much of the all-important tribal knowledge from the team.

Here are some practical moves:

  • Create an apprenticeship program. Assign apprentices (even “experienced” apprentices as described above) alongside slayers. Tribal knowledge transfer isn’t just a four-week handover from old to new. Even senior roles need hands-on apprenticeship training to truly understand what you’re building and how it works
  • Invite outsiders / left-fielders in (part 1). Bring in outsiders and people from non-OSS professions to help overcome entrenched challenges. Let them evaluate constraints and systems with no baggage. In one of my favourite books, Getting Everything You Can Out of All You’ve Got, one of Jay Abraham’s core philosophies is the power of cross-pollination: borrowing successful strategies from unrelated industries and adapting them to your own (you can find Jay’s book in my Uncommon OSS Books list)
  • Invite outsiders / left-fielders in (part 2). The sad reality is that most of the most profound innovations in OSS / BSS / telco in recent decades have originated from outside. Innovations such as cloud-native, APIs, SaaS, DevOps, Agile, AIOps, Virtualisation, Data Lakes, AI pipelines, etc, etc. As such, we need to look to experts in other IT fields to find the evolution of software, networks, data, UI/UX design and processes that will re-shape our OSS into the future
  • Flip the feedback loop. Let new joiners lead post-mortems, pre-mortems and post-incident reviews (PIRs). Their observations often highlight blind spots that experts has long since ignored
  • Challenge your veterans to unlearn. Ask them to name one belief they will question this quarter. Celebrate those who do
  • Challenge your veterans to listen. The most knowledgeable and admired members of the team are often also the most vocal leaders. We need to give room and safety for questions, debates, and listening, to embrace the beginner’s mind again (writing a blog about OSS can help you wear other hats and try to think from others’ perspectives 😀 )
  • Re-invent using the long-tail of OSS functionality. As part of our re-framing exercise, we help clients visualise what’s really important using long-tail diagrams and then go about re-factoring rather than just adding
  • Friction point analysis. Old hands will often navigate around their OSS as seamlessly as someone who’s been driving a manual / stick-shift car for decades. But for a new-starter (learner drivers), there might be layers of friction hidden in non-intuitive OSS designs. Subtracting the suck is your innovation pipeline

There’s one more reason to invite the new archetypes in. Newbies help your veterans grow again. For the dragon slayers to keep slaying, they need to keep learning, to sharpen their swords. Perhaps they even need to learn how to use new weapons that they’ve never used before.

Just as it’s important to create a culture where the newbies can ask questions, experiment and grow, we also need to encourage our veterans to:

  • Reverse or Bidirectional Mentoring. Where the mentor teaches, but also learns from or co-learn with the novices
  • Explore beyond OSS
    • Talk with startups, analysts, operators, etc in other industries
    • Read beyond telco (just like the uncommon OSS book list) and bring back paradigms, analogies and models from other industries

The goal is not to replace their expertise. It is to reinvigorate it.

.

Your Job as the King / Queen

If you are the one assembling the team, your job is not just to deploy experience. It’s to find the curious minds at all experience levels who are, or who will likely become, linchpins / tripods.

AI is proliferating and touching many aspects of OSS and telco. In this next phase of OSS, I suspect victory will not go to those with the greatest knowledge (strongest swords). I suspect it will go to those who see the changing map, ask the best questions and move first or fastest. To those who listen to the squires. Who run with the scouts. Who let the alchemists experiment. Who listen to the apprentices who notice something the slayers might have missed.

OSS is a team sport.

As alluded to in the previous post, hopefully you still have access to dragon-slayers, even if they’re not in your core team anymore. Hopefully you have linchpins / tripods that act as master connectors. Hopefully you’re also able to assemble the rest of the questing party to work with them together.

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

The Buyer-Seller Chasm Series Summary

This article provides a summary of our Buyer-Seller Chasm series of articles, where we start with the guiding principle that: The buyers (carriers) desperately need

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.