Category Archives: Career

The OctopOSS needs the innovators and the implementers to carry it forward along, offering unlimited career development opportunities along the way

Nobody dabbles at dentistry

Posted on by
Reply

“There are some jobs that are only done by accredited professionals.
And then there are most jobs, jobs that some people do for fun, now and then, perhaps in front of the bathroom mirror.
It’s difficult to find your footing when you’re a logo designer, a comedian or a project manager. Because these are gigs that many people think they can do, at least a little bit.”
Seth Godin here.

I’d love to plagiarise the entire post from Seth above, but instead suggest you have a look at the other pearls of wisdom he shares in the link above.

So where does OSS fit in Seth’s thought model? Well, you don’t need an accreditation like a dentist does. Most of the best I’ve met haven’t had any OSS certifications to speak of.

Does the layperson think they can do an OSS role? Most people have never heard of OSS, so I doubt they would believe they could do a role as readily as they could see themselves being logo designers. But the best I’ve met have often come from fields other than telco / IT / network-ops.

One of my earliest OSS projects was for a new carrier in a country that had just deregulated. They were the second fixed-line carrier in this country and tried to poach staff from the incumbent. Few people crossed over. To overcome this lack of experience, the carrier built an OSS team that consisted of a mathematician, an architect, an automotive engineer, a really canny project manager and an assortment of other non-telco professionals.

The executives of that company clearly felt they could develop a team of experts (or just had no choice but to try). The strategy didn’t work out very well for them. It didn’t work out very well for us either. We were constantly trying to bring their team up to speed on the fundamentals in order to use the tools we were developing / delivering (remembering that as one of my first OSS projects, I was still desperately trying to bring myself up to speed – still am for that matter).

As Seth also states, “If you’re doing one of these non-dentist jobs, the best approach is to be extraordinarily good at it. So much better than an amateur that there’s really no room for discussion.” That needs hunger (a hungriness to learn without an accredited syllabus).

It also needs humility though. Even the most extraordinarily good OSS proponents barely scratch the surface of all there is to learn about OSS. It’s the breadth of sub-expertise that probably explains why there is no single accreditation that covers all of OSS.

Am I being an OSShole?

Posted on by
Reply

““Am I being an asshole?” In other words, am I pointing out problems or am I finding solutions?”
Ramit Sethi.

One of the things I’ve noticed working on large and small OSS teams is that people who excel at finding solutions thrive in both. The ones who thrive on only identifying problems seemingly only function in large organisations.

In a small team, everyone needs to contribute to the many solutions that need resolving. There’s a clear line of sight to what’s being delivered. I’ve tended to find that the pure problem-finders feel uncomfortable to be the only ones not clearly delivering.

But there’s absolutely a role for identifying problems or for asking the question that completely re-frames the problem. One of the best I’ve seen is a CEO of a publicly listed company. He had virtually no knowledge of OSS, but could listen to half an hour of technical, round-in-circles discussions, then interject with a summary or question that re-framed and simplified the solution. The team then had a clear direction to implement. The CEO didn’t find the solution directly, but he was an instrumental component in the team reaching a solution.

The question to pose though is whether the question asker is being an OSShole or an agent provocateur*.

* BTW, I use this term within the context of being a change agent, someone who contributes to finding a solution, as opposed to the literal sense, which is to incite others into performing illegal acts.

What to read from a simple little OSS job advertisement from AWS

Posted on by
Reply

Not sure if you noticed, but AWS posted this job advertisement on LinkedIn a couple of days ago – Business Portfolio Leader – Telecom OSS/BSS Solutions.

The advertisement includes the following text:
“Amazon Web Services (AWS) is leading the next paradigm shift in computing and is looking for a world class candidate to manage an elite portfolio of strategic AWS technology partners focused on the Operation support System (OSS) and Business Support System (BSS) applications within telecommunications segment. Your job will be to use these strategic partners to develop OSS and BSS applications on AWS infrastructure and platform.”

