Training network engineers to code, not vice versa

Did any of you read the Light Reading link in yesterday’s post about Google creating automated network operations services? If you haven’t, it’s well worth a read.

If you did, then you may’ve also noticed a reference to Finland’s Elisa selling its automation smarts to other telcos. This is another interesting business model disruption for the OSS market, although I’ll reserve judgement on how disruptive it will be until Elisa sells to a few more operators.

What did catch my eye in the Elisa article (again by Light Reading’s Iain Morris), is this paragraph:
Automation has not been hassle-free for Elisa. Instilling a software culture throughout the organization has been a challenge, acknowledges [Kirsi] Valtari. Rather than recruiting software expertise, Elisa concentrated on retraining the people it already had. During internal training courses, network engineers have been taught to code in Python, a popular programming language, and to write algorithms for a self-optimizing network (or SON). “The idea was to get engineers who were previously doing manual optimization to think about automating it,” says Valtari. “These people understand network problems and so it is a win-win outcome to go down this route.”.

It provides a really interesting perspective on this diagram below (from a 2014 post about the ideal skill-set for the future of networking)

There is an undoubted increase in the level of network / IT overlap (eg SDN). Most operators appear to be taking the path of hiring for IT and hoping they’ll grow to understand networks. Elisa is going the opposite way and training their network engineers to code.

With either path, if they then train their multi-talented engineers to understand the business (the red intersect), then they’ll have OSS experts on their hands right folks?? 😉

Assuming the other person can’t come up with the answer

Just a quick word of warning. This blog starts off away from OSS, but please persevere. It ends up back with a couple of key OSS learnings.

Long ago in the technology consulting game, I came to an important realisation. When arriving on a fresh new client site, chances are that many of the “easy technical solutions” that pop into my head to solve the client’s situation have already been tried by the client. After all, the client is almost always staffed with clever people, but they also know the local context far better than me.

Alan Weiss captures the sentiment brilliantly in the quote below.
I’ve found that in many instances a client will solve his or her own problem by talking it through while I simply listen. I may be asked to reaffirm or validate the wisdom of the solution, but the other person has engaged in some nifty self-therapy in the meantime.
I’m often told that I’m an excellent problem solver in these discussions! But all I’ve really done is listen without interrupting or even trying to interpret.
Here are the keys:
• Never feel that you’re not valuable if you’re not actively contributing.
• Practice “active listening”.
• Never cut-off or interrupt the other person.
• Stop trying to prove how smart you are.
• Stop assuming the other person can’t come up with the answer
.”

I’m male and an Engineer, so some might say I’m predisposed to immediately jumping into problem solving mode before fully understanding a situation… I have to admit that I do have to fight really hard to resist this urge (and sometimes don’t succeed). But enough about stereotypes.

One of the techniques that I’ve found to be more successful is to pose investigative questions rather than posing “brilliant” answers. If any gaps are appearing, then provide bridging connections (ie through broader industry trends, ideas, people, process, technology, contract, etc) that supplement the answers the client already has. These bridges might be built in the form of statements, but often it’s just through leading questions that allow the client to resolve / affirm for themselves.

But as promised earlier, this is more an OSS blog than a consulting one, so there is an OSS call-out.

You’ll notice in the first paragraph that I wrote “easy technical solutions,” rather than “easy solutions.” In almost all cases, the client representatives have great coverage of the technical side of the problems. They know their technology well, they’ve already tried (or thought about) many of the technology alternatives.

However, the gaps I’ve found to be surprisingly common aren’t related to technology at all. A Toyota five-why analysis shows they’re factors like organisational change management, executive buy-in, change controls, availability of skilled resources, requirement / objective mis-matches, stakeholder management, etc, as described in this recent post.

It’s not coincidence then that the blog roll here on PAOSS often looks beyond the technology of OSS.

If you’re an OSS problem solver, three messages:
1) Stop assuming the other person (client, colleague, etc) can’t come up with the answer
2) Broaden your vision to see beyond the technology solution
3) Get great at asking questions (if you aren’t already of course)

