What in OSS does nobody agree with you on?

Peter Thiel (co-founder of PayPal, Founders Fund and many other snippets in an impressive highlights reel) asks prospective entrepreneurs to tell him something they believe is true that nobody agrees with them about.

Today I’m asking you the same question and would love to hear your answers:

What do you believe to be true in OSS that nobody else seems to agree with you on?

The exciting thing about OSS is that it has so much potential, so many opportunities to do things better. And that means so many opportunities to do things differently, to come at things from a different angle to everyone else.

After all, success comes from doing things differently.

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?

The biggest moonshot facing OSS today

Moonshot thinking is about making something 10x better. This forces you to throw away the existing assumptions and create something bold and new. Reality will eat into your 10x. At the end of the process it may only be 2x, but that’s still amazing.”
Brian Jansen
‘s Book Summary: “Bold: How To Go Big, Create Wealth, and Impact the World,” by Peter Diamandis & Steven Kotler.

I think the biggest moonshot facing OSS today is the design and implementation of an architecture that allows other moonshots to happen.

Take a moment to reflect on that…

As of today, our OSS tend to be complex, entangled beasts, governed by the chess-board analogy. The entanglement is so profound that we tend to only do small, incremental charges. Moving a single piece on the chess-board takes soooo much planning to avoid negative consequences. lt’s the reason that some of our high-profile OSS probably still contain chunks of code that were written in the 1990’s or 2000’s.

In the world of OSS, the 10x moonshot comes with a risk of delivering -5x not just the 2x mentioned in the quote above.

Having said that, I’m all for a good moonshot project. It might take just one disentanglement moonshot to allow 1000 subsequent moonshots to fire! A disentanglement moonshot like the small-grid approach described here.

Avoiding the OSS honey trap

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

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

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

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

Are we measuring OSS at the wrong end?

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

Just a few examples:

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

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

Building an OSS piggybank with scoreboard pressure

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

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

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

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

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

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

Been done before, been done before

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

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

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

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

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

OSS User Experiences at 3.5 inches

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

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

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

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

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

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

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 alchemy of OSS

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

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

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

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

Simple question – Do you have any in your organisation?

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

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.

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.

Call for Innovation by Swisscom, Telia and Proximus

Software Defined Networking (SDN) and Network Function Virtualization (NFV) are about to transform and disrupt the network operator industry.

That’s why Swisscom, Telia Company and Proximus, three leading telco providers from across Europe, are jointly issuing this unique Call for Innovation and invite startups and innovators developing “Next Generation Virtual Telco Functions & Services (SDN / NFV 2.0)” to apply until 23 October 2016.

The best startups will be able to pitch their solution in front of an expert jury and have the chance to be selected for a PoC project and future collaboration with all three telcos..
What we are looking for

The topics considered for this call are related to SDN/NFV development within the telecommunication industry. The baseline infrastructure for SDN/NFV is available and is largely based on the de-facto standards and open source-based systems of OpenStack/OPNVF/CloudFoundry. The next steps and next wave of innovations should be using that infrastructure for new networking functions, cloud-native implementation of existing network functions, and new Telco services we could offer in the market.”

From http://call-for-innovation.com/sdn-nfv

Let me start out with an apology. This is old news. The Swisscom / Telia Company / Proximus Call for Innovation closed nearly a year ago. However, I’m bringing it to your attention for what it means to the telco industry. It’s acknowledging that traditional suppliers to telcos are not always servicing the need for innovative approaches to the problems the telcos are facing. It’s targeting the long tail of innovation.

Whilst this is specifically seeking SDN/NFV innovations, what does a Call for Innovation look like for OSS? Keep an eye out here on PAOSS, as I’ll be publishing an OSS Call for Innovation shortly.

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.

Getting past the first layer on the OSS onion

When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions.”
Steve Jobs
.

The quote above pretty well describes my experience with OSS. The first solutions we come up with for a given problem are generally very complex…. and that’s where we stop because there are so many other problems to move on to next.

Does that reflect your experiences too?

Do we ever get the chance to take a deep breath because we have all our roadmap items completed, and then therefore have time to peel more layers off old problems?

In my experience this just doesn’t happen. So that just leaves us with solutions that are complex… to the detriment of OSS as a whole.

So the question for you today is how to give the time and space to be able to peel more layers off our OSS onions?

My initial thought is that we should stop adding so many things into the roadmap – to take the 80/20 approach into our roadmap prioritisation – leaving more time to refine the really important stuff. I’d love to hear your thoughts though.