How do you read this advertisement? I have a few different perspectives to pose to you:

I can’t predict AWS’ future success with this initiative, but I’m assuming they’re creating the role because they see a big opportunity that they wish to capture. They have plenty of places they could otherwise invest, so they must believe the opportunity is big (eg the industry of OSS suppliers selling to CSPs is worth multi-billions of dollars and is waiting to be disrupted).

OSS/BSS are typically seen by CSPs as a very expensive (and risky) cost of doing business. I’m certain there’s a business model for any organisation (possibly AWS and its tech partners) that can significantly improve the OSS/BSS delivery costs/risks for CSPs.

The ad identifies CSPs (specifically the term, “major telecom infrastructure providers”) as the target customer. You could pose the concept that the CSPs won’t want to support a competitor in AWS. The CSPs I’m dealing with can’t get close to matching AWS cost structures so are partnering with AWS etc. Not just for private cloud, but also public and hybrid cloud too. The clip-the-ticket / partnership selling model appears to be becoming more common for telcos globally, so the fear-of-competition barrier “seems” to be coming down a little.

The other big challenge facing the role is network and data security. What’s surprised me most are core network services like directory services (used for internal authentication/AAA purposes). I never thought I’d see these outsourced to third-party cloud providers, but have seen the beginnings of it recently. If CSPs consume those, then OSS/BSS must be up for grabs at some CSPs too. For example, I’d imagine that OSS/BSS tools were amongst the 1,000 business apps that Verizon is moving to AWS.

The really interesting future consideration could be the advanced innovation that AWS et al could bring to the OSS space, and in ways that the telcos and OSS suppliers simply can’t. This recent post showed Google’s intent to bring AI to network operations. It could revolutionise the OSS/BSS industry. Not just for CSPs, but for their customers as well (eg their enterprise-grade OSS). Could it even represent another small step towards the OSS Doomsday Scenario posed here?

And just who are the “strategic partners” that AWS is referring to? I assume this old link might give at least one clue.

I’m certainly no Nostradamus, so I’d love to get your opinions on what ramifications this strategic hire will have on the OSS/BSS industry we know today.

The Jeff Bezos prediction for OSS

Posted on by
Reply

“If we start to focus on ourselves, instead of focusing on our customers, that will be the beginning of the end … We have to try and delay that day for as long as possible.”
Jeff Bezos.

Jeff Bezos recently predicted that Amazon is likely to fail and/or go bankrupt at some point in time, as history has eventually proven for most high-flying companies. The quote above was part of that discussion.

I’ve worked with quite a few organisations that have been in the midst of some sort of organisational re-structure – upsizing, downsizing, right-scaling, transforming – whatever the words that might be in effect. Whilst it would be safe to say that all of those companies were espousing being focused on their customers, the organisational re-structures always seem to cause inward-facing behaviour. It’s human nature that change causes feelings of fear, job security, opportunities to expand empires, etc.

And in these types of inward-facing environments in particular, I’ve seen some really interesting decisions made around OSS projects. When making these decisions, customer experience has clearly been a long way down the list of priorities!! And in the current environment of significant structural change in the telco industry, these stimulants of internal-facing behaviour appear to be growing.

Whilst many people want to see OSS projects as technical delivery solutions and focus on the technology, the people and culture aspects of the project can often be even more challenging. They can also be completely underestimated.

What have your experiences been? Do you agree that customer-facing vision, change management and stakeholder management can be just as vital as technical brilliance on an OSS implementation team?

Does Malcolm Gladwell’s 10,000 hours apply to OSS?

Posted on by
Reply

You’ve probably all heard of Malcolm Gladwell’s 10,000 hour rule from his book, Outliers? In it he suggests that roughly 10,000 hours of deliberate practice makes an individual world-class in their field. But is 10,000 hours enough in the field of OSS?

