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

Linus’s Law of OSS defects

Given enough eyeballs, all bugs are shallow.”
Eric S. Raymond
, whose quote is now known as Linus’ Law in honour of Linus Torvalds.

In other words, if you have enough people looking at the code, someone will surely categorise the problem and then the community will also figure out a way to solve it.

The fragmentation of the OSS industry means that OSS eyeballs are spread across thousands of code bases. Based on the inverse of Linus’ Law, there’s an implication that OSS bugs are deep. In fact, there are so many defects and/or enhancements waiting to be resolved across our industry that only the highest priority tickets tend to get any eyeballs at all.

The open-source revolution has ensured that the code of the most important applications (I use the word “important” figuratively) get lots of eyeballs. It’s one of the reasons that I believe the next OSS revolution will come about when an open-source OSS (an OSS OSS??) starts getting a critical mass of eyeballs. That OSS OSS just needs to be compelling enough to draw the eyeballs to it.

This is one of the pillars in the Call for Innovation that will be released here on PAOSS shortly.

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.

Think war!

Think war. Extreme times call for extreme measures. When your ideas are facing life or death, that’s an extreme time. Like a soldier in battle, you can’t even afford to suffer a single hit – so make sure you hit first. Pull out all stops. Remember, when your idea’s life is on the line, the last thing you want is a fair fight. Use every available weapon. If possible, grab the unfair advantage. And never forget what might well be your most effective weapon: the passion you feel for your idea.
Ken Segall
in his book, “Insanely Simple.”

I’m normally involved in OSS projects as a delivery or strategy resource rather than the instigator of the project. However, the quote above represents one of the key messages I suggest to customers during the early days of a project, especially on significant OSS transformation or implementation projects.

Plan to bring (and sustain) all the firepower you can to the change effort. Don’t just scramble for air support if you’re losing the change battle.

Expect there to be many obstacles to arise that are outside the level of influence the delivery teams can exert. What are your unfair advantages?

One unasked last question for OSS business cases

OSS business case evaluators routinely ask many questions that relate to key metrics like return on investment, capital to be outlaid, expected returns, return on investment, and more of the same circular financial questions. 🙂

They do also ask a few technical questions to decide risk – of doing the project or not doing the project. Timeframes and resources come into play, but again tend to land back on the same financial metric(s). Occasionally they’ll ask how the project will impact the precious NPS (Net Promoter Score), which we all know is a simple estimate to calculate (ie pluck out of thin air).

As you can tell, I’m being a little tongue-in-cheek here so far.

One incredibly important question that I’ve never heard asked, but is usually relatively easy to determine is, “Will this change make future upgrades harder?

The answer to this question will determine whether the project will have a snowballing effect on the TCO (total cost of ownership – yes, another financial metric that actually isn’t ROI) of the OSS. Any customisation to off-the-shelf tools will invariably add to the complexity of performing future upgrades. If customisations feed data to additional customisations, then there is a layer multiple to add to the snowball effect.

Throw in enough multi-layered (meshed?) customisations and otherwise routine upgrades start to become massive undertakings. If upgrades are taking months of planning, then your OSS clearly no longer facilitates the level of flexibility that is essential for modern service providers.

The burden of tech-debt insidiously finds its way into OSS stacks, so when evaluating change, don’t forget that one additional question, “Will this change make future upgrades harder?

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

If you can’t repeat it, you can’t improve it

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.”
From, “I want a business outcome, not a deployment challenge.”

OSS struggles when it comes to repeatability. Often within an organisation, but almost always when comparing between organisations. That’s why there’s so much fragmentation, which in turn is holding the industry back because there is so much duplicated effort and brain-power spread across all the multitude of vendors in the market.

I’ve worked on many OSS projects, but none have even closely resembled each other, even back in the days when I regularly helped the same vendors deliver to different clients. That works well for my desire to have constant mental stimulation, but doesn’t build a very efficient business model for the industry.

Closed loop architectures are the way of the future for OSS, but only if we can make our solutions repeatable, measurable / comparable and hence, refinable (ie improvable). If we can’t then we may as well forget about AI. After all, AI requires lots of comparable data.

I’ve worked with service providers that have prided themselves on building bespoke solutions for every customer. I’m all for making every customer feel unique and having their exact needs met, but this can still be accommodated through repeatable building blocks with custom tweaks around the edges. Then there are the providers that have so many variants that you might as well be designing / building / testing an OSS for completely bespoke solutions.

You could even look at it this way – If you can’t implement a repeatable process / solution, then measure it, then compare it and then refine it, then you can’t create a customer offering that is improving.

In desperate search of OSS flow

Flow, also known as the zone, is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does, and a resulting loss in one’s sense of space and time.”
Wikipedia.

