Women in OSS

OSS doesn’t seem to be a very enticing career for women unfortunately. Over all my years of OSS projects, I can’t think of any where women outnumbered the men. However, my OSS projects have been interspersed with a variety of other projects where women have dominated the team numbers.

Looking back, there’s almost perfect correlation between the positivity of the project environment and the proportion of women on the team. The teams with few or no women have definitely been the most challenging projects from a morale perspective and least balanced.

The level of “success” of the project also seems to be correlated, but perhaps not quite so strongly, probably due to the larger number of factors that contribute to project success.

I’m not qualified to offer suggestions on why there aren’t more women in OSS (or IT / telco) but based on my experiences, we definitely need more to improve the health of our working environments.

Your thoughts?
I’d particularly love to hear from any OSS-women reading this blog.

AI to practice as you play

I’m a die-hard sports fan, as a player and watcher, so I find it interesting how parallels are drawn between work and sport – in particular, that “you practice as you play.” Alternatively, it’s implied that if you practice sloppy, you play sloppy. But if we look at a professional athlete that dedicates 40 hours per week to their craft, perhaps only an hour of that week is actually IN the event, leaving 39 hours to fine-tune FOR the event. In work, we don’t really get that luxury. If we work 40 hours, we rarely get the chance to practice for an outcome. We’re generally using most of the 40 hours to deliver outcomes IN the event. So at face value, I find this common analogy a strange one.

There are some areas of relevance for OSS though:

  • Crisis management – taking the time to prepare the team for crises to ensure mitigation of the negative contingencies that could effect business operation. We want to practice these events regularly like an athlete to ensure that we recover as quickly as possible from adverse conditions. Set the chaos monkeys loose!
  • In-flight training – Whereas an athlete can train certain practice drills to enhance performance before their event and monitor indicators to use as feedback for fine-tuning, OSS exponents don’t get that chance. However, we do have the ability to collect data, use it as feedback to improve our in-flight performance via decision support and trial different techniques to compare outputs, just like a coach refining an athlete’s drills
  • Match simulations / projections – An athlete will use feedback from training and events to identify strengths / weaknesses and simulate scenarios in their events. In OSS we are caught up in the event but still have to project forward. We have capacity planning tools and lots of historical data to prepare sophisticated predictive simulations (and optimisations) from

As you can see from the three points above, they’re all about utilising feedback whilst in the event because we don’t get much downtime before the event. Machine learning and artificial intelligence represent an exciting opportunity for OSS because they give us an opportunity to train and refine our OSS whilst we’re in the event, allowing us to indeed practice as we play.

Our tools going the way of the slide rule

My grandfather achieved many great things in his lifetime and I’m really proud to come from his lineage. I have many great memories of him and one perplexing one.

When I was accepted into Engineering at Uni, he proudly presented me with his trusty slide-rule and stated that I’d be needing it in my course. Of course I thanked him but I’m somewhat embarrassed to say that I didn’t take the time to learn how to use it.

It got me thinking though, what are the tools that the greatest minds of our generation will hand down to their grandchildren with equally perplexing results?

I can fairly confidently predict that the concept of OSS will be meaningless. Personal computers / laptops / tablets will be antique curiosities by then too. Will fixed-line networks exist (even the almost limitless capacity optical fibre networks)? Programming will be vastly different… if software / apps are even still relevant at all. Will today’s software-defined everything become software-defined nothing? Will any of Google, Facebook, Apple et al be the ageless GE of our generation (hundred-year innovators) or just the horse-drawn carriage companies of my grandfather’s? [Which unicorn do you predict as most likely?]

All of my current tools-of-trade will be utterly useless to my grandchildren (assuming I have any). But I can’t wait to help pave the way (in any major or minor context) to whatever tools come next to replace them. 🙂

The Second Law of OSS Thermodynamics

Applying the Second Law of Thermodynamics to understanding reality, Boyd infers that individuals or organizations that don’t communicate with the outside world by getting new information about the environment or by creating new mental models act like a “closed system.” And just as a closed system in nature will have increasing entropy, or disorder, so too will a person or organization experience mental entropy or disorder if they’re cut off from the outside world and new information.
The more we rely on outdated mental models even while the world around us is changing, the more our mental “entropy” goes up.
Think of an army platoon that’s been cut off from communication with the rest of the regiment. The isolated platoon likely has an idea, or mental model, of where the enemy is located and their capabilities, but things have changed since they last talked to command. As they continue to work with their outdated mental model against a changing reality, confusion, disorder, and frustration are the results
Brett & Kate McKay

