Thursday, 12 May 2016

Consulting, Star Trek Prime Directive & My Simple Rules

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

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

Naturally, I chose the latter option - and in hindsight, I'm glad I did so, and still maintain this approach to this day, in all my consulting gigs. In doing so, I've come to learn a great deal about leadership, coaching & mentor-ship, patience, servitude, not to mention the importance of authentic-and-sincere relationships, and I think I've emerged a better person/professional as a result.

This experience was kindly validated by one of the many bright and talented engineers in the team, who took time to publicly recommend my work:

"It ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things."
"I worked with Muhammad on the DStv Explora and saw it past launch from a very different initial plan. Muhammad’s role grew with the project as he grew into his natural position, then, as strategic programme manager. With an eye across the entire business, he has the ability to orchestrate change wherever it is required. Within our division this manifested itself as his ability to transition Agile methodologies and culture from something entirely contained within the development team to something more akin to an organisational capability.  
To achieve this, and other of his feats, required Muhammad to earn the trust of all those around him, to efficiently identify and deal with problems (both technical and human) and to communicate across the entire value-chain.  
His technical problem solving skills can be seen quite clearly in his CV; earning trust, his knack at identifying complex problems and his communication skills are all extraordinary, but require no further discussion. His human problem solving skills, however, require some more mention:  
On more than a few occasions, Muhammad has hosted workshops within the business for e.g.: to resolve inter-departmental conflict, to identify roles and responsibilities in the changing landscape of our business and to punt international best practise in product development. On each occasion the attendees learned what Muhammad wanted to impart, but did so of their own accord allowing them to take greater ownership of the required change. Like horses, he leads people to water through understanding and open discussion – we then arrive there thirsty and grateful, and drink all that is on offer. (It sounds very Machiavellian – perhaps it is – but Muhammad wields his great power with an even greater sense of social responsibility).  
We are truly a different organisation from the one Muhammad joined in 2011 – and that change is largely due to the efforts of Muhammad. "
I learnt to eat humble pie, I learnt patience & I learnt the art of empowering people. I learnt to appreciate the new culture (I came from a different one). When I started my company, AS3 (Africa Systems & Software Services), the essence at the heart of the company is to: Delight | Engineer | Innovate | Lead | Empower. 

We aim to delight our clients through our own uniqueness to handling engagements, taking pains not to thrust processes and practices dogmatically, without taking time to work with our clients to fully appreciate the systems (cultural, organisational & engineering). So we delight by not being too presumptuous.  We engineer practical, workable solutions, avoiding complexity as far as possible, keeping it real and contextual.   We seek to innovate expanding on the current state-of-play that happens to be as-is, in-process behaviours.  We continuously foster this innovation by leading through example, we appreciate that the ideas AS3 introduces might not sit immediately well with people, so we take time to appreciate feedback and through working with people, we empower individuals and teams to follow-through on their own, whilst overseeing their trajectory to reach the desired goals that AS3 jointly establishes with its client stakeholders.
The above can be seen as my very own Prime Directive.

And when I'm not comfortable with a client or a potential engagement respecting this philosophy, I walk away and never look back (another rule of mine is Leave it All Behind).


I've come to learn that you need to be mindful about managing default or natural reactions, the desire for instigating change (based on your experience) is more likely feeding one of your personal biases (e.g. confirmation bias), and that instigating changes outside your circle of control / influence needs to be considered very carefully, since it's more than likely going to impact you in many ways that you don't realise: time, energy, current commitments, relationships, etc.

Another rule in this prime directive chest, is to be mindful of the risk of starting a Cargo Cult. I have seen many-a-team fall in love with the latest process, only to scratch the surface, mimicking ceremonies instead of understanding the essence of the process, its underlying wisdom & rationale, not process-for-process-sake.

It is never easy with change - and if it's not your mandate, you'd be better off walking away. Even if it was part of your mandate, then executing on the change transformation is a journey of leading people through the change, creating a following, being a brand ambassador, understanding systems dynamics & complexity, winning hearts and minds - it is never about the process, it is never about proving Waterfall is better than Agile for predictive planning, it is not about proving software development is like a manufacturing line...no, it is more about creating a following, converting mindsets and behaviours, igniting a spark, and seeing that spark grow brighter and brighter...so much so that when you leave it behind, you know there's enough forward momentum left over to keep the people forging ahead, and no risk of falling back to old habits. 

I now consult on projects outside the immediacy of the technical streams, and instead work more on enterprise-level, cross-business co-ordination of large scale projects, where my primary customers are at CXO-level, as a project leader (a.k.a Project, Program & Portfolio Management).

My Rules

I still maintain my generalised prime directive, these simple rules act as my guiding compass:
  1. Respect the Client, Respect the Engagement - Always.
  2. Mind Your Place - know your Zorro Circle. Focus on your formal engagements only, do not exceed the limits, overstepping your boundaries.
  3. Remember you do NOT know everything, you can never know everything, your ideas are NOT always the best ideas. There is far greater strength in the collective than the individual. Get off your ivory tower and humble yourself.
  4. The group is always smarter than the individual - build authentic and sincere relationships, cemented by layers of trust. People Matter.
  5. Be mindful of your biases & your own personal bias for action / change. Think back to Star Trek's Prime Directive & Cargo Cults - Limit your Interference, work with the rightful owners.
  6. Always sharpen your toolset & add to your toolbox, even if the civilisation you're currently engaged with, is not ready to use these tools - avoid mediocrity as best as you can, don't get complacent [which fits in with my Persona Rankings].
  7. If the work does not feel right, if the organisation / culture conflicts with your Design | Engineer | Innovate | Lead | Empower principles, then walk away! Find another gig, the Client isn't worth your time & energy.
  8. Keep Showing Up, Do Your Best Work, regardless of praise, acknowledgement or seeking anything in return - no matter how mundane you think the job is. You owe it to yourself to always show up and do your best work...if not, and your energy & passion is gone, go to rule 7.
  9. Maintain your authenticity, sincerity & courageousness. There is always potential to "boldly go where no-one has gone before", but not alone...
  10. GoTo Rule 1.
Do you have any simple rules / prime directive of your own??
Please share...

[Phew! That's my outlet for May, release valve depressurised]...

No comments:

Post a Comment