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 Dad Rich 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 Success Insanely 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.
Rework Rework
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 Actions Enchantment: 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 Business Rain: 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 Audience The 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 Industry Killing 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 CEO Jack 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 Costs The 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 Less Essentialism: 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 Entrepreneur Anything 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 Industry Brick 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 Work Principles: 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 Irrelevant Blue 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 Change Leading 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 Time Everything 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 Sales Endless 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 Innovation The 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
null Linchpin: 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.
Dangerous Company: Consulting Powerhouses and the Companies They Save and Ruin Dangerous Company: Consulting Powerhouses and the Companies They Save and Ruin
by Charles Madigan and James O’Shea
This book provides some insights into the best and worst of management consulting. It is a little old now, dating back to the late 1990’s but it had a significant impact on me when I read it in the 2010’s. It describes some of the unscrupulous acts / tactics / results that have lead to the poor reputation that consulting has in some circles. It also reinforced a strong belief I’ve always had in doing right by the client before the firm because building reputation and integrity ultimately benefits the firm anyway.
Made to Stick: Why Some Ideas Survive and Others Die Made 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 It The 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 Remarkable Purple 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 Inspiration Creativity, 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 Rich The 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 Providers OSS 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 Edition Million 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 Techniques Mastering 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 All Power 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 World The 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 Leader Harder 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 Complexity Waging 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 Order Cryptocurrency: 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?

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.”

One link in an OSS chain reaction

Have you ever experienced an event where you realised that you’d spent the previous 10+ years doing something wrong (or at least incomplete)?

I had one such experience last Friday during a presentation by Roger Gibson, a Partner at Infosys Consulting.

Now you all know that I’m a passionate spruiker of change management on OSS projects, mainly because one of the biggest reasons for OSS failure is the lack of CM. You may’ve even noticed a recent article here on PAOSS relating to the techniques we can use to influence change.

My entirely random guess is that about 95% of people in OSS focus primarily on the technical aspects of what’s being implemented, leaving only 5% who’ve grasped the significance of influencing change. My lightbulb moment on Friday came in realising that there’s actually also a 1% group (to be honest, it’s probably far less than 1%).

As an external consultant on most projects, I’ve generally figured that client representatives have far greater tenure and more ability to influence change within their organisation than me. My modus operandi has been to create change strategies and persuade the project team (plus key stakeholders) to start change initiatives as early as possible.

In effect, I’ve been delegating change responsibility. l now realise that’s not going far enough. It is MY responsibility to light the fire under every project I work on – to initiate the chain reaction.

Do you agree that it’s also YOUR responsibility to light the fire under every project you work on?
To quote Wayne Dyer, “It’s never crowded along the extra mile.”

The PAOSS Call for Innovation has been released

I’ve been promising to release an OSS Call for Innovation, a manifesto of what OSS can become – a manifesto that also describes areas where exponential improvements are just waiting to happen .

It can be found here:
http://passionateaboutoss.com/oss-call-for-innovation/
And you’ll also notice that it’s a new top-level menu item here on PAOSS.

Each time I’ve released one of these vision-statement style reports in the past, I’ve been pleasantly surprised to find that some of the visions are already being worked on by someone in the industry.

Are there any visions that I’ve overlooked? I’d love to see your comments on the page and spread the word on all the amazing innovations that you’re working on and/or dreaming about.

Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?
No?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

The OSS Think Big juxtaposition

I recently saw the advertisement below:

I’ve clipped only the last 10 seconds because that was the part that struck me. The ad is for BHP*, one of the world’s largest miners. The mining industry thinks in long-term projects because it takes many years to deliver results – for exploration, planning, approvals, for the infrastructure to be built and operationalised, etc.

Mining is “only” the process of pulling natural resources out of the ground, but despite all our complexities, mining projects tend to be far more complex than for OSS. The decade-long duration of projects means that technologies that were originally included in plans frequently become obsolete mid-flight and have to be re-planned. That means major contracts also need to be obsoleted and re-planned mid-flight. Work-force management has a completely different scale than for OSS.