Does the description above resonate with you in relation to OSS? It does for me on a couple of levels.

The first is in relation to data quality. If you create a closed system, one where there isn’t continual, ongoing improvement efforts entropy and disorder goes up. If you only do big-bang data fix projects intermittently, you will experience entropy until the next big (and usually expensive) data remediation effort. And if your processes don’t have any improvement mechanisms, they tend to fall into a data death spiral.

The second is in relation to innovation. We can sometimes get stuck in our own mental models of what this industry is about. The technologies that are in enormous flux around us and impacting OSS mean that our mental models should be evolving on a daily / weekly / monthly basis. Unfortunately, sometimes we get stuck in the bubble of our current project and don’t get the feedback into the system that we need. PAOSS was spawned from a situation like that. For 18 months, I was leading a $100m+ project that had little to do with OSS and was increasingly drawing me away from the passion for OSS. PAOSS was my way of popping the bubble.

But I know my mental models still need to shift more than ever before (strong convictions, weakly held). Technologies such as CI/CD, AI/ML, virtualised networking, IoT and many more are changing the world we operate in. This needs vigilance to continually re-orient. That’s fun if you enjoy change, but many of our stakeholders don’t. Change management becomes increasingly important, yet increasingly underestimated.

Some even say that OSS is an old mental model (to which I counter by saying that new operational models look nothing like the old ones, but they’re still operational assistance tools, as per Theseus’s boat).

Accomplishing the incredible seems normal

Jon: I started listening to audiobooks and podcasts 4-8 hours a day.
James: Why was that your goal?
Jon: If you spend the majority of your time in worlds where people are accomplishing incredible things, all of a sudden that starts to seem normal

Podcast discussion between Jon Morrow and James Altucher.

The great thing about books and podcasts is that you usually get the best ideas from the author / interviewee. You get the distilled insights of a lifetime of work of some of the greatest minds in the world (assuming that you’re reading/listening to the right content of course!). I once heard that Elon Musk used to read up to 60 books each month.

Are you ever going to have giants like Elon Musk, Richard Branson, Jack Welch, Seth Godin, (insert your list of heroes’ names here) as your mentors? Probably not. But you can get the next best thing in your own home, at your own time, at your own speed.

The part I love about Jon’s take on this “do lots of reading” adage is that listening to the exploits of giants doesn’t just give insights, it creates a new normal to be inspired by and to measure your own accomplishments against.

I’ve noticed that the most thought-provoking people in the OSS industry absorb a wide variety of ideas and are able to inter-link them in their inspiring stories.

What are you currently reading / listening to and how far does it stray from OSS?

Speaking of industry giants, we’re now only a week away from the start of TM Forum Live! It’s probably the greatest assembly of OSS thought-generators in the world, so I’m going to be fascinated to listen to the vast range of topics being discussed.

Centre of attention

There are a lot of OSS experts out there. There are a lot of people who know an extraordinary level of detail about certain aspects of OSS. I sure do admire those people.

But do you know what? The people who I admire even more are the ones who understand the big picture. Knowing the big picture generally puts you in a greater position of influence for a few reasons:

  • There are relatively few OSS experts who know enough about the big picture to know how to pull all the pieces of projects together
  • Those who do become the centre of attention on the project because others need guidance on how their parts bolt together with everyone else

Malcolm Gladwell suggests that it takes 10,000 hours of practise to master a field. That’s what it takes to be Lebron James, Christiano Ronaldo, et al. You couldn’t expect to be as good as them by only dedicating 500 hours of practice, but with 500 hours you probably will be better than 80% of the population.

What if you found a cross-over point between two fields (ie a niche) that you’ve dedicated 500 hours to (eg network technology and contract law)?.Chances are that you’d be a master of that niche because of it’s relative uniqueness. What if you found a cross-over of three 500-hour fields?

You might not be able to fast-track the 10,000 hours in a specific field within OSS, but there are plenty of cross-over points in OSS where you can add even more value in a fraction of the time.

The greatest currency is success

