OSS expendables

When looking at a telco org chart, where does the highest staff turnover tend to occur? Contact centres? Network Operations?

The fact that these two groups tend to have the highest turnover indicates that their employers see them as expendable resources. They’ll never come out and say it directly, but actions speak louder than words. If these resources were valued more highly, more effort would be made on their retention.

Now, what do you notice on the diagram below?
The pyramid of pain

The diagram below is taken from an earlier post entitled “The pyramid of OSS pain.” It’s an over-simplification of where the source of OSS complexity (ie pain) tends to originate from, but who bears the brunt of all the upstream complexity generated within a service provider? Yes, the contact centres and network operations centres.

This can’t be a coincidence can it? The teams bearing the brunt of complexity have the highest turnover.

But how can this be allowed? If those are the roles dealing with most complexity, why do we tend to have our least experienced operators there? And why are we allowing their accrued knowledge for handling that complexity to walk out the door as expendable resources?

Avoiding the OSS honey trap

Regardless of whose estimates you read, OSS is a multi billion industry. However, based on the relatively infrequent signing of new vendor deals, it’s safe to say that only a very small percentage of those billions are ever “in play.”

In other words, OSS tend to be very sticky, in part because they’re so difficult to forklift out and replace. Some vendors play his situation extremely well, with low install costs but with strategies such as “land and expand,” “so sue us” and “that will be a variation.” These honey pots hide the real cost of ownership.

Cloud IT architectures such as containerisation and microservices can provide a level of modularity and instant replaceability between products (ie competition). When combined with a Minimum Viable Product mindset rather than complex, entwining customisations, you can seek to engineer a lower lock-in solution.

The aim is to ensure that products (and vendors) stay in-situ for long periods based on merit (ie partnership strength, functionality, valuable outcomes, mutual benefit, etc) rather than lock-in.

Are we measuring OSS at the wrong end?

I have a really simple philosophical question to pose of you today – Are we measuring our OSS at the wrong end?
It seems that a vast majority of our OSS measurement is at the input end of a process rather than at the output.

Just a few examples:

  • Financial predictions in a business cases vs Return on Invested Capital (ROIC) of that project
  • Implementation costs vs lifetime ownership implication costs
  • Revenues vs profitability (of products, services, workflows, activities, etc)
  • OSS costs vs enablement of service and/or monetisation of assets (ie operationalising assets such as network equipment via service activation)
  • OSS incidents raised (or even resolved) vs insurance on brand value (ie prevention of negative word-of-mouth caused by network / service outages)

In each of these cases, it’s much easier to measure the inputs. However, the output measurements portray a far more powerful message don’t you think?

6 principles of OSS UI design

When we talk about building capabilities by design, there are a set of four core capabilities that you should keep in mind:

  • Designed for self-sufficiency: Enable an environment where the business user is capable of acquiring, blending, presenting, and visualizing their data discoveries. IT needs to move away from being command and control to being an information broker in a new kind of business-IT partnership that removes barriers, so that users have more options, more empowerment, and greater autonomy.
  • Designed for collaboration: Have tools and platforms that allow people to share and work together on different ideas for review and contribution. This further closes that business-IT gap, establishes transparency, and fosters a collective learning culture.
  • Designed for visualization: Data visualizations have been elevated to a whole new form of communication that leverages cognitive hardwiring, enriches visual discovery, and helps tell a story about data to move from understanding to insight.
  • Designed for mobility: It is not enough to be just able to consume information on mobile devices, instead users must be able to work and play with data “on the go” and make discovery a portable, personalized experience.

Lindy Ryan in the book, “The Visual Imperative: Creating a Visual Culture of Data Discovery.”

When it comes to OSS specifically, I have two additional design principles:

  • Designed for Search – there is so much data in our OSS / BSS suites; some linked, some not; some normalised, some not; some cleansed, some not; This design principle allows abstraction from all those data challenges to allow operators to make psuedo-natural language requests for information. Noting that this could be considered an overlap between points 1 and 3 in the prior list
  • Designed for user journeys – in an omni-channel world, the entry point and traversal of any OSS workflow could cross multiple channels (eg online, retail store, IVR, app, etc). This makes pre-defined workflows almost impossible to design / predict. Instead, on OSS / BSS suite must be able to handle complete flexibility of user journeys between state / event transitions

NTT East Japan adopts Cisco NFV

NTT East Japan Adopts Cisco NFV Portfolio To Help Small and Medium Enterprises With ICT Cloud Computing.

Cisco Systems G.K. announced that Nippon Telegraph and Telephone East Corporation has adopted a full-stack, ETSI-compliant NFV solution validated and supported by Cisco for its new Maruraku Office service. This will enable the centralized creation, management and operation of Information and Communications Technology (ICT) environments for small and medium enterprises.

Developed in response to the ICT challenges faced by small and medium enterprises
NTT East is creating a highly reliable virtualization environment by transitioning from its existing service platform to provide new services aimed at resolving the problems posed by the ongoing shortage of dedicated IT personnel in many small and medium enterprises. The virtualization platform of the company’s new service for consolidating Internet lines, firewalls, routers, storage and business phones in the cloud requires a wide range of system components. In addition, sophisticated coordination between these elements is essential to ensure stability.

Working with Cisco Advanced Services, NTT East deployed Cisco® Network Services Orchestrator (NSO), Cisco Elastic Services Controller (ESC), and the Cisco Network Functions Virtualization Infrastructure (NFVI) solution, including Cisco Virtual Topology System (VTS) and Cisco Virtualized Infrastructure Manager (VIM). The solution enabled the automation and integration of component functions with complex configurations within its virtualization platform. This cuts costs by reducing manual work and optimizing operations, whilst ensuring greater business agility for service changes and deployment.

Support for creation of new services promoting small and medium enterprises
The deployment of services by operators in the small and medium enterprise market must be agile. NTT East’s adoption of Cisco products and technology in its new service platform was based on the latter’s comprehensive and unified response and support system. This extends to general maintenance and operation of software and hardware spanning everything from service controllers to virtual server platforms and physical networks. NTT East will work to ensure the security and agility of the platform through automated and optimized operation, while developing new services and expanding ongoing services in support of small and medium enterprises.

Guns don’t kill OSS

Guns don’t kill people, people do.
Similarly, Technology doesn’t kill OSS projects, people do… Actually people with technology do.

The following shows the escalation of global CAPEX allocated by CSPs over the last thirty years (in current currency).. apart from a few brief years around the Global Financial Crisis (GFC).
Global CAPEX

The CAPEX uplift also represents the increase in complexity in the networks and solutions used by CSPs. There are just more technologies in our networks than ever before. If you follow the trendline, we can predict that the challenges caused by increased complexity will be followed by even more investment in technologies that will further increase complexity. Just wait until virtualised networking spend hits its nadir!

And all of that complexity flows downstream to our OSS. The variants are killing us.

This may seem completely stupid to most people in the industry, but the supposed holy grail of ever-faster TTM (Time to Market) may actually be killing us more quickly – a faster TTM means a faster ramp-up of variants flowing down at us.

And our response to the increase in variants? That’s right – more technology – which just happens to add more variants. Did someone say death spiral??? 🙂

But we’re made of sterner stuff. We’re not going to let that happen are we? We’re going to hire Chief Simplification Officers who will wield the Simple Stick across entire CSP organisations (not just Operations) and institute massive complexity reduction projects.

Building an OSS piggybank with scoreboard pressure

“The gameplan tells what you want to happen, but the scoreboard tells what is happening.”
John C Maxwell

Over the years, I’ve found it interesting that most of the organisations I’ve consulted to have significant hurdles for a new OSS to jump through to get funded (the gameplan), but rarely spend much time on the results (the scoreboard)… apart from the burndown of capital during the implementation project.

From one perspective, that’s great for OSS implementers. With less accountability, we can move straight on to the next implementation and not have to justify whether our projects are worth the investment. It allows us to focus on justifying whether we’ve done a technically brilliant implementation instead.

However, from the other perspective, we’re short-changing ourselves if we’re not proving the value of our projects. We’re not building up the credits in the sponsor bank ahead of the inevitable withdrawals (ie when one of our OSS projects goes over time, budget or functionality is reduced to bring in time/budget). It’s the lack of credits that make sponsors skeptical of any OSS investment value and force the aforementioned jumping through hoops.

One of our OSS‘s primary functions is to collect and process data – to be the central nervous system for our organisations. We have the data to build the scoreboards. Perhaps we just don’t apply enough creativity to proving the enormous value of what our OSS are facilitating.

Do you ever consider whether you’re on the left or right side of this ledger / scoreboard?

Been done before, been done before

What percentage of the work you do each day is work where the process (the ‘right answer’) is known? Jobs where you replicate a process instead of inventing one…
The place where we can create the most value is when we do a job where exploration and a new solution is what’s needed. Not rote, but exploration. Which means we’re doing something that’s not been done before, something that might not work.
This isn’t something to avoid, it’s the work we need to seek out
.”
Seth Godin
in this blog.

From the perspective of OSS experts, this blog from Seth Godin has three distinct perspectives:

  • The OSS operators’ perspective – Where we want super-repeatability, consistency and quality. We can accommodate exploration, but only if we’re monitoring Darwinian change and using it to evolve to become ever fitter and faster. Operator roles are all about coercing large volumes of activities through the funnel as quickly and accurately as possible, supported by our OSS tools and processes.
  • The OSS installer’s perspective – Where we want the out of the box installation to also be highly efficient, repeatable and consistent. In most cases, we don’t want room for exploration during an install
  • The OSS builders’ perspective – Where we want to follow Godin’s explorative lead, where we want to configure / customise an OSS by seeking something that’s never been done before in the hope that the solution is better than has ever been done before (in readiness to hand over to operators and installers)

Some people enjoy rote, consistency and repeatability, knowing what they’re going to do each day before the day starts. OSS needs these personalities.

But for the OSS builder roles, rote isn’t something to avoid, it’s the work we need to seek out, perhaps more passionately and laterally than we may care to admit.

If OSS is my hammer, am I only seeing nails?

OSS is a powerful multi-purpose tool, much like a hammer.

If OSS is my only tool, do I see all problems as nails that I have to drive home with my OSS?

The downside of this is that it then needs to be designed, built, integrated, tested, released, supported, upgraded, data curated and maintained. The Total Cost of Ownership (TCO) for a given problem extends far beyond the time-frame envisaged during most solutioning exercises.

To be honest, I’ve probably been guilty of using OSS to solve problems before seeking alternatives in the past.

What if our going-in position was that answers should be found elsewhere – outside OSS – and OSS simply becomes the all-powerful last resort? The sledgehammer rather than the ball-pein hammer.

With all this big data I keep hearing about, has anyone ever seen any stats relating to the real life-time costs of OSS customisations made by a service provider to its off-the-shelf OSS? If such data exists, I’d love to see what the cost-benefit break-even point might look like and what we could learn from it. I assume we’re contributing to our very own Whale Curve but have nothing to back that assumption up yet.

OSS User Experiences at 3.5 inches

The far-reaching impact of the technology revolution of 2007 with the launch of the Apple iPhone is not to be underestimated. Across every industry, Apple has had a profound influence through the psychological effect of how consumers expect technology to interact with them. People now expect good design as part of their visual communication and interactivity with information. In obsessing over simple, intuitive design, Apple sets a new standard for visual communication. It was necessary to design a completely original visualization experience because when converting from the real estate of a computer monitor to a 3.5-inch screen, smart choices must be made to effectively communicate visually and create intuitive interaction with the device. Not that Apple has always done this perfectly, but it has always focused on aesthetics and the user experience.
Lindy Ryan
in the book, “The Visual Imperative: Creating a Visual Culture of Data Discovery.”

Great point by Lindy Ryan above, but I’d probably suggest that Apple re-set consumer expectations about 5 years earlier with the iPod.  Anyway, here’s what a typical OSS looks like today:
Current OSS UI

Not exactly clean and elegant. Go on. Tell me it’s not true? How many OSS have you used that have a User Interface as cluttered and un-intuitive as the tongue-in-cheek sample shown above?

What if we took the perspective of having to design our OSS for a 3.5″ screen? Would we have to simplify? Would we have to reduce the design and workflows down to their very essence?

Humour me. Just as an experiment, what happens if you set exactly this task to your OSS UI designers (do you even have UI / UX designers or just devs)? Then ask them to expand any learnings back out to the full-sized monitors. I’d love to hear what you come back with.

Put it this way, I’m doubting the designs will be worse.

OSS death in The Matrix

84 percent of employees are “matrixed” to some extent, meaning they serve on multiple teams
Gallup Report: “State of the American Workplace.”

Like me, you’ve probably worked on some highly functional OSS teams as well as some dysfunctional ones. Perhaps you’ve even worked with teams that have had elements of both.

Today I reflect on what have been the ingredients of the highly functional teams I’ve been lucky to work with.

They’ve had smart, dedicated people, but so have the dysfunctional teams so that’s not it. The dysfunctional teams have had conflict, but so have the functional teams.

Interestingly, the highest achieving teams I’ve worked on have tended to be small and located far away from home. They haven’t had a single powerful leader but have had a core of tripods with functional groupings surrounding the core. They haven’t always had great project managers leading the project but that certainly doesn’t mean a lack of leadership.

Large OSS projects tend to evolve as they go, so having a clear view of the end state hasn’t been the differentiator. I’ve always believed that the customer / client gets back what they put in but some of the highest-achieving teams have delivered even when there has been something of an us against them dynamic (but still significant interaction with the client).

My take on all of this is:

  • Having a core of 3-5 multi-functional experts, each guiding smaller teams, spreads the dependence compared with having a single guru
  • Being offshore has tended to force a greater level of team interaction and deeper understanding between team members, especially outside work hours, even where that hasn’t necessarily translated to close friendships
  • Being part of a small team that is under-resourced means everyone has had to go outside the comfort zone of their job title to get priority tasks done. Whilst the single common objective (ie to deliver an OSS) is clear, there has been flexibility in how the objective is achieved
  • Having a single objective (ie not matrixed across multiple teams and projects) has allowed a focus amidst the chaos and a sense of accountability to a single team

l tend to believe that the last item on the list could be one of the biggest, most underestimated factors. Most big OSS projects I’ve worked on in the last few years have been heavily matrixed. They also haven’t had the most highly functional teams interestingly.

If you’re envisioning a moonshot OSS project, I’d recommend building a small expert core and eliminate any sense of the matrix from around them.

In your experience, what have been the ingredients of the most successful teams you’ve engaged with? Are my ingredients consistent or contrary to yours?

Big circle. Little circle. Crossing the red line

Data quality is the bane of many a telco. If the data quality is rubbish then the OSS tools effectively become rubbish too.

Feedback loops are one of the most underutilised tools in a data fix arsenal. However, few people realise that there are what I call big circle feedback loops as well as little circles.

The little circle is using feedback in data alone, using data to compare and reconcile other data. That can produce good results, but it’s only part of the story. Many data challenges extend further than that if you’re seeking a resolution.

The big circle is designing feedback loops that incorporate data quality into end-to-end processes, which includes the field-work part of the process.

Redline markups have been the traditional mechanism to get feedback from the field back into improving OSS data. For example, if designers issue a design pack out to field techs that prove to be incorrect, then techs return the design with redline markups to show what they’ve implemented in the field instead.

With mobile technology and the right software tools, field workers could directly update data. Unfortunately this model doesn’t seem to fit into practices that have been around for decades.

There remain great opportunities to improve the efficiency of big circle feedback loops. They probably need a new way of thinking, but still need to fit into the existing context of field workers.

An uncommon list of OSS books

Since reading the first book on this list, I’ve become a very avid and wide-ranging reader. The seeds sown by the book list below have immensely helped enrich the content you see here on the PAOSS blog and other PAOSS content.

You’ll begin to notice a very curious thing about this list though. There are only two books in the entire list that are actually about OSS. I have many OSS books in my library, but most struggle for relevance beyond the author’s frame of reference – they have been written from the specific technical experiences of the author, which are rarely transferable to other OSS. Either the technologies are now out of date and/or the details / terminologies were pertinent only to that OSS time and place. It’s one of the reasons that PAOSS content is specifically intended to abstract from technology and deliver insights, methodologies, processes and frameworks that have a broader relevance and greater longevity (hopefully).

The remaining books in the list have not been written with OSS in mind but definitely provide insights and perspectives that are transferable to the challenges we face in the OSS industry. In no particular order (except the first being the first…)

Rich Dad, Poor DadRich Dad, Poor Dad
by Sharon L. Lechter Robert T. Kiyosaki
This was the book that changed it all for me. Whilst its intent is to educate on personal finance, the effect it had was to lift my eyes beyond the purely technical. Like 95%+ of people in our industry, I had previously only ever focused on delivering the best technical solution I could with the assumption that this would deliver a great customer outcome. I now know that the challenges we face are far  bigger than that!
Insanely Simple: The Obsession That Drives Apple's SuccessInsanely Simple: The Obsession That Drives Apple’s Success
by Ken Segall
The greatest OSS (but non-OSS) book I’ve read. The first half of this book in particular delivers powerful examples of simplification at all levels of an organisation as experienced by an advertising executive working alongside Steve Jobs at Apple. The OSS and communications industry need more people who are able to wield the simple stick like Steve did.
ReworkRework
by Jason Fried, David Heinemeier Hansson
These gentlemen have built a strong business around the Basecamp project management suite of tools. In Rework, just like their blog at 37signals, they provide brilliant contrarian insights into how to run a software business… Or any business for that matter. Efficiency and simplicity are the mantra ahead of the Red-Bull fuelled heroics spouted by many organisations in the software industry. One of my all-time favourite business books.
Enchantment: The Art of Changing Hearts, Minds, and ActionsEnchantment: The Art of Changing Hearts, Minds, and Actions
by Guy Kawasaki
Guy defines enchantment as, “the process of delighting people with a product, service, organisation or idea. The outcome of enchantment is voluntary and long-lasting support that is mutually beneficial.” If there was ever an industry that was in need of enchantment, it is the OSS industry right now.
Rain: What a Paperboy Learned About BusinessRain: What a Paperboy Learned About Business
by Jeffrey J. Fox
An easy to digest story about a boy with a paper-route learning the key tenets of rainmaking, the ability to delight customers and make sales (and projects) happen.
The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any AudienceThe Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience
by Carmine Gallo
There are two acronyms that pervade in the OSS / telco / tech industry; DBA (Death by Acronym) and DBP (Death by Powerpoint). This book provides some stunning insights into how to make a compelling presentation on your latest OSS project.
Killing Giants: 10 Strategies to Topple the Goliath in Your IndustryKilling Giants: 10 Strategies to Topple the Goliath in Your Industry
by Stephen Denny
There are a number of goliath incumbents in our industry. However, I suspect that most of the required disruption is coming from the Davids of our industry, despite the burning platforms at the goliaths. Interesting reading for a different perspective on innovation and change.
Jack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEOJack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEO
by Robert Slater
This book describes a number of key strategies for how Jack Welch pared back the weighty bureaucracy of General Electric upon his ascension to CEO. I suspect our industry needs similarly brutal change leadership to thrive into the future
The Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control CostsThe Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control Costs
by Bill Price, David Jaffe
There is a distinct difference between the customer service models of the typical communications service provider (CSP) and digital service providers (DSP) like Google, Facebook, Amazon, et al. Most CSPs can only wish for the level of customer self-service that the DSPs enjoy. I was working on a project for a customer-facing business unit of a CSP whilst reading this book and the parallels were almost scary.
Essentialism: The Disciplined Pursuit of LessEssentialism: The Disciplined Pursuit of Less
by Greg McKeown
Think: Less but better. A motto for our industry, one individual at a time.
Anything You Want: 40 Lessons for a New Kind of EntrepreneurAnything You Want: 40 Lessons for a New Kind of Entrepreneur
by Derek Sivers
Derek Sivers was a professional musician before starting his own business, one that helped sell the CDs of the long tail of the music industry, musicians overlooked by the big labels. This might sound barely relevant to the OSS industry but there is an uncommon clarity in the way that Sivers views businesses, customers and delivery. Many of his thoughts really struck a chord with me (bad pun intended).
Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy IndustryBrick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry
by David Robertson, Bill Breen
Bespoke creativity took this icon of childrens’ toys to the brink of bankruptcy. Perhaps counter-intuitively, paring it back to the basic building blocks (another bad pun) allowed creativity and profitability to thrive at Lego.
Principles: Life and WorkPrinciples: Life and Work
by Ray Dalio
Built around the principles that Ray Dalio codified at his company, Bridgewater Associates. Many of his principles of team and culture seem like common sense, but helpfully compiled into a single volume. Not all OSS teams have these principles mastered.
Blue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition IrrelevantBlue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition Irrelevant
by W. Chan Kim, Renée Mauborgne
This book provides frameworks for shifting an organisation out of fragmented, highly competitive markets (bloody red oceans) into a unique market segment (blue oceans). I’ve even added some of the concepts in this book into a framework that helps my clients plot differentiated strategic roadmaps and product evaluations.
Leading ChangeLeading Change
by John P. Kotter
OSS projects are challenging to implement. Through harsh experience, I’ve learnt that even technically perfect implementations are prone to fail if the organisational change effort hasn’t been managed well. Whilst there are newer change management methodologies available, I still find that Kotter’s 8 steps provide a valuable framework for building OSS change management strategies around.
Everything Is Negotiable: How to Get the Best Deal Every TimeEverything Is Negotiable: How to Get the Best Deal Every Time
by Gavin Kennedy
Introduces some fascinating negotiation tactics such as “The Mother Hubbard” (ie the cupboard is bare). There is more negotiation required in OSS than I first gave it credit for.
Endless Referrals: Network Your Everyday Contacts into SalesEndless Referrals: Network Your Everyday Contacts into Sales
by Bob Burg
In the early days of my career, I’d gone from one project to the next, with my head down focusing on delivery. This book opened my eyes to the value of staying in touch with past colleagues and adding value to my network. The results have surprised me so I recommend this book’s teachings to anyone who is purely tech-focused.
The Idea Factory: Bell Labs and the Great Age of American InnovationThe Idea Factory: Bell Labs and the Great Age of American Innovation
by Jon Gertner
Put simply, this is probably the most inspiring book I’ve read in relation to the communications industry. The groundbreaking innovations (including OSS) that were developed within R&D powerhouses like Bell Labs during the 1900’s are staggering and something that we can barely even aspire to today. It’s no coincidence that the OSS Call for Innovation references this book
nullLinchpin: Are You Indispensable?
by Seth Godin
A call to action to become a linchpin, someone who delivers in territory where there is no map / rule-book, someone who inspires those around them. OSS needs more linchpins.
Made to Stick: Why Some Ideas Survive and Others DieMade to Stick: Why Some Ideas Survive and Others Die
by Chip Heath, Dan Heath
The term “stickiness” was popularised by Malcolm Gladwell in “The Tipping Point.” This book borrows the term and looks to explain why an idea or concept remains sticky. OSS tend to be so sticky, in many cases to the detriment of the customer experience, but our industry is also in desperate need for powerfully sticky new ideas and approaches.
The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About ItThe E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It
by Michael E. Gerber
The ideas in this book are based on growing small businesses, but there are certainly take-aways for OSS. The biggest for me is the need for repeatability. We need to codify and systematise if we are to refine and improve.
Purple Cow, New Edition: Transform Your Business by Being RemarkablePurple Cow, New Edition: Transform Your Business by Being Remarkable
by Seth Godin
In a cluttered or fragmented marketplace, like OSS, it is difficult to stand out from all other suppliers. Seth Godin introduces the concept of the purple cow – when you’re on a long trip in the countryside, seeing lots of brown or black cows soon gets boring, but if you saw a purple cow, you’d immediately take notice. This book provides the impetus to make your products stand out and drive word of mouth rather than having to differentiate via your marketing.
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True InspirationCreativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
by Ed Catmull, Amy Wallace
From the creative brilliance of Pixar Studios comes this book of how to cultivate inspired creativity. My biggest take-away was the amount of time and money Pixar spends on upgrading its hardware and software platforms between films…. unlike some of our OSS that are still rooted in tech from the 1990s.
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New RichThe 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
by Timothy Ferriss
Starts off strongly but drops away rapidly in the second half IMHO. The words of a friend of mine aptly paraphrase what Tim Ferris talks about in this book, “Only do what only you can do.” Prioritise your efforts on what make you truly unique and use other efficiency tools and/or engage others to do the rest
OSS Essentials: Support System Solutions for Service ProvidersOSS Essentials: Support System Solutions for Service Providers
by Kornel Terplan
Finally, a book that’s actually about OSS. Whilst covering some obsolete technologies, this is one of the very few OSS books that retains a longevity of relevance (it was published in 2001)
Million Dollar Consulting: The Professional's Guide to Growing a Practice, Fifth EditionMillion Dollar Consulting: The Professional’s Guide to Growing a Practice, Fifth Edition
by Alan Weiss
Alan Weiss has the ability to cut through the waffle that’s offered in many consultancy how-to manuals. He provides insightful and often contrarian advice that will make you a more professional consultant, no matter what area of expertise you cover.
Mastering your OSS: Operational Support System Implementation Tips and TechniquesMastering your OSS: Operational Support System Implementation Tips and Techniques
by Ryan Jeffery
This is the best OSS book that I’ve written (so far), but with new material in the pipeline, watch this space for even better publications. It provides the frameworks, processes, insights and recommendations that will help guide you through the myriad of challenges, technical or otherwise, that you will face in the world of OSS.
Power Listening: Mastering the Most Critical Business Skill of AllPower Listening: Mastering the Most Critical Business Skill of All
by Bernard T. Ferrari
Bernard Ferrari advises the use of the Pareto Principle to listening. In other words, spending 80% of the time listening and only 20% talking. It’s such an important trait for all technical resources, yet perhaps somewhat uncommon unfortunately. As the “hired gun,” there is a tendency to start firing from both barrels verbally as soon as you meet with the customer. But the most insightful insights are the ones that are understandable to the customer. They have to be relevant in terminology, desired outcomes, roles/responsibilities, respective capabilities, etc, etc. You only get that context from Power Listening.
The Click Moment: Seizing Opportunity in an Unpredictable WorldThe Click Moment: Seizing Opportunity in an Unpredictable World
by Frans Johansson
Johansson also introduces the concept of the “smallest executable step” as a mechanism for harnessing the apparent randomness of our modern, rapidly changing world. He suggests that we make many small bets rather than one massive bet as a means of improving success rates. OSS are complex systems so any small deviation makes predictions of completion time, resources and cost difficult. As implementers, it’s our job to remove as much complexity as possible
 Harder Than I Thought: Adventures of a Twenty-First Century LeaderHarder Than I Thought: Adventures of a Twenty-First Century Leader
by Robert D. Austin, Richard L. Nolan
More than anything else, one paragraph has stuck with me from this guide to project change leadership, “….once you start a company transformation, it’s like a stampede. If you try to lead from the front, you get trampled; if you try to lead from the back, you have no impact. Best to lead from the side by carefully nudging and turning the stampede to avoid everyone going over the cliff.”
Waging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational ComplexityWaging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational Complexity
by Stephen A. Wilson, Andrei Perumal.
Amongst other things, this book introduces the concept of The Whale Curve, a model that breaks products into the profitable or the cannibalistic.
Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic OrderCryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order
by Paul Vigna, Michael J. Casey
You may (or may not) be interested in cryptocurrencies right now, but this book provides brilliant context for two concepts that are likely to have a big impact on future OSS – blockchains and smart contracts.

What have I missed? What should I be adding to my reading list? Alternatively, which books on the list do you think I’ve over-rated?

The OSS cosmetic surgery analogy

I love the fact that we’re constantly seeking incremental improvements for our OSS. However, cumulative OSS changes can be a double-edged sword, just as they can be in the cosmetic surgery industry. In both cases, these well intentioned changes can distort as readily as they can improve.


Photo-collage courtesy of DailyMail.co.uk.

I’ve seen OSS go from being open, intuitive, adaptable and flexible tools to being so customised for a single client purpose that they need additional reconstructive work for even the tiniest change (eg process revision, network configuration / topology type, new card type in an existing device, etc).

Embarking on a course of incremental customisation, such as an Agile methodology, can become dangerous without careful consideration. Be vigilant of where your changes might be guiding you.

The alchemy of OSS

Alchemy is the ancient practice of trying to turn lead into gold… alchemy was an art based partly upon experimentation and partly upon magic.”
Benjamin Radford
here on Live Science.

The definition of alchemy is, “part science, part art,” according to Geoff Leong. To William Whewell, “In general, art has preceded science. Men have executed great, and curious, and beautiful works before they had a scientific insight into the principles on which the success of their labours was founded. There were good artificers in brass and iron before the principles of the chemistry of metals were known; there was wine among men before there was a philosophy of vinous fermentation… Art was the mother of Science.”

In OSS, we have the science / experimentation part well covered. Indeed, we have great creativity in science / experimentation.

But are we lavished with the curiosity, the art or the magic (apart from the “magic” within some OSS product slide-decks)? Who are our Michaelangelos, Ben Franklins, Steve Jobs, et al – those who are preceding OSS science with art?

Simple question – Do you have any in your organisation?

Do you, like me, feel that we need art and magic to be the instigators of The Call for OSS Innovation?

The madness of most OSS training

When you’ve just implemented a new OSS, what does the training look like? A 2-3 week classroom course series? A train-the-trainer series, which then trickles down to the workforce?

If this is what your OSS training looks like (or even closely resembles), then this is madness. Unfortunately, this is the model that I’ve seen most predominantly in the wild. Many OSS build contracts / RFPs even mandate this type of knowledge transfer.

It’s madness because classroom courses don’t tend to be very good for absorbing the context or nuance of using an OSS. OSS training tends to be generic, without the local context of using the customer’s process flows, naming conventions, device types, topologies, services, etc.

Alan Weiss articulates this well, “…skills building occurs best when it includes application on the job, oversight by immediate supervisors, accountability for implementation, and rewards for success. None of that is accomplished in a classroom.”

What are the better alternatives then? Embedded training including:

  1. Have the customer operatives deeply embedded in the implementation project, absorbing knowledge in “real” situations as it is being built
  2. Offer supported sandpit environments that reflect PROD (Production environments) and allow operatives the time to build scenarios from their own contexts in the sandpit
  3. Provide handover support, where the installation team is on hand to support operational teams during an initial period after handover
  4. Master classes where operatives ask questions within their specific contexts, noting that this technique is only suitable after students have already developed a significant base of knowledge

Whilst PAOSS offers virtual class-based OSS training (which are generic by nature, not product-specific), I’ve found embedded knowledge transfer is far more successful and is my strongly recommended approach.

This is NEVER going to happen

Have you noticed all the recent headlines about the big, iconic brands in our industry struggling to make targets, cutting headcounts, etc.? This covers vendors and service providers alike.

As a complete generalisation:

  • Vendors are going backwards
  • Traditional CSPs are going backwards
  • Profit decline means projects and investments in OSS can only be trending downwards too

We know it’s a burning platform. We know that the current arc isn’t working. We know that change isn’t just an option, but a necessity.

Given this environment, today I’ll talk about an idea that will never happen, but I’d love to imagine just for the purpose of experimentation – to see whether it would disrupt in a positive way or just cause destruction.

The one big impetus we need is increasing eyeballs on a smaller number of OSS (ie decreasing fragmentation) – a critical mass of eyeballs on a smaller number of code bases. That means all the big, but flailing OSS vendors throw their code over to an independent arbiter to make a unified, powerful core product suite that then becomes open-sourced.

The core manages inventory, alarms, performance, workflows, service ordering, provisioning, security, scalability, APIs and all the other elements of a foundational OSS.

The vendors can then just innovate and differentiate with add-ins and services and content since there’s currently marginal differentiation in the core anyway (ie everyone has the “entry” functionality).

What are your completely contrarian ideas that will never happen but you’d like to trial just to see the outcomes?

Lighting the fire under OSS

Forcing people to follow new rules is always an uphill battle, but getting them to buy into a concept to the point where they start contributing their own ideas can literally create a movement within an organisation.”
Ken Segall
.

I’ve really diverted away from direct discussions about OSS in a couple of recent posts about influence, persuasion and change. However, as the link suggests, I recently had a late-onset epiphany in relation to what’s needed to take OSS forward. I’ll give you a hint – it’s not OSS technology change per se.

The recent Call for Innovation has sparked significant direct feedback and a large up-tick in traffic here on PAOSS. This interactivity says that there’s a significant latent appetite for drastic change in our industry.

We’re all really busy, mostly on implementations, so its not change we’re lacking. It’s a lack of fundamental change. Big picture change. The type of change that takes significant collaborative effort, but a correspondingly massive mindset shift of the collective.

That’s the challenge that I’m now grappling with. How do we take the leap from being an implementer of incremental change to sparking something much bigger? It’s also a realisation that the skillsets are different to what most of us in OSS tend to try to develop.

I’d love to hear your thoughts and words / experiences of inspiration.

Fon joins prpl Foundation

Fon joins prpl Foundation to accelerate open-source innovation for the Digital Home and Carrier WiFi.

The prpl Foundation, an open-source, community-driven, not-for-profit consortium with a focus enabling the security and interoperability of embedded devices for the smart society of the future, has announced that Fon has joined the Foundation. As the world’s leading WiFi software company, Fon joins prpl to accelerate the development of a common, open-source-based software framework which will enable deployment of new carrier services for the digital home and carrier WiFi hotspots.

“With the formation of our Carrier Interest Group last year, we set out to strengthen the ties between telecommunications carriers, major chipset vendors and the open source community,” said Art Swift, president of the prpl Foundation. “One of the key goals was to bring new carrier-grade features to gateways and routers that would enable new business models, while promoting the use of open source software as much as possible. Fon’s expertise in providing WiFi technology solutions, including residential WiFi sharing and carrier WiFi, as well as their long-standing relationships with the vibrant OpenWrt open source community, will add momentum to this effort.”

“For many years, Fon has been working with the world’s leading operators to provide WiFi on the go. We strive to always deliver the best user experience for our clients’ customers. We want to help create an ecosystem around home WiFi CPEs that have been ignored for so long, which is why we have chosen to join the prpl Foundation. We believe that it’s essential to keep innovating and building powerful technology in order to keep up-to-date with users’ needs, a belief that prpl shares,” noted Iurgi Arginzoniz, CINO of Fon. “We’ve shipped millions of WiFi devices already that leverage open-source software, and we are delighted to join prpl’s efforts to work with the open-source community to address additional carrier needs. This will help us and others deliver excellent products to the end users, which is, in essence, the focus of what we do.”

In addition to membership in the Foundation, alongside a variety of Fon’s clients, the company intends to participate in prpl’s Carrier Interest Group, the prplWrt working group, and the common API task group.

Your OSS – asset or liability?

An asset is something that puts money into your pocket every month. A liability takes money out.

Based on those very simple terms, is your OSS an asset or a liability? If a liability, does it aspire to be an asset? By that, I mean are you actively doing stuff to make it profitable in its own right, or are you happy to just apportion the cost of your OSS out across the “asset” business units every month?

The diagram below shows what is known as The Whale Curve. It provides a graph of the relative profitability of each product in your product mix. Both are generating revenues, but assets are on the left, liabilities on the right.
The Whale Curve

Can your OSS even be plotted on this graph or is it just dragging all the products down by cost apportionment?

Even if you are unable to productise your OSS, one simple mindset shift changes OSS asset perception – talk in business outcomes or results, never in deliverables or functionalities.

For example, a business outcome is,”our new OSS allows us to activate customer services (and turn on revenue) 5 days faster than our competitors (on average).” The same thing stated in functionality-speak is, “Our new OSS uses machine learning to automate the customer design and build process.”