Mining thinks in time-frames of decades. OSS transformations are planned in time-frames of years. OSS delivery, especially Agile deliveries, often only think in quarters (or much, much less).

In OSS, do we really Think Big?

But there’s a twist on this question. In the rare cases when we do think big, are we constraining ourselves by then following into the “deliver big” mindset too? In OSS, I’ve always felt that we deliver most efficiently when very small numbers of very clever people group together.

So there’s the juxtaposition with the clip above – Think Big… Think Small.

When you’re thinking of OSS roadmaps, what’s your thinking time-frame?

* For disclosure, I’m not an investor in BHP to my knowledge, but perhaps my super fund is.

OSS brand building with the simple stick

Today’s consumers want to get the best prices, but offering your brand at a discount can undermine profits and threaten viability. Smart brands utilize strategies to create and sustain a meaningful difference that helps consumers justify spending more.”
Nigel Hollis
, in his PoV on branding.

I once read a statistic that at one point Apple owned 6.5% of the total handset market, but accounted for 75% of the entire industry’s operating profit. Now that’s a premium brand!

Whilst some in the OSS industry may claim their brand is the strongest, none come close to having the fanatic customer base that Apple has built. This makes me ponder what it would take to create a truly premium OSS brand.

People buy a premium brand for the enjoyment it brings them, either in the experience, the status, the prestige, the satisfaction of having a need met efficiently and probably many other variants on these reasons.

Three questions for you:

  1. For how many customers is the OSS buying experience an enjoyable one?
  2. For how many customers is the implementation / integration experience an enjoyable one?
  3. For how many customers is the user experience an enjoyable one?

Actual customer experiences in relation to the questions above might be 1) Confusing, 2) Arduous and 3) Unintuitive.

I’m going to take a completely contrarian view because the status quo clearly isn’t working. This contrarian view focuses squarely on simplicity. It seems that our developers are always building new functionality. However, most of the OSS functionality that users will ever need has already been around for decades. Rather than new functionality, how about a focus on making old functionality vastly more simple?

Rather than with Engineers, how about beating OSS with the simple stick by engaging marketers, designers, artists, stylists – the creatives – to improve the three experiences above?

Use cases for architectural smoke-tests

I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.”

Yesterday’s blog discussed the use of use cases to test a new OSS architecture. TM Forum’s eTOM is the go-to model for process mapping for OSS / BSS. Their process maps define multi-level standards (in terms of granularity of process mapping) to promote a level of process repeatability across the industry. Their clickable model allows you to drill down through the layers of interest to you (note that this is available for members only though).

In terms of quick smoke-testing an OSS stack though, I tend to use a simpler list of use cases for an 80/20 coverage:

  • Service qualification (SQ)
  • Adding new customers
  • New customer orders (order handling)
  • Changes to orders (adds / moves / changes / deletes / suspends / resumes)
  • Logging an incident
  • Running a report
  • Creating a new product (for sale to customers)
  • Tracking network health (which may include tracking of faults, performance, traffic engineering, QoS analysis, etc)
  • Performing network intelligence (viewing inventory, capacity, tracing paths, sites, etc)
  • Performing service intelligence (viewing service health, utilised resources, SLA threshold analysis, etc)
  • Extracting configurations (eg network, device, product, customer or service configs)
  • Tracking customer interactions (and all internal / external events that may impact customer experience such as site visits, bills, etc)
  • Running reports (of all sorts)
  • Data imports
  • Data exports
  • Performing an enquiry (by a customer, for the purpose of sales, service health, parameters, etc)
  • Bill creation

There are many more that may be required depending on what your OSS stack needs to deliver, but hopefully this is a starting point to help your own smoke tests.

Use-case driven OSS architecture

When it comes to designing a multi-vendor (sometimes also referred to as best-of-breed) OSS architecture stack, there is never a truer saying than, “the devil is in the detail.”

Oftentimes, it’s just not feasible to design every interface / integration / data-flow traversing a theoretical OSS stack (eg pre-contract award, whilst building a business case, etc). That level of detail is developed during detailed design or perhaps tech-spikes in the Agile world.