Whether it’s at an individual, business unit or organisational level, demonstrated achievement on OSS projects tends to lead to greater opportunities and rewards. There are so many OSS projects underway globally and so much expertise required, but there are a high proportion of projects that don’t deliver or are currently stagnating. This means opportunity.

However, we generally don’t tend to use testimonials as much as we could. In my experience, vendors presenting to potential customers don’t tend to use testimonials. They mention current / past customers (often in a first-date principle kind of way), but don’t tend to use testimonials from those customers. They don’t tend to proactively* provide references to customers where success has been proven (* ie not only providing references upon request).

At an individual level, word-of-mouth can be a powerful influence on winning new roles, but we also don’t tend to proactively utilise testimonials if the hirer doesn’t have mutual connections with us. How many CVs do you see with “references available upon request” rather than saying, “please speak with person X, Y, Z to understand how I’ve contributed to success on their projects, here are their contact details,” during an interview?

Have you found that a history of achievement will tend to speak for itself? I feel that you don’t need to make claims about how good you are, others will be happy to make those claims on your behalf. And there are plenty of opportunities to passively demonstrate how good you are in OSS.

That’s somebody else’s job

One of the advantages of being a consultant is that you get to assist big corporates without being wrapped up in some of the big corporates’ mindsets.

Of course this isn’t true of all employees at big corporates, but I’ve found the, “that’s somebody else’s job,” mindset to be more prevalent there. In some ways it makes sense right – having a large group of employees means that there is likely to be someone with the title / responsibility to tackle almost any given task.

But personally, I’ve loved working on large OSS projects with smaller project teams because there are always activities that slip through the cracks. I’ve found these types of projects give the biggest opportunities to learn.

For example, back in my early days in OSS, I was a network SME who was assisting the data migration team. Unfortunately (fortunately) there was a change in personnel and I ended up inheriting the whole network modelling and data migration function. This provided the opportunity to design and model network inventory that covered 3000+ network elements, 200 SDH rings, 10 DWDM rings, 70 ATM switches, 2000 multi-service access nodes, 16 PSTN switches, more than 250 IP switches/routers, RAS, LMDS, DCME, DACS, VoIP and network synchronisation devices. There were well over 100,000 services modeled, across products including voice/PABX/IN, ISDN, ATM, FR, Leased Line, ADSL and other IP related services. Having an intimate knowledge of the data meant that I was increasingly called upon to architect solutions and even design product enhancements.

Now nobody would ever hire me as a coder (I can’t program my way out of a wet paper bag, despite having a computer science degree), but to get the above-mentioned job done, I had to teach myself SQL to manipulate, correlate and import large data sets. It was somebody else’s job to write code, but they couldn’t keep up with demand and got moved to another project anyway.

That was a very formative project in terms of my passion for OSS. Having a mindset of “that’s somebody else’s job” would’ve reduced my workload on that project immeasurably, but also would’ve prevented me from accessing the amazing opportunities I’ve been given since. A “somebody else’s job” mindset would’ve meant the cool opportunities that followed would’ve also become somebody else’s jobs!

The Noah’s Ark of OSS success

Don’t be involved in 50 or 100 things. That’s a Noah’s Ark way of investing – you end up with a zoo that way. Put meaningful amounts of money in a few things you know well.”
Warren Buffett

There are a lot of OSS products on the market. From that list, you can probably name a handful that have been very profitable. The reason why, I believe, can be distilled down to two primary factors:

  1. Successful OSS have a specific focus
  2. Successful OSS help a large number of people

Specific Focus – One of the best* OSS that I’ve worked with had a brilliant core and covered a large portion of the TM Forum TAM map (ie delivered a lot of the components that make up a “complete” OSS). I still have a soft spot for this vendor but unfortunately they went out of business, in part because they didn’t narrow their focus tightly enough. Their product development was spread out across the whole zoo. By contrast, unlike this company, some of the OSS companies with largest market share (and profits) don’t directly develop resource performance or fault management tools. Those segments of the market are already well serviced, so those big vendors focus their efforts elsewhere.

Extend helpfulness – I believe that the fastest way to achieve success is to first assist a large number of people in succeeding. The larger the number, the better. If you think about the most profitable companies in the world, you’ll notice that they tend to help a large number of people. The same is true in OSS – the most successful vendors either support a large number of customers, or if supporting a relatively smaller customer list, then each customer tends to be large a organisation with many operators.