It’s almost definitely no coincidence that a majority of the achievements I’m most proud of within the context of OSS have been originated outside business hours. I strongly believe it all comes down to flow. In a day that is punctuated by meeting after meeting, there is no flow, no ability to get into deep focus. In the world of transaction-based doing, there is rarely the opportunity to generate flow.

Every OSS project I’ve worked on has been in desperate need of innovation. That’s not a criticism, but a statement of the whole industry having so many areas in which improvement is possible. But on your current and/or past projects, how many have fostered an environment where deep focus was possible for you or your colleagues? Where have your greatest achievements been spawned from?

Jason Fried of Basecamp and 37signals fame is an advocate of building an environment where flow can happen and starts with manager and meeting minimisation. The best managers I’ve worked with have been great at facilitating flow for their teams and buffered them from the M&M noise.

How can we all build an OSS environment where the thinkers get more time to think… about improving every facet of ideating, creating, building and implementing?

How would Einstein or Darwin manage an OSS?

Here are a few questions I reflect on:
– Am I excited to be doing what I’m doing or am I in aimless motion?
– Are the trade-offs between work and my relationships well-balanced?
– How can I speed up the process from where I am to where I want to go?
– What big opportunities am I not pursuing that I potentially could?
– What’s a small thing that will produce a disproportionate impact?
– What could probably go wrong in the next 6 months of my life?

Zat Rana
on here on Business Insider.

The link above provides some insights into the way some of the world’s greatest innovators have tackled the challenges that lay before them. It espouses the benefits of Reflective Thinking versus the current mindset of Doing Thinking, as discussed here earlier.

If you were to follow Zat Rana’s suggestion of allocating two hours a week to reflective thinking, what are the seed questions you could ask? Would the list above work as a starting point? Perhaps something more specific to your situation?

Here are a few other possibilities:

  • Do I know what (my) OSS will look like in 5 years
  • Am I satisfied that (my) OSS is actually helping outside operations
  • What tangents could (my) OSS take to improve the world
  • Where does complexity stem from that impacts (my) OSS
  • Which areas can I pare back with negligible impact
  • What is the OSS moonshot that changes the landscape forever
  • What is my lead domino(es) (ie What’s a small thing that will produce a disproportionate impact?)
  • Have I thought about what might impact business continuity
  • How can I impact the bigger bodies (eg CSPs, vendors, standards bodies) around me

Functional silos can be dysfunctional

OSS are often delivered into large organisational structures, structures that are functionally siloed. For large OSS, even the OSS team can have multiple functional silos.

Where there are functional silos, there are activities within OSS that need to be delivered across silos. That’s where things can get a bit dysfunctional. Jurisdictions, ownership of responsibilities, agreements on approach, misalignments of performance indicators, downstream impacts and dare I say it, turf wars, can make it more difficult to deliver an OSS organisationally than technically… and OSS can be incredibly difficult to deliver from a technical perspective.

Organisational change management is often completely overlooked, or only brought to bear far too late in the delivery process. Often there are so much dysfunction between silos, even where each silo has the best of intentions, that a bigger change management accord needs to be invoked.

These include:

  • A burning platform – communicating the need for urgent, radical changes brought about by dire circumstances
  • A moon shot – focussing the attention of the entire organisation on incredibly ambitious challenge
  • Dictatorship of decision making rather than democracy

Alternatively, insert any other method to help ensure all members of the team, across all silos, have a clear understanding of the greater objectives the team is trying to meet. I’d love to hear of examples that you’ve invoked to get great team results on complex OSS projects (or any other project type for that matter).

The OSS Mechanical Turk

The Mechanical Turk… was a fake chess-playing machine constructed in the late 18th century. From 1770 until its destruction by fire in 1854 it was exhibited by various owners as an automaton, though it was eventually revealed to be an elaborate hoax.
The Turk was in fact a mechanical illusion that allowed a human chess master hiding inside to operate the machine. With a skilled operator, the Turk won most of the games played during its demonstrations around Europe and the Americas for nearly 84 years, playing and defeating many challengers including statesmen such as Napoleon Bonaparte and Benjamin Franklin
.”
Wikipedia.

This ingenious contraption can be mirrored in certain situations within the OSS industry.

I once heard of an OSS fulfilment solution that had consumed a couple of years of effort and millions of dollars before management decided to try an alternate path because there was still no end in sight. There was so much sunk cost that it was a difficult decision.

The problem statement was delivered to a new team brought in from outside the organisation.

They had it working within a single weekend!!

How?

They had focused on what the end customers needed and developed an efficient self-service portal (a front end) that created tickets. The tickets were then manually entered into the back-end systems. Any alerts from the back-end systems were fed back into the portal.

It did the job because transaction volumes were low enough to be processed manually. The first approach failed because integrations, workflows and exception-handling were enormously complex and they were laser-focused on perfect automation.

