We all want to develop trusted OSS partnerships, so why does so much scepticism exist?

Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer.

I’m an independent consultant, so I have been lucky enough to represent many organisations on both sides of that equation. And in that position, I’ve been able to get a first-hand view of the perception of trust between OSS vendors / integrators (suppliers) and operators (customers). Let’s just say that in general, we’re working in an industry with more scepticism than trust.

So if trust is so important and such a desired status, where is it breaking down?

Whilst I’d like to assume that most people in our industry go into OSS projects with the very best of intentions, there are definitely some suppliers that try to trick and entrap their customers whilst acting in an untrustworthy way. For the rest of this post, I’m going to assume the best – assume that we all have great intentions. We then look at why the trust relationships might be breaking down and some of the ways we can do better.

Jon Gordon provides a great list of 11 ways to build trust. Check out his link for a more detailed view, but the 11 factors are as follows:

  1. Say what you are going to do and then do what you say!
  2. Communicate, communicate, communicate
  3. Trust is built one day, one interaction at a time, and yet it can be lost in a moment because of one poor decision
  4. Value long term relationships more than short term success
  5. Sell without selling out. Focus more on your core principles and customer loyalty than short term commissions and profits.
  6. Trust generates commitment; commitment fosters teamwork; and teamwork delivers results.
  7. Be honest!
  8. Become a coach. Coach your customers. Coach your team at work
  9. Show people you care about them
  10. Always do the right thing. We trust those who live, walk and work with integrity.
  11. When you don’t do the right thing, admit it. Be transparent, authentic and willing to share your mistakes and faults

They all sound quite obvious don’t they? Do you also notice that many of the 11 (eg communication, transparency, admitting failure, doing what you say, etc) can be really easy to say but harder to do flawlessly under the pressure of complex OSS delivery projects (and ongoing operations)?

I know I certainly can’t claim a perfect track record on all of  these items. Numbers 1 and 2 can be particularly difficult when under extreme delivery pressure, especially when things just aren’t going to plan technically and you’re focussing attention on regaining control of the situation. In those situations, communication and transparency are what the customer needs to maintain confidence, but the customer relationship takes time that also needs to be allocated to overcoming the technical challenges. It becomes a balancing act.

So, how do we position ourselves to make it easier to keep to these 11 best intentions? Simple. By making a concerted effort to reduce complexity… actually not so simple as it sounds, but rewarding if you can achieve it. The less complex your delivery projects (or operational models), the more repeatable and reliable a supplier’s OSS delivery becomes. The more reliable, the less friction and a reduced chance of fracturing relationships. Subsequently, the more chance of building and retaining trust.

Hat-tip to Robert Curran of Aria Networks for spawning a discussion about trust.

Bringing Eminem’s blank canvas to OSS

“When you start out in your career, you have a blank canvas, so you can paint anywhere that you want because the shit ain’t been painted on yet. And then your second album comes out, and you paint a little more and you paint a little more. By the time you get to your seventh and eighth album you’ve already painted all over it. There’s nowhere else to paint.”
Eminem. (on Rick Rubin and Malcolm Gladwell’s Broken Record podcast)

To each their own. Personally, Eminem’s music has never done it for me, whether his first or eighth album, but the quote above did strike a chord (awful pun).

It takes many, many hours to paint in the detail of an OSS painting. By the time a product has been going for a few years, there’s not much room left on the canvas and the detail of the existing parts of the work is so nuanced that it’s hard to contemplate painting over.

But this doesn’t consider that over the years, OSS have been painted on many different canvases. First there were mainframes, then client-server, relational databases, XaaS, virtualisation (of servers and networks), and a whole continuum in between… not to mention the future possibilities of blockchain, AI, IoT, etc. And that’s not even considering the changes in programming languages along the way. In fact, new canvases are now presenting themselves at a rate that’s hard to keep up with.

The good thing about this is that we have the chance to start over with a blank canvas each time, to create something uniquely suited to that canvas. However, we invariably attempt to bring as much of the old thinking across as possible, immediately leaving little space left to paint something new. Constraints that existed on the old canvas don’t always apply to each new canvas, but we still have a habit of bringing them across anyway.

