OSS is an industry that’s undergoing constant, and massive change. But it still hasn’t been disrupted in the modern sense of that term. It’s still waiting to have its Uber/AirBnB-moment, where the old way becomes almost obsoleted by the introduction of a new way. OSS is not just waiting, but primed for disruption.
It’s a massive industry in terms of revenues, but it’s still far from delivering everything that customers want/need. It’s potentially even holding back the large-scale service provider industry from being even more influential / efficient in the current digital communications world. Our recent OSS Call for Innovation spelled out the challenges and opportunities in detail.
Today we’ll talk about the two types of disruptive technologists – one that assists change and one that hinders.
The first disruptive technologist is a rare beast – they’re the innovators who create solutions that are distinctly different from anything else in the market, changing the market (for the better) in the process. As discussed in this recent post, most of the significant changes occurring to OSS have been extrinsic (from adjacent industries like IT or networking rather than OSS). We need more of these.
The second disruptive technologist is all too common – they’re the technologists whose actions disrupt an OSS implementation. They’re usually well-intended, but can get in the way of innovation in two main ways:
1) By not looking beyond incremental change to existing solutions
2) Halting momentum by creating and resolving a million “what if?” scenarios
Most of us probably fall into the second category more often than the first. We need to reverse that trend individually and collectively though don’t we?
Would you like to nominate someone who stands out as being the first type of disruptive technologist and why?
The exposure effect (no, not the one circulating through Hollywood) has a few interesting implications for OSS.
“The mere-exposure effect is a psychological phenomenon by which people tend to develop a preference for things merely because they are familiar with them.” Wikipedia
In effect, it’s the repetition that drills familiarity, comfort, but also bias, into our sub-conscious. Repetition doesn’t make a piece of information true, but it can make us believe it’s true.
Many OSS experts are exposed to particular vendors/products for a number of years during their careers, and in doing so, the exposure effect can build. It can have a subtle bias on vendor selection, whereby the evaluators choose the solution/s they know ahead of the best-fit solution for their organisation. Perhaps having independent vendor selection facilitators who are familiar with many products can help to reduce this bias?
The exposure effect can also appear through sales and marketing efforts. By regularly contacting customers and repetitively promoting their wares, the customer builds a familiarity with the product. In theory it works for OSS products as it does with beer commercials. This can work for or against, depending on the situation.
In the case for, it can help to build a guiding coalition to get a complex, internal OSS project approved and supported through the challenging times that await every OSS project. I’d even go so far as to say, “you should use it to help build a guiding coalition,” rather than, “you can use it to help build a guiding coalition.” Never underestimate the importance of organisational change management on an OSS project.
In the case against, it can again develop a bias towards vendors / products that aren’t best-fit for the organisation. Similarly, if a “best-fit” product doesn’t take the time to develop repetition, they may never even get considered in a selection process, as highlighted in the diagram below.
Along similar analytical lines, there’s a structural shift underway in traditional business consulting, as described in a recent post contrasting “clean” and “dirty” consulting. There’s an increasing skepticism in traditional “gut-feel” or “set-and-forget” (aka clean) consulting and a greater client trust in hard data / analytics and end-to-end implementation (dirty consulting).
Clients have less need for consultants that just turn the ignition and lay out sketchy directions, but increasingly need ones that can help driving the car all the way to their desired destination.
Consultants capable of meeting these needs for the telco / service provider industries have:
Extensive coal-face (delivery) experience, seeing and learning from real success and failure situations / scenarios
An ability to use technology to manage, interpret and visualise real data in a client’s data stores, not just industry trend data
An ability to build repeatable frameworks (including the development of smart contracts)
Have you noticed that the four key features above are perfectly aligned with having worked in OSS? OSS/BSS data stores contain information that’s relevant to all parts of a telco / service provider business. That makes us perfectly suited to being the high-value consultants of the future, not just contractors into operations business units.
Few consultancy tasks are productisable today, but as technology continues to advance, traditional consulting roles will increasingly be replaced by IP (Intellectual Property) frameworks, data analytics, automations and tools… as long as the technology provides real business benefit.
“There’s some things that I’ve challenged my team to do. We have to be faster than the web scale players and that sounds audacious. I tell them you can’t you can’t go to the bus station and catch a bus that’s already left the station by getting on a bus. We have to be faster than the people that we want to get to. And that sounds like an insane goal but that’s one of the goals we have. We have to speed up to catch the web scale players.”
John Donovan, AT&T at this link.
Last week saw a series of articles appear here on the PAOSS blog around the accumulation of tech-debt and how microservices / Agile had the potential to accelerate that accumulation.
The part that I find most interesting about this new approach to telco (or more to the point, to the Digital Service Provider (DSP) model) is that it speaks of a shift to being software companies like the OTT players. Most telcos are definitely “digital” companies, but very few could be called “software” companies.
All telcos have developers on their payroll but how many would have software roles filling more than 5% of their workforce? How many would list their developer pools amongst a handful of core strengths? I’d hazard a guess that the roots of most telcos’ core strengths would’ve been formed decades ago.
Software-centric networks are on the rise. Rapid implementation models like DevOps and Agile are on the rise. API / Microservice interfaces to network domains (irrespective of being VNF, PNF, etc) are on the rise. Software, software, software.
In response, telcos are talking software. Talking, but how many are doing?
Organic transition of the workforce (ie boomers out, millennials in) isn’t going to refresh fast enough. Are telcos actively re-inventing their resource pool? Are they re-skilling on a grand scale, often tens of thousands of people, to cater for a future mode of operation where software is a core capability like it is at the OTT players? Re-skilling at a speed that’s faster than the web-scale bus?
If they can’t, or don’t, then perhaps software is not really the focus. Software isn’t their differentiator… they do have many other strengths to work with after all.
If so then OSS, microservices, SDN / NFV, DevOps, etc are key operational requirements without being core differentiators. So therefore should they all be outsourced to trusted partners / vendors / integrators (rather than the current insourcing trend), thus delegating the responsibility for curating the tech-debt we spoke about last week?
I’m biased. I see OSS as a core differentiator (if done well), but few agree with me.
Have you ever noticed that the biographies of almost every successful person contains the chapter(s) where everything goes disastrously? It seems inevitable that there are periods in our careers where things don’t go right, no matter how successful you are.
Interestingly my least successful project was also one that had only a very small OSS component to it. It was one of the triggers to starting PAOSS.com. PAOSS was a way to remain connected to OSS outside the demands of that day job.
That project may’ve been less successful, but it certainly wasn’t short on handing me lessons. It wasn’t the lack of OSS in that day job that made it less successful. I’ve done other telco projects that have given very different, valuable insights on OSS without being directly related to OSS.
I’ve recently had a number of job offers that have looked quite exciting. They’ve made me re-think whether I’d be better at my “art” (with PAOSS as the vehicle) if it wasn’t also my main career arc.
Derek Sivers has an interesting take on this here, “Do something for love, and something for money. Don’t try to make one thing satisfy your entire life. In practice, then, each half of your life becomes a remedy for the other. You get paid and get stability for part of your day, but then need creative time for expression.”
Contrary to Derek’s suggestion, do you combine your art with your job? If OSS is your job, what is your art?
My wife and I attended a Christmas party over the weekend and on the trip home we discussed customer service. In particular we were discussing the customer service training she’d had, as well as the culture of customer service reinforcement she’d experienced via leaders and peers in her industry. She doesn’t work in ICT or OSS (obviously?).
In our industry, we talk the customer experience talk via metrics like NPS (Net Promoter Score). However, I don’t recall ever working with a company that provided customer service training or had a strong culture of reinforcing customer service behaviours. Some might claim that it’s just an unwritten rule / expectation.
Conversely, some players in our industry go the opposite way and appear to have the mentality of trying to screw over their customers. Their customers know it and don’t like it but are locked in for any number of reasons.
As OSS implementers, the more consistent trend seems to be a culture of technical perfection. I know I’ve dropped the ball on customer service in the past by putting the technical solution ahead of the customer. I feel bad about that on reflection.
Perhaps what we don’t realise is that we’re missing out on an unfair advantage.
As Seth Godin states in this blog, “Here’s a sign I’ve never seen hanging in a corporate office, a mechanic’s garage or a politician’s headquarters: WE HAVE AN UNFAIR ADVANTAGE:
We care more.
It’s easy to promise and difficult to do. But if you did it, it would work. More than any other skill or attitude, this is what keeps me (and people like me) coming back.”
Could it be a real differentiator in our fragmented market?
Since reading the first book on this list, I’ve become a very avid and wide-ranging reader. The seeds sown by the book list below have immensely helped enrich the content you see here on the PAOSS blog and other PAOSS content.
You’ll begin to notice a very curious thing about this list though. There are only two books in the entire list that are actually about OSS. I have many OSS books in my library, but most struggle for relevance beyond the author’s frame of reference – they have been written from the specific technical experiences of the author, which are rarely transferable to other OSS. Either the technologies are now out of date and/or the details / terminologies were pertinent only to that OSS time and place. It’s one of the reasons that PAOSS content is specifically intended to abstract from technology and deliver insights, methodologies, processes and frameworks that have a broader relevance and greater longevity (hopefully).
The remaining books in the list have not been written with OSS in mind but definitely provide insights and perspectives that are transferable to the challenges we face in the OSS industry. In no particular order (except the first being the first…)
Rich Dad, Poor Dad
by Sharon L. Lechter Robert T. Kiyosaki
This was the book that changed it all for me. Whilst its intent is to educate on personal finance, the effect it had was to lift my eyes beyond the purely technical. Like 95%+ of people in our industry, I had previously only ever focused on delivering the best technical solution I could with the assumption that this would deliver a great customer outcome. I now know that the challenges we face are far bigger than that!
Insanely Simple: The Obsession That Drives Apple’s Success
by Ken Segall
The greatest OSS (but non-OSS) book I’ve read. The first half of this book in particular delivers powerful examples of simplification at all levels of an organisation as experienced by an advertising executive working alongside Steve Jobs at Apple. The OSS and communications industry need more people who are able to wield the simple stick like Steve did.
by Jason Fried, David Heinemeier Hansson
These gentlemen have built a strong business around the Basecamp project management suite of tools. In Rework, just like their blog at 37signals, they provide brilliant contrarian insights into how to run a software business… Or any business for that matter. Efficiency and simplicity are the mantra ahead of the Red-Bull fuelled heroics spouted by many organisations in the software industry. One of my all-time favourite business books.
Enchantment: The Art of Changing Hearts, Minds, and Actions
by Guy Kawasaki
Guy defines enchantment as, “the process of delighting people with a product, service, organisation or idea. The outcome of enchantment is voluntary and long-lasting support that is mutually beneficial.” If there was ever an industry that was in need of enchantment, it is the OSS industry right now.
Rain: What a Paperboy Learned About Business
by Jeffrey J. Fox
An easy to digest story about a boy with a paper-route learning the key tenets of rainmaking, the ability to delight customers and make sales (and projects) happen.
Killing Giants: 10 Strategies to Topple the Goliath in Your Industry
by Stephen Denny
There are a number of goliath incumbents in our industry. However, I suspect that most of the required disruption is coming from the Davids of our industry, despite the burning platforms at the goliaths. Interesting reading for a different perspective on innovation and change.
Anything You Want: 40 Lessons for a New Kind of Entrepreneur
by Derek Sivers
Derek Sivers was a professional musician before starting his own business, one that helped sell the CDs of the long tail of the music industry, musicians overlooked by the big labels. This might sound barely relevant to the OSS industry but there is an uncommon clarity in the way that Sivers views businesses, customers and delivery. Many of his thoughts really struck a chord with me (bad pun intended).
Principles: Life and Work
by Ray Dalio
Built around the principles that Ray Dalio codified at his company, Bridgewater Associates. Many of his principles of team and culture seem like common sense, but helpfully compiled into a single volume. Not all OSS teams have these principles mastered.
by John P. Kotter
OSS projects are challenging to implement. Through harsh experience, I’ve learnt that even technically perfect implementations are prone to fail if the organisational change effort hasn’t been managed well. Whilst there are newer change management methodologies available, I still find that Kotter’s 8 steps provide a valuable framework for building OSS change management strategies around.
Endless Referrals: Network Your Everyday Contacts into Sales
by Bob Burg
In the early days of my career, I’d gone from one project to the next, with my head down focusing on delivery. This book opened my eyes to the value of staying in touch with past colleagues and adding value to my network. The results have surprised me so I recommend this book’s teachings to anyone who is purely tech-focused.
The Idea Factory: Bell Labs and the Great Age of American Innovation
by Jon Gertner
Put simply, this is probably the most inspiring book I’ve read in relation to the communications industry. The groundbreaking innovations (including OSS) that were developed within R&D powerhouses like Bell Labs during the 1900’s are staggering and something that we can barely even aspire to today. It’s no coincidence that the OSS Call for Innovation references this book
Linchpin: Are You Indispensable?
by Seth Godin
A call to action to become a linchpin, someone who delivers in territory where there is no map / rule-book, someone who inspires those around them. OSS needs more linchpins.
Dangerous Company: Consulting Powerhouses and the Companies They Save and Ruin
by Charles Madigan and James O’Shea
This book provides some insights into the best and worst of management consulting. It is a little old now, dating back to the late 1990’s but it had a significant impact on me when I read it in the 2010’s. It describes some of the unscrupulous acts / tactics / results that have lead to the poor reputation that consulting has in some circles. It also reinforced a strong belief I’ve always had in doing right by the client before the firm because building reputation and integrity ultimately benefits the firm anyway.
Made to Stick: Why Some Ideas Survive and Others Die
by Chip Heath, Dan Heath
The term “stickiness” was popularised by Malcolm Gladwell in “The Tipping Point.” This book borrows the term and looks to explain why an idea or concept remains sticky. OSS tend to be so sticky, in many cases to the detriment of the customer experience, but our industry is also in desperate need for powerfully sticky new ideas and approaches.
Purple Cow, New Edition: Transform Your Business by Being Remarkable
by Seth Godin
In a cluttered or fragmented marketplace, like OSS, it is difficult to stand out from all other suppliers. Seth Godin introduces the concept of the purple cow – when you’re on a long trip in the countryside, seeing lots of brown or black cows soon gets boring, but if you saw a purple cow, you’d immediately take notice. This book provides the impetus to make your products stand out and drive word of mouth rather than having to differentiate via your marketing.
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich
by Timothy Ferriss
Starts off strongly but drops away rapidly in the second half IMHO. The words of a friend of mine aptly paraphrase what Tim Ferris talks about in this book, “Only do what only you can do.” Prioritise your efforts on what make you truly unique and use other efficiency tools and/or engage others to do the rest
Mastering your OSS: Operational Support System Implementation Tips and Techniques
by Ryan Jeffery
This is the best OSS book that I’ve written (so far), but with new material in the pipeline, watch this space for even better publications. It provides the frameworks, processes, insights and recommendations that will help guide you through the myriad of challenges, technical or otherwise, that you will face in the world of OSS.
Power Listening: Mastering the Most Critical Business Skill of All
by Bernard T. Ferrari
Bernard Ferrari advises the use of the Pareto Principle to listening. In other words, spending 80% of the time listening and only 20% talking. It’s such an important trait for all technical resources, yet perhaps somewhat uncommon unfortunately. As the “hired gun,” there is a tendency to start firing from both barrels verbally as soon as you meet with the customer. But the most insightful insights are the ones that are understandable to the customer. They have to be relevant in terminology, desired outcomes, roles/responsibilities, respective capabilities, etc, etc. You only get that context from Power Listening.
The Click Moment: Seizing Opportunity in an Unpredictable World
by Frans Johansson
Johansson also introduces the concept of the “smallest executable step” as a mechanism for harnessing the apparent randomness of our modern, rapidly changing world. He suggests that we make many small bets rather than one massive bet as a means of improving success rates. OSS are complex systems so any small deviation makes predictions of completion time, resources and cost difficult. As implementers, it’s our job to remove as much complexity as possible
Harder Than I Thought: Adventures of a Twenty-First Century Leader
by Robert D. Austin, Richard L. Nolan
More than anything else, one paragraph has stuck with me from this guide to project change leadership, “….once you start a company transformation, it’s like a stampede. If you try to lead from the front, you get trampled; if you try to lead from the back, you have no impact. Best to lead from the side by carefully nudging and turning the stampede to avoid everyone going over the cliff.”
Have you ever experienced an event where you realised that you’d spent the previous 10+ years doing something wrong (or at least incomplete)?
I had one such experience last Friday during a presentation by Roger Gibson, a Partner at Infosys Consulting.
Now you all know that I’m a passionate spruiker of change management on OSS projects, mainly because one of the biggest reasons for OSS failure is the lack of CM. You may’ve even noticed a recent article here on PAOSS relating to the techniques we can use to influence change.
My entirely random guess is that about 95% of people in OSS focus primarily on the technical aspects of what’s being implemented, leaving only 5% who’ve grasped the significance of influencing change. My lightbulb moment on Friday came in realising that there’s actually also a 1% group (to be honest, it’s probably far less than 1%).
As an external consultant on most projects, I’ve generally figured that client representatives have far greater tenure and more ability to influence change within their organisation than me. My modus operandi has been to create change strategies and persuade the project team (plus key stakeholders) to start change initiatives as early as possible.
In effect, I’ve been delegating change responsibility. l now realise that’s not going far enough. It is MY responsibility to light the fire under every project I work on – to initiate the chain reaction.
Do you agree that it’s also YOUR responsibility to light the fire under every project you work on?
To quote Wayne Dyer, “It’s never crowded along the extra mile.”
Have you ever noticed that almost every person who works in OSS is extremely clever?
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?
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 in order to be competent.”
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.
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.
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?
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.
“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.
That’s what fast-growing, important organizations do.
Making stuff is great.
Making connections is even better.”
Seth Godinin 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.
“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 Hanssonhere 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.
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?
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).
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.
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.