Micro-strangulation vs COTS customisation

Over the last couple of posts, we’ve referred to the following diagram and its ability to create a glass ceiling on OSS feature releases:
The increasing percentage of tech debt

Yesterday’s post indicated that the current proliferation of microservices has the potential to amplify the strangulation.

So how does that compare with the previous approach that was built around COTS (Commercial off-the-shelf) OSS packages?

With COTS, the same time-series chart exists, just that it sees the management of legacy, etc fall largely with the COTS vendor, freeing up the service provider… until the service provider starts building customisations and the overhead becomes shared.

With microservices, the rationalisation responsibility is shifted to the in-house (or insourced) microservice developers.

And a third option: If the COTS is actually delivered via a cloud “OSS as a service” (OSSaaS) model, then there’s a greater incentive for the vendor to constantly re-factor and reduce clutter.

A fourth option, which I haven’t actually seen as a business model yet, is once an accumulation of modular microservices begins to grow, vendors might begin to offer microservices as a COTS offering.

Can the OSS mammoths survive extinction?

Startups win with data. Mammoths go extinct with products.”
Jay Sharma
.

Interesting phraseology. I love the play on words with the term mammoths. There are some telcos that are mammoth in size but are threatened with extinction though changes in environment and new competitors appearing.

I tend to agree with the intent of the quote, but also have some reservations. For example, products are still a key part of the business model of digital phenoms like Google, Facebook, etc. It’s their compelling products that allow them to collect the all-important data. As consumers, we want the product, they get our data. We also want the products sold by the Mammoths but perhaps they don’t leverage the data entwined in our usage (or more importantly, the advertising revenues that gets attracted to all that usage) as well as the phenoms do.

Another interesting play on words exists here for the telcos – in the “winning with data.” Telcos are losing at data (their profitability per bit is rapidly declining to the point of commoditisation), so perhaps a mindset shift is required. Moving the business model that’s built on the transport of data to a model based on the understanding of, and learning from, data. It’s certainly not a lack of data that’s holding them back. Our OSS / BSS collect and curate plenty. The difference is that Google’s and Facebook’s customers are advertisers, whilst the Mammoths’ customers are subscribers.

As OSS providers, the question remains for us to solve – how can we provide the products that allow the Mammoths to win with data?

PS. The other part of this equation is the rise of data privacy regulations such as GDPR (General Data Protection Regulation). Is it just me, or do the Mammoths seem to attract more attention in relation to privacy of our data than the OTT service providers?

Are your OSS better today than they were 5 years ago?

Are your OSS better today than they were 5 years ago?
(or 10, 15, 20 years depending on how long you’ve been in the industry) 

Your immediate reaction to this question is probably going to be, “Yes!” After all, you and your peers have put so much effort into your OSS in the last 5 years. They have to be better right?

On the basis of effort, our OSS are definitely more capable… but let me ask again, “Are they better?”

How do they stack up on key metrics such as:

  1. Do they need less staff to run / maintain
  2. Do they allow products to be released more quickly to market
  3. Do they allow customer services to be ready for service (RFS) faster
  4. Are mean times to repair (MTTR) faster when there’s a problem in the network
  5. Are bills more accurate (and need less intervention across all of the parties that contribute)
  6. Are there less fall-outs (eg customer activations that get lost in the ether)
  7. Are we better at delivering (or maintaining) OSS on budget
  8. Are your CAPEX and OPEX budgets lower
  9. Are our front-office staff (eg retail, contact centres, etc) able to give better outcomes for customers via our OSS/BSS
  10. Are our average truck-rolls per activation lower
  11. Are the insights we’re identifying generating longer-run competitive advantages
  12. etc, etc

Maybe it’s the rose-coloured glasses, but my answer to the initial question when framed against these key metrics is, “Probably not,” but with a couple of caveats.

Our OSS are certainly far more complicated. The bubble in which we operate is far more complicated (ie network types, product offerings, technology options, contact channels, more touchpoints, etc). This means more variants for our OSS / BSS to handle. In addition, we’ve added a lot more functionality (ie complexity of our own).

Comparison of metrics will vary greatly across different OSS operators – some for the better, some worse. Maybe I’m just working on projects that are more challenging now than I was 5, 10, 15 years ago.

Do you have the data to confirm / deny that your OSS is better than in years past?

PS. Oh, and one last call-out. You’ll notice that the metrics above tend to be cross-silo. I have no doubt that individual OSS products have improved in terms of functionality, usability, processing speeds, etc. But what about our end-to-end workflows through our OSS/BSS suite of products?