We don’t always ask enough questions like:

  • Does this existing process still suit the new canvas
  • Can we skip steps
  • Can we obsolete any of the old / unused functionality
  • Are old and new architectures (at all levels) easily transmutable
  • Does the user interface need to be ported or replaced
  • Do we even need a user interface (assuming the rise of machine-to-machine with IoT, etc)
  • Does the old data model have any relevance to the new canvas
  • Do the assurance rules of fixed-network services still apply to virtualised networks
  • Do the fulfillment rules of fixed-network services still apply to virtualised networks
  • Are there too many devices to individually manage or can they be managed as a cohort
  • Does the new model give us access to new data and/or techniques that will allow us to make decisions (or derive insights) differently
  • Does the old billing or revenue model still apply to the new platform
  • Can we increase modularity and abstraction between modules

“The real reason “blockchain” or “AI” may actually change businesses now or in the future, isn’t that the technology can do remarkable things that can’t be done today, it’s that it provides a reason for companies to look at new ways of working, new systems and finally get excited about what can be done when you build around technology.”
Tom Goodwin

Torturous OSS version upgrades

Have you ever worked on an OSS where a COTS (Commercial Off-The-Shelf) solution has been so heavily customised that implementing the product’s next version upgrade has become a massive challenge? The solution has become so entangled that if the product was upgraded, it would break the customisations and/or integrations that are dependent upon that product.

This trickle-down effect is the perfect example of The Chess-board Analogy or The Tech-debt Wreck at work. Unfortunately, it is far too common, particularly in large, complex OSS environments.

The OSS then either has to:

  • skip the upgrade or
  • take a significant cost/effort hit and perform an upgrade that might otherwise be quite simple.

If the operator decides to take the “skip” path for a few upgrades in a row, then it gets further from the vendor’s baseline and potentially misses out on significant patches, functionality or security hardening. Then, when finally making the decision to upgrade, a much more complex project ensues.

It’s just one more reason why a “simple” customisation often has a much greater life-cycle cost than was initially envisaged.

How to reduce the impact?

  1. We’ve recently spoken about using RPA tools for pseudo-integrations, allowing the operator to leave the COTS product un-changed, but using RPA to shift data between applications
  2. Attempt to achieve business outcomes via data / process / config changes to the COTS product rather than customisations
  3. Enforce a policy of integration as a last resort as a means of minimising the chess-board implications (ie attempting to solve problems via processes, in data, etc before considering any integration or customisation)
  4. Enforcing modularity in the end-to-end architecture via carefully designed control points, microservices, etc

There are probably many other methods that I’m forgetting about whilst writing the article. I’d love to hear the approach/es you use to minimise the impact of COTS version upgrades. Similarly, have you heard of any clever vendor-led initiatives that are designed to minimise upgrade costs and/or simplify the upgrade path?

The exposure effect can work for or against OSS projects

The exposure effect (no, not the one circulating through Hollywood) has a few interesting implications for OSS.

“The mere-exposure effect is a psychological phenomenon by which people tend to develop a preference for things merely because they are familiar with them.”

In effect, it’s the repetition that drills familiarity, comfort, but also bias, into our sub-conscious. Repetition doesn’t make a piece of information true, but it can make us believe it’s true.

Many OSS experts are exposed to particular vendors/products for a number of years during their careers, and in doing so, the exposure effect can build. It can have a subtle bias on vendor selection, whereby the evaluators choose the solution/s they know ahead of the best-fit solution for their organisation. Perhaps having independent vendor selection facilitators who are familiar with many products can help to reduce this bias?

The exposure effect can also appear through sales and marketing efforts. By regularly contacting customers and repetitively promoting their wares, the customer builds a familiarity with the product. In theory it works for OSS products as it does with beer commercials. This can work for or against, depending on the situation.

In the case for, it can help to build a guiding coalition to get a complex, internal OSS project approved and supported through the challenging times that await every OSS project. I’d even go so far as to say, “you should use it to help build a guiding coalition,” rather than, “you can use it to help build a guiding coalition.” Never underestimate the importance of organisational change management on an OSS project.

In the case against, it can again develop a bias towards vendors / products that aren’t best-fit for the organisation. Similarly, if a “best-fit” product doesn’t take the time to develop repetition, they may never even get considered in a selection process, as highlighted in the diagram below.

7 touches of sales
Courtesy of the OnlineMarketingInstitute.

When low OSS performance is actually high performance

It’s not unusual for something to be positioned as the high performance alternative. The car that can go 0 to 60 in three seconds, the corkscrew that’s five times faster, the punch press that’s incredibly efficient…
The thing is, though, that the high performance vs. low performance debate misses something. High at what?
That corkscrew that’s optimized for speed is more expensive, more difficult to operate and requires more maintenance.
That car that goes so fast is also more difficult to drive, harder to park and generally a pain in the neck to live with.
You may find that a low-performance alternative is exactly what you need to actually get your work done. Which is the highest performance you can hope for
Seth Godin
in this article, What sort of performance?

Whether selecting a vendor / product, designing requirements or building an OSS solution, we can sometimes lose track of what level of performance is actually required to get the work done can’t we?

How many times have you seen a requirement sheet that specifies a Ferrari, but you know the customer lives in a location with potholed and cobblestoned roads? Is it right to spec them – sell them – build them – charge them for a Ferrari?

I have to admit to being guilty of this one too. I have gotten carried away in what the OSS can do, nearer the higher performance end of the spectrum, rather than taking the more pragmatic view of what the customer really needs.

Automations, custom reports and integrations are the perfect OSS examples of low performance actually being high performance. We spend a truckload of money on these types of features to avoid manual tasks (curse having to do those manual tasks)… when a simple cost-benefit analysis would reveal that it makes a lot more sense to stay manual in many cases.

The double-edged sword of OSS/BSS integrations

…good argument for a merged OSS/BSS, wouldn’t you say?
John Malecki

The question above was posed in relation to Friday’s post about the currency and relevance of OSS compared with research reports, analyses and strategic plans as well as how to extend OSS longevity.

This is a brilliant, multi-faceted question from John. My belief is that it is a double-edged sword.

Out of my experiences with many OSS, one product stands out above all the others I’ve worked with. It’s an integrated suite of Fault Management, Performance Management, Customer Management, Product / Service Management, Configuration / orchestration / auto-provisioning, Outside Plant Management / GIS, Traffic Engineering, Trouble Ticketing, Ticket of Work Management, and much more, all tied together with the most elegant inventory data model I’ve seen.

Being a single vendor solution built on a relational database, the cross-pollination (enrichment) of data between all these different modules made it the most powerful insight engine I’ve worked with. With some SQL skills and an understanding of the data model, you could ask it complex cross-domain questions quite easily because all the data was stored in a single database. That edge of the sword made a powerful argument for a merged OSS/BSS.

Unfortunately, the level of cross-referencing that made it so powerful also made it really challenging to build an initial data set to facilitate all modules being inter-operable. By contrast, an independent inventory management solution could just pull data out of each NMS / EMS under management, massage the data for ingestion and then you’d have an operational system. The abovementioned solution also worked this way for inventory, but to get the other modules cross-referenced with the inventory required engineering rules, hand-stitched spreadsheets, rules of thumb, etc. Maintaining and upgrading also became challenges after the initial data had been created. In many cases, the clients didn’t have all of the data that was needed, so a data creation exercise needed to be undertaken.

If I had the choice, I would’ve done more of the cross-referencing at data level (eg via queries / reports) rather than entwining the modules together so tightly at application level… except in the most compelling cases. It’s an example of the chess-board analogy.

If given the option between merged (tightly coupled) and loosely coupled, which would you choose? Do you have any insights or experiences to share on how you’ve struck the best balance?

OSS that keep the cuckoos out of the nest

The cuckoo bird is infamous for laying its eggs in other birds’ nests. The young cuckoos grow much faster than the rightful occupants, forcing the other chicks out – if they haven’t already physically knocked the other eggs overboard. (See “brood parasitism”, here).
Analogies exist quite widely in technology – a faster-growing “tenant” sometimes pushes out the offspring of the host. Arguably Microsoft’s original Windows OS was an early “cuckoo platform” on top of IBM’s PC, removing much of IBM’s opportunity for selling additional software. 

In many ways, Internet access itself has outgrown its own host: telco-provided connectivity. Originally, fixed broadband (and the first iterations of 3G mobile broadband) were supposed to support a wide variety of telco-supplied services. Various “service delivery platforms” were conceived, including IMS, yet apart from ordinary operator telephony/VoIP and some IPTV, very little emerged as saleable services.

Instead, Internet access – which started using dial-up modems and normal phone lines before ADSL and cable and 3G/4G were deployed – has been the interloping bird which has thrived in the broadband nest instead of telcos’ own services. It’s interesting to go back and look at the 2000-era projections for walled-garden, non-Internet services.

The problem is that everyone wants to be a platform player. And when you’re building and scaling a new potential platform, it’s really hard to turn down a large and influential “anchor tenant”, even if you worry it might ultimately turn out to be a Trojan Horse (apologies for the mixed metaphor). You need the scale, the validation, and the draw for other developers and partners.

This is why the most successful platforms are always the one which have one of their own products as the key user. It reduces the cannibalisation risk. Office is the anchor tenant on Windows. iTunes, iMessage and the camera app are anchors on iOS. Amazon.com is the anchor tenant for AWS.

Unfortunately, the telecoms industry looks like it will have to learn a(nother) tough lesson or two about “cuckoo platforms”.”
Dean Bubley from Disruptive Wireless.

The link above provides some really interesting perspectives from Dean in relation to OTT business models and the challenges that telcos have faced in trying to build valuable platforms to sit on top of their capital-intensive network platforms. I really recommend having a read of the full article by clicking on the link.

I loosely equate this to the OSI stack where telcos own the L1 to L2 (L3 in many cases) platform, but haven’t been so successful at creating dominant platforms in the layers above that. That’s also why there are two distinct business model categories – the traditional CSP (Communications Service Provider) that services L1 to 2/3 and acts like a utility or REIT or the more competitive DSP (Digital Service Provider). One Telco group can have both by leveraging their trillion dollar treasure chest.

Traditional OSS service the CSP (as well as some of the aspects of the DSP model) but we probably need to create some innovative new concepts if we’re going to assist our telco customers to build DSP platforms and / or to keep the cuckoos out of the nest.

Can you re-skill fast enough to justify microservices?

There’s some things that I’ve challenged my team to do. We have to be faster than the web scale players and that sounds audacious. I tell them you can’t you can’t go to the bus station and catch a bus that’s already left the station by getting on a bus. We have to be faster than the people that we want to get to. And that sounds like an insane goal but that’s one of the goals we have. We have to speed up to catch the web scale players.”
John Donovan
, AT&T at this link.

Last week saw a series of articles appear here on the PAOSS blog around the accumulation of tech-debt and how microservices / Agile had the potential to accelerate that accumulation.

The part that I find most interesting about this new approach to telco (or more to the point, to the Digital Service Provider (DSP) model) is that it speaks of a shift to being software companies like the OTT players. Most telcos are definitely “digital” companies, but very few could be called “software” companies.

All telcos have developers on their payroll but how many would have software roles filling more than 5% of their workforce? How many would list their developer pools amongst a handful of core strengths? I’d hazard a guess that the roots of most telcos’ core strengths would’ve been formed decades ago.

Software-centric networks are on the rise. Rapid implementation models like DevOps and Agile are on the rise. API / Microservice interfaces to network domains (irrespective of being VNF, PNF, etc) are on the rise. Software, software, software.

In response, telcos are talking software. Talking, but how many are doing?

Organic transition of the workforce (ie boomers out, millennials in) isn’t going to refresh fast enough. Are telcos actively re-inventing their resource pool? Are they re-skilling on a grand scale, often tens of thousands of people, to cater for a future mode of operation where software is a core capability like it is at the OTT players? Re-skilling at a speed that’s faster than the web-scale bus?

If they can’t, or don’t, then perhaps software is not really the focus. Software isn’t their differentiator… they do have many other strengths to work with after all.

If so then OSS, microservices, SDN / NFV, DevOps, etc are key operational requirements without being core differentiators. So therefore should they all be outsourced to trusted partners / vendors / integrators (rather than the current insourcing trend), thus delegating the responsibility for curating the tech-debt we spoke about last week?

I’m biased. I see OSS as a core differentiator (if done well), but few agree with me.

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.

10 ways to #GetOutOfTheBuilding

Eric Ries’ “The Lean Startup,” has a short chapter entitled, “Get out of the Building.” It basically describes getting away from your screen – away from reading market research, white papers, your business plan, your code, etc – and out into customer-land. Out of your comfort zone and into a world of primary research that extends beyond talking to your uncle (see video below for that reference!).