In this interim state, I often leverage use-case design and touch-point mapping through the stack to ensure that all of the use-cases can be turned into user-journeys, process journeys and data journeys. This process can pick up the high-level flows, but more importantly, the high-level gaps in your theoretical stack.

Can you define why OSS projects are so challenging?

Answer. Change creates incompetence.

Whether on the vendor/integrator side, the customer side or along the strategic advisor line, OSS projects bring about constant change; massive change.

I’ve often wondered why I can feel so incompetent in the world of OSS, even though I know more about it than (probably) any other topic.

The answer has just dawned on me, as per above – change creates incompetence. There is so much change happening on so many levels within OSS that every one of us is a freshly-minted incompetent, no matter how much prior competence we may’ve built up.

And this defines the double-edged sword of OSS. The pain of feeling incompetent drives the thirst for learning / evolution.

The top-down, bottom-up design process

When planning out a full-stack business / network / services management solution, I tend to follow the top-down, bottom-up design process.

Let’s take the TMN pyramid as a starting point:
TMN Pyramid
Image courtesy of www.researchgate.net

Bottom-up: When designing the assurance stream (eg alarms, performance, etc), I start at the bottom (Network Elements), understanding what devices exist in the network and what events / notifications / monitors they will issue. From there, I seek to understand what tool/s will manage them (Element Management / Network Management), then keep climbing the stack to understand how to present key information that impacts services and the business.

Top-down: When designing the fulfilment stream (eg designs, provisioning, moves/adds/changes, configuration, etc), I generally start at the top* (Business Management), what services are being offered (Service Management) and figure out how those workflows propagate down into the network and associated tools (such as ticketing, workforce management, service order provisioning, etc).

This helps to build a conceptual architecture (ie a layered architecture with a set of building blocks, where the functional building blocks start out blank). From the conceptual architecture, we can then identify the tools / people / processes that will deliver on the functions within each blank box.

This approach ensures we have the big picture in mind before getting bogged down into the minutiae of integrations, data flows, configurations of tools, etc.

To get momentum quickly, I tend to start with the bottom-up side as data flows (eg SNMP traps) are more standardised and the tools tend to need less configuration to get some (but not all) raw alarms / traps into management tools, perhaps just sand-pit versions. For the next step, the top-down part, I tend to create just one simple service scenario, and perhaps even design the front-end to use The Mechanical Turk model described yesterday, and follow the flow manually down through the stack and into element management or network layers. Then grow both streams from there!

* Note that I’m assuming services are already flowing through the network under management and/or the team has already figured out the services they’re offering. In a completely green-fields situation, the capabilities of the network might determine the product set that can be offered to customers (bottom-up), but generally it will be top-down.

Short-sighted / long-sighted OSS

When I hear that the average tenure in tech is just two years, I wonder how anyone gets anything done. When I hear such job hopping justified by the fact that changing companies is the only way to get a raise, I just shake my head at the short-sightedness of such companies.”
David Heinemeier Hansson
here on Signal v Noise.

Have you noticed how your most valuable colleagues also tend to have had lengthy tenures in their workplace*? No matter how experienced you are at OSS, it takes a six month (plus) apprenticeship before you start adding real value in a new OSS role. The apprenticeship is usually twelve months or longer for those who are new to the industry. Unfortunately, it takes that long to develop the tribal knowledge of the tools, the processes, the people, the variants and the way things get done (including knowing how to circumvent rules).

To be honest, like DHH above, I shake my head when employers treat their OSS talent as expendable and don’t actively seek to quell high turnover in their ranks. An average tenure of two years equates to massive inefficiency. That’s my perspective on internal resources, the resources that run an OSS. The problem with internal roles though is that they can be so all-encompassing that resources become myopic, focused only on the internal challenges / possibilities.

The question then becomes how you can open up a wider field of view. The perfect example in our current environment is in the increasing use of CI/CD / DevOps / Agile methods to manage OSS delivery. I hear of a new tool almost every day (think Ansible, Kubernetes, Jenkins, Docker, Cucumber, etc, etc). It bewilders me how people keep up to know which are the best options, yet this is only one dimension of the change that is occurring in the OSS landscape. In these situations, high turnover actually helps with the cross-fertilisation of ideas / tools / practices. Similarly, external consultants can also assist with insights garnered from multiple environments.

