Digital Transformation

It seems like “Digital Transformation” of organisations is all the rage – or is it fear? – in C-suites around the world. The term implies the pursuit of new business models and, by extension, new revenue streams. I’ve been speaking recently with folks in a number of organisations attempting “Digital Transformation”, some for the fourth or fifth time. I get the impression that things are not going well, on a broad front.

What is Digital Transformation?

Even though the term is ubiquitous nowadays, what any one organisation means by the term seems to vary widely. I’ll attempt my own definition, for the sake of argument, whilst recognising that any given organisation may have in mind something rather different, or sometimes no clear idea at all. Ask ten different organisations what Digital Transformation means to them, and you’re likely to get at least ten different answers.

Digital Transformation is the creation and implementation of new business models, new organisational models and new revenue streams made possible by the use of new digital technologies and channels.

Ironically it’s proving to NOT be about technology, but rather about company culture (this, in itself, being a product of the collective assumptions and beliefs of the organisation).

“A significant number of organisations are not getting [digital] transformation right because of a fundamental quandary over what digital transformation really is.”

~ Brian Solis, principal analyst and futurist at Altimeter

My Interest

So, why am I bothering to write this post? Aren’t there already reams of articles about every conceivable aspect of Digital Transformation?

Well, one aspect of Digital Transformation I see little covered is that relating to the development of “digital” products for the digitally-transformed company. And the implications this brings to the party.

Digital Transformation requires the development of new products and services to serve the new business models, new organisational models and new revenue streams. Digital products and digital services. In most cases, this means software development. And organisations, particularly untransformed organisations – which even now means most of them – are spectacularly inept at both software development and product development. Some refer to this as “a lack of digital literacy”.

Things have not changes much in this arena for the past fifty years and more. Failure rates resolutely hover around the 40% mark (and even higher for larger projects). And the much-vaunted (or is it much cargo-cullted?) Agile approach to development has hardly moved the needle at all.

For the past two decades I have been writing about the role of the collective psyche – and the impact on organisational effectiveness of the collectively-held assumptions and beliefs about how work should work. And make no mistake, effectiveness is a key issue in digital product development. Relatively ineffective organisations will fail to deliver new digital products and services at least as often as 40% of the time. Relatively effective organisations can achieve results at least an order of magnitude better than this.

The Marshall Model provides an answer to the question: what do we have to do to become more effective as an organisation? And it’s not a popular answer. By analogy, people looking to lose weight rarely like to hear they will have to eat less and exercise more. Organisations looking to become more effective rarely like to face up to the fact that they will have to completely rethink long-held and deeply-cherished beliefs about the way work should be organised, managed, directed and controlled. And remodel their organisations along entirely alien lines in order to see a successful Digital Transformation and compete effectively in the digital domain.

Successful Digital Transformations demand organisations not only come up with new business strategies, organisational models, revenue streams and digital products and services, but also that they shift their collective mindset to one which aligns with their ambitions. Personally, I see shifting the collective mindset as an essential precursor to the former. Most organisations approaching Digital Transformation fail to recognise this inevitability, this imperative. And so, most Digital Transformations are doomed to underachieve, or fail entirely.

“Ask yourself whether what you’re doing is disruptive to your business and to your industry. If you can say yes with a straight face, you may well be conducting a legitimate digital transformation.” And if you’re unable to say yes, then whatever you’re doing, it’s likely not a Digital Transformation.

If you’d like to explore this topic, understand more about the Marshall Model, its relevance and its predictive power, and save your organisation millions of Dollar/Pounds/Euros – not to mention much embarrassment and angst – I’d be delighted to chat things over with you and your executive team.

– Bob

Further Reading

Reinventing Organizations ~ Frederic Laloux

Effectiveness

I recently had a bit of a wake-up call via Twitter. I asked the following question:

“What’s the one thing /above all/ that makes for an effective organisation?”

My thanks to all those who took the time to reply with their viewpoint. The wake-up call for me was the variety of these responses. All over the map might be a fair description. Which, given I’ve been writing about effectiveness in the context of organisations for more than a decade now, tells me I’ve some way to go to get my perspective across. Not that I’d expect folks to respond by simply parroting my definition, of course. And nor do I claim any special authority over the term.