The Mechanical Turk approach to this OSS conundrum proved to be far more successful. It doesn’t work in all situations but it could be used more often than it is.

Is commission management the key for next-gen OSS?

Relationships with the things we ‘consume’ (rather than ‘own’) are increasing, and are being governed by ongoing supply arrangements between customers and vendors. What sits at the heart of these relationships, from a financial perspective, is billing. The entity that has the billing relationship with the customer essentially ‘owns’ the customer – they have the right to communicate with the customer regularly, and this can form the basis of a far deeper customer relationship.”
David Werdiger
in his article “The Own-Lease-Rent-Subscribe Continuum“.

The snippet above is just a small part of a very interesting article about asset utilisation and ownership structures. The continuum that David speaks of is increasingly presenting opportunities towards the subscribe / consume end and breaking down barriers to entry for those with entrepreneurial spirit.

This has implications for our OSS from a number of angles. OSS are typically expensive to buy or build or run, as are the networks that they manage. As a result, in years past the only opportunities arising from these assets were for their owners, the communications service providers (CSPs).

The subscribe end of the continuum allows CSPs to share the capital risk with customers, which has traditionally been done via the selling of comms services. But with comms services commoditising, innovative subscription models become a more attractive way of sharing the risk. These include virtual network operators, off-payroll sales agents, managed service offerings and the like.

We’ve spoken previously about how APIs allow third-parties to uplift and upsell services offered by CSPs. From a similar, but slightly different perspective, efficient / effective commission management functionality within your OSS / BSS effectively extends and incentivises the sales arm of any business (whether internal or external). You don’t need as many (any?) salespeople on the payroll, but you are still selling… if you incentivise the commission management process and associated earnings.

Whether additional selling and consumption is supported via human interfaces such as portal / UI or via machine interfaces such as API / microservices, it’s ultimately the billing that allows ownership of the customer. CSPs still have a significant strength from their billing base and clever design of our OSS / BSS can help to leverage that further in the consumption economy.

Could you replace a 150-person OSS team with just 1?

In 1998 Berkshire Hathaway acquired a reinsurance company called General Re. “The only significant staff change that followed the merger was the elimination of General Re’s investment unit. Some 150 people had been in charge of deciding where to invest the company’s funds; they were replaced with just one individual – Warren Buffett.
Robert G. Hagstrom
in, “The Warren Buffett Way.”

Following on from yesterday’s post about Warren Buffett’s prioritisation techniques and the recent series about the “frenzy of doing,” I was reminded of the staggering story at General Re described above.

Buffett was able to replace 150 people, and significantly outperform them, because they were performing (relatively) small value, high volume transactions and he was, well, the opposite.

OSS implementation and long-play investing are obviously very different in terms of resource requirements, but if we were to draw on this story, how would we replace whole OSS teams with just one person (or a small handful of people)?

Most CSPs have vast numbers of people who build and maintain their OSS. For most of those CSPs, the OSS isn’t the core business; in fact OSS is a cost of doing business; so does it really even make sense to have so many OSS people on staff?

How do you think this analogy stacks up:

  • Remove the legions of resources who are performing high volume, low value, transactional updates to the OSS
  • Replace them with one person who has a mindset of simplification, long-term outcomes and only betting big on the most strategic of changes
  • Outsource operations of the OSS to partners who have a strong track record of return on capital, just as Buffett avoids having to manage the companies he acquires by only investing if they are led by strong management teams who have a proven ability to deliver returns

One major chink in this strategy is that it is much easier to divest of bad stocks and wait until the right investment comes along, as opposed to making in-flight transformation of the tools a CSP needs to run all parts of its business (eg sales, engineering, field-work, etc).

If you were told you HAD to replace a team of 150 OSS implementers with one person, what would your strategy be?
Even if not being quite so drastic, could elements of your strategy work within your current OSS environment?

Alternatively, if you represent an OSS vendor that offers managed services, do you have the data to prove that you deliver strong returns on a customer’s invested capital?

Are we passing right past the importance of thinking?

Are we spawning a maelstrom, the butterfly effect from all of our doing?

Yesterday’s post pondered the question of whether we’re getting entangled in our frenzy for doing.

I’ve been privileged to have worked in a dozen countries or more and even more privileged to be an Australian. Less proud am I though of the way of working that seems to pervade our corporate icons. I’ve worked within the halls of the largest telcos, banks and enterprises in Australia as well as their counterparts internationally. In my experience, the Australian versions don’t tend to compare well when it comes to efficacy. Why?

For a start, every organisation in this category that I’ve worked with automatically supplies a case-load of meetings (I sadly admit to being partly to blame as a meeting initiator) upon joining. Wall-to-wall meetings allows lots of talking, lots of posturing, but little remainder for doing. And with all this focus on doing (see yesterday’s post, link above), the little time left has to be “seen to be doing.”