The way I like to think of it is:

  • For point 1 – know what’s on the left side of your whale curve and therefore what to focus attention on
  • For point 2 – without breaching point 1, think laterally about how your focussed product / suite could assist a larger customer group. For example, this might be thinking about how it can assist your customer’s sales / marketing / executive / etc business units, not just operations

This isn’t just an organisational-level perspective. From a personal level, these are also the same two personal growth questions I ask myself regularly. What are your thoughts? How could I (or you) improve on these two factors (or others)?

* When I referred to the vendor as being one of the “best,” I was clearly judging on metrics other than profitability.

OSS = insecurity

Insecurity is fascinating.

We hide it.

We beat ourselves up for it.

And to top it off, it seems like we’re the only ones who ever feel it.

And yet: It’s the times we feel most insecure that we grow the most.

Take my friend Noah Kagan.

He’s founded two multimillion-dollar businesses. And he lives an amazing life eating tacos in Austin, snowboarding in Vail and working from his laptop in Mexico. (Sign me up!)

But what’s most interesting isn’t his success. It’s how he got there.

After getting an amazing job as employee #30 at Facebook, he faced one of the most difficult periods of his career.

Here’s what he said about working at Facebook.

“We all feel smart. So to be put in a place where every day I’m feeling retarded, like, ‘Wow, I am definitely the dumbest shit here,’ sucked. It sucked… But recently when I was thinking about it, that was my biggest growth period of my life. It was the biggest growth period because I was challenged the most.”

If the average person felt that way at work, they’d probably quit.”
Ramit Sethi.

OSS makes me feel like “Wow, I am definitely the dumbest shit here” too, but it’s also been largely responsible for the biggest professional growth period of my life (so far). With the constant change hitting our industry, I can’t see the chance to get into a comfort zone any time soon either.

Does OSS feel like that for you? If the average person felt that way at work, they’d probably quit, so by implication does that make you a high achiever?

Ambidextrous leadership in OSS

Ambidextrous leadership (investor + operator thinking): Sue believes there is enormous value in pairing venture capital investor-type thinking with operator-type thinking. Being able to step back and analyze opportunities from an investor’s perspective can be a valuable tool in helping entrepreneurs and managers alike make better decisions. And for investors, thinking like an operator is so important to understand the businesses they are investing in and, more than that, to best leverage your resources to help the companies.”
Peter Diamandis

Peter / Sue make a strong case for the pairing of perspectives, to see the world through different eyes – as an investor, through operator’s eyes; as an operator, through investor’s eyes.

In business and investing, it’s in the ability to be ambidextrous. For OSS, we need to grow an extra limb.

There are three perspectives that the greatest exponents of OSS hold, at least the ones that I’ve met:

  • Business-savvy (ie the investor perspective) – understanding the business environments in which our OSS operate and how they contribute to the success of an organisation
  • Operations-savvy (ie the operator perspective) – understanding the roles and activities of operations so that they can be supplemented and streamlined using our OSS
  • Tech-savvy – understanding the IT, networks, cloud, software, etc and the associated delivery of this technology stack to support the business and operations needs

A majority of people in OSS (and the businesses they’re built for) bring only the perspective of one, maybe two of these arms. Those who are able to understand these three entwined perspectives and how to bring them together are a rare and invaluable breed. I’ve certainly met some very, very talented people who bring just one perspective (eg technical), but the best I’ve worked with are all adept across all three.

The big and the bold needs catalyst thinking

My role is that of a catalyst. I try to create an environment in which others make decisions.
Ricardo Semler, in his book, “Maverick.”

Creating something big and bold that’s never been done before (within a company, if not an industry) seems to scare most people in OSS. I think that this comes about partly because most people in the tech industry seem to be details (or bottom-up) thinkers – if they don’t have (almost) all of the details stitched together then it becomes a massive task of gathering all the pieces before a solution can be proposed (ie it becomes a really hard problem to solve).

But new, big and bold OSS needs top-down thinking. By nature, you don’t have all of the pieces of the puzzle figured out, so you have to start from the top – and break things down piece by piece, digging deeper on each element and discovering along the way. The WBS (Work Breakdown Structure) and mind-map approaches support this top-down approach.

