Do we actually need less intellectual giants?

Have you ever noticed that almost every person who works in OSS is extremely clever?
No?

They may not know the stuff that you know or even talk in the same terminologies that you and your peers use, but chances are they also know lots of stuff that you don’t.

OSS sets a very high bar. I’ve been lucky enough to cross into many different industries as a consultant. I’d have to say that there are more geniuses per capita in OSS than in any other industry / sector I’ve worked in.

So why then are so many of our OSS a shambles?

Is it groupthink? Do we need more diversity of thinking? Do we actually need less intellectual giants to create pragmatic, mere-mortal solutions?

Our current approach appears to be flawed. Perhaps Project Platypus gives us on alternate framework?

Actually, I don’t think we need less intellectual giants. But I do think we need our intellectual giants to have a greater diversity of experiences.

My least successful project

Many years ago I worked on a three-way project with 1) a customer, 2) a well-known equipment vendor and 3) a service provider (my client). Time-frames were particularly tight, not so much because of the technical challenge, but because of the bureaucratic processes of the customer and the service provider. The project was worth well in excess of $100M, so it was a decent-sized project as part of a $1B+ program.

The customer had handed the responsibility of building a project schedule to the equipment vendor and I, which we duly performed. The Gantt chart was quite comprehensive, running into thousands of lines of activities and had many dependencies where actions by the customer were essential. These were standard dependencies such as access to their data centres, uplift to infrastructure, firewall burns, design approvals, and the list goes on. The customer had also just embarked on a whole-of-company switch of project management frameworks, so it wasn’t hard to see that related delays were likely.

The vendor and I met with the customer to walk through the project plan. About half-way in, the customer asked the vendor whether they were confident that timelines could be met. The vendor was happy to say yes. I was asked the same question. My response was that I was comfortable with the vendor’s part, I was comfortable with our part (ie the service provider’s), but that the customer’s dependencies were a risk because we’d had push-back from their Project Manager and each of the internal business units that we knew were impacted (not to mention the other ones that were likely to be impacted but we had no visibility of yet).

That didn’t go down well. I copped by far the biggest smashing of my career to date. The customer didn’t want to acknowledge that they had any involvement in the project – despite the fact that they were to approve it, house it, host it, use it and maintain aspects of it. It seemed like common sense that they would need to get involved.

Over the last couple of decades of delivery projects, one trend has been particularly clear – the customer gets back what they put in. That project had at least twelve PMs on the customer side over the 18 month duration of the project. It moved forward during stints under the PMs who got involved in internal solutioning, but stagnated during periods under PMs that just blame-stormed. Despite this, we ended up delivering, but the user outcomes weren’t great.

As my least successful project to date (hopefully ever), it was also one of my biggest “learnings” projects. For a start, it emphasised that I needed to get better at hearts and minds change management. There were many areas where better persuasion was required – from the timelines / dependencies to the compromised architecture / hardware that was thrust upon us by the customer’s architects. What seemed obvious to me was clearly not so obvious to the customer stakeholders I was trying to persuade.

You have to love being incompetent

You have to love being incompetent in order to be competent.”
James Altucher
.

Not sure that anyone loves feeling incompetent, but James’ quote is particularly relevant in the world of OSS. There are always so many changes underway that you’re constantly taken out of your comfort zone. But the question becomes how do you overcome those phases / areas of incompetence?

Earlier in my career, I had more of an opportunity to embed myself into any area of incompetence, usually spawned by a technical challenge being faced, and pick it up through a combination of practical and theoretical research. That’s a little harder these days with less hands-on and more management responsibilities, not to mention more demands on time outside hours.

In a way, it’s a bit like stepping up the layers of TMN management pyramid.
TMN Pyramid
Image courtesy of www.researchgate.net.

With each step up, the context gets broader (eg more domains under management), but more abstracted from what’s happening in the network. Each subsequent step northbound does the same thing:

  • It abstracts – it only performs a sub-set of the lower layer’s functionality
  • It connects – it performs the task of connecting and managing a larger number of network elements than the lower layer

Conversely, each step down the management stack should produce a narrower (ie not so many device interconnections), but deeper field of view (ie a deeper level of information about the fewer devices).

The challenge of OSS is in choosing where to focus curiosity and improvements – diving down the stack into new tech or looking up and sidewards?

The mafia… Pressure? What pressure?

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

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

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

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

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

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

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

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

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

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

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

What’s the next tool in your toolbelt?

As OSS exponents, I’m sure you’ll agree that there are many OSS tools / skills that we use and develop (to differing degrees) over the years.

In fact, there are so many to choose from that we often have to make a conscious decision which ones to master and which ones to leave for others to master. Other times we have the decision thrust upon us.

When you have the chance to decide, do you choose from a perspective of craft or value?

Choosing by craft is analogous to already having a toolbelt with a hammer, a screwdriver and a glue gun, then choosing a nail-gun as the next tool to learn. They all fall into the same category of fasteners. They make you more proficient at choosing the right fastener for the job, but adding more to the list is unlikely to significantly increase the hourly rate a customer or employer will pay for your services. Whilst you’re more skilled, there are still a lot of others out there who can use fasteners. In fact, it can arguably be said that I can even use a few of those tools. They’re not really differentiators for you or your customer / employer.

Choosing by value, to extend on the analogy, is to add expertise as a builder, surveyor, draftsman, architect, etc in addition to the fastener skills you already have. They might be harder to attain, but that’s what increases differentiation. They’re perceived to be more valuable because they are perceived to play a more exclusive part in the final product that’s being offered to customers.

In OSS, if you can already program in five languages, does taking the time to learn a sixth significantly add value (to you or your value chain)? Sometimes perhaps. But if you were to spend the same amount of time to become more proficient at infrastructure or networks or team leadership, etc I suspect your contribution to the value fabric (ie customers, your team, etc) would increase far more… even if it didn’t immediately translate to a higher hourly rate.

The most invaluable people I’ve worked alongside in OSS, the valuable tripods, are proficient across many of OSS‘s domains and can link silos of expertise together. But that’s certainly not to devalue the importance of the craftspeople, as it’s their continued search for excellence that strengthens the silos, the foundations of OSS.

When you next have the chance to decide, will you choose from a perspective of craft or value?

Can you define why OSS projects are so challenging?

Answer. Change creates incompetence.

Whether on the vendor/integrator side, the customer side or along the strategic advisor line, OSS projects bring about constant change; massive change.

I’ve often wondered why I can feel so incompetent in the world of OSS, even though I know more about it than (probably) any other topic.

The answer has just dawned on me, as per above – change creates incompetence. There is so much change happening on so many levels within OSS that every one of us is a freshly-minted incompetent, no matter how much prior competence we may’ve built up.

And this defines the double-edged sword of OSS. The pain of feeling incompetent drives the thirst for learning / evolution.

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?

Art!

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

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

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.