I look back to the year 2000, when I first started on OSS projects. Over the following 5 years or so, I averaged an 85 hour week (whilst being paid for a 40 hour week, but I just loved what I was doing!!). If we multiply 85 by 48 by 5, we end up with 20,400 hours. That’s double the Gladwell rule. And I was lucky to have been handed assignments across the whole gamut of OSS activities, not just monotonously repeating the same tasks over and over. But those first 5 years / 20,000+ hours were barely the tip of the iceberg in terms of OSS expertise.

Whilst 10,000 hours might work for repetitive activities such as golf, tennis, chess, music, etc it’s probably less impactful for such multi-faceted fields as OSS.

So, what does it take to make an OSS expert? Narrow focus on just one of the facets? Broad view across many facets? Experience just using, building, designing, optimising OSS, or all of those things? Study, practice or a combination of both?

If you’re an OSS expert, or you know any who stand head and shoulders above all others, how would you describe the path that got you / them there?
Or if I were to ask another way, how would you get an OSS newbie up to speed if you were asked to mentor them from your lofty position of expertise?

Who are more valuable, OSS hoarders or teachers?

Posted on by
Reply

Any long-term readers of this blog will have heard me talk about tripods, and how valuable they are to any OSS team. They’re the people who know about IT, operations/networks and the business context within which they’re working. They’re the most valuable people I’ve worked with in the world of OSS because they’re the ones who can connect the many disparate parts that make up an OSS.

But on reflection, there’s one other factor that almost all of the tripods have who I’ve worked with – they’re natural teachers. They want to impart any and all of the wisdom they may contain.

I once worked in an Asian country where teaching was valued incredibly highly. Teachers were put on the highest pedestal of the social hierarchy. Yet almost every single person in the organisation, all the way from the board that I was advising through to the workers in the field, hoarded their knowledge. Knowledge is power and it was definitely treated that way by the people in this organisation. Knowledge was treated like a finite resource.

It was a fascinating paradox. They valued teachers, they valued the fact that I was open with sharing everything I could with them, but guarded their own knowledge from anyone else in their team.

I could see their rationale, sort of. Their unique knowledge made them important and impossible to replace, giving them job stability. But I could also not see their rationale at all. Let me summarise that thought in a single question – who have you found to be more valuable (and needing to be retained in their role), the genius hoarder of knowledge who can perform individual miracles or the connector who can lift and coordinate the contributions of the whole team to get things done?

I’d love to get your thoughts and experiences working with hoarders and teachers.

Introducing our OSS expert registry, for making connections in the OSS industry

Posted on by
Reply

Here at Passionate About OSS, we’re passionate about making OSS happen. We have an extensive network of contacts. We just naturally tend to find ourselves making connections between the many experts in our network. Connecting those who are hoping to find an OSS expert with an OSS expert hoping to be found.

We’ve just introduced a new free-of-charge OSS expert registry to help people find OSS experts when they need to. This registry is intended to cover the buy-side and sell-side of the OSS market. Click on the link above to check it out.

For fear of OSS investment

Posted on by
Reply

Friday’s post discussed three analogies about the challenges of performing an OSS pivot.

The biggest challenge in initiating the transformation / replacement of any significant OSS is fear. There are many OSS out there whose “owners” want to change and need to change… but fear changing because a significant pivot would mean a “sell the farm” decision.

The fear is completely understandable. These are highly complex projects with so many potential pitfalls that invest massive amounts of resource (time, money, people). The risks can be huge for sponsors / stakeholders / investors. Failure of these projects can be career changing. The upside potential rarely balances the downside risk.

So, the only choice we have is to present pivots that aren’t “bet the farm” decisions.

The delivery approach of a bet the farm pivot tends to look like this:
The Bet-the-farm OSS Transformation Approach

The less risky, dependency-reduced, stepping-stone transformation tends to look a bit like this, but probably with a lot more verticals, as described here:
The Stepping-Stone OSS Transformation Approach

Your OSS Justice League

Posted on by
Reply

Is it just me or has there been a proliferation of superhero movies coming out at cinemas lately? Not only that, but movies where teams of superheros link up to defeat the baddies (eg Deadpool 2, Justice League, etc)?

The thing that strikes me as interesting is that there’s rarely an overlap of super-powers within the team. They all have their different strengths and points of difference. The sum of the parts… blah, blah, blah.

Anyway, I’m curious whether you’ve noticed the same thing as me on OSS projects, that when there are multiple team members with significant skill / experience overlap, the project can bog down in indecision? I’ve noticed this particularly when there are many architects, often super-talented ones, on a project. Instead of getting the benefit of collaboration of great minds, we can end up with too many possibilities (and possibly egos) to work through and the project stagnates.

If you were to hand-pick your all-star cast for your OSS Justice League, just like in the movies, you’d look for a team of differentiated, but hopefully complementary, super-heroes I assume. But I’m diverting away from my main point here.

Each project, just like each formidable foe in the movies, is slightly different and needs slightly different super-powers to tackle it. When selecting a cast for a movie, directors have a global pool to choose from. When selecting a cast for an OSS project, directors have traditionally chosen from their own organisation, possibly with some outside hires to fill the long-term gaps.

With the increasing availability of freelance resources (ie people who aren’t intrinsically tied to carriers or vendors), the proposition of selecting a purpose-built project team of OSS super-heroes is actually beginning to become more possible. I’m wondering how much the gig economy will change the traditional OSS project team model in coming years.

I’d love to hear your thoughts and experiences on this.

Expanding your bag of OSS tricks

Posted on by
2

Let me ask you a question – when you’ve expanded your bag of tricks that help you to manage your OSS, where have they typically originated?

By reading? By doing? By asking? Through mentoring? Via training courses?
Relating to technical? People? Process? Product?
Operations? Network? Hardware? Software?
Design? Procure? Implement / delivery? Test? Deploy?
By retrospective thinking? Creative thinking? Refinement thinking?
Other?

If you were to highlight the questions above that are most relevant to the development of your bag of tricks, how much coverage does your pattern show?

There are so many facets to our OSS (ie. tentacles on the OctopOSS) aren’t there? We have to have a large bag of tricks. Not only that, we need to be constantly adding new tricks too right?

I tend to find that our typical approaches to OSS knowledge transfer cover only a small subset (think about discussion topics at OSS conferences that tend to just focus on the technical / architectural)… yet don’t align with how we (or maybe just I) have developed capabilities in the past.

The question then becomes, how do we facilitate the broader learnings required to make our OSS great? To introduce learning opportunities for ourselves and our teams across vaguely related fields such as project management, change management, user interface design, process / workflows, creative thinking, etc, etc.

Are OSS business tools or technical tools?

Posted on by
Reply

I’d like to get your opinion on this question – are OSS business tools or technical tools?

We can say that BSS are as the name implies – business support systems.
We can say that NMS / EMS / NEMS are network management tools – technical tools.

The OSS layer fits between those two layers . It’s where the business and technology worlds combine (collide??).
BSS_OSS_NMS_EMS_NE_abstract_connect

If we use the word Operations / Operational to represent the “O” in OSS, it might imply that they exist to help operate technology. Many people in the industry undoubtedly see OSS as technical, operational tools. If I look back to when I first started on OSS, I probably had this same perception – I primarily faced the OSS / NMS interface in the early days.

But change the “O” to operationalisation and it changes the perspective slightly. It encourages you to see that the technology / network is the means via which business models can be implemented. It’s our OSS that allow operationalisation to happen.

So, let me re-ask the question – are OSS business tools or technical tools?

They’re both right? And therefore as OSS operators / developers / implementers, we need to expand our vision of what OSS do and who they service… which helps us get to Simon Sinek’s Why for OSS.