5 principles for your OSS Innovation Lab

Corporate innovation is far more dependent on external collaboration and customer insight than having a ‘lab’.”
Andy Howard
in a fabulous LinkedIn post.

Like so many other industries, OSS is ripe for disruption through innovation. Andy Howard’s post provides a number of sobering statistics for any large OSS vendors thinking of embarking on an Innovation Lab journey as a way of triggering innovation. Andy quotes the New York Times as follows, “The last three years have seen Nordstrom, Microsoft, Disney, Target, Coca-Cola, British Airways and The New York Times either close or dramatically downsize their innovation labs. 90% of innovation labs are failing.”

He also proposes five principles for corporate innovation success (Andy’s comments are in italics, mine follow):

  1. People. Will taking people out of the business and placing them into a new department change their thinking? No way. Those successful in corporate innovation are more entrepreneurial and more customer-centered, and usually come from outside of the organisation.
    Are you identifying (and then leveraging) those with an entrepreneurial bent in your organisation?
  2. Commercial intent. Every innovation project requires a commercial forecast. To progress, a venture must demonstrate how it could ultimately generate at least €100 million in annual revenue from a market worth at least €1 billion, and promise higher profit margins than usual.
    The numbers quoted above come from Daimler’s (wildly successful) Innovation Lab. Have you noticed that they’ve set the bar high for their innovation teams? They’re seeking the moonshots, not the incremental change.
  3. Organisational architecture. Whether it’s an innovation lab or simply an innovation department, separating the innovation team from the rest of the business is important. While the team may be bound by the same organisational policies, separation has cultural benefits. The most critical separation is not in terms of physical space, but in the team’s roles and responsibilities. Having employees attempt to function in both an ‘innovation’ role and ‘business as usual’ role is counterproductive and confusing. Innovation is an exclusive job.
    I’m 50/50 on this one. Having a gemba / coal-face / BAU role provides a much better understanding of real customer challenges. However, having BAU responsibilities can detract from a focus on innovation. The question is how to find a balance that works.
  4. External collaboration. Working with consultants and customers from outside of the organisation has long been a contributor to corporate innovation success. Companies attempting a Silicon Valley-style ‘lone genius’ breakthrough are headed towards failure. P&G’s ‘Connect and Develop’ innovation model, designed to bring outside thinking together with P&G’s own teams, is attributed with helping to double the P&G share price within five years.
    Where do you source your external collaboration on OSS innovation? Dirty or clean consultants? Contractors? Training of staff? Delegating to vendors?
  5. Customer insight. Innovations solve real customer problems. Staying close to customers and getting out of the building is how customer problems are discovered.
    As indicated under point 3 above, how do you ensure your innovators are also deeply connected with the customer psyche? Getting the team out of the ivory tower and onto the customer site is a key here

Bill Gates’ two rules of OSS technology (plus one)

The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”
Bill Gates
.

The pervading OSS business case paradigm is to seek cost-out by introducing automation that reduces head-count – Do more with less.

But it seems that’s the antithesis of how to look for cost reduction. It’s adding more complexity into a given system. Fundamentally, more complexity can not be the best approach to a cost-reduction strategy, right?

The cost-out paradigm should be built on reducing, not adding complexity – Let’s stop doing more that delivers less.

To add to Bill Gates’ two rules of technology, my third rule is that if you’re going to add technology (ie complexity), it should attempt to create growth opportunities, not seek to reduce costs.

Do you want dirty or clean OSS consulting?

The original management consultant was Frederick Taylor, who prided himself in having discovered the “one best way” which would be delivered by “first-class men”. These assumptions, made in 1911, are still dominant today. Best practice is today’s “one best way” and recruiters, HR and hiring managers spend months and months searching for today’s “first-class men”.

I call this type of consulting clean because the assumptions allow the consultant to avoid dirty work or negative feedback. The model is “proven” best practice. Thus, if the model fails, it is not the consultants’ fault – rather it’s that the organisation doesn’t have the “first-class employees” who can deliver the expected outcome. You just have to find those that can. Then everything will be hunky dory.

All responsibility and accountability are abdicated downwards to HR and hiring managers. A very clean solution for everybody but them.

It’s also clean because it can be presented in a shiny manner – lots of colourful slide-decks promising a beautiful outcome – rational, logical, predictable, ordered, manageable. Clean. In today’s world of digital work, the best practice model is a new platform transforming everything you do into a shiny, pixelated reality. Cleaner than ever.

The images drawn by clean consultants are compelling. The client gets a clearly defined vision of a future state backed up by evidence of its efficacy.