Goldratt defines (in)effectiveness as:

“Things that should not have been done but nevertheless were done.”

Drucker defined it as:

“Successfully aligning behaviour with intentions.”

Aside: It’s been my experience that (organisational) effectiveness gets little attention or focus in most organisations. And seeing as how in most organisations things are so ineffective, I’ve come to believe that those making the calls don’t see a need for effectiveness.

Spectra

Effectiveness is a spectrum. From highly ineffective through to highly effective. Note that this spectrum is orthogonal to the spectrum of organisational success (by whatever measure you might choose for success: revenues, profits, social impact, personal kudos, joy, employee satisfaction, customer satisfaction, quality, returns to shareholders, executive bonuses, w.h.y.).

Effective organisations are not necessarily successful, and successful organisations are not necessarily effective. I posit that effectiveness can help create, contribute to, and sustain success. I seem to be in a minority.

Survey Results

Here’s the responses I received to my question:

  • @FragileAgile: “Folks needs being intentionally met.”
  • @andycleff: “+1 to Trust. Foundation for all the things.”
  • @LMaccherone: “Happy paying customers”
  • @stuart_snelling: “Accurate, contextual and meaningful data that is readily accessible.”
  • @ChangeTroops: ”Growth mindset.”
  • @allygill: “Effective people who understand the needs of their customers (internal and external) and each other.”
  • @KarimHarbott: “Totally and utterly dependent on what they are trying to achieve.”
  • @ArnoutOrelio: “People”. “Their ability to improve things; their creativity.”
  • @gertveenhoven: “Trust.”
  • @ferigan: “A team structure that doesn’t require effort to collaborate in and allows work to flow well.”
  • @anam_liath: “Common vision and ideals.”
  • @rogersaner: “Empowering your people.”
  • @sourabhpandey05: “I would say ‘Culture’ of the organisation. Culture which promotes1 the values trust, transparency, respect for everyone.”
  • @heybenji: “Ingenuity.”
  • @joserra_diaz: “Mindset of the owner.”
  • @ard_kramer: “Autonomy for individuals and a common understanding of what is of value for the organisation.”
  • @martinahogg: “Alignment.”
  • @briscloudnative: “Love.”
  • @barryfarnworth: “Understanding purpose….”
  • @mikeonitstuff: “Ultimately I think it’s leadership. The leaders set the stage for the culture and the vision for the organization. Poor leadership can destroy value and morale, great leadership creates the conditions for high performance.”
  • @EricStephens: “Uniform Commitment to the mission.”

For each of the above, I invite you to apply this litmus test: “if we had this, would we then necessarily be effective?”

Rightshifting

Some folks asked me for my “answer”, so here it is:

Rightshifting and the Marshall Model both attribute (relative) organisational effectiveness to the prevailing collective mindset. That’s to say, what an organisation collectively believes about how the world of work should work will absolutely dictate how effective that organisation will be. Any organisation wishing to become significantly more effective faces the formidable challenge of changing its collective assumptions and beliefs about work (in the broadest sense of the term). In other works, change the prevailing paradigm, or better yet, acquire the power to transcend /any/ particular paradigm.

For clarity then, the one thing above all that makes for an effective organisation is its collective mindset a.k.a. memeplex.

This echoes the famous “Twelve Leverage Points to Intervene in a System” by Donella Meadows:

– Bob

Ending Therapy

Plan for the Ending

Any therapy relationship is likely to end, sooner or later. Sometimes it’ll be a happy ending, sometime less so. Although the seeds planted during therapy often means the client can continue to grow and develop, becoming more whole, more congruent, in their own time and under their own tutelage.

There are many reasons clients decide to end therapy. Sometimes they’ve reached their goals. Sometimes they need a break. Sometimes the connection with their therapist isn’t there. Sometimes they notice a red flag. Sometimes they’re about to face a new fear or realise a new insight.

Whatever the reason, it’s vital the therapist and the client brings it up as soon as either party becomes conscious of it. Wanting to end therapy is a critical topic to explore. And it could be as simple either the client or the therapist saying “I feel like it might be time to end therapy, I wonder what that’s all about?”.