Does this align or conflict with your experiences?

When your ideas get stolen

When your ideas get stolen.
A few meditations from Seth Godin:
“Good for you. Isn’t it better that your ideas are worth stealing? What would happen if you worked all that time, created that book or that movie or that concept and no one wanted to riff on it, expand it or run with it? Would that be better?
You’re not going to run out of ideas. In fact, the more people grab your ideas and make magic with them, the more of a vacuum is sitting in your outbox, which means you will prompted to come up with even more ideas, right?
Ideas that spread win. They enrich our culture, create connection and improve our lives. Isn’t that why you created your idea in the first place?
The goal isn’t credit. The goal is change.”

A friend of mine has lots of great ideas. Enough to write a really valuable blog. Unfortunately he’s terrified that someone else will steal those ideas. In the meantime, he’s missing out on building a really important personal brand for himself. Do you know anyone like him?

The great thing about writing a daily blog is that it forces you to generate lots of ideas. It forces you to be constantly thinking about your subject matter and how it relates to the world. Putting them out there in the hope that others want to run with them, in the hope that they spread. In the hope that others will expand upon them and make them more powerful, teaching you along the way. At over 2000 posts now, it’s been an immensely enriching experience for me anyway. As Seth states, the goal is definitely change and we can all agree that OSS is in desperate need for change.

It is incumbent on all of us in the OSS industry to come up with a constant stream of ideas – big and small. That’s what we tend to do on a daily basis right? Do yours tend towards the smaller end of the scale, to resolve daily delivery tasks or the larger end of the scale, to solve the industry’s biggest problems?

Of your biggest ideas, how do you get them out into the world for others to riff on? How many of your ideas have been stolen and made a real difference?

If someone rips off your ideas, it’s a badge of honour and you know that you’ll always generate more…unless you don’t let your idea machine run.

Drinking from the OSS firehose

Most people know what they want, but don’t know how to get it. When you don’t know the next step, you procrastinate or feel lost. But a little research can turn a vague desire into specific actions.
For example: When musicians say, “I need a booking agent”, I ask, “Which one? What’s their name?”
You can’t act on a vague desire. But with an hour of research you could find the names of ten booking agents that work with ten artists you admire. Then you’ve got a list of the next ten people you need to contact.
A life coach told me that most of his job is just helping people get specific. Once they turn a vague goal into a list of specific steps, it’s easy to take action
.”
Derek Sivers
in his blog, “Get Specific!

In a post last week, I spoke about feeling like never before that I’m at an OSS cross-road, looking towards a set of paths. The paths all contribute heavily to the next-generations of OSS, but there’s the feeling of dread that no one person will have the ability to step out each path. The paths I’m talking about include network virtualisation, data-science / artificial-intelligence / machine-learning, open-source deployments like ONAP, cloud infrastructure and delivery models, and so many more. Each represents a life’s work to become a fully-fledged expert.

In the past, a single OSS polymath could potentially scramble along a majority of the paths and understand the terrain within their local OSS environment. But that’s becoming increasingly less likely as we become ever more dependent upon the interconnection of disparate expertise.

This represents a growing risk. If nobody understands the whole terrain, how do we map out Derek’s “list of specific steps” on our complex OSS projects? If we can’t adequately break down the work, we’re at risk of running projects as a set of vague, disjointed activities. So I imagine you’re wondering how we do “Get Specific!”?

Most technology experts appear to me to have a predilection to plan projects from the bottom up (ie building up a solution from their detailed understanding of some parts of the project). However, on projects as complex as OSS, I’ve never seen a bottom-up plan come together efficiently. Nobody knows enough of the details to build up the entire plan.

Instead, I prefer the top-down approach of building a WBS (work breakdown structure), progressively diving deeper into the details and turning the vague goal into a tree of ever more specific steps. I consider the ability to break down complex projects into manageable chunks of work as my only real super-power, but in reality it largely just comes from using the WBS approach.

Okay, it might sound a bit like a waterfall model (depends on how you design the tree really), but it beats the “trying to drink from a firehose” alternative model.

Which approach works best for you?

The answer is soooo obvious…. or is it?

There’s a crowded room of OSS experts, a room filled with serious intellectual horsepower. You might be a virtu-OSS-o, but you surely know that there’s still so much to be learnt from those around you. You have the chance to unlock the experiences and insights of your esteemed colleagues. But how? The answer might seem to be obvious. You do so by asking questions. Lots of questions.

But that obvious answer might have just one little unexpected twist.

Do you ask:

  1. Ego questions – questions that demonstrate how clever you are (and thus prove to the other experts that you too are an expert); OR
  2. Embarrassing questions – questions that could potentially embarrass you (and demonstrate major deficiencies in your knowledge, perhaps suggesting that you’re not as much of as expert as everyone else)

I’ve been in those rooms and heard the questions, as you have too no doubt. What do you think the ratio of ego to embarrassing would typically be? 10 to 1? 20 to 1?

The problem with the ego questions is that they can be so specific to the context of a few that they end up steering the conversations to the depths of technology hell (of course they can also end up inspiring / enlightening too, so I’m generalising here).

But have you observed that the very best in our industry happen to ask a lot of embarrassing  questions?

A quote by Ramit Sethi splices in brilliantly here, “The very best ask lots of questions. 3 questions I almost never hear: (1) “Just a second. If you don’t mind me asking, how did you get to that?” (2) “I’m not sure I understand the conclusion — can you walk me through that?” (3) “How did you see that answer?” Ask these questions and stop worrying about being embarrassed. How else are you going to learn?

Just for laughs, next time you’re at one of these events (and I notice that TM Forum Live is coming up in May), try to guess what the ego to embarrassing ratio might be there and which set of questions are spawning the more interesting / insightful / helpful conversations.

We all want to develop trusted OSS partnerships, so why does so much scepticism exist?

Every OSS supplier wants to achieve “trusted” status with their customers. Each supplier wants to be the source trusted to provide the best vision of the future for each customer.

I’m an independent consultant, so I have been lucky enough to represent many organisations on both sides of that equation. And in that position, I’ve been able to get a first-hand view of the perception of trust between OSS vendors / integrators (suppliers) and operators (customers). Let’s just say that in general, we’re working in an industry with more scepticism than trust.

So if trust is so important and such a desired status, where is it breaking down?

Whilst I’d like to assume that most people in our industry go into OSS projects with the very best of intentions, there are definitely some suppliers that try to trick and entrap their customers whilst acting in an untrustworthy way. For the rest of this post, I’m going to assume the best – assume that we all have great intentions. We then look at why the trust relationships might be breaking down and some of the ways we can do better.

Jon Gordon provides a great list of 11 ways to build trust. Check out his link for a more detailed view, but the 11 factors are as follows:

  1. Say what you are going to do and then do what you say!
  2. Communicate, communicate, communicate
  3. Trust is built one day, one interaction at a time, and yet it can be lost in a moment because of one poor decision
  4. Value long term relationships more than short term success
  5. Sell without selling out. Focus more on your core principles and customer loyalty than short term commissions and profits.
  6. Trust generates commitment; commitment fosters teamwork; and teamwork delivers results.
  7. Be honest!
  8. Become a coach. Coach your customers. Coach your team at work
  9. Show people you care about them
  10. Always do the right thing. We trust those who live, walk and work with integrity.
  11. When you don’t do the right thing, admit it. Be transparent, authentic and willing to share your mistakes and faults

They all sound quite obvious don’t they? Do you also notice that many of the 11 (eg communication, transparency, admitting failure, doing what you say, etc) can be really easy to say but harder to do flawlessly under the pressure of complex OSS delivery projects (and ongoing operations)?

I know I certainly can’t claim a perfect track record on all of  these items. Numbers 1 and 2 can be particularly difficult when under extreme delivery pressure, especially when things just aren’t going to plan technically and you’re focussing attention on regaining control of the situation. In those situations, communication and transparency are what the customer needs to maintain confidence, but the customer relationship takes time that also needs to be allocated to overcoming the technical challenges. It becomes a balancing act.

So, how do we position ourselves to make it easier to keep to these 11 best intentions? Simple. By making a concerted effort to reduce complexity… actually not so simple as it sounds, but rewarding if you can achieve it. The less complex your delivery projects (or operational models), the more repeatable and reliable a supplier’s OSS delivery becomes. The more reliable, the less friction and a reduced chance of fracturing relationships. Subsequently, the more chance of building and retaining trust.

Hat-tip to Robert Curran of Aria Networks for spawning a discussion about trust.

Dan Pink’s 6 critical OSS senses

I recently wrote an article that spoke about the obsolescence of jobs in OSS, particularly as a result of Artificial Intelligence.

But an article by someone much more knowledgeable about AI than me, Rodney Brooks, had this to say, “We are surrounded by hysteria about the future of artificial intelligence and robotics — hysteria about how powerful they will become, how quickly, and what they will do to jobs.” He then describes The Seven Deadly Sins of AI Predictions here.

Back into my box I go, tail between my legs! Nonetheless, the premise of my article still holds true. The world of OSS is changing quickly and we’re constantly developing new automations, so our roles will inevitably change. My article also proposed some ideas on how to best plan our own adaptation.

That got me thinking… Many people in OSS are “left-brain” dominant right? But left-brained jobs (ie repeatable, predictable, algorithmic) can be more easily out-sourced or automated, thus making them more prone to obsolescence. That concept reminded me of Daniel Pink’s premise in A Whole New Mind where right-brained skills become more valuable so this is where our training should be focused. He argues that we’re on the cusp of a new era that will favor “conceptual” thinkers like artists, inventors and storytellers. [and OSS consultants??]

He also implores us to enhance six critical senses, namely:

  • Design – the ability to create something that’s emotionally and/or visually engaging
  • Story – to create a compelling and persuasive narrative
  • Symphony – the ability to synthesise new insights, particularly from seeing the big picture
  • Empathy – the ability to understand and care for others
  • Play – to create a culture of games, humour and play, and
  • Meaning – to find a purpose that will provide an almost spiritual fulfillment.

I must admit that I hadn’t previously thought about adding these factors to my development plan. Had you?
Do you agree with Dan Pink or will you continue to opt for left-brain skills / knowledge enhancement?

Finding the most important problems to solve

The problem with OSS is that there are too many problems. We don’t have to look too hard to find a problem that needs solving.

An inter-related issue is that we’re (almost always) constrained by resources and aren’t able to solve every problem we find. I have a theory – As much as you are skilled at solving OSS problems, it’s actually your skill at deciding which problem to solve that’s more important.

With continuous release methodologies gaining favour, it’s easy to prioritise on the most urgent or easiest problems to solve. But what if we were to apply the Warren Buffett 20 punch-card approach to tackling OSS problems?

I could improve your ultimate financial welfare by giving you a ticket with only twenty slots in it so that you had twenty punches – representing all the investments that you got to make in a lifetime. And once you’d punched through the card, you couldn’t make any more investments at all. Under those rules, you’d really think carefully about what you did, and you’d be forced to load up on what you’d really thought about. So you’d do so much better.”
Warren Buffett
.

I’m going through this exact dilemma at the moment – am I so busy giving attention to the obvious problems that I’m not allowing enough time to discover the most important ones? I figure that anyone can see and get caught up in the noise of the obvious problems, but only a rare few can listen through it…

I’m predicting the demise of the OSS horse

“What will telcos do about the 30% of workers AI is going to displace?”
Dawn Bushaus

That question, which is the headline of Dawn’s article on TM Forum’s Inform platform, struck me as being quite profound.

As an aside, I’m not interested in the number – the 30% – because I concur with Tom Goodwin’s sentiments on LinkedIn, “There is a lot of nonsense about AI.
Next time someone says “x% of businesses will be using AI by 2020” or “AI will be worth $xxxBn by 2025” or any of those other generic crapspeak comments, know that this means nothing.
AI is a VERY broad area within computer science that includes about 6-8 very different strands of work. It spans robotics, image recognition, machine learning, natural language processing, speech recognition and far more. Nobody agrees on what is and isn’t in this.
This means it covers everything from superintelligence to artificial creativity to chatbots
.”

For the purpose of this article, let’s just say that in 5 years AI will replace a percentage of jobs that we in tech / telco / OSS are currently doing. I know at least a few telcos that have created updated operating plans built around a headcount reduction much greater than the 30% mentioned in Dawn’s article. This is despite the touchpoint explosion and increased complexity that is already beginning to crash down onto us and will continue apace over the next 5 years.

Now, assuming you expect to still be working in 5 years time and are worried that your role might be in the disappearing 30% (or whatever percentage), what do you do now?

First, figure out what the modern equivalents of the horse are in the context of Warren Buffett’s quote below:

“What you really should have done in 1905 or so, when you saw what was going to happen with the auto is you should have gone short horses. There were 20 million horses in 1900 and there’s about 4 million now. So it’s easy to figure out the losers, the loser is the horse. But the winner is the auto overall. [Yet] 2000 companies (carmakers) just about failed.”

It seems impossible to predict how AI (all strands) might disrupt tech / telco / OSS in the next 5 years – and like the auto industry, more impossible to predict the winners (the technologies, the companies, the roles). However, it’s almost definitely easier to predict the losers.

Massive amounts are being invested into automation (by carriers, product vendors and integrators), so if the investments succeed, operational roles are likely to be net losers. OSS are typically built to make operational roles more efficient – but if swathes of operator roles are automated, then does operational support also become a net loser? In its current form, probably yes.

Second, if you are a modern-day horse, ponder which of your skills are transferable into the future (eg chassis building, brakes, steering, etc) and which are not (eg buggy-whip making, horse-manure collecting, horse grooming, etc). Assuming operator-driven OSS activities will diminish, but automation (with or without AI) will increase, can you take your current networks / operations knowledge and combine that with up-skilling in data, software and automation tools?

Even if OSS user interfaces are made redundant by automation and AI, we’ll still need to feed the new technologies with operations-style data, seed their learning algorithms and build new operational processes around them.

The next question is double-edged – for both individuals and telcos alike – how are you up-skilling for a future without horses?

The two types of disruptive technologists

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 can work for or against OSS projects

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.

7 touches of sales
Courtesy of the OnlineMarketingInstitute.

The future of telco / service provider consulting

Change happens when YOU and I DO things. Not when we argue.”
James Altucher
.

We recently discussed how ego can cause stagnation in OSS delivery. The same post also indicated how smart contracts potentially streamline OSS delivery and change management.

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)
  • A mix of business, IT and network / tech expertise, like all valuable tripods

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.

Can you re-skill fast enough to justify microservices?

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.

A career without OSS

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?

The unfair OSS advantage

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?