But it’s far too often a dud. Things are ignored. The complex differences between the client and the other companies the model has been used on. The differences in size, in market, in demographic, in industry. None matter – because the one best way model is just that – one best way. It will work everywhere for everyone. As long as they keep doing it right and can find the right people to do it.

The dirty consultant has a problem that the clean consultant doesn’t have. It’s a big problem. He doesn’t have an immediate answer for the complex problem vexing the client. He has no flashy best practice model he strongly believes in. No shiny slide deck that outlines a defined future state.

It’s a difficult sell.

What he does have is a research process. A way of finding out what is actually causing the organisational problems. Why and how the espoused culture is different from organisational reality. Why and how the supposed best practice solution is producing stressed out anxiety or cynical apathy.

This process is underpinned by a fundamentally different perspective on the world of work. Context is everything. There is no solution that can fit every company all of the time. But there’s always a solution for the problem. It just has to be discovered.

The dirty consultant enters an organisation ready and willing to uncover the dirty reasons for the organisation not performing. This involved two processes – (1) working out where the inefficiencies and absurdities are, and (2) finding out who knows how to solve them.”

The text above all comes from this LinkedIn post by Dr Richard Claydon. It’s also the longest quote I’ve used in nearly 2000 posts here on PAOSS. I’ve copied such a great swathe of it because it articulates a message that is important for OSS.

There is no “best practice.” There is no single way. There are no cookie-cutter consulting solutions. There are too many variants at play. Every OSS has massive local context. They all have a local context that is far bigger than any consultant can bring to bear.

They all need dirty consulting – assignments where the consultant doesn’t go into the job knowing the answers, acknowledging that they don’t have the same local, highly important context of those who are at gemba every day, at the coal-face every day.

There is no magic-square best-fit OSS solution for a given customer. There should be no domino-effect selection of OSS (ie the big-dog service provider in the region has chosen product X after a long product evaluation so therefore all the others should choose X too). There is no perfect, clean answer to all OSS problems.

Having said that, we should definitely seek elements of repeatability – using repeatable decision frameworks to guide the dirty consulting process, to find solutions that really do fit, to find where repeatable processes will actually make a difference for a given customer.

So if the local context is so important, why even use a consultant?

It’s a consultant’s role to be a connector – to connect people, ideas, technologies, concepts, organisations – to help a customer make valuable connections they would otherwise not be able to make.

These connections often come from the ability to combine the big-picture concepts of clean consulting with the contextual methods of dirty consulting. There’s a place for both, but it’s the dirty consulting that provides the all-important connection to gemba. If an OSS consultant doesn’t have a dirty-consulting background, an ability to frame from a knowledge of gemba, I wonder whether the big-picture concepts can ever be workable?

What are your experiences working with clean consultants (vs dirty consultants) in OSS?

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?

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.

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.

Dirty tickets done dirt cheap

The only way to get rid of Dirty Tickets of Work (DToW) is to get rid of Tickets of Work (ToW)

DToW is terminology used in Telstra to indicate that incorrect information has been entered into the ToW or where the field tech hasn’t been able to complete the ToW as originally designed / planned. I’m not sure if only Telstra uses this terminology. I haven’t heard it used at any other service provider I’ve worked at.

A DToW is an important metric because it effectively means the job has just got more expensive due to quality issues. lt probably means re- design effort,perhaps data audit / remediation and an extra truck roll… at a minimum.

I love the concept and am proposing to extend it to other workflows like Dirty Service Orders, Dirty Trouble Tickets, Dirty API calls, Dirty Processing (fall-outs), etc.

Because of the quality / cost implications, many very clever people have spent a lot of effort wrestling with solutions to this problem. Technical solutions, process solutions, data solutions, user interface solutions. To my knowledge, the problem remains to be solved, not just at Telstra, but at every other Telco that uses a different name for the same metric.

Now we could take the traditional (eg Six Sigma) approach, which is improving the quality of all the ingredients of a ToW. Or, we could take the lightbulb perspective posed in the opening quote and ask how we can build a solution that doesn’t require ToWs or SOs or TTs, etc.

That might just start a revolution for OSS.

How do we get to zero field work? Ubiquitous and over-provisioned connectivity, virtualised networks and CPE (vCPE) and colour-palette solution simplicity are surely a starting point. Blanket wireless networks and a greater use of feedback loop thinking probably help too.

How do we get to no service orders? I’m thinking consumption-based billing here, not your first reaction – thinking I’m espousing free use. But perhaps free use is an option as there are plenty of other revenue models available to clever service providers.