An end in therapy can be more like a bittersweet parting than a sad, abrupt, or complicated loss. Ideally, clients can have a satisfying closure to therapy that will help them end other relationships well in the future.

Processing negative feelings can be a way to work through maladaptive patterns and make the therapeutic relationship a corrective experience. If clients avoid this conversation by simply discontinuing therapy, they may miss the opportunity for a deeper level of healing resulting from their therapy.

I find it helpful to mention the ending even from the outset of the therapy relationship. If only in the information conveyed as part of the setup of that relationship.

Any particular client may find it a distraction, discomforting, or scary to entertain the idea that the relationship – or, at least, the therapy – might come to an end even as it’s just getting started. So the timing of the broaching of the subject generally depends on how things are going.

Advice for Clients re: Ending Therapy

  1. Examine your reasons

A positive approach to ending therapy is to delve into the possible reasons why you’d like to leave. Is it because you feel disrespected, stuck or incompatible or because of feelings of discomfort in dealing with certain things that the therapist is pushing on me on? It’s common and part of the process of changing problematic patterns, to feel triggered and even angry with your therapist.

  1. Don’t stop suddenly

It’s important for clients to discuss the ending with their therapists, because they may suspect that the desire to part ways is somehow premature. Even if a client decides to leave therapy, processing this can be therapeutic in itself. Some sessions discussing  the subject, including feelings and what kinds of post-therapy experiences the client might go through can help ease the guilt, regret or sadness that often arise.

Plus, honouring the relationship and the work everyone has done together, with some sessions to achieve closure in a positive way can be a very powerful experience in its own right.

  1. Talk in person

Avoid ending therapy with a text, email or voicemail. Speaking directly is an opportunity to practice assertive communication and perhaps also conflict resolution, making it is an opportunity for learning and growth.

  1. Provide honest feedback

If you feel comfortable and emotionally safe doing so, it is best to be direct and honest with your therapist about how you are feeling about him or her, the therapeutic relationship or the approach you’ve been experiencing. After all, this has been a partnership, and part of growth is to embrace that, see the therapist as a human being, and see other folks’ needs met – including the therapist.

When offering feedback, do so without judgment. After all, the therapist will be working with other organisations and your thoughts may change their style and help them to better serve their clients in the future.

A good therapist will be open to feedback and will use it to continually improve.

  1. Communicate clearly

Be as direct, open, and clear as possible. Articulate the exact reasons for wanting to end therapy.

  1. Be ready for dissent

It is not unusual for a therapist to agree with ending therapy, especially if the client has reached their goals and is doing well. But they also might disagree. This disagreement can serve positively, as a spur to enhance the ability for discussing difficult topics.

Every therapy ends, there’s no reason to avoid this reality. Early in therapy, when discussing goals, why not talk about how and when therapy might end.

Advice for Therapists re: Ending Therapy

  1. Invite feedback

Most personal therapists note that having their clients share feedback on their experiences is incredibly valuable. It’s no different in the OP context. Feedback helps therapist  improve and grow as practitioners.

  1. Sometimes we won’t know why

Sometime we won’t get to know why a client ends their therapy. The connection can just fizzle out, with little to no contact or explanation. As we’re very invested in our work and in our relationship with the client, such an ending can be both a puzzle and a disappointment.

  1. Practice letting go

Some clients simply stop, so it’s not easy to know if they’re just ‘done’ with therapy or if we’ve done something to make them want to leave. When this is the case, I just let it go. It’s their issue, not mine, and I don’t need to worry over it when I don’t know the reasons behind it. Of course we could wish it were otherwise, but letting go can be the hardest thing.

  1. Enjoy the experience

When client and therapist are able to have some sessions for proper closure, it becomes a great opportunity to reflect on their work together. These sessions can be highly joyful, for both parties.

Our goal is to support our clients in confronting life and the issues they see as holding them back, blocking them from greater success. If clients have clear reasons to end therapy and we’ve had the time to talk about it and tie up the loose ends, ending therapy is a great time to reflect on our work, invite the client to talk about their future, and discuss what has been accomplished and what hasn’t. We can leave with a sense of closure, without nagging, unresolved issues. And with the sense that the client is now netter placed to tackle themselves new issues that might arise in their future.