OSS of the past probably tended to be the point of collision and friction between business and tech groups within an organisation. Some modern OSS architectures give me the impression of being meet-in-the-middle tools, which will hopefully bring more collaboration between fiefdoms. Time will tell.

An OSS doomsday scenario

Posted on by
Reply

If I start talking about doomsday scenarios where the global OSS job industry is decimated, most people will immediately jump to the conclusion that I’m predicting an artificial intelligence (AI) takeover. AI could have a role to play, but is not a key facet of the scenario I’m most worried about.
OSS doomsday scenario

You’d think that OSS would be quite a niche industry, but there must be thousands of OSS practitioners in my home town of Melbourne alone. That’s partly due to large projects currently being run in Australia by major telcos such as nbn, Telstra, SingTel-Optus and Vodafone, not to mention all the smaller operators. Some of these projects are likely to scale back in coming months / years, meaning less seats in a game of OSS musical chairs. But this isn’t the doomsday scenario I’m hinting at in the title either. There will still be many roles at the telcos and the vendors / integrators that support them.

There are hundreds of OSS vendors in the market now, with no single dominant player. It’s a really fragmented market that would appear to be ripe for M&A (mergers and acquisitions). Ripe for consolidation, but massive consolidation is still not the doomsday scenario because there would still be many OSS roles in that situation.

The doomsday scenario I’m talking about is one where only one OSS gains domination globally. But how?

Most traditional telcos have a local geographic footprint with partners/subsidiaries in other parts of the world, but are constrained by the costs and regulations of a wired or cellular footprint to be able to reach all corners of the globe. All that uniqueness currently leads to the diversity of OSS offerings we see today. The doomsday scenario arises if one single network operator usurps all the traditional telcos and their legacy network / OSS / BSS stacks in one technological fell swoop.

How could a disruption of that magnitude happen? I’m not going to predict, but a satellite constellation such as the one proposed by Starlink has some of the hallmarks of such a scenario. By using low-earth orbit (LEO) satellites (ie lower latency than geostationary satellite solutions), point-to-point laser interconnects between them and peering / caching of data in the sky, it could fundamentally change the world of communications and OSS.

It has global reach, no need for carrier interconnect (hence no complex contract negotiations or OSS/BSS integration for that matter), no complicated lead-in negotiations or reinstatements, no long-haul terrestrial or submarine cable systems. None of the traditional factors that cost so much time and money to get customers connected and keep them connected (only the complication of getting and keeping the constellation of birds in the sky – but we’ll put that to the side for now). It would be hard for traditional telcos to compete.

I’m not suggesting that Starlink can or will be THE ubiquitous global communications network. What if Google, AWS or Microsoft added this sort of capability to their strengths in hosting / data? Such a model introduces a new, consistent network stack without the telcos’ tech debt burdens discussed here. The streamlined network model means the variant tree is millions of times simpler. And if the variant tree is that much simpler, so is the operations model and so is the OSS… with one distinct contradiction. It would need to scale for billions of customers rather than millions and trillions of events.

You might be wondering about all the enterprise OSS. Won’t they survive? Probably not. Comms networks are generally just an important means-to-an-end for enterprises. If the one global network provider were to service every organisation with local or global WANs, as well as all the hosting they would need, and hosted zero-touch network operations like Google is already pre-empting, would organisation have a need to build or own an on-premises OSS?

One ubiquitous global network, with a single pared back but hyperscaled OSS, most likely purpose-built with self-healing and/or AI as core constructs (not afterthoughts / retrofits like for existing OSS). How many OSS roles would survive that doomsday scenario?

Do you have an alternative OSS doomsday scenario that you’d like to share?

Hat tip again to Jay Fenton for pointing out what Starlink has been up to.

Training network engineers to code, not vice versa

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
4

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

Posted on by
Reply

“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?

Posted on by
Reply

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?

Posted on by
Reply

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. Similarly, each OSS customer wants a supplier they can trust and seek guidance from.

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

Posted on by
Reply

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

Posted on by
Reply

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…