How do we get to no trouble tickets?
Self-healing, highly resilient, elastic networks (and OSS). Also, robotic event processing and automated pattern-recognition / decision-support / root-cause. The perspective here is a “no moving parts” electronics analogy – where Solid State Drives (SSD) tend to be more reliable than spinning drives.

Hat tip to Roger Gibson again for seeding a couple of ideas here.

You want more (OSS)?

Something dawned on me recently – People who want to save money don’t want to spend money.

That statement has more profound implications for the world of OSS than you might initially think. Let me explain.

If someone’s main priority is to save money, what are the chances that they’ll spend money to buy a product (let’s say a book) that shows them how to save? I imagine it takes REALLY compelling marketing to overcome the customer’s primary urge.

Is it the same in business? Does someone who’s been tasked with saving money for their company readily open the purse-strings in order to save? This is a little less clear-cut than for the individual case – the employee may’ve been assigned a budget to spend with expected savings attached to it.

What if I offered these alternatives:

  1. Spend money to save money; OR
  2. Spend money to make money

Which is more compelling?

The “cost out” sales model appears rampant in the OSS industry at the moment – if you buy this tool, your headcount / costs will go down by X. [Did someone just mention AI?]

That’s just capitulating to the mantra that OSS will only ever be cost centres (and allowing bean-counters to dictate that costs must be reduced).

We don’t strive hard enough to fasten our metrics to the positives (eg income generation)? If anything, our OSS tend to be associated with loss-related metrics (eg network outages, faults, SLA degradation, etc). That’s the O (Operations) in OSS talking. If we only frame our thinking to building solutions for Operations, we’re pushing the figurative ship uphill to make a sale*.

Here are some suggestions on how to positively re-frame your OSS messaging.

* the “sales model” that I’m talking about here refers to internal pitches / business-cases, not just sellers from third-parties like vendors/integrators.

The colour palette analogy of OSS

Let’s say you act for a service provider and the diagram below represents the number of variations you could offer to customers – the number that are technically supported by your solution.
13,824,000 Colours
That’s 13,824,000 colours.

By comparison, the following diagram contains just 20 colours:
20 Colours

If I asked you what colours are in the upper diagram, would you say red, orange, yellow, green, blue, etc? Is it roughly the same response as to the lower diagram?

If you’re the customer, and know you want an “orange*” product, will you be able to easily identify between the many thousands of different orange hues available in the upper diagram? Would you be disenfranchised if you were only offered the two orange hues in the lower diagram instead of thousands? Or might you even be relieved to have a much easier decision to make?

The analogy here to OSS is that just because our solutions can support millions of variants, doesn’t mean we should. If our OSS try to offer millions of variants, it means we have to design, then build, then test, then post-sale support millions of variants.

However, in reality, we can’t provide 100% coverage across so many variants – we aren’t able to sufficiently design, then build, then test, then post-sale support every one of the millions of variants. We end up overlooking some or accept risk on some or estimate a test spread that bypasses others. We’ve effectively opened the door to fall-outs.

And it’s fall-outs that tend to create larger customer dissatisfaction metrics than limited colour palettes.

Just curious – if you’ve delivered OSS into large service providers, have you ever seen evidence of palette analysis (ie variant reduction analysis) across domains (ie products, marketing, networks, digital, IT, field-work, etc)?

Alternatively, have you ever pushed back on decisions made upstream to say you’ll only support a smaller sub-set of options? This doesn’t seem to happen very often.

* When I’m talking about colours, I’m using the term figuratively, not necessarily the hues on a particular handset being sold through a service provider.

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?

Increasing the percentage of digital revenues

Digital revenues
The diagram above comes from research by AT Kearney and Delta Partners courtesy of an article by Mark Newman of TM Forum.

It provides an interesting perspective on CSPs‘ ability to “compete” with a broader, more digitally native group of service providers.

The golden age for CSPs was when they transported data from point A to point B (ie data and voice services) and people performed the value-add on top of those communications (ie business development, marketing, etc). DSPs have disrupted this model by now providing the value-added as digital services on top of base comms services (ie the over-the-top play).

The breadth of OTT services means that CSPs can’t possibly create the whole long tail of offerings. However, like DoCoMo, they can create partnerships and/or platforms that support the long tail of third-party offerings. It’s no coincidence that DoCoMo is the clear leader in the graph above as they have a long history of deriving revenues from third-party partnerships.