Those precious final sessions afford the opportunity to relax, reminisce about our shared experiences, ponder the future, and learn how to be a better therapist for others.

When clients can approach the ending of therapy with respect, dignity and integrity, that sets the tone for other relationship issues. In other words, with proper closure, everybody wins.

In your practice, how often do you plan for the ending?

– Bob

The Relevance of Giants – 2. O Sensei (Morihei Ueshiba)

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, O Sensei have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s continue, with this second post in the series, with O Sensei.

O Sensei

Morihei Ueshiba

(December 14, 1883 – April 26, 1969)  (See also: Wikipedia entry)

I’m not going to dwell on his early life and experiences in the Japanese Army, his adventures in Mongolia, nor his experiences in Manchuria and Japan during the time of World War 2.

Aikido

I suggest the primary relevance of O Sensei to most folks working in the field of software development (and production operations) is Aikido – the martial art he developed. Excepting it’s less a martial art, and more a philosophy for life, and for harmonising with others.

Unlike many other martial arts, Aikido is focussed on caring for others, as emphasised by the translation of the three kanji: ai-ki-do as the Way of Unifying Spirit or the Way of Spiritual Harmony. O Sensei envisioned Aikido as an expression of his personal philosophy of universal peace and reconciliation. O Sensei’s goal was to create an art that practitioners could use to defend themselves while also protecting their attacker from injury.

Blending“, one of the core techniques of Aikido, invites us to look at conflicts from the perspectives of the other person – or people – involved. For me, this has a direct connection with empathy – as promoted by e.g. Marshall Rosenberg and others of the nonviolent community.

“Life is growth. If we stop growing, technically and spiritually, we are as good as dead.”

~ Morihei Ueshiba

Where’s the Relevance?

How do we make it more likely that we’re all spending our time on stuff that matters? How do we go about attending to folks’ real needs? I find blending a great asset in identifying with the needs of others. As I blend, I see their perspective, and their needs, more clearly. And in turn, they can feel more listened-to. And choose to reveal other things, crucial things, that means we get to understand more about what matters to us all. With this knowledge – and goodwill – we have a better chance of focusing on what matters, and of reducing the chance of wasting some or all of our time on the inconsequential, on detours, and on dead ends.

Practical Investigation

You might like to join an Aikido dojo, to practice the physical forms of the techniques. And to discuss the philosophy with like-minded people wha have already started the journey. Beware, though, of those dojos and sensei that emphasise the physical forms at the expense of Aikido philosophy.

– Bob

Further Reading

The Life We Are Given ~ Michael Murphy, George Leonard
The Way of Aikido ~ George Leonard
It’s A Lot Like Dancing ~ Terry Dobson

The Relevance of Giants – 1. Deming

On most every occasion when I’m speaking in public – at conferences, workshops, and the like – I tend to mention one or more of my “Giants” of Rightshifting. Men and women who, through their lives and work have contributed significantly to my understanding of work, and in particular to my understanding of effective collaborative knowledge work.

Many folks express interest in these Giants, but I do wonder if they appreciate the relevance of the ideas and experiences of these Giants to their own daily lives at work.

I mean, what relevance does, say, Bill Deming have to developers, testers, operations staff and the like? Which aspects of any of these Giants’ work could be useful or helpful or simply comforting to these folks?

In this occasional series of posts I’ll be exploring some of the Giants’ relevance to folks other than theorists, managers, consultants and the like. I’ll be sharing some insights into their work, and specifically, the likely relevance.

With these posts I hope to pique your curiosity just a little. Let’s start with Bill Deming.

W. Edwards Deming

Bill Deming

(October 14, 1900 – December 20, 1993)  (See also: Wikipedia entry)

I’m not going to dwell on his work in SPC (Statistical Process Control) or SQC (Statistical Quality Control), his pivotal role in the Japanese post-war economic miracle, his 14 Point system of thought he called the “System of Profound Knowledge”, nor his Plan-Do-Study-Act (PDSA) cycle (the latter being the basis for most Agile approaches, btw).

Deming’s 95/5

I suggest the primary relevance of Deming to most folks working in the field of software development (and production operations) is primarily the idea known as “Deming’s 95/5” (although this originated in a quote from Peter Scholtes).