An uncommon list of OSS books

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 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 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.
Rework Rework
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 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 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.
The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience
by Carmine Gallo
There are two acronyms that pervade in the OSS / telco / tech industry; DBA (Death by Acronym) and DBP (Death by Powerpoint). This book provides some stunning insights into how to make a compelling presentation on your latest OSS project.
Killing Giants: 10 Strategies to Topple the Goliath in Your Industry 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.
Jack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEO Jack Welch & The G.E. Way: Management Insights and Leadership Secrets of the Legendary CEO
by Robert Slater
This book describes a number of key strategies for how Jack Welch pared back the weighty bureaucracy of General Electric upon his ascension to CEO. I suspect our industry needs similarly brutal change leadership to thrive into the future
The Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control Costs The Best Service is No Service: How to Liberate Your Customers from Customer Service, Keep Them Happy, and Control Costs
by Bill Price, David Jaffe
There is a distinct difference between the customer service models of the typical communications service provider (CSP) and digital service providers (DSP) like Google, Facebook, Amazon, et al. Most CSPs can only wish for the level of customer self-service that the DSPs enjoy. I was working on a project for a customer-facing business unit of a CSP whilst reading this book and the parallels were almost scary.
Essentialism: The Disciplined Pursuit of Less Essentialism: The Disciplined Pursuit of Less
by Greg McKeown
Think: Less but better. A motto for our industry, one individual at a time.
Anything You Want: 40 Lessons for a New Kind of Entrepreneur 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).
Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry Brick by Brick: How LEGO Rewrote the Rules of Innovation and Conquered the Global Toy Industry
by David Robertson, Bill Breen
Bespoke creativity took this icon of childrens’ toys to the brink of bankruptcy. Perhaps counter-intuitively, paring it back to the basic building blocks (another bad pun) allowed creativity and profitability to thrive at Lego.
Principles: Life and Work 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.
Blue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition Irrelevant Blue Ocean Strategy, Expanded Edition: How to Create Uncontested Market Space and Make the Competition Irrelevant
by W. Chan Kim, RenĂŠe Mauborgne
This book provides frameworks for shifting an organisation out of fragmented, highly competitive markets (bloody red oceans) into a unique market segment (blue oceans). I’ve even added some of the concepts in this book into a framework that helps my clients plot differentiated strategic roadmaps and product evaluations.
Leading Change Leading Change
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.
Everything Is Negotiable: How to Get the Best Deal Every Time Everything Is Negotiable: How to Get the Best Deal Every Time
by Gavin Kennedy
Introduces some fascinating negotiation tactics such as “The Mother Hubbard” (ie the cupboard is bare). There is more negotiation required in OSS than I first gave it credit for.
Endless Referrals: Network Your Everyday Contacts into Sales 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 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
null 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 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 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.
The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It The E-Myth Revisited: Why Most Small Businesses Don’t Work and What to Do About It
by Michael E. Gerber
The ideas in this book are based on growing small businesses, but there are certainly take-aways for OSS. The biggest for me is the need for repeatability. We need to codify and systematise if we are to refine and improve.
Purple Cow, New Edition: Transform Your Business by Being Remarkable 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.
Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration
by Ed Catmull, Amy Wallace
From the creative brilliance of Pixar Studios comes this book of how to cultivate inspired creativity. My biggest take-away was the amount of time and money Pixar spends on upgrading its hardware and software platforms between films…. unlike some of our OSS that are still rooted in tech from the 1990s.
The 4-Hour Workweek: Escape 9-5, Live Anywhere, and Join the New Rich 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
OSS Essentials: Support System Solutions for Service Providers OSS Essentials: Support System Solutions for Service Providers
by Kornel Terplan
Finally, a book that’s actually about OSS. Whilst covering some obsolete technologies, this is one of the very few OSS books that retains a longevity of relevance (it was published in 2001)
Million Dollar Consulting: The Professional's Guide to Growing a Practice, Fifth Edition Million Dollar Consulting: The Professional’s Guide to Growing a Practice, Fifth Edition
by Alan Weiss
Alan Weiss has the ability to cut through the waffle that’s offered in many consultancy how-to manuals. He provides insightful and often contrarian advice that will make you a more professional consultant, no matter what area of expertise you cover.
Mastering your OSS: Operational Support System Implementation Tips and Techniques 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 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 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 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.”
Waging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational Complexity Waging War on Complexity Costs: Reshape Your Cost Structure, Free Up Cash Flows and Boost Productivity by Attacking Process, Product and Organizational Complexity
by Stephen A. Wilson, Andrei Perumal.
Amongst other things, this book introduces the concept of The Whale Curve, a model that breaks products into the profitable or the cannibalistic.
Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order Cryptocurrency: How Bitcoin and Digital Money are Challenging the Global Economic Order
by Paul Vigna, Michael J. Casey
You may (or may not) be interested in cryptocurrencies right now, but this book provides brilliant context for two concepts that are likely to have a big impact on future OSS – blockchains and smart contracts.

What have I missed? What should I be adding to my reading list? Alternatively, which books on the list do you think I’ve over-rated?

One link in an OSS chain reaction

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

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?