The question for an industry where 3.8% of revenues are from digital sources is not so much how to transition to an OTT model themselves, but how to provide digital delivery platforms that support third-party revenue streams and to do so more profitably (for all parts of the supply chain).

Omnichannel will remain disjointed until…

Omnichannel is intended to be a strategy that provides customers with a seamless, consistent experience across all of their contact channels – channels that include online/digital, IVR, contact centre, mobile app, retail store, B2B portal, etc.

The challenge of delivering consistency across these platforms is that there is little cross-over between the organisations that deliver these tools. Each is a fragmented market in its own right and the only time interaction happens (in my experience at least) is on an as-needed basis for a given project.

Two keys to delivering seamless customer experience are the ability to identify unique customers and the ability to track their journeys through different channels. The problem is that some of these channels aren’t designed to uniquely identify and if they can, aren’t consistent with other products in their linking-key strategies.

A related problem is that user journeys won’t follow a single step-by-step sequence through the channels. So rather than process flows, user journeys need to be tracked as state transitions through their various life-cycles.

OSS/BSS are ideally situated to manage linking keys across channels (if the channels can provide the data) as well as handling state-transition user journeys.

Omnichannel represents a significant opportunity, in part because there are two layers of buyers for such technology. The first is the service provider that wants to provide their customer with a truly omnichannel experience. The second is to provide omnichannel infrastructure to the service providers’ customers, customers that are in business and want to offer consistent omnichannel experiences for their end-customers.

Who is going to be the first to connect the various channel products / integrators together?

From pipeline to platform

Amazon established an architecture to leverage its assets for implementing a wide range of business models in a repeatable way for the retail industry. In most cases, Amazon is exposing product offerings it doesn’t actually own. It carries some inventory for third parties, but its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging payment and delivery of purchases. The company’s business model is to provide an ever-growing number of products through a broad, simple solution that’s fast, efficient and highly effective.
A similar level of speed and efficiency is possible when the same approach is applied to an operator’s architecture. Easy access, exposure of product information, a managed ecosystem of partners, a simple solution that hides background complexity – many of the same things that make it so easy to shop with Amazon – can transform the way our products are created, modified, assembled, offered, personalized and delivered. In other words, operators need architectures that support platform business models analogous to the Amazon architecture to onboard offers from many, connecting suppliers to consumers and monetizing the end solution with settlement of payments to those involved. Many platforms are possible because of technology, but they’re successful because of trust among ecosystem partners, curator and consumers
.”
From TM Forum’s “Digital Platform Reference Architecture Concepts and Principles” (IG1157 Release 17.0.0)

A recent post entitled, “I want a business outcome, not a deployment challenge,” discussed cloud deployment, hosted service offerings and trust – three important considerations to the Amazon-style platform play for future CSP business models.

Neither the architecture or the trust currently tends to exist to allow most telcos to follow a model where, “its main tasks now are vetting retail partners, ensuring product quality, giving partners access to the marketplace, and arranging [e-]payment and [e-]delivery of purchases.” Some telcos are already going down the path of complete transformation to services-driven platforms (ie SOA). This is as much for offering (web) services to internal silos as it is to external customers.

The real platform play will only happen when the “internal” services are also opened up to third-parties to provide, not just consume.

I want a business outcome, not a deployment challenge

We can look and take lessons on how services evolved in the cloud space. Our customers have expressed how they want to take these services and want a business outcome, not a deployment challenge.”
Shawn Hakl
.

Make no mistake, cloud OSS is still a deployment challenge (at this nascent stage at least), but in the context of OSS, Shawn Hakl’s quote asks the question, “who carries the burden of that deployment challenge?”

The big service providers have traditionally opted to take on the deployment challenge, almost wearing it as a badge of honour. I get it, because if done well, OSS can be a competitive differentiator.

The cloud model (ie hosted by a trusted partner) becomes attractive from the perspective of repeatability, from the efficiency of doing the same thing repeatedly at scale. Unfortunately this breaks down in a couple of ways for OSS (currently at least).

Firstly, the term “trusted partner” is a rare commodity between OSS providers and consumers for many different reasons (including trust from a security perspective, which is the most common pushback against using hosted OSS). Secondly, we haven’t unlocked the repeatability problem. Every organisation has different networks, different services, different processes, even different business models.

Cloud-hosted OSS represents a big opportunity into the future if we first focus on identification of the base ingredients of repeatability amongst all the disparity. Catalogs (eg service catalogs, product catalogs, virtual network device catalogs) are the closest we have so far. Intent abstraction models follow this theme too, as does platform-thinking / APIs. Where else?