One of the challenges with this approach is that the catalyst must be humble enough to acknowledge that they won’t have all the answers, but will rely on the smarts of other people who have the detailed knowledge.

Over the years, I’ve been able to coax teams of people much, much cleverer than I out of their stalemates and through to implementation using this approach. Whilst I may have facilitated, it was always the team that resolved a vast majority of the challenges. Just a few examples include:

  • The creation of a traffic engineering module that had been sold to a customer before being even conceptually architected. The team was almost ready to default on a many-million dollar contract due to the complexity of building a whole new traffic engineering engine but we were able to stitch together a set of existing tools with only a few weeks of effort
  • An orchestration engine that had stalled for months because the underlying technology wasn’t at all suited to what the customer needed done. After another month, we had a working version that became saleable as a product to many existing customers around the world
  • Before automated discovery was common-place, we had a highly flexible data model that could absorb almost any network technology. However, that flexibility meant we needed a discovery platform that could cater for any known or future technology. After 2-3 intense months, we were able to discover and aggregate circuts that traversed multiple domains, linking feeds from different management systems and building on multiple layers of bearers
  • Helping a high-profile, green-fields carrier to go live with operational processes that extended well beyond the reach of our OSS offering, The customer’s big-4 consulting firm and their legion of staff had not come close to building workflows that would allow the customer to go live by a regulator-imposed deadline.
  • Unlocking the secret of integrating to a network interface within hours after it had previously consumed 6-8 weeks of interrogation effort

BTW. Having a great adjacency view described in the previous post also helps to understand the top-level pieces and who to engage in the team.

Driving your OSS like a racing-car team

The best race car drivers are not only the ones who can drive well but can also communicate clearly with the pit crew on how to set up the car (eg tyre pressures, suspension settings, etc). They understand the adjacent fields and are able to communicate with them. They’re not mechanics. They leave the task of setting up the car to the experts, but they do have enough knowledge about the setup of the car to to transpose the sense of how it feels and how it can be optimised.

OSS is the same. You might be brilliant at what you do within your role in OSS but in almost all cases you will also have multiple adjacencies to align with and communicate with to ensure the car is running optimally. This requires a thirst for questioning and empathetic learning from the adjacencies rather than the more prevalent practice of demonstrating brilliance in your field of expertise.

The other part of the race-car analogy is that race teams are constantly tinkering with the settings to try to optimise outputs for the changing conditions. Whilst OSS doesn’t do laps (although OSS projects can go around and around at times) thus allowing lap times to be compared for a given setup, we can learn from the analogy by tinkering, testing, measuring and refining. We definitely do a lot of tinkering, but we don’t always have a clear set of measures to test and refine against.

Unlocking a more intelligent OSS future

As Chaney Ojinnaka wrote, IoT (Internet of Things) needs AI (Artificial Intelligence). But on the flipside, AI also needs IoT to grow its awareness and understanding of the world. According to Christof Koch, a leading brain researcher at Seattle’s Allen Institute, “Consciousness is a property of matter, like mass or energy.” He says that a strand of grass that turns towards sunlight is more “conscious” than the most advanced computer simulation to date. This is because its information is integrated in a refined physical system that grows and learns as one.

To build machines with a better understanding of the world, we need to build integrated systems that learn through connected sensors and act directly via smart devices. These gadgets expand the physical presence and footprint of AI to help it grow more aware and intelligent. Google’s big bet on mobile and home devices is starting to pay off, while Amazon’s Alexa is already deployed by 7,000 companies in everything from fridges to cars. Each user interaction is now teaching these AIs every moment.

These gadgets provide service and gather data, but also bring additional complexity to the already complicated world. By 2020, the number of connected devices is expected to grow to around 30 billion, according to market analysis firm IHS Markit. Companies need to drive convergence for two major reasons: to reduce the cognitive load on customers, and to streamline design, development, and operations across interfaces.”
Sami Viitamaki. Havas on VentureBeat.

The article above also supplies the following diagram:

Interesting concept. AI needs IoT (as a data collector to improve its cognisance to facilitate learning) as much as IoT needs AI (to handle the volume and variety of messaging to facilitate insight and acceleration).