There is a place for both on OSS projects, but I strongly subscribe to DHH’s views above. It’s the age-old question – how to attract and retain great talent, but do we give this question enough consideration??

* BTW. I’m certainly not implying that by corollary all long-tenured resources are the most valuable.

Ramping down network variants, ramping up digital variants

Voice and data are no longer the services that organisations, large and small, see as making a difference. The services that do make a difference are more dynamic and diverse – digital distribution, promotion and marketing, payments and billing, business intelligence, business continuity (including security) and more – the factors that make their organisations thrive.

Our OSS and BSS are currently complex due to all the network variants that they handle. But if customers don’t value the network (as a differentiator) then why are we putting so much effort / attention there? If customers want ubiquitous, secure data streams with digital services on top, then why aren’t we reducing network variants and correspondingly reducing complexity in our network-based OSS / BSS?

That will give us the head-room to enhance our tools and ramp up the digital services that organisations do value.

Customers like options. But if all the options are available on the digital services / bundles, customers won’t really care if they’re delivered over a network stream that has almost no variants. This also allows a transition to more of a consumption-based model rather than all the variants of speeds and feeds and protocols.

The big challenge here is convincing the networks teams to ramp down and allow digital teams to ramp up. That concept won’t go down too well at most service providers though will it?

The three big lies of the telecoms industry

What are the three big lies of the telecoms industry?
The first lie is that data monetisation is coming. Well we are still waiting.
The second is that we have billions of customers. Well are they really our customers or are they people who just tolerate us and are really customers of someone else?
The third lie is that we are utility so we have stable returns, and because we have spectrum allocations that is our safety net. EBITDA multiples for the telco industry were at around 6, while utilities were at multiples of 12 to 16, so it could not be said that telcos – which often had up to five competitors in markets – were utilities
.”
Alexey Reznikovich

Three valid points. OSS / BSS could be highly influential in whether these are actually lies or not.

Data:
If we think of data as carriage, that’s clearly not monetising for most telcos currently. Well, it does bring in revenues but at a diminishing rate per bit. If we think of data in terms of content (eg voice, video, text, etc), then there are some monetisation wins (eg Game of Thrones) but more content is coming on line so there is more supply, making the profitability tail longer. If we talk about data as insight (or supporting the generation of insights if selling analytics or API offerings) then this will never go out of fashion (although with more “insights” being generated, the bar will be raised on what is truly insightful)

Customers:
Alexey’s note here that our customers just tolerate us and are really customers of someone else possibly has some merit. It’s the reason why the OTT play has been so successful. I still have the sense that there is an implicit trust in our service providers, due to the long subscription/billing history, media / shareholder attention on them and regulation that governments place on them (even if not an implicit trust in their customer service). Not all OTT players have the same track record of regulatory governance. Some OTT providers are invisible, hidden somewhere out on the cloud. I feel that this could represent a strong opportunity in a world where crypto-currencies carry vastly more value than they do today.

Utilities:
This comes down to the business model of any given Telco and / or the regulatory frameworks they operate within. They could opt to go down the path of ubiquitous data (like ubiquitous voice of the distant past), or like most, they can go down the path of being a digital service provider. To be honest, there are probably quite a few incumbent providers that are probably more closely aligned to utility than DSP in the collective way of thinking within their workforce. That often transfers to their mindset in building OSS.

Channelling “Intel Inside” to improve the brand recognition of your OSS

During Intel’s marketing of “Intel Inside” they taught consumers to look for the Intel Inside logo as an assurance of quality. Consumers eventually came to see “Intel Inside” as a standard and began asking the question: “Why doesn’t your product use Intel processors?” This standard became so important that today it is one of the world’s largest co-operative marketing programs,where hundreds of computer companies license the use of the Intel Inside® logos.
The ingredient must be highly differentiated in order to add value to the overall brand. This means the ingredient should have a separate name and logo and overall purpose, because the added value comes from the extra identity. First and foremost, brands should not create confusion in the market. The main brand should be well established in the market before employing an ingredient branding strategy because the consumer needs first understand the core brand and then find additional value in the ingredient
.”
From an article about Ingredient Branding on Disenthrall.co.

