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.
Over the years, I’ve often referred to The Corkscrew Analogy or Momentum Spiral to describe a mindset of incremental improvement that’s needed to keep an
We’ve embarked on a journey of trying to plan for the future of OSS/BSS, not by predicting the future, but by seeking ways to be
As discussed in the previous article, “Future Scenario Planning: Have you given up on doing an OSS transformation? (part 1)” part of the fun of
Earlier in the week, a friend mentioned he was reading “Alchemy” by Rory Sutherland. It’s not an OSS book per se, but does provide some
Here at Passionate About OSS, we are exactly that – Passionate About OSS (Operational Support Systems). We’re also passionate about BSS, NMS, or any other names you call the tools that help to operationalise your network.
2 Responses
Hi Ryan
I have found that it is definitely a mix of most or all of the aspects you mention which lead to insights, tricks, and ultimately improved OSS solutions. This is also why I am of the opinion that a good OSS architect (or any IT architect or designer for that matter) should have a background in pretty much all disciplines, i.e. development, business consultancy, testing, operations, etc. in order to develop the insights required to design solutions which optimize across all or at least most of those disciplines and at the very least make conscious decisions about where the inevitable compromises are.
Johan, absolutely!! I’m in complete agreement with you. The best I’ve worked with in the OSS and technology industries have had the biggest bags of tricks because they’ve been so well rounded and have an understanding of where all the silos interconnect. I tend to refer to these people as tripods or linchpins https://passionateaboutoss.com/tripods/