This draws a parallel with OSS. AI needs OSS (as a data collector to improve its cognisance to facilitate learning) as much as OSS needs AI (to handle the volume and variety of messaging to facilitate insight and acceleration).

OSS are already producing more data than most humans can handle (perhaps they always have). We’ve been through the cycle of using algorithms to augment our decision making process (eg filters, suppressions, augmentations, etc). For the general populace, IoT is the required data collection technique that AI needs. For CSPs, OSS have long captured vast amounts of data on which to learn, but perhaps we haven’t utilised enough sophisticated machine learning (ML) to date.

The touchpoint explosion means that we’ll become even more reliant on sophisticated exponential learning techniques into the future. If you’re looking to add a new skill to your OSS bow over the next few years, I would suggest that AI / ML might be a valuable investment and medium-term differentiator.

What do you think? Can you suggest a more valuable personal development path?

Some personal OSS principles

  • While most others seem to believe that learning what we are taught is the path to success, I believe that figuring out for yourself what you want and how to get it is a better path.
  • While most others seem to believe that having answers is better than having questions, I believe that having questions is better than having answers because it leads to more learning.
  • While most others seem to believe that mistakes are bad things, I believe mistakes are good things because I believe that most learning comes via making mistakes and reflecting on them.
  • While most others seem to believe that finding out about one’s weaknesses is a bad thing, I believe that it is a good thing because it is the first step toward finding out what to do about them and not letting them stand in your way.
  • While most others seem to believe that pain is bad, I believe that pain is required to become stronger

Ray Dalio in his Principles manifesto.

When I reflect on years of OSS implementations, I find Ray Dalio’s principles above to be a contrarian view that I also share… But the question is, that if I share his contrarian view, is it actually contrarian? If all of you share the contrarian view then it wouldn’t seem to be contrarian at all.

There are a lot of very clever people in OSS, with lots of very clever thoughts and lots of strong opinions. With that comes the perspective that most OSS experts fall into the “most others” category. But without being inside the head of others (well obviously), is this just some sort of perception / bias that we all hold about others?

I’d love to get your thoughts. What do you think on his principles above? Please respond with an answer of “Ray’s view” or “most others”

BTW. These list quoted above is just a very small sub-set of a very interesting set of theories in Ray’s manifesto. I definitely recommend having a read through it here, but noting that it is quite long.

Platforms are eating the world

The platform strategy has two key elements, and it is important not to confuse them. First is the platform business model, where companies build digital ecosystems or marketplaces connecting customers with producers of goods and/or services, making it easy for them to do business, rather than playing a direct role in the supply chain (think, Airbnb, eBay and Uber).
Second is the technology platform, which supports the electronic marketplace and facilitates the digital business model. Many platform businesses began with a platform business model in mind, so they purposely built their infrastructure and IT systems to support such a model from the outset. Others, including most communications service providers, are now evolving their business models to take advantage of their infrastructure, IT systems and connectivity to facilitate and create digital ecosystems
Dawn Bushaus
in a TM Forum Report called “Platforms: How to join the revolution

This report is well worth a read if you’re looking for insights into how CSPs can leverage their hard / soft / wet assets to build a platform strategy. Another member of the TM Forum team, Sarah Wray, has created this blog, “Network effects “create category kings”,” which provides some fascinating quantification of how platforms are eating the non-CSP world.

Dawn Bushaus’ report also states, “Communications service providers are uniquely placed to turn their networks and operational and business support systems inside out the way Amazon did, and many are already starting to do it. These architectural changes enable them to shift to a platform business model and offer customers access to all kinds of services that may or may not be hosted on their network. This is similar to how the Apple App Store or Google Play offers access to third-party applications.
A customer can order services on demand through a self-service portal, and the operator, in turn, can provision and manage them end to end, potentially in conjunction with partners, so that the services consistently meet pre-determined levels of quality. Eventually these services will be ‘zerotouch’, meaning everything happens automatically, without any human intervention, using orchestration, analytics and policy management

Service providers, via their OSS/BSS, are already starting to become more API-driven, which gives them the opportunity to offer platforms upon which their customers can build.

The next step for service providers is to leverage the power of their enormous existing subscriber base, to connect the buyers and sellers of all sorts amongst it, and add value to their lives. For an earlier perspective on this topic, see here. We’re barely scratching the surface of the valuable business models we can create based on the data collected and collated by our OSS/BSS.

