How would Einstein or Darwin manage an OSS?

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

Zat Rana
on here on Business Insider.

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

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

Here are a few other possibilities:

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

When in doubt, connect

When in doubt, connect.
That’s what fast-growing, important organizations do.
Making stuff is great.
Making connections is even better
Seth Godin
in his post here.

Simple words. Simple concept. Interesting message…. with a traffic-light of OSS layers.

Layer 1 – A connection red light
The more connections an OSS has, the more enriched the data tends to become. However, by contrast the more interconnected an OSS gets, the more inflexible and difficult it gets to maintain. The chess-board analogy and the handshake analogy attest to the challenges associated to a highly connected OSS. In this case, when in doubt, don’t connect.

Layer 2 – A connection orange light
Five of the top seven companies (by market cap) in the world are tech companies (1. Apple, 2. Alphabet (Google), 3. Microsoft, 6. Amazon, 7. Facebook). They have become valuable through the power of connection. China Telecom represents one of the original connectors, the telecommunications carriers, and just makes it into the top 10 whilst Verizon and AT&T are both worth over $250B too. Our OSS allow these connections to be made – but they’re making a connection “for” the customer rather than making a connection “with” the customer. Until brand-OSS starts making a connection with the customers, we’ll never be fast growing like the tech titans. When in doubt, connect at a deeper level.

Layer 3 – A connection green light
Tripods or Linchpins are the most valuable of OSS resources because of their ability to connect (ideas, people, products, workflows, contracts, etc). They are the pinnacle of OSS implementers because their breadth of connections allows them to interconnect the most complex of OSS jigsaws. If you want to become an OSS tripod, then Seth’s lead is a great one to follow – When in doubt, connect.

Short-sighted / long-sighted OSS

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

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

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

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

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

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

What would you do in this situation?

The world of OSS, no matter where you are placed within its orbit, seems to be chaotic. There are always so many things to get done – updates, fixes, incidents, planning, designs, meetings, emails, etc, etc.

I’d love to hear what you would do if the following situation presented itself:
Every week, you get a four hour block of time (at a time of your choosing) where there are no obligations, no interruptions, no additional mounting workload, no meetings, no emails / calls / messages. Time stands still around you.

What would you do with that time, week after week?
Why would it make a difference… and for who?

The interview question tech recruiters will never ask, but should

Over the last few days, this blog has been diving into the career steps that OSS (and tech) specialists can make in readiness for the inevitable changes in employment dynamics that machine learning and AI will bring about.

You’ve heard all the stories about robots and AI taking all of our jobs. Any job that is repeatable and / or easy to learn will be automated. We’ve also seen that products are commoditising and many services are too, possibly because automation and globalisation is increasing the supply of both. Commoditisation means less profitability per unit to drive projects and salaries. We’ve already seen how this is impacting the traditional investors in OSS (eg CSPs).

Oh doom and gloom. So what do we do next?


That leads to my contrarian interview question. “So, tell me about your art.”

More importantly, using the comments section below, tell me about YOUR art. I’d love to hear your thoughts.

FWIW, here’s Seth Godin’s definition of art, which resonates with me, “Art isn’t only a painting. Art is anything that’s creative, passionate, and personal. And great art resonates with the viewer, not only with the creator.
What makes someone an artist? I don’t think it has anything to do with a paintbrush. There are painters who follow the numbers, or paint billboards, or work in a small village in China, painting reproductions. These folks, while swell people, aren’t artists. On the other hand, Charlie Chaplin was an artist, beyond a doubt. So is Jonathan Ive, who designed the iPod. You can be an artist who works with oil paints or marble, sure. But there are artists who work with numbers, business models, and customer conversations. Art is about intent and communication, not substances

If we paint our OSS by numbers (not with numbers), we’re more easily replaced. If we inspire with solutions that are unique, creative, passionate and personal, that’s harder for machines to replace.

Getting literate in the language of the future

As we all know, digitalisation of everything is decreasing barriers to entry and increasing the speed of change in almost every perceivable industry. Unfortunately, this probably also means the half-life of opportunity exploitation is also shrinking. The organisations that seem to be best at leveraging opportunities in the market are the ones that are able to identify and act the quickest.

They identify and act quickly… based on data. That’s why we hear about data-driven organisations and data-driven decision support. OSS collect enormous amounts of data every year. But it’s only those who can turn that information into action who are able to turn opportunities into outcomes.

Data is the language of the future (well today too of course), so literacy in that language will become increasingly important. I’m not expecting to become a highly competent data scientist any time soon, but I’m certainly not expecting to delegate completely to mathletes either.

The language of data is not just in the data sets, but also in the data processing techniques that will become increasingly important – regression, clustering, statistics, augmentation, pattern-matching, joining, etc. If you can’t speak the language, you can’t drive the change or ask the right questions to unearth the gems you’re seeking. Speaking the language allows you to take the tentative first steps towards machine learning and AI.

As a consultant, I see myself as a connector – of ideas, people, concepts, solutions – and I see OSS largely falling into the same category. But the consultancy, and/or OSS, skills of today will undoubtedly need to be augmented with connection of data too – connection of data sets, data analysis techniques, data models – to be able to prove consultancy hypotheses with real data. That’s where consultancy and OSS is going, so that’s where I need to go too.

Burning out

Information overload is happening at all career levels. Companies restructure, and current staff absorb additional responsibilities, requiring new skills to be learned. Technology changes, and new systems, tools and processes need to be mastered. Markets change, and new strategies or client prospects or industry sectors need to be researched. To be successful in today’s times you need to master not only the skills relevant to your own job, but also the skills of learning , adapting to change quickly, and sustainably dealing with change without burning out.”
Caroline Ceniza-Levine

Sounds like a day in the life of OSS doesn’t it?

I’m a huge fan of AFL. The game, like OSS, is getting increasingly sophisticated, faster and strategic. Despite this, there’s almost not a week that goes by without one of the top-Line coaches stating that it’s really a simple game. The truth of the matter is that it is not a simple game but the best coaches have a way of simplifying the objectives so that their players can function well within the chaos.

They train and strategise for the complexity but simplify the game-day messaging to players down to only 2-3 key indicators and themes [at least that’s what the coaches say in interviews, but I wouldn’t know for sure having not been a professional footballer].

On any given day on most of the OSS projects I’ve worked on, there is more chaos than clarity. A chaos of technologies, meetings, deadlines, deliverables, processes, designs, checklists, etc.

How often do we stop to run a pre-mortem before death by complexity has occurred?

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 obviously to me, 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.