When you think about the chips inside the multitude of electronic devices you own and use, how many brands could you identify? How many chipsets are differentiated enough to sway your decision on the device itself?

According to FastCompany, “If one thing distinguishes Intel’s innovative thinking, it is their 1990s strategy of branding a semiconductor chip as a valuable feature that consumers would look for when they purchased a computer. The campaign’s two decades of ubiquity make us forget this now, but at the time it was an incredibly novel approach to marketing. People bought computers because of the software, the specs, or a friend’s recommendation. Who cared about who made some tiny chip inside the box that you couldn’t even see?
But with the proliferation of PCs, and with consumers at a loss in trying to figure out what made one better than the other, Intel saw an opportunity, and so it took a major risk. Intel’s leadership was convinced this was the way to grow market share…

The “Intel Inside” initiative has arguably been the most successful ingredient marketing exercises in history. They’ve made the invisible visible.

To many users/customers, the achievements of our OSS are invisible, with other components getting the credit for outcomes that are heavily underpinned by our OSS. The challenge for us, just like Intel, is to differentiate and improve the value of our brand. We get the flak for when things go wrong (often through no fault of our own), but we rarely get the credit for the things that work – for the services activated, for the problems resolved, for the equipment ordered, for the new services enabled, for the insights gleaned, etc.

The question for us all is how to make those accomplishments, that differentiation, the brand value visible. [Note that I’m referring to the brands of internal OSS suites here, not just external vendor products]

If we think about making the invisible visible to key execs / sponsors / stakeholders, we need to think about how they tend to interact with OSS. I would surmise that in most cases they interact via reports. Assuming you’re confident that you’ve nailed the content of your reports, that they’re succinct and valuable to those stakeholders, is there any reason why we couldn’t put our equivalent of the “Intel Inside” badge on the reports?

But first, are you confident that the badge is a badge of honour? Will your brand instil in customers a sense of quality, assuredness and innovation?

Next step, man-machine partnerships

Getting literate in the language of the future posed the thought that data is the language of the future and therefore it is incumbent on all OSS practitioners to ensure their literacy.

It also posed that data literacy provides a stepping stone to a future where machine learning is more prevalent. This got me thinking. We currently think about man-machine interfaces where we design ways for humans and machines to get info into the system. But the next step, the future way of thinking will be man-machine partnerships, where we design ways to leverage machines to get more out of the system.

Data literacy will be essential to making this transition from MM interface to MM partnership. Machines (eg IoT and OSS) will get data into the system. Through partnerships with humans, machines will also be instrumental in the actions / insights coming out of the system.

Inverting the iceberg to get more funding for your OSS

In the last couple of days, we’ve discussed frameworks that could allow CSPs to design disruptive business models around factors that our OSS / BSS can control. Not exactly riveting stuff for the tech-heads amongst the reader-base, but relevant for the amount of investment that gets directed into the tech projects that we all work on.

Let me get a little more specific today. We only get to work on cool OSS projects if funding is allocated to them. As we all know, OSS are the linchpin around which a service provider is built, but most executive sponsors don’t grasp the full extent of this dependence. There are a few reasons for this:

  1. OSS are perceived as not generating any revenue directly
  2. OSS projects continually disappoint (on time, cost and/or functionality)
  3. The full picture of OSS functionality is hidden (like an iceberg) and is boring to most. The Service provider’s customers certainly have zero interest in the back-end systems / functionality in use
  4. Our business cases tend to be built around cost reduction, not business growth. Let’s be honest, OSS cost reductions go in the same excitement bucket as a reduction in paper clips, pens and printer paper
  5. The technologies used by OSS seem to be obsoleted even faster than the network technologies they manage
  6. They tend to deliver more negative messaging (eg network outages, fall-outs resulting in poor customer experiences, etc), whilst others get the credits for any positive messaging that OSS have facilitated
  7. Due to the costs of implementation and change, OSS are seen by many as giant sinkholes of cost centres
  8. The list goes on!!