Strong orchestration convictions, weakly held

I first came across the phrase “strong convictions, weakly held” through Marc Andreessen, but a bit of Googling showed me it was originally coined by Paul Saffo, then Director of the Palo Alto Institute for the Future. According to this post he advised his people to think this way for three reasons:
•It is the only way to deal with an uncertain future and still move forward
•Because weak opinions don’t inspire confidence or action, or even the energy required to test them
•Because becoming too attached to opinions undermines your ability to see and hear evidence that clashes with your opinion (confirmation bias)

Saffo came up with this logic almost 15 years ago, and as change happens faster and faster it has become increasingly compelling, to the extent that the importance of having “strong convictions, weakly held” is starting to become somewhat of a cliche amongst many of the best investors I know.

However, it applies to the whole startup world, not just investing. In fact it applies to anyone who is (or should be) searching for the truth, or more properly the closest approximation we can get to it. Much of the time in startups we have to make decisions based on minimal information in an environment that is fast moving and where there is no objectively ‘right’ answer. The best we can do is form an opinion based on the facts in front of us and then have the courage to act on that opinion. Then, and this is often the most difficult bit, we must find the courage to change our opinion if new information suggests we were wrong.”
Nick Brisbourne here.

“Strong opinions, weakly held,” is a suitable mantra for the OSS industry (perhaps even the name, OSS). When so much around us is changing, it’s imperative that we consider other “right answers” isn’t it? And despite this, so much change is still underpinned by concepts that haven’t changed much at all.

I’m currently doing some work on an orchestration project. Orchestration is the big new thing. Everyone is talking orchestration, service catalogs, etc. Nobody refers to flow-through provisioning anymore… And yet, all of the concepts that make up next generation orchestration appear to be almost identical to the flow-through provisioning solutions I first configured back in 2000. But I’m also completely open to hearing about the new innovations that make orchestration more repeatable, allowing engineers to configure new or modified services far more quickly.

When it comes to orchestration (and so many other aspects of OSS), I have strong opinions, weakly held.

Moving closer to the sale

The definition of moving up the value chain will be different for freelancers depending on their industry. But in general, the closer you are to the sale, the higher you will be valued, and the more you can charge.
For example, a content writer is just responsible for writing a certain number of blog posts per week.
But a content strategist is responsible for the overall strategy of a website to bring in new leads and customers
Joe Choi
on GrowthLab.

The quote above is clearly targeted at an audience that has seemingly little overlap with the OSS industry. However, the concept holds true for our industry as well. The closer you are to consistently making an OSS sale or initiating an OSS project, the higher you tend to be valued and harder it is to replace you.

Despite its somewhat tarnished reputation, the OSS industry still attracts enormous amounts of capital globally. However, the sales cycle tends to be lengthy on the allocation of that capital, with many flaming hoops to jump through before starting a project. Part of the reason for lengthy sale processes is because there are so many objections to overcome from so many stakeholders. There are objections from the financiers, the technical experts, the implementers, the operators, the executives and more. It follows that the list of objections will be multi-faceted in nature. The rainmakers are so invaluable in our industry because they find a way to navigate the array of objections, often with the help of very talented teams.

As mentioned last week in “Software is eating the world…. and eating your job?” software is revolutionising the OSS industry. At first glance, you would think a software developer is in prime position to benefit from this change, but the post suggested otherwise (in some cases).

Moving closer to the sale and / or being consistently responsible for getting OSS projects off the ground is the better guarantee of an assured income stream. And to get there requires being a tripod or the red sector in the following diagram (sourced from this old post):

As an industry, we have to get better at building our skills in the red and yellow intersects so that we keep building a pipeline of projects that add enough value to justify the capital they attract.

As an aside, whilst smart contracts have the potential to coordinate algorithmic purchasing, being closer to the sale will probably also make it harder to replace our roles with bots in the years to come.

Software is eating the world…. and eating your job?

A funny thing happened today. I was looking for a reference to Marc Andreessen’s original, “software is eating the world,” quote and came across an article on TechCrunch that expressed many of the same thoughts I was going to write about. However, it doesn’t specifically cover the service provider and OSS industries so I’ll push on, with a few borrowed quotes along the way (in italics, like the following).

