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.
We recently discussed how the “Ultimate Game,” a study in behavioural psychology, might help to explain why there tends to be less initial animosity between
The great thing about the holiday period is you often get the chance to step away from business as usual (BAU) activities. As customer projects
Last year, we published a series of articles about the chasm that exists between OSS/BSS buyers and sellers. “The chasm” is best exemplified by the
Whilst setting up for another new initiative this week I became aware that the PAOSS blog has just ticked past 1 million words. And that’s
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/