“The fact is that the system that people work in and the interaction with people may account for 90 or 95 percent of performance.”

From my studies of Deming, and from applying his ideas in my practice, I have come to believe that it’s the interactions between people that account for the lions share of “productivity”, “performance” and “success” in collaborative knowledge work. And the “system” a.k.a. the way the works works has a major (hidden) influence on the quality of those relationships, as well as on the work (output, results) of the individual workers.

“Dr. Deming taught me that 95% of the performance of an organization is attributable to the system (processes, technology, work design, regulations, etc.) and [only] 5% is attributable to the individual.”

~ Tripp Babbitt

Where’s the Relevance?

If, like most people, you’re looking for a better quality of life at work, Deming points the way to us improving our relationships with our colleagues, peers and managers. Maybe this perspective is something to consider on those occasions when you’re less than happy in your work, when you’re checked-out, or disengaged, or frustrated.

And Deming’s attribution of 90-95% of your performance to the system within which you’re obliged to work throws a new light on many typical organisational practices such as history-led recruitment, performance appraisals and reviews, stack ranking, criticisms (and praise) for your efforts, etc.. Your results (and self-esteem) may be taking a hit from the effects and constraints inherent in that system, not from anything you’re doing (or not doing) yourself.

Practical Investigation

Deming designed the Red Bead Experiment to illustrate these very points, in a way that most people can directly relate to.

– Bob

Further Reading

Four Days with Dr Deming ~ Latzko and Saunders
95% of performance is governed by the system ~ Vanguard web page

Inventing Agile

[Tl;Dr: I invented Agile in UK / Europe, independent of the USA / Snowbird folks, circa 1994].

I was running a project in Europe when I first woke up to the value of “process” in delivering working software. It wasn’t the first project I’d been managing, but it was the first time in a corporate environment, with many stakeholders, and with developers and methods not of my own choosing. I have to say that the project was not an unalloyed success.

Upon completing my assignment and returning to England, spurred by my dissatisfaction, I explored the existing literature for ideas about how to do things better. And in my next few assignments I experimented with some of these ideas and began to evolve a coherent approach to software development.

Motivation

I had already long been motivated by a need to see folks able to realise their innate potential. I had often been appalled by the waste of human potential I had seen time and again in places I had worked. I was convinced there must be a better way, and set about finding it.

Influences

Key influences during this time included:

  • RAD (Rapid Application Development – James Martin, etc.)
  • JAD (Joint Application Development)
  • Evolutionary Development (Gilb)
  • Rapid Iterative Development
  • Risk Management (Capers Jones, etc.)
  • TQM (Crosby, Juran, Shingo et al)
  • NextSTEP
  • Modula-2 (Wirth)
  • Eiffel (Meyer)
  • Objective-C (Cox)

The Roots of European Agile

By the time I came to work with the CFO of Barclays, running some internal projects at Barclays head office, I had the kernel of an approach that today we’d label “Agile”. This was 1994.

As you may see from the influences listed above, I was already leaving the waterfall / V-model camp and beginning to favour iterative and incremental approaches.

Even in these early days, the results were outstanding.

Continuing to apply and evolve the ways of working I discovered at Barclays, I then did a tour of some of the major merchant banks in the City, where proven ideas for improving their software development results found some favour.

A couple of years later found me at Sun Microsystems’ UK Java Center, bringing these development approaches to Sun’s major corporate clients looking to transition their development teams into the Java ecosystem.

At this time I began referring to my now well-formed approach as “Jerid”.

Note on the Name

Jerid grew out of two complementary initiatives I had been running for some years named “SPEAR” and “BEAR” – Software Process Engineering And Reengineering, and Business process Engineering And Reengineering. SPEAR consisted of many of the techniques I had found useful through years of experimentation and application, packaged into a coherent whole. But SPEAR was more an umbrella concept, with different flavours of specific development approaches underneath – most notably Jerid.

In case you’re wondering, “Jerid” is a kind of javelin (throwing spear) used in games played on horseback in certain Muslim countries in the Middle East. It was also a somewhat convoluted acronym for “Java Enterprise Rapid Iterative Development”. Jerid later evolved into “Javelin”.