Aaarghhh! Why do we bother working in OSS?

For all of us in the OSS industry, we understand the justifications behind these derogatory remarks above.

It all comes down to the messaging going to executive sponsors. Like Steve Jobs, I have just three things (to help build a compelling story for your executive sponsors):

  • Break “the sink-hole perspective” by generating revenues – via APIs, via platforms, via metrics that show OSS contribution to revenues or anything else that shows real value, not just cost-out, to executive sponsors as well as the customers they’re trying to service
  • Invert the iceberg – show just how much capability is hidden under the surface by mapping how dependant the organisation’s positive outcomes are on its OSS (OSS as the puppet-master). All the sexy stuff (eg 5G, IoT, network virtualisation, etc) can only be monetised if our OSS pull all the strings to make them happen
  • Simplify – the massive (and increasing) complexity in our business is boring to non-OSS people and an impediment to us in our ability to deliver exciting outcomes for everyone else. Just take Google – they have an incredibly complex tech-stack to run… but what does the customer interact with on their search page?

How to disrupt through your OSS – a base principles framework

We’ve all heard the stories about the communications services industry being ripe for disruption. In fact many over-the-top (OTT) players, like Skype and WhatsApp have already proven this fact for basic communications services, let alone the value-add applications that leverage CSP connectivity.

As much as the innovative technologies they’ve built, the OTT players have thrived via some really interesting business models to service gaps in the market. The oft-quoted examples here are platforms like Airbnb providing clients with access to accommodation without having the capital costs of building housing.

In thinking about the disruption of the CSP industry and how OSS can provide an innovative vehicle to meeting customer demands, the framework below builds upon the basic principles of supply and demand:

Supply and Demand opportunities in a service provider

The objective of the diagram is to identify areas where innovative OSS models could be applied, taking a different line of thinking than just fulfillment / assurance / inventory:

  • Supply – how can OSS influence supply factors such as:
    • Identifying latent supply (eg un-used capacity) and how incremental revenues could be generated from it, such as building dynamic offers
    • Unbundling supply by stripping multiple elements apart to supply smaller desirable components rather than all of the components of a cross-subsidised bundle. Or vice versa, taking smaller components and bundling them together to supply something new
    • Changing the costs structures of supply, which could include virtualisation, automation and many of the other big buzz-words swirling around our industry
  • Demand – how can OSS / BSS build upon demand factors such as:
  • Marketplace / Platforms – how can OSS / BSS better facilitate trade between a CSP‘s subscribers, who are both producer / suppliers and consumers. CSPs traditionally provide data connectivity, but the OTT players tend to provide higher perceived value of trade-connectivity including:
    • Bringing buyers and sellers together on a common platform
    • Providing end-to-end trade support from product development, sales / marketing, trading transactions, escrow / billing / clearing-house; and then
    • Analytics on gathered data to improve the whole cycle
  • Supply chain – how can OSS / BSS help customers to efficiently bring the many pieces of a supply chain together. This is sometimes overlooked but can be one of the hardest parts of a business model to replicate (and therefore build a sustainable competitive advantage from). For OSS / BSS, it includes factors such as:
    • As technologies get more complex, but more modular, partnerships and their corresponding interfaces become more important, playing into microservices strategies
    • Identifying delivery inefficiencies, which include customer impediment factors such as ordering, delivery, activations. Many CSPs have significant challenges in this area, so efficiency opportunities abound

These are just a few of the ideas coming out of the framework above. Can the questions it poses help you to frame your next OSS innovation roadmap (ie taking it beyond just the typical tech roadmap)?

The OSS / Singapore analogy

Singapore has made some really innovative decisions over the years. Recent ones include tokenisation of the Singapore Dollar on cyber-currencies, investing heavily in international startups based in Singapore and the streamlining of identity management (which will undoubtedly help to get around one of the biggest blockers to self-on-boarding new customers onto comms networks, particularly mobile).

Singapore perhaps lacks the natural commercial advantages (eg mining, manufacturing, agriculture, etc) that some other countries have. Despite that, it has made itself into a significant global player by being an economic and trading hub. It’s a focus on the abovementioned types of innovative thinking that has helped simplify the ability for people to do business in / through Singapore and has been instrumental in it developing a presence that outsizes its natural assets.

OSS falls into a similar category with regards to natural commercial advantages. Most people see OSS as cost centres, which implies having no ability to generate revenues directly (I don’t agree with this perspective, but that’s another story or two).

OSS can take a leaf out of Singapore’s book to out-size its presence – by acting as a highly efficient facilitator of business (and social) activities – but also by diligently identifying innovative ways to improve efficiency even further.

One way is for OSS to take more of a lead in the omni-channel experience as elegantly stated here:
The customer travels across all their channels — online, mobile, IVR, live and more – as they interact with you. You need to travel with them. If your channels aren’t fully integrated, they become just one more source of customer frustration. When you aren’t fully aware of how your customers have engaged with you across all your channels, costs of sales and service rise, and customer satisfaction shrinks.”

Another is through acting as a conduit to trade by doing more to bring its subscribers, all of which are buyers and sellers at some level, together with platform / marketplace / API / service thinking.

Another is through using data to provide marketing / sales / product-dev insights. Taking this further, to provide insightful information as mobile moments.

I’m sure you can think of more angles that take OSS beyond an inward-only facing operations toolset (ie cost centre). Do you have any great Singapore-thinking ideas for OSS to embrace?

OSS S-curves

I should say… that in the real world exponential curves don’t continue for ever. We get S-curves which closely mimic exponential curves in the beginning, but then tail off after a while often as new technologies hit physical limits which prevent further progress. What seems to happen in practice is that some new technology emerges on its own S-curve which allows overall progress to stay on an something approximating an exponential curve.
Socio tech

The chart above shows interlocking S-curves for change in society over the last 6,000 years. That’s as macro as it gets, but if you break down each of those S-curves they will in turn be comprised of their own interlocking S-curves. The industrial age, for example, was kicked off by the spinning jenny and other simple machines to automate elements of the textile industry, but was then kicked on by canals, steam power, trains, the internal combustion engine, and electricity. Each of these had it’s own S-curve, starting slowly, accelerating fast and then slowing down again. And to the people at the time the change would have seemed as rapid as change seems to us now. It’s only from our perspective looking back that change seems to have been slower in the past. Once again, that’s only because we make the mistake of thinking in absolute rather than relative terms.”
Nic Brisbourne
here.

I love that Nic has taken the time to visualise and articulate what many of us can perceive.

Bringing the exponential / S-curve concept into OSS, we’re at a stage in the development of OSS that seems faster than at any other time during my career. Technology change in adjacent industries are flowing into OSS, dragging it (perhaps kicking and screaming) into a very different future. Technologies such as continual integration, cloud-scaling, big-data / graph databases, network virtualisation, robotic process automation (RPA) and many others are making OSS look so different to what they did only five years ago. In fact, we probably need these technologies to keep apace with the other technologies. For example, the touchpoint explosion caused by network virtualisation and IoT mean we need improved database technologies to cope. In turn this introduces a complexity and change that is almost impossible for people to keep track of, driving the need for RPA… etc.

But then, there are also things that aren’t changing.

Many of our OSS have been built through millions of developer days of effort. That forces a monumental decision for the owners of that OSS – to keep up with advances, you need to rapidly overhaul / re-write / supersede / obsolete all that effort and replace it with something that keeps track of the exponential curve. The monolithic OSS of the past simply won’t be able to keep pace, so highly modular solutions, drawing on external tools like cloud, development automation and the like are going to be the only way to track the curve.

All of these technologies rely on programmable interfaces (APIs) to interlock. There is one major component of a telco’s network that doesn’t have an API yet – the physical (passive) network. We don’t have real-time data feeds or programmable control mechanisms to update it and manage these typically unreliable data sources. They are the foundation that everything else is built upon though so for me, this is the biggest digitalisation challenge / road-block that we face. Collectively, we don’t seem to be tackling it with as much rigour as it probably deserves.