Today, the idea that “every company needs to become a software company” is considered almost a cliché. No matter your industry, you’re expected to be reimagining your business to make sure you’re not the next local taxi company or hotel chain caught completely off guard by your equivalent of Uber or Airbnb. But while the inclination to not be “disrupted” by startups or competitors is useful, it’s also not exactly practical. It is decidedly non-trivial for a company in a non-tech traditional industry to start thinking and acting like a software company.”
[or the traditional tech industry like service providers???]

This is completely true of the dilemma facing service providers the world over. A software-centric network, whether SDN, NFV, or others, is nearly inevitable. While the important metrics don’t necessarily stack up yet for SDN, software will continue to swarm all over the service provider market. Meanwhile, the challenge is that the existing workforce at these companies, often in the hundreds of thousands of people, don’t have the skills or interest in developing the skills essential for the software defined service provider of the (near) future.

Even worse for those people, many of the existing roles will be superseded by the automations we’re building in software. Companies like AT&T have been investing in software as a future mode of operation for nearly a decade and are starting to reap the rewards now. Many of their counterparts have barely started the journey.

This old post provided the following diagram:
The blue circle is pushing further into the realm of the green to provide a larger yellow intersection, whereby network engineers will no longer be able to just configure devices, but will need to augment their software development skills. For most service providers, there just isn’t enough IT resources around to make the shift (although with appropriate re-skilling programs and 1+ million IT/Engineering resources coming out of universities in India and China every year, that is perhaps a moot point).

Summarising, I have two points to note:

  1. Bet on the yellow intersect point – service providers will require the converged skill-sets of IT and networks (include security in this) in larger volumes… but consider whether the global availability of these resources has the potential to keep salaries low over the longer term* (maybe the red intersection point is the one for you to target?)
  2. OSS is software and networking (and business) – however, my next post will consider the cyclical nature of a service provider building their own software vs. buying off-the-shelf products to configure to their needs

Will software eat your job? Will software eat my job? To consider this question, I would ask whether AI [Artificial Intelligence] develops to the point that it does a better job at consultancy than I can (or any consultant for that matter)? The answer is a resounding and inevitable yes… for some aspects of consultancy it already can. Can a bot consider far more possible variants for a given consulting problem than a person can and give a more optimal answer? Yes. In response, the follow-up question is what skills will a consulter-bot find more difficult to usurp? Creativity? Relationships? Left-field innovation?

* This is a major generalisation here I know – there are sectors of the IT market where there will be major shortages (like a possible AI skills crunch in the next 2-5 years or even SDN in that timeframe), sometimes due to the newness of the technology preventing a talent pool from being developed yet, sometimes just for supply / demand misalignments.

Working on the business rather than in the business of OSS

Blogs from the last two days have covered the dilemma of dynamic operating procedures and why the standard operating procedures of the past are perhaps too idealistic a concept. Despite this, I still try to build repeatability into the various aspects of OSS delivery – initial installation, documentation, demonstrations, training, testing (and regression testing), etc. This concept was one of my key take-aways from the book, “The E-Myth Revisited,” by Michael Gerber.

The other take-away was that people who start businesses often make one fatal assumption – if you understand the technical work of a business, you understand a business that does that technical work. [1]

The reason most small businesses don’t work is that they are run by a “Technician”, someone who knows how to do the technical work involved in a job (working IN the business), without much thought to two other, equally important roles described in the book, the “Entrepreneur” and the “Manager” (working ON the business). [2]

We can probably draw an analogy to the OSS industry here. A vast majority of OSS experts fit into the “Technician” category by their activities, and who also focus their thinking on delivering outstanding technical resolutions. They’re working in the business. But the most valuable OSS experts I’ve dealt with also manage to switch between Technician, Entrepreneur and Manager. They manage to work on the business, it’s long-term implications and codifying the systems to make it more reliable and repeatable.

Interestingly enough, by taking the mindset of working on the business of OSS, it brings greater clarity on the context of the technical activities that need to be performed and in which priorities.

If you are an OSS expert and haven’t filled your roster of new year’s resolutions yet, may I suggest that you allocate the thoughts and efforts required to take your OSS and/or the OSS industry forward with your Entrepreneur” and the “Manager” hats on?

1. Paraphrased from sivers.org
2. Paraphrased from squeezedbooks.com