DISCLAIMER: This is another idea or concept that just might not work, or people might find it a bit edgy...but it's been on my mind of late, and so I needed an outlet, hence this post, likely to need a few iterations :-)
In Star Trek, there is this philosophy called the Prime Directive, where an advanced civilisation, when either coming into contact with, or observing from afar, a culture or civilisation that is less advanced, or, the culture is at an early stage of growth / innovation / expansion, the rule is one of non-interference. Interfering or exposing advanced technology (or a culture) to a somewhat less-advanced civilisation might end up causing more harm-than-good, so it's better to stay away (as a right of non-imposition / interference).
Can this concept be applied to consulting, or even your workspace in general?
Can this concept be applied to consulting, or even your workspace in general?
Star Trek
As the right of each sentient species to live in accordance with its normal cultural evolution is considered sacred, no Star Fleet personnel may interfere with the normal and healthy development of alien life and culture. Such interference includes introducing superior knowledge, strength, or technology to a world whose society is incapable of handling such advantages wisely. Star Fleet personnel may not violate this Prime Directive, even to save their lives and/or their ship, unless they are acting to right an earlier violation or an accidental contamination of said culture. This directive takes precedence over any and all other considerations, and carries with it the highest moral obligation
My Own Prime Directive (Simple Rules)
I believe some parts of this philosophy can be applied to the subject of consulting, coaching or projects that touch on change & transformation, for example: agile-transformation, or even the reverse, going back from "wrong agile" to a structured, predictable waterfall, classic command-control-central-planning methods...the situation in my context: coming from a world of advanced software engineering into a world just starting out, without having an actual mandate for intervening on changing process & methods (even though you know there is a better way)...or in the project world, how to work with people still entrenched in methodology dogma, instead of seeing projects as a people leadership activity, run by conversations & commitments and less so on Gantt-chart-style, date-status-checker-are-you-done-yet project management...
Being a consultant, at least in my experience, you need to have one or more prime directives of your own, some simple rules to guide you along a path that not only protects you as a professional (as well as a person / individual), but more importantly protects the clients (civilisations) you encounter during your formal engagements, including adhoc interactions & connections.
You could say I've been a consultant for the last five years, even though from a job title front, it is going on for 150 weeks and counting, nearing the three year mark. Before returning to South Africa, I had worked for international companies that specialised in Software & Systems Design & Engineering. I had the privilege to work with a few great teams, engineers, managers and leaders where I learnt the arts and secrets to some fairly sound, tried-and-tested Software Development & Project Management methods, including large-scale agile frameworks (which I've written about previously). Leaving the UK I'd just come off one of the largest, and most intense projects in my career to date (read here) - it is the kind of project that essentially kick-starts your career into consulting, it was my Everest where I knew instinctively that that project was as good-as-it-gets, and the probability of experiencing another similar monumental project in my future was going to be pretty low...
So when I started with my next project going back five-years ago, the landscape of the company, the product roadmap & projects portfolio was almost a copy-and-paste of my last project but tuned down by a factor of say 20 notches or so. I saw that as an opportunity to leverage the wins (and learn from the pain-points) of my Everest project, looking forward to create something similar but evolved...
It turned out it wasn't going to be that straightforward in reality...this particular civilisation was only just starting out, so I had to be mindful of the state & maturity level (new team, new to agile, new everything) just as when our Star Trek Explorers come into contact with less advanced civilisations and need to reference the Prime Directive. And the role I played wasn't grand divisional manager, but a role limited to program delivery (leaving the technical & rest of development processes in the hands of the respective managers). Even though I had come from a world of great industry, here I was faced with the challenge of working in a world just starting out...the choices:
It turned out it wasn't going to be that straightforward in reality...this particular civilisation was only just starting out, so I had to be mindful of the state & maturity level (new team, new to agile, new everything) just as when our Star Trek Explorers come into contact with less advanced civilisations and need to reference the Prime Directive. And the role I played wasn't grand divisional manager, but a role limited to program delivery (leaving the technical & rest of development processes in the hands of the respective managers). Even though I had come from a world of great industry, here I was faced with the challenge of working in a world just starting out...the choices:
I could go in all gung-ho guns-blazing (I'm the professional, I'm experienced, I've got years of experience, what you're doing is so minor in comparison to my last project, just listen to me, I'm the Expert, You listen-and-follow-me, I'll fix your entire division up even if it's outside my world of Project Management, I'm a generalist, I've seen it all...), heavily & dogmatically prescribe a blue-print, cookie cutter process, and do what-it-takes to enforce (bulldoze-through) the adoption;
OR
I could pick and choose the core concepts to focus on (in-line with the organisation's state of development i.e. similar to how a civilisation has advanced technically/socially/culturally), that would incrementally lead to the organisation's goal (deliver product), but at the same time forge the road ahead on which their teams would grow, learn, develop & empowered to own the problem-space (allowing them to make mistakes along the way).
OR
I could pick and choose the core concepts to focus on (in-line with the organisation's state of development i.e. similar to how a civilisation has advanced technically/socially/culturally), that would incrementally lead to the organisation's goal (deliver product), but at the same time forge the road ahead on which their teams would grow, learn, develop & empowered to own the problem-space (allowing them to make mistakes along the way).