The Heart of Jerid

Jerid was founded primarily on ideas from risk management and rapid and evolutionary iterative development. By 1997 it had evolved to a point where, with hindsight, it looked circa 80% like Scrum was to look some years later. Two-week iterations (time boxed), sprints, sprint goals, sprint planning, retrospectives, etc.. I had independently invented “Agile” software development in Europe some years before the name itself was chosen at Snowbird, USA in 2001.

The core difference between Jerid and e.g. USA Agile/Scrum was Jerid’s emphasis on risk management. Jerid projects ensured that the major risks were identified and controlled. For me, this is the essence of any Agile approach – managing and controlling the major risks – both those common to all software development projects and those specific to each individual project.

We continued to apply and evolve Jerid during the late ’90s, at Familiar and its clients, until my departure from Familiar circa 2000.

Since then I have worked with a large number of different companies, large and small, helping them discover the fundamental principles underpinning iterative and agile approaches, and evolving practices and ways of working from those principles.

Acknowledgements

I’m very pleased to be able to acknowledge the contributions made to SPEAR and Jerid by many folks along the way. Although none of this would have happened without my input, their help and support was invaluable to me in evolving my understanding of software development, and later, the intersection of software development and general business.

Disclaimer

I’m pretty sure other folks also invented their own takes on the Agile theme before it became known by that name. Maybe even before I did. I’d be delighted to hear from anyone who believes they fall into that category.

Also please note that many of the strands of the thing that has become known as “Agile” existed long before I even got started in the field of software development methods. We all owe a debt to those many pioneers who were pushing the envelope and challenging accepted wisdom back as far as the 1960s and 1970s, if not before.

– Bob

Cognitive Function

How often do you get pissed off by interruptions and distractions? You know, when you’re zoned in on something, in a state of flow, and something happens to break the flow? Personally, when I’m writing code, I have to be in a quiet place, by myself or with my pair or mob, else I can’t get anything done for the continual distractions.

This is but one example of how easily cognitive function can be impaired.

Common sources of cognitive impairment:

  • Distractions and interruptions
  • Stress (specifically, negative stress a.k.a. distress) Cf Amygdala Hijack
  • Tiredness, fatigue, lack of sleep.
  • Multitasking
  • Poverty
  • Diet
  • Shift patterns
  • Noise and other forms of environmental stressors (lighting, odours, vibrations, exposure to particulates, elevated carbon dioxide, etc.)
  • Physiological issues (such as colds and flu, hypoglycemia, aphasia, depression, dehydration, hypertension, obesity, trauma, diabetes, Parkinson’s, POTS, dementia, hypoxia, atrial fibrillation)
  • Substance abuse (drink, drugs, etc. – short and long term effects, chronic and acute)

Wow. That’s quite a list. Seems like almost anything can impair cognitive function.

Why Does this Matter?

So why does cognitive function matter. What’s the connection with knowledge work? I’ll spell it out in case it’s not clear:

Knowledge work – such as software development – by definition involves working with our brains. If our brains are performing well (i.e. effective or relatively high cognitive functioning) then we can expect our work to go well, things to get done quicker, with fewer errors, and so on.

Conversely, when our cognitive function is impaired, our brains will take longer to accomplish tasks, come up with less effective solutions, commit more errors, and generally perform more ineffectively.

It’s also likely that with impaired cognitive function we’ll be less reflective, with less energy or capacity to spend on thinking about our work, our relationships, our behaviours, our practices, our customers, possible innovations, our needs and the needs of others, etc..

Does it sound to you like non-impaired cognitive function is something worth having? Something worth paying attention to?

Paying Attention?

So how many folks – managers, workers, organisations – pay any attention AT ALL to folks’ cognitive functioning in the workplace or whilst working? I’d suggest the answer is none, or as near none as makes no difference.

Which seems strange to me, if we truly seek our collaborative knowledge work (and workers) to be as effective as possible. Of course, that objective may be a false assumption. Maybe blissful ignorance and indifference is preferable to paying attention and taking action? Given the reluctance I’ve encountered when broaching this subject, I suspect blissful ignorance and/or indifference holds sway.

How does it go in your organisation?

– Bob

%d bloggers like this: