I have this sense that the other OSS, open source software, holds the key to the next wave of OSS (Operational Support Systems) innovation.
Why? Well, as yesterday’s post indicated (through Nic Brisbourne), “it’s hard to do big things in a small way.” I’d like to put a slight twist on that concept by saying, “it’s hard to do big things in a fragmented way.” [OSS is short for fragmented after all]
The skilled resources in OSS are so widely spread across many organisations (doing a lot of duplicated work) that we can’t reach a critical mass of innovation. Open source projects like ONAP represent a possible path to critical mass through sharing and augmentating code. They provide the foundation upon which bigger things can be built. If we don’t uplift the foundations across the whole industry quickly, we risk losing relevance (just ask our customers for their gripes list!).
But you may ask how organisations can protect their trade secrets whilst embracing open source innovation. Derek Sivers provides a fascinating story and line of thinking in “Why my code and ideas are public.” I really recommend having a read about Valerie.
“…it’s hard to do big things in a small way, so I suspect incumbents have more of an advantage than they do in most industries.”
The quote above came from a piece about the rise of ConstructTech (ie building houses via means such as 3D printing). However, it is equally true of the OSS industry.
Our OSS tend to be behemoths, or at least the ones I work on seem to be. They’ve been developed over many years and have millions of sunk person-hours invested in them. And they’ve been customised to each client’s business like vines wrapped around a pillar. This gives enormous incumbency power and acts as a barrier to smaller innovators having a big impact in the world of OSS.
Want an example of it being hard to do big things in a small way? Ever heard of ONAP? AT&T is a massive telco with revenues to match, committed to a more software-centric future, and has developed millions of lines of code yet it still needs the broader industry to help flesh out its vision for ONAP.
There are occasionally niche products developed but it’s definitely hard to do big things in a small way. The small grid analogy proposed earlier gives more room for the long tail of innovation, allowing smaller innovators to impact the larger ecosystem.
Write a comment below if you’d like to point out an outlier to this trend.
OSS is an industry that’s undergoing constant, and massive change. But it still hasn’t been disrupted in the modern sense of that term. It’s still waiting to have its Uber/AirBnB-moment, where the old way becomes almost obsoleted by the introduction of a new way. OSS is not just waiting, but primed for disruption.
It’s a massive industry in terms of revenues, but it’s still far from delivering everything that customers want/need. It’s potentially even holding back the large-scale service provider industry from being even more influential / efficient in the current digital communications world. Our recent OSS Call for Innovation spelled out the challenges and opportunities in detail.
Today we’ll talk about the two types of disruptive technologists – one that assists change and one that hinders.
The first disruptive technologist is a rare beast – they’re the innovators who create solutions that are distinctly different from anything else in the market, changing the market (for the better) in the process. As discussed in this recent post, most of the significant changes occurring to OSS have been extrinsic (from adjacent industries like IT or networking rather than OSS). We need more of these.
The second disruptive technologist is all too common – they’re the technologists whose actions disrupt an OSS implementation. They’re usually well-intended, but can get in the way of innovation in two main ways:
1) By not looking beyond incremental change to existing solutions
2) Halting momentum by creating and resolving a million “what if?” scenarios
Most of us probably fall into the second category more often than the first. We need to reverse that trend individually and collectively though don’t we?
Would you like to nominate someone who stands out as being the first type of disruptive technologist and why?
Let’s admit it; we’ve all worked on an OSS project that has gone into a period of extended stagnation because of a fear of the unknown. I call them “What if?” scenarios. They’re the scenarios where someone asks, “What if x happens?” and then the team gets side-tracked whilst finding an answer / resolution. The problem with “What if?” scenarios is that many of them will never happen, or will happen on such rare occasions that the impact will be negligible. They’re the opposite end of the Pareto Principle – they’re the 20% that take up the 80% of effort / budget / time. They need to be minimised and/or mitigated.
In some cases, the “what if?” questions comes from a lack of understanding about the situation, the product suite and / or the future solution. That’s completely understandable because we can never predict all of the eventualities of an OSS project at the outset. That’s the OctopOSS at work – you think you have all of the tentacles under control, but another one always comes and whacks you on the back of the head.
The best way to reduce the “what if?” questions from getting out of control is to give stakeholders a sandpit / MVP / rapid-prototype / PoC environment to interact with.
The benefit of the prototype environment is that it delivers something tangible, something that stakeholders far and wide can interact with and test assumptions, usefulness, usability, boundary cases, scalability, etc. Stakeholders get to understand the context of the product and get a better feeling for what the end solution is going to look like. That way, many of the speculative “what ifs?” are bypassed and you start getting into the more productive dialogue earlier. The alternative, the creation of a document or discussion, can devolve into an almost endless set of “what-if” scenarios and opinions, especially when there are large groups of (sometimes militant) stakeholders.
The more dangerous “what if?” questions come from the experts. They’re the ones who demonstrate their intellectual prowess by finding scenario after scenario that nobody else is considering. I have huge admiration for those who can uncover potential edge cases, race conditions, loopholes in code, etc. The challenge is that they can be extremely hard to document, test for and circumvent. They’re also often very difficult to quantify or prove a likelihood of occurrence, thus consuming significant resources.
Rather than divert resources to resolving all these “what if?” questions one-by-one, I try to seek a higher-order “safety-net” solution. This might be in the form of exception handling, try-catch blocks, fall-out analysis reports, etc. Or, it might mean assigning a watching brief on the problem and handling it only if it arises in future.
Experts know a lot…. obviously.
They have lots of answers… obviously.
There are lots of OSS experts. Combined, they know A LOT!!
Powerful indeed, but not sure if that’s what we need right now. I feel like we’re in a bit of an OSS innovation funk. The biggest improvements in OSS are coming from outside OSS – extrinsic improvement.
Where’s the intrinsic improvement coming from? Do we need someone to shake it up (do we need everyone to shake it up?)? Do we need new thinking to identify and create new patterns? To re-organise and revolutionise what the experts already know. Or do we need to ask the massive questions that re-frame the situation for the experts?
So, considering this funky moment in time, is the real expert the one who knows lots of answers… or the person who can catalyse change by asking the best mind-shift questions?
May I ask you – As an OSS expert, are you prouder of your answers…. or your questions?
To tackle that from a different angle – What is your answer : question ratio? Are you such an important expert that your day is so full of giving brilliant answers that you have no time left to ruminate and develop brilliant questions?
If so, can we take some of your answer time back and re-prioritise it please?
In the words of Socrates, “I cannot teach anybody anything, I can only make them think.“
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.” Wikipedia
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.
Check out the video below, which gives an example of the 10 minute / 1 minute / 10 second challenge (you can check out more of them here).
When given 10 minutes to sketch Spiderman, the result is far richer than when the artist is given only 10 seconds… well obviously!!
But let me pose a question. If Sketch B was compiled from 60 sequential 10s updates (ie Sketch B would also take 10 mins total sketching time) do you think the final sketch would look as impressive as the 1 x 10 min sketch (Sketch A)? The total sketching time is the same, but will the results be similar?
From the 10s sketch above, you can see that the composition is not as precise. Subsequent updates would have to work around the initial structural flaws.
Do you wonder whether this is somewhat analogous to creating OSS using continuous development frameworks like Agile or DevOps? By having tightly compressed (eg weekly) release cycles, are we compromising the structure from the start?
I’m a big believer in rapid prototyping with subsequent incremental improvements instead of the old big-bang OSS delivery model. I’m also impressed with automated dev / test / release frameworks. However, I’m concerned that rapid release cycles can enforce unnecessary deadlines and introduce structural compromises that are difficult to fix mid-flight.
“With the increasing pace of change, the moment a research report, competitive analysis, or strategic plan is delivered to a client, its currency and relevance rapidly diminishes as new trends, issues, and unforeseen disrupters arise.”
By the same token as the quote above, does it follow that the currency and relevance of an OSS rapidly diminishes as soon as it is delivered to a client?
In the case of research reports, analyses and strategic plans, currency diminishes because the static data sets upon which they’re built are also losing currency. That’s not the case for an OSS – they are data collection and processing engines for streaming (ie constantly refreshing) data. [As an aside here – Relevance can still decrease if data quality is steadily deteriorating, irrespective of its currency. Meanwhile currency can decrease if the ever expanding pool of OSS data becomes so large as to be unmanagable or responsiveness is usurped by newer data processing technologies]
However, as with research reports, analyses and strategic plans, the value of an OSS is not so much related to the data collected, but the questions asked of, and answers / insights derived from, that data.
Apart from the asides mentioned above, the currency and relevance of OSS only diminish as a result of new trends, issues and disrupters if new questions can not or are not being asked with them.
You’ll recall from yesterday’s post that, “An ability to use technology to manage, interpret and visualise real data in a client’s data stores, not just industry trend data,” is as true of OSS tools as it is of OSS consultants. I’m constantly surprised that so few OSS are designed with intuitive, flexible data interrogation tools built in. It seems that product teams are happy to delegate that responsibility to off-the-shelf reporting tools or leave it up to the client to build their own.
Along similar analytical lines, there’s a structural shift underway in traditional business consulting, as described in a recent post contrasting “clean” and “dirty” consulting. There’s an increasing skepticism in traditional “gut-feel” or “set-and-forget” (aka clean) consulting and a greater client trust in hard data / analytics and end-to-end implementation (dirty consulting).
Clients have less need for consultants that just turn the ignition and lay out sketchy directions, but increasingly need ones that can help driving the car all the way to their desired destination.
Consultants capable of meeting these needs for the telco / service provider industries have:
Extensive coal-face (delivery) experience, seeing and learning from real success and failure situations / scenarios
An ability to use technology to manage, interpret and visualise real data in a client’s data stores, not just industry trend data
An ability to build repeatable frameworks (including the development of smart contracts)
Have you noticed that the four key features above are perfectly aligned with having worked in OSS? OSS/BSS data stores contain information that’s relevant to all parts of a telco / service provider business. That makes us perfectly suited to being the high-value consultants of the future, not just contractors into operations business units.
Few consultancy tasks are productisable today, but as technology continues to advance, traditional consulting roles will increasingly be replaced by IP (Intellectual Property) frameworks, data analytics, automations and tools… as long as the technology provides real business benefit.
“A long, long time ago Dennis Haslinger told me that most of the most serious mistakes I would make in life would be bad ego decisions. I have found that to be true.”
OSS is an industry filled with highly intelligent people. In every country I’ve visited to work on OSS assignments, perhaps excluding Vietnam, my colleagues have been predominantly male. Dare I say it, do those two preceding facts imply a significant ego level exists on many (most?) OSS projects (or has it just been a coincidence that I’ve experienced)?
Given that OSS projects tend to cross business units, inter-departmental power plays like the one described in the Dilbert comic below can become just another potential pitfall.
To be honest, I can’t recall any examples where ego (mine or others) has lead to serious mistakes as such, but I’ve seen many cases where it’s lead to serious stagnation, delays in project delivery, that have been extremely costly.
Stakeholder management and change management are highly underestimated factors in the success of OSS projects.
PS. The “intellectual brilliance” link above also talks about the possible benefits of smart contracts in OSS delivery. I wonder whether smart contracts will reduce some of the ego-related stagnation on OSS projects, or simply shift it from the delivery phase to the up-front smart contract agreement phase, thus introducing more “what if scenario” stagnation?
With the holiday period looming for many of us, we will have the head-space to reflect – on the year(s) gone and to ponder the one(s) upcoming. I’d like to pose the rhetorical question, “What do you expect to reflect on?”
It’s probably safe to say that a majority of OSS experts are engaged in delivery roles. Delivery roles tend to require great problem-solving skills. That’s one of the exciting aspects of being an OSS expert after all.
There’s one slight problem though. Delivery roles tend to have a focus on the immediacy of delivery, a short-term problem-solving horizon. This generates incremental improvements like new dashboards within an existing dashboard framework, refining processes, next release software upgrades, releasing new stuff that adds to the accumulation of tech-debt, etc, etc.
That’s great, highly talented, admirable work, often exactly what our customers are requesting, but not necessarily what our industry needs most.
We need the revolutionary, not the evolutionary. And that means raising our horizons – to identify and comprehend the bigger challenges and then solving those. That is the intent of the OSS Call for Innovation – to lift our vision to a more distant horizon.
When you reflect during this holiday period, how distant will your horizon be?
PS. Upon your own reflection, are there additional big challenges or exponential opportunities that should be captured in the OSS Call for Innovation?
“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.
You’ve probably noticed that microservices are the big buzz in our industry. They’re perceived as being the big white hope for our future. I have my reservations though.
If you’re at t0 in the chart above, microservices allow for rapid rollout of features, whole small-grid architectures even (in a Lean / MVP world). My reservations stem from the propensity for rapid release of microservices to amplify the accumulation of tech debt (ie the escalation of maintenance and testing in the chart above). They have the potential to take organisations to t0+100 really quickly.
The upside though is that replacement or re-factoring of smaller modules (ie microservices) should be easier than the change-out of monolithic software suites. The one caveat… we have to commit to a culture of subtraction projects being as important as feature releases.
The diagram below provides a time-sequence view of how tech-debt accumulation eventually strangles new OSS feature releases unless the drastic measures described are taken.
At start-up (t0), the system is brand new and has no legacy to maintain, so all effort can be dedicated to delivering new features (or products) as well as testing to ensure control of quality.
But over time (t0 + 10, where 10 is a nominal metric that could be days, years, release cycles, etc), effort is now required to maintain existing functionality / infrastructure. Not only that, but the test load increases. New features need to be tested as well as regression testing done on the legacy because there are now more variants to consider. You’ll notice that less of the effort is now available for adding new features.
The rest of the chart is self-explanatory I hope. Over a longer period of time, so much effort is required just to maintain and assure the status quo that there is almost no time left to add new features. Any new features come with a significant testing and maintenance load.
Many traditional telcos (Mammoths) and their OSS suites have found themselves at t0+100. The legacy is so large and entwined that it’s a massive undertaking to make any pivotal change (the chess-board analogy).
This is where startups and the digital / cloud players have a significant disruptive advantage over the Mammoths. They’re at t0 to t0+10 (if the metric is in years) and can roll out more new features proportionally.
What the chart above doesn’t show is subtraction projects, the effort required to ensure the legacy maintenance load and number of variants (ie testing load) are hacked away at every opportunity. The digital players call this re-factoring and the telcos, well, they don’t really have a name for it because they rarely do it (do they?).
Telcos (and their OSS suites) are like hoarders, starting off with an empty house (t0) and progressively filling it with stuff until they can barely see any carpet for the clutter (t0+100). It generally takes the intervention of an outsider to force a de-cluttering because the hoarder can’t notice a problem.
The risk with the Agile, DevOps, continuous release movement that’s currently underway is that it’s rapidly speeding up the release cadence so we might be near t0 now but we’re going to get to t0+100 far faster than before when release cadences were far slower.
Can we all see that an additional colour MUST be added to the time-series chart above – the colour that represents reductionist effort? I’m so passionate about this that it’s a strong thread running through the arc of my next book (keep an eye out for upcoming posts as I’ll be seeking your help and insights on it in the lead-up to launch).
“Moonshot thinking is about making something 10x better. This forces you to throw away the existing assumptions and create something bold and new. Reality will eat into your 10x. At the end of the process it may only be 2x, but that’s still amazing.”
Brian Jansen‘s Book Summary: “Bold: How To Go Big, Create Wealth, and Impact the World,” by Peter Diamandis & Steven Kotler.
I think the biggest moonshot facing OSS today is the design and implementation of an architecture that allows other moonshots to happen.
Take a moment to reflect on that…
As of today, our OSS tend to be complex, entangled beasts, governed by the chess-board analogy. The entanglement is so profound that we tend to only do small, incremental charges. Moving a single piece on the chess-board takes soooo much planning to avoid negative consequences. lt’s the reason that some of our high-profile OSS probably still contain chunks of code that were written in the 1990’s or 2000’s.
In the world of OSS, the 10x moonshot comes with a risk of delivering -5x not just the 2x mentioned in the quote above.
Having said that, I’m all for a good moonshot project. It might take just one disentanglement moonshot to allow 1000 subsequent moonshots to fire! A disentanglement moonshot like the small-grid approach described here.
Regardless of whose estimates you read, OSS is a multi billion industry. However, based on the relatively infrequent signing of new vendor deals, it’s safe to say that only a very small percentage of those billions are ever “in play.”
In other words, OSS tend to be very sticky, in part because they’re so difficult to forklift out and replace. Some vendors play his situation extremely well, with low install costs but with strategies such as “land and expand,” “so sue us” and “that will be a variation.” These honey pots hide the real cost of ownership.
Cloud IT architectures such as containerisation and microservices can provide a level of modularity and instant replaceability between products (ie competition). When combined with a Minimum Viable Product mindset rather than complex, entwining customisations, you can seek to engineer a lower lock-in solution.
The aim is to ensure that products (and vendors) stay in-situ for long periods based on merit (ie partnership strength, functionality, valuable outcomes, mutual benefit, etc) rather than lock-in.
Guns don’t kill people, people do.
Similarly, Technology doesn’t kill OSS projects, people do… Actually people with technology do.
The following shows the escalation of global CAPEX allocated by CSPs over the last thirty years (in current currency).. apart from a few brief years around the Global Financial Crisis (GFC).
The CAPEX uplift also represents the increase in complexity in the networks and solutions used by CSPs. There are just more technologies in our networks than ever before. If you follow the trendline, we can predict that the challenges caused by increased complexity will be followed by even more investment in technologies that will further increase complexity. Just wait until virtualised networking spend hits its nadir!
And all of that complexity flows downstream to our OSS. The variants are killing us.
This may seem completely stupid to most people in the industry, but the supposed holy grail of ever-faster TTM (Time to Market) may actually be killing us more quickly – a faster TTM means a faster ramp-up of variants flowing down at us.
And our response to the increase in variants? That’s right – more technology – which just happens to add more variants. Did someone say death spiral??? 🙂
But we’re made of sterner stuff. We’re not going to let that happen are we? We’re going to hire Chief Simplification Officers who will wield the Simple Stick across entire CSP organisations (not just Operations) and institute massive complexity reduction projects.
Data quality is the bane of many a telco. If the data quality is rubbish then the OSS tools effectively become rubbish too.
Feedback loops are one of the most underutilised tools in a data fix arsenal. However, few people realise that there are what I call big circle feedback loops as well as little circles.
The little circle is using feedback in data alone, using data to compare and reconcile other data. That can produce good results, but it’s only part of the story. Many data challenges extend further than that if you’re seeking a resolution.
The big circle is designing feedback loops that incorporate data quality into end-to-end processes, which includes the field-work part of the process.
Redline markups have been the traditional mechanism to get feedback from the field back into improving OSS data. For example, if designers issue a design pack out to field techs that prove to be incorrect, then techs return the design with redline markups to show what they’ve implemented in the field instead.
With mobile technology and the right software tools, field workers could directly update data. Unfortunately this model doesn’t seem to fit into practices that have been around for decades.
There remain great opportunities to improve the efficiency of big circle feedback loops. They probably need a new way of thinking, but still need to fit into the existing context of field workers.
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
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
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.
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
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
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.
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.
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).
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.
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.
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
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
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
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
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.
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.
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
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
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
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
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.”
I love the fact that we’re constantly seeking incremental improvements for our OSS. However, cumulative OSS changes can be a double-edged sword, just as they can be in the cosmetic surgery industry. In both cases, these well intentioned changes can distort as readily as they can improve.
Photo-collage courtesy of DailyMail.co.uk.
I’ve seen OSS go from being open, intuitive, adaptable and flexible tools to being so customised for a single client purpose that they need additional reconstructive work for even the tiniest change (eg process revision, network configuration / topology type, new card type in an existing device, etc).
Embarking on a course of incremental customisation, such as an Agile methodology, can become dangerous without careful consideration. Be vigilant of where your changes might be guiding you.