Is there any time left over for thinking? Or helping?

If yesterday’s post is indeed true, that we’re creating a spaghetti of complexity in our frenzy of doing, are we passing right past the importance of thinking?

When was the last time you spent half a day (or even half an hour) in a quiet corner of your workplace thinking about how to make a workable OSS solution simpler, more elegant, more intuitive? Or trying to resolve the organisation’s most challenging challenges?

Does your corporate culture allow this to happen? During work hours?? Even if it did, would the culture allow it to be ripped to pieces in intellectual arm wrestling or democratic reasoning thereafter?

People pay for two things. What about OSS?

People pay for two things:
Results: You do something they couldn’t do for themselves.
Convenience: You do something they don’t want to do for themselves, or you make something difficult easier to do
.”
Ramit Sethi
.

I really like the way Ramit has broken down an infinite number of variants down to just two key categories. Off the top of my head, these categories of payment (ie perceived value) seem to hold true for most industries, but we can unpack how they align with OSS.

In traditional OSS, most of the functionality / capability we provide falls into the convenience category.

In assurance, we tend to act as aggregators and coordinators, the single pane of glass of network health and remedial actions such as trouble-ticketing. But there’s no reason why we couldn’t manage those alarms from our EMS and tickets through spreadsheets. It’s just more convenient to use an OSS.

In fulfilment, we also pull all the pieces together, potentially from a number of different systems ranging from BSS, inventory, EMS and more. Again, it’s just more convenient to use an OSS.

But looking into the future, with the touchpoint explosion, the sheer scale of events hitting our assurance tools and the elastic nature of fulfilment on virtualised networks means that humans can’t manage by themselves. OSS and high-speed decision support tools will be essential to deliver results.

One other slight twist on this story though. All of the convenience we try to create using our OSS can actually result in less convenience. If we develop 1,000 tools that, in isolation, do something they [our customers] don’t want to do for themselves, it adds value. But if those tools in aggregate slow down our OSS significantly, increase support costs (lifetime costs) and make them inflexible to essential changes, then it’s actually reducing the convenience. On this point I have a motto – Just because we can, doesn’t mean we should (build extra convenience tools into our OSS).

Short-sighted / long-sighted OSS

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

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

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

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

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

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

Telcos still innovate… but more by proxy now

CSPs globally are trying to be innovative, and being heavily involved in tech since their earliest days, always perceive themselves to be innovative to their core (yes, bad pun).

There’s no doubt that there is a lot of innovation happening in large CSPs, but I wonder how much of it is really attributable to the CSP? Much of the change swirling through our organisations (or customer organisations) has been designed elsewhere. SDx (Software Defined Everything) was invented elsewhere (as were IP networks prior), IoT, CI / CD, Agile, Design Thinking, User Experience (UI/UX), AR/VR, AI/ML, open-source and all the other modern buzz-words.

Telcos do come from innovative roots when you look back at what Bell Labs, BT Research, Telstra Research Labs, or most other major telcos were doing globally in the early-mid 1900s. They defined not just telco but developed ground-breaking primary research into transistors, microwaves, satellites, lasers, communications theory, etc. Since this golden era, they’ve increasingly delegated the innovation process to suppliers. The same is true in our OSS. OSS were originally invented by telcos, but suppliers largely frame the story now.

In many recent blogs, including yesterday’s on network vs digital variants, we’ve discussed ways to invent new, more profitable revenue streams… revenue streams that will in turn fund exciting new OSS projects.

But I also wonder whether the reverse is true? If a telco was to discard the addiction to innovation and take on the utility mindset – providing ubiquitous, bullet-proof, regulated supply of long-haul and wide-spread access networks – would that be a better fit for these large, highly regulated enterprises?

They tend to have the natural moat in their networks – the cables and spectrum that require too much capital for others to easily replicate and compete, but whose physical assets have long useful lives. If they remove the constant need to constantly invest in change then their cost structures will arguably reduce more quickly than their revenues are dipping (yes, that means profitability increases). That gives the opportunity to focus on doing things simpler and better rather than doing things newer.

Have many CSPs long since lost the innovation war? Is their innovation primarily by proxy (through partners and suppliers), acquired rather than earned? Many factors work against them ever recapturing the innovative lead that they once held. So why not just admit it and let the innovators innovate, incubating partnerships rather than competing?
The answer is because that’s anathema to these organisations (and the people who drive them), which still perceive themselves to be innovators, perhaps akin to the aging Lothario with the comb-over and expanding waistline dreaming of his younger days.

Would the OSS market look much differently if CSPs were to all “age gracefully” with respect to innovation and take a different approach to the inventiveness that still surrounds them?