This concept applies equally well to OSS product developers as it does to start-up entrepreneurs. In fact the concept is so important that the chapter name has inspired it’s own hashtag (#GetOutOfTheBuilding).

This YouTube video provides 10 tips for getting out of the building (I’ve started the clip at Tendai Charasika’s list of 10 ways but you may want to scroll back a bit for his more detailed descriptions).

But there’s one thing that’s even better than getting out of the building and asking questions of customers. After all, customers don’t always tell the complete truth (even when they have good intentions). No, the better research is to observe what they do, not what they say. #ObserveWhatTheyDoNotWhatTheySay

This could be by being out of the building and observing customer behaviour… or it could be through looking at customer usage statistics generated by your OSS. That data might just show what a customer is doing… or not doing (eg customers might do small volume transactions through the OSS user interface, but have a hack for bulk transactions because the UI isn’t efficient at scale).

Not sure if it’s indicative of the industry as a whole, but my experience working for / with vendors is that they don’t heavily subscribe to either of these hashtags when designing and refining their products.

Does your OSS collect primary data to #ObserveWhatTheyDoNotWhatTheySay? If it does, do you ever make use of it? Or do you prefer to talk with your uncle (does he know much about OSS BTW)?

Watching customers under an omnichannel strobe light

Omnichannel will remain full of holes until we figure out a way of tracking user journeys rather than trying to prescribe (design, document, maintain) process flows.

As a customer jumps between the various channels, they move between systems. In doing so, we tend to lose the ability to watch customer’s journey as a single continuous flow. It’s like trying to watch customer behaviour under a strobe light… except that the light only strobes on for a few seconds every minute.

Theoretically, omnichannel is a great concept for customers because it allows them to step through any channel at any time to suit their unique behavioural preferences. In practice, it can be a challenging experience for customers because of a lack of consistency and flow between channels.

It’s a massive challenge for providers to deliver consistency and flow because the disparate channels have vastly different user interfaces and experiences. IVR, digital, retail, etc all come from completely different design roots.

Vendors are selling the dream of cost reductions through improved efficiency within their channels. Unfortunately this is the wrong place for a service provider to look. It’s the easier place to look, but the wrong place nonetheless. Processes already tend to be relatively efficient within a channel and data tends to be tracked well within a channel.

The much harder, but better place to seek benefits is through the cross-channel user journeys, the hand-offs between channels. That’s where the real competitive advantage opportunities lie.

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?

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

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

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

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

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

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

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

OSS User Experiences at 3.5 inches

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

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

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

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

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

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

OSS death in The Matrix

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

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

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

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

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

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

My take on all of this is:

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

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

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

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

An uncommon list of OSS books

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

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

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

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

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

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?

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

The mafia… Pressure? What pressure?

OSS delivery teams can be quite tense environments to work within can’t they? Deadlines, urgency, being in the customer’s line of sight and did I mention deadlines? [As an aside, I’m not sure which type of deadline is more stressful, the ongoing drain of fortnightly releases under Agile, or the chaos of a big-bang release that is preceded by lengthier periods of relative calm.]

When it comes to dealing with stress, I see two ends of a continuum:

  • The teflon end – get it off me, get it off me – the people who, when under stress, push stress onto everyone else and make the whole team more stressed
  • The sponge end – the people who are able to absorb the pressure around them and exude a calm that reduces stress contagion

I can completely understand those who fall at the teflon end, but I can’t admire them or aspire to work with them. I’m sure most would feel the same way. They let urgency overwhelm logic.

This reminds me of a project where the mafia were tightly entwined into a customer’s project team and they were constantly wrangling scope, approvals and payments to ensure “the organisation” profited. They were particularly “active” around delivery time.

A biggest of big-bang deliveries required me to stand in front of a large customer contingent for three days straight to demonstrate functionality and get grilled about processes, tools and data sets. At the end of the third day, we’d scheduled the demonstration of some brand new functionality.

It was a module that had been sold to the customer before even being conceptually architected let alone built. [You know the story – every requirement on an RFP must be responded to with a “Complies” even if it doesn’t]. My client (the vendor) was almost ready to back away from this many-million dollar contract due to the complexity and time estimated to build the entirely new module from scratch. I stepped in and proposed a solution that stitched together four existing tools, some glue and only a few weeks of effort… but we’d never even had it working in the lab before entering into the demo.

At first pass, the demo failed. Being at the end of the three-day demo (and the hectic weeks leading up to it), my brain was fried. The customer agreed to take a short break while we investigated what went wrong. We were struggling to find a resolution, so I was proposing to delay demonstration of the new tool until the following day.

Luckily for me, the most junior member of our team sat in the background plugging away, trialling different fixes. He tapped me on the shoulder and told me that he thought he’d resolved the problem.

We regathered the customer’s team and presented the new module. We waited for the customer’s lead to push an unknown configuration into the network and waited for him to check whether our new tool had responded correctly. It did and the customer was ecstatic.

We’d been saved by a very clever young man with an ability to absorb pressure like a sponge. I couldn’t thank him enough.