Archive

Improvement

Rightshifting and Quintessence 

Long-time readers of this blog will already be familiar with the concept of rightshifting. 

Shifting an organisation to the right (i.e. in the direction of increased organisational effectiveness, and towards the quintessential) is not for the work-shy or indolent. Yet the rewards are massive. 

Whilst the Marshall Model provides a general framework for such rightshifting, there’s not been a detailed roadmap describing the shifts necessary to acquire such improved effectiveness. 

My most recent book, “Quintessence”, provides just such a roadmap (or blueprint). It details the shifts in collective assumptions and beliefs necessary to become a highly effective knowledge-work organisation. Shifts of which significant outliers such as Zappo, WL Gore, Morning Star, Semco, and a host of others have demonstrated the benefits.

Go take a look and gaze in awe at what is possible in the way of improvements. 

– Bob

Further Reading

Marshall, R.W. (2018). Hearts over Diamonds: Serving Business and Society Through Organisational Psychotherapy. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Memeology: Surfacing and Reflecting On the Organisation’s Collective Assumptions and Beliefs. Falling Blossoms (LeanPub).

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub). 

Effectiveness

It’s long been observed that folks commissioning i.e. product developments have a natural tendency to believe that quality costs money. Which is to say that they tend to believe that a higher quality product costs more to develop and deliver into the market. Even though Phil Crosby put the lie to this fallacy decades ago with his observation, detailed in his book of the same name, that “Quality is Free”.

So it is with effectiveness. I’ve met many folks who unwittingly assume that having their organisations become more effective is going to raise costs, and involve increased time, attention and effort.

Again, nothing could be further from the truth. Highly effective organisations run more smoothly, more predictably and with higher productivity and significantly lower costs. This is, for me, the essence of effectiveness.

How about you? What comes to mind when you hear the term “increased effectiveness”?

– Bob

Am I the only person in the world interested in improving the effectiveness of organisations? In making organisations better places to work, better places to play, better places to learn? Is it just me? Most days it seems like it is.

The Way Forward

By way of a counterpoint to my previous post “What’s Holding Us Back“, I’m interested in the way forward for the software industry, businesses, and society in general.

It’s become delightfully obvious to me that a whole raft of helpful assumptions and beliefs constitute that way forward.

In my most recent books (Memeology, Quintessence) I detail these helpful assumptions and beliefs at length, and again in keeping with my preference for short blog posts, I’ll just summarise, here…

Here’s some of the major assumptions and beliefs helpful to enabling organisations better achieve success:

  • Generalising specialists form the core of quintessential organisations (see e.g. Paint Drip People).
  • Continual small changes in assumptions and beliefs (kaizen), with occasional larger step changes (Kaikaku) are the way to effect improvements.
  • Change is desirable, best left to serendipity, and better seen in small daily increments.
  • Dialogue is at the core of improvements, in relationships and the way the work works, both.
  • Everyone’s needs matter (at least for all the Folks That Matter). See also: the Antimatter Principle.
  • Clarity and honesty on what constitutes “success” is the only way to align folks and see everyone’s real needs are being attended to.
  • Culture is the visible by-product of the invisible set of prevailing assumptions and beliefs, and is amenable to intentional change through eg Organisational Psychotherapy (be that facilitated or via self-help).
  • There are many possible organisational structures other than hierarchy. They have all be tried at one time or another. Most have proven more successful that hierarchy.
  • Change always requires revisions to existing policies and rules. See: Innovation ALWAYS Demands We Change the Rules.
  • Talent is unnecessary when we have thriving relationships, and a focus on the way the work works.
  • Interpersonal relationships are core to success.
  • Interesting work and the prospect of community, meaning, and other “soft” elements trumps high pay as a motivator and attractant, every time.
  • Productivity ensues from optimising the way the work works, which in turn requires a focus on collective assumptions and beliefs.
  • Efficiency is a distracting red herring, effectiveness is the path to productivity and success.
  • Business problems are almost never the fault of certain individuals.
  • Breaking the organisation into parts and managing these parts separately is a recipe for significant sub-optimisation and shortfalls in success.
  • In collaborative knowledge work, intrinsic motivation is much more powerful than extrinsic motivation. The latter serves as a demotivator.
  • The social dynamic and listening are the only means to effect changes in people’s behaviours.

…and so on, and so on. 

All the above assumptions have been proven time and again through decades of research. By listening, experimenting and being interested in the science and outliers, our ignorance can be assuaged and enlightened.

– Bob

What’s Holding Us Back

It’s become painfully obvious to me that a whole raft of unhelpful assumptions and beliefs is holding us back. And has been doing so for at least fifty years.

And by “us”, I’m referring here to the software industry, businesses, and society in general.

In my most recent books (Memeology, Quintessence) I explore these beliefs in detail and at length, but in keeping with my preference for short(er) blog posts, I’ll summarise…

Here’s some of the major assumptions and beliefs I’ve recently seen holding back organisations back from the success they espouse:

  • Specialists are desirable. Generalist and generalising specialists offer no value.
  • Reorganisations are the way to effect improvements.
  • Change, if ever necessary, is better managed, and in large lumps.
  • Dialogue is a waste of everyone’s time.
  • The only needs that matter are those of the elite (CxOs, managers).
  • It’s best not to describe “success” as this would only expose the elite’s agenda.
  • Culture is what it is – it’s not amenable to intentional change.
  • There’s not other possible organisational structure than hierarchy.
  • Change, when it happens, happens in isolation, independent of existing policies and rules.
  • We must recruit and retain talent, specialist talent. Talent is indispensable.
  • Interpersonal relationships are messy, and have next to no relevance to business results.
  • High pay is the (only) way to attract and retain talent.
  • Productivity ensues from hiring talent.
  • Efficiency is top priority, effectiveness a meaningless and useless term.
  • Business problems are always the fault of certain individuals.
  • Breaking the organisation into parts and managing these parts separately is the only way to go.
  • Extrinsic motivation is much more powerful than intrinsic motivation.
  • Evidence and instruction (telling) are the only means to effect changes in people’s behaviours.

…and so on, and so on. 

All the above assumptions are, of course, false, and proven false by decades of research. Yet nobody is listening, nor interested in the science. Our ignorance is humungous.

– Bob

It’s the system (the way the work works) that determines circa 95% of an individual’s performance in their job.

Are you still “managing the 5%” (through training, coaching, motivation, appraisals, etc.)?

#Deming

Getting Along

When all is said and done, all our artifices, all our strivings, all our efforts to organise work… it’s simply about figuring our how to get along (with each other). 

If we’re getting paid but not being productive, the payers will rankle and cavil, and they and we won’t get along. If we’re producing stuff that doesn’t meed the needs of our customers, they will feel frustrated and they and we won’t get along.  If we treat some folks like pariahs or cogs in our machine, they won’t feel valued or respected, and they and we won’t get along.

There’s really no more to work, and organisations, than getting along. In Rightshifted organisations, for example, such as the quintessential ones, folks simple get along better.

What does it take for us all to get along?

– Bob

The V8 Question

There are multiple ways to open a conversation with a new client (organisation). Here’s a few I use from time to time:

The Miracle Question

Derived from Solution Focus Brief Therapy (SFBT).

Example:

This may seem like a strange question to ask, but please bear with me. Imagine going about your life as normal and heading off to sleep at the usual time.

Unknown to you, during the night, something happens – a miracle. When you wake up the following day, something exciting has happened.

The very problem that brought you to see me today is no longer there.

What would be the very first difference you would notice in your life?

See also: How to Use the Miracle Question in Therapy: 3 Examples

The Clean Language Opening Question

Example:

“What would you like to have happen?” or

“What would you like to have happen in [context]?”

And my take on the clean opening question, the Antimatter Opening Question:

The Antimatter Opening Question

The V8 Question

For a different perspective and dynamic, and for all the petrol heads out there.

A V8 engine with twin turbos

Example:

If your organisation was a V8, how many cylinders would it be firing on, at the moment?

And to appreciate a V8 firing on all cylinders: https://youtu.be/3DVPfJxr4Wo

– Bob

More Employable

Ineffectiveness is the norm (in particular in the software and collaborative knowledge work fields).

Therefore the less effective someone appears to e.g. hiring managers, the more employable they are. The ineffective fit right in, don’t challenge norms or ruffle feathers, and appear a competent “good hire” even as they join in with sustaining and compounding the organisation’s prevailing ineffectiveness.

Simple Truth

This simple truth explains why some many organisations are so poor at developing tech products, and software more generally. They unwittingly hire “good fits’ i.e. the profoundly ineffective. And never realise the productivity improvments, etc., that they’re leaving on the table.

The (modified) Marshall Model chart (below) illustrates the situation:

How might we help these organisations appreciate their dire situation? Is that even possible?

– Bob

Further Reading

Peters, T.J. and Waterman, R.H. (1982). In Search of Excellence: Lessons from America’s Best-run Companies.  Profile Books.

Marshall, R.W. (2021). Quintessence: An Acme for Software Development Organisations. Falling Blossoms (LeanPub).

We Can All Be Doing So Much Better

Looking on the bright side for 2022, there’s no real blockers to us and our organisations doing so much better in 2022.

And all it takes is reflecting upon, and surfacing, our collective and individual assumptions and beliefs.

Rightshifting

The Rightshifting chart illustrates the awesome scope for “better” in our organisations:

Most organisations cluster around an effectiveness of “1”, whereas a simple shift in our assumptions and beliefs about the world of collaborative knowledge work could take us to becoming “3”, “4” or even “5” times more effective. That sounds like “better”, to me.

Quintessential Organisations

In my recent book “Quintessence“, I describe what organisations to the right of “4”, on the above chart, look like, feel like and work like.

– Bob

The Quintessential Developer

In my recent book, “Quintessence” I write, of the Quintessential organisation, that “everybody does things differently”. By which I mean, every role in a quintessential organisation looks very different from its counterpart in more conventional organisations, even though the name of the role may be similar, or the same..

This post looks at the role of the developer, and how – in quintessential organisations – this role differs markedly from the role in more conventional organisations.

Here’s a contextualising excerpt from Chapter 2 of Quintessence:

Everybody Does Things Differently

The quintessential organisation invites everyone involved to surface and reflect on their individual and collective assumptions and beliefs about work and how work should work. Progress towards the quintessential depends on progress with respect to changing these assumptions and beliefs.

This is the foundational reason why we see so few quintessential organisations, and why making the transition to a quintessential organisation is so difficult, and so rarely achieved successfully.

Here’s a brief outline of roles that look very different from the quintessential perspective:

The Manager’s role looks very different. So different, in fact, that the term “manage” ceases to be relevant. Managers in a quintessential organisation have relinquished ideas of control, and embraced a role of enablement, resourcing and support.

The Developer’s role looks very different. So different, in fact, that “software” and “technology” cease to be relevant. Developers in a quintessential organisation have downplayed a focus on “hard” technical skills, such as coding, and embraced and learned social skills, including skilful dialogue, empathy, self-organisation and compassion.

The Tester’s role looks very different. So different, in fact, that “testing” a.k.a. “inspection” ceases to be relevant. Testers in a “quintessential organisation have have relinquished a focus on inspection skills, and embraced means of preventing defects, and ensuring that attending to the need of the Folks That Matter™️ is “baked in” to how the work works.

The Customer’s role looks very different. Customers of a quintessential organisation get to have conversations about their needs, and have those needs attended to, more often and with more clarity than customers of more traditional organisations.

Even though a rational explanation of these differences serves little purpose, and will convince no one, we’ll take a more detailed look into the rationale later in this book.

Quintessence presents my experiences from over forty years of leading, working in, and advising software development shops and companies. I invite you to find inspiration, motivation and connection from my journey. Quintessence presents an ideal approach to making money (and other things) via attending to folks’ needs

Note: I say an ideal, not the ideal. There may well be other ways of achieving the same ends.

The Quintessential Developer Role

Note: This section describes the role of developers in a quintessential organisation. That is, the adjective “quintessential” applies to the organisation within which developers work, rather than the developers themselves.

In a quintessential organisation, developers pay much less attention to “technical” competencies such as coding, and much more attention to identifying the Folks That Matter™️, and understanding their (evolving) needs (cf. the Needsscape).

Developers in a quintessential organisation (being self-organising, self-managing and self-directing) focus on understanding what needs to be done (and for whom), compared to developers in conventional (poorly effective) organisations.

Necessary developer skills, in order of significance (most significant first): 

  • Dialogue skills – for conversations with the Folks That Matter™️ about their needs, and identifying other folks that may also matter.
  • Empathy – for establishing and maintaining humane relationships with all the Folks That Matter™️. Assuming, of course, that the organisation permits developers to actually talk with e.g. customers. A fairly rare scenario, to be sure.
  • Self-organisation – absent middle managers, project managers, etc., organising the work and then assigning work items to individual developers (and teams), developers in quintessential organisations have the freedom to to organise the work, and their assignments, themselves. This can range in scope from a single work item of a few hours, all the way through to new product features and indeed whole new products.
  • Risk Management – cultivating awareness of risks, their likely impact, and identifying and implementing active mitigations.
  • Opportunity Management – one step further than risk management.
  • System thinking – for reflecting on how the work works, with a view to continuous improvement.
  • Quality – building quality into the way the works works (as contrasted with hand-offs to e.g. testers and other QC personnel).
  • Researching and Learning – to discover and apply new ideas and techniques, both regarding how the work works and new technical skills/tools..
  • Investigating solutions – especially #NoSoftware solutions. 
  • Technical skills – including various implementation technologies, such as human systems (solutions staffed by human beings), paper prototypes and implementations, and, in extremis, writing software (a.k.a. programming, coding).

To recap:

Working/playing for/with a quintessential organisation is a fabulous experience (both literally and metaphorically). But the developer role is awesomely different from the conventional developer role. Can you grok it?

– Bob

Further Reading

Marshall, R.W. (2012). So You Really Want to be an Agile Developer? [online] Think Different. Available at: https://flowchainsensei.wordpress.com/2012/05/22/so-you-really-want-to-be-an-agile-developer/ [Accessed 30 Dec. 2021].

All Agilists are Unethical

Are all Agilists unethical? This post argues that, absent objective evidence, it’s simply unethical for Agilists to claim that product and software development in the Agile fashion is reasonably effective.

The Ethics of Belief

London, April 11, 1876. There is uproar in the House. But this is not the House of Commons, rather the Grosvenor Hotel, and the furore is not political but – more unusually perhaps – philosophical.

William Kingdon Clifford – then professor of mathematics and mechanics at University College London – and the youngest ever person to be accepted into London’s elite Metaphysical Society, is presenting his inaugural paper. His audience includes the likes of Alfred Tennyson, William Gladstone, Thomas Huxley and the cream of London’s intelligentsia. The title of his paper is “The Ethics of Belief”.

Even before he finishes his reading, half the audience have stormed out of the room in protest. The remainder are on their feet, heartily engaged either in shouting him down or cheering him on.

What did the audience find so contentious about Clifford’s proposition? In his essay, he asserts that whatever someone chooses to believe cannot be exempt from the ethical judgement of others. A belief may leave someone open to a charge of unethical behaviour, depending on whether they have earned “the right to believe it”.

Ethics In the Development of Software-intensive Products and Services

London, December 2021. Waves of covid infections crash upon the bulwarks of the World’s healthcare systems. Ordinary people in all walks of life look upon the excesses of governments and businesses in a new, and distinctly unflattering light. What has happened to the traditional values of probity, social responsibility, ethics? Good questions indeed. In many quarters, scientists and specialists are regarded as pariahs.

Of course, recent events have only served to propel these issues into the public eye. In many avenues – and over many years – complacency, self-interest and greed seem to have overturned diligence, responsibility and probity. I believe we could all benefit from taking a long hard look at what we have become.

My own focus of concern is the arena of software and product development. I have seen literally hundreds of organisations in the business of developing software-intensive products and services in the course of my career. Most of these businesses have been wasting enormous amounts of time, money, effort, and human potential, through their unwittingly inefficient approaches to the practice of software development.

“…whatever someone chooses to believe cannot be exempt from the ethical judgement of others.”

And in most cases, little or nothing of any effective, practical value is done to address the situation, or if done, then not sustained.

In my experience this almost always comes about because those advising people nominally responsible for the situation – the senior executives of a company – honestly believe that Agile development approaches are effective (even though that rarely seems good enough).

So here’s the rub:

Do Agilists have the right to believe – and proselytise – that their approach(es) are as productive as possible, even if they have not gathered and considered the evidence?

Is such a belief, even when sincerely held, justifiable when these Agilists have acquired his or her belief…

“…not by honestly earning it in patient investigation but rather by stifling his doubts? And although in the end he may have felt so sure about it that he could not think otherwise, yet inasmuch as he had knowingly and willing worked himself into that frame of mind, he must be held responsible for it.”

But what if disaster (or merely loss of profit) does not befall the an Agile transformation or project? Would the Agilist be any less guilty?

“Not one jot. When any action is once done. it is right or wrong, forever; no accidental failure of its good or evil fruits can possibly alter that. The man would not have been innocent, he would only have been not found out. The question of right or wrong has to do with the origin of his belief, not the matter of it; not what it was, but how he got it; not whether it turned out to be true or false, but whether he had a right to believe on such evidence as was before him.”

Prior to Clifford, the established intelligentsia presumed that beliefs could never be examined in an ethical light. A gentleman could believe any damn thing he pleased.

Until recently, it seemed as if that presumption still held sway in many organisations. But today, William Clifford’s question comes back to haunt us. Yes, Agilists may truly believe that people working in an Agile way are being as productive as possible – but do they have any right to believe it?

About the Author

My name is Bob Marshall and I’ve been a specialist in the transformation of organisational performance – particularly in the software development and business technology arenas – for the past forty years and more.

I became interested in the field in the first place because of the egregious waste of time, money, effort and – above all – human potential that I saw time and again in organisations trying to develop software-intensive systems and products. So many people have such a poor time at work, frustrated and unfulfilled every day, in the majority of “Agile” (and other) organisations out there.

And the main reason for all this misery and waste? A simple belief that the Agile approach is beneficial. Or at least, not amenable to further improvement. Such a belief seems widespread, particularly amongst long-standing Agilists.

This distribution suggests that most software personnel have never seen software development at its best (or even, good). Their unfamiliarity with effective practice gives rise to a natural scepticism about whether things are really any better anywhere. Even people who have worked in the software industry for twenty or thirty years might never have seen software development practices anywhere near their best.

Most people will have spent their entire careers working in under-performing organisations. But some lucky few have seen for themselves that Quintessential organisations are indeed much more effective than the rest.

The Ethical and Moral Imperative

How do you feel about people wasting their time? I’m talking here specifically about the waste of effort, time and resources during the working day. There’s the obvious economic cost, of course. If employees are wasting time, by definition that’s costing their employer money. In software development, both the waste – and the cost – are often significant, but rarely visible.

However, I’m not going to dwell on this aspect in this article. Instead I want to talk about the morality of waste. Or rather, the immorality of it all.

We’ve already seen how Clifford caused uproar amongst his peers by suggesting that belief is subject to ethical scrutiny. And I’ve suggested that most Agilists’ belief that things are OK within their clients’ or employers’ software development shops fails that ethical test.

But I feel it goes further than that. Not only is Agilists’ naïve belief in the productivity of their clients’ or employers’ workforce unethical in itself, but the consequences – for individuals, the client organisations and wider society – are immoral too: waste, misery, stress, friction, conflict, disrespect, under-achievement, despondency, profligacy, demoralisation and frustration, to name but a few.

The Ethical Way Forward

So what to do? First, even before looking at the reality of the situation, on the ground, in their own organisations, I would invite responsible Agilists take a look at themselves – and their own motivations and culpability. Have they “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

Have Agilists “honestly earned the right to their belief through patient investigation” – or are they merely “stifling their doubts”?

If the latter, then I suggest Agilists are ethically bound to go look for themselves at the reality of the situation in their clients’ or employers’ organisations. Some may feel uncomfortable doing this, lacking the necessary skills, access, or even simply the time. This need be no bar, however. Various specialist organisations exist to offer the necessary intervention, audit and review services. These organisations can conduct Clifford’s “patient investigations” and furnish the objective evidence.

Having the necessary evidence in mind, executives may then take pride that their beliefs pass the ethical test.

Of course, having real evidence to hand will likely show that the client has much scope for improvement, improvements which dwarf the proposed benefits of “going Agile”.

And finally, Agilists with a new-found or renewed ethical sentiment may begin to examine their peers’ beliefs in an ethical light, too. Thus, ethical business, and a more ethical society at large, grows stronger. Or is that too much to hope for?

In closing, I leave you with the words of Bertrand Russell:

“What is wanted is not the will to believe, but the wish to find out, which is its exact opposite.“

– Bob

Golden Insights From the Gemba

A recent video (57 minutes) exploring the long-term experiences in Portsmouth City Council with the Vanguard Method. Golden.

https://beyondcommandandcontrol.com/2021/10/08/portsmouth-city-council-and-the-vanguard-method-15-years-on/

Also applies to software development (and other functions) within tech organisations. Can you see the parallels?

– Bob

 

I Literally Just Told You

Q: How do we make our organisation more effective?

I literally just told you: Quintessence.

Q: How do we change our organisation’s culture for the better?

I literally just told you: Memeology and Organisational Psychotherapy.

Q: How do we change our organisation’s culture more quickly?

I literally just told you: Hearts over Diamonds.

– Bob

Forget about product roadmaps. Far more useful are capability roadmaps.

What is a capability roadmap?

A capability roadmap outlines the capabilities an organisation needs to have in the upcoming quarters and years. Capability roadmaps are a way to frame longer-term strategy, focusing on an organisation’s potential beyond the limitations of any particular initiative.

Blueprint For Effectiveness

How would you go about explaining the factors that contribute to a highly effective software development team, group, organisation?

In Quintessence (currently 24% complete), I’ve done it for you! But do you agree with it?

I invite you to take a look (extensive free sample now available).

– Bob

 

The Organisational Psychotherapy Retrospective

Are you bored with mundane retrospectives? I know I am. And so are the teams I work with.

Scrum Retrospectives

By way of example, let’s take a quick look at the Scrum version of retrospectives.

Scrum describes Sprint Retrospectives thusly:

The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

During the Sprint Retrospective, the team discusses:

      • What went well in the Sprint?
      • What could be improved?
      • What will we commit to improve in the next Sprint?

Even thought the above description mentions assumptions, the bullet list makes no such provision. And I’ve never seen an IRL retrospective that raised the question of assumptions.

A New Hope

So here’s a new kind of retrospective you might like to experiment with – the OP Retrospective.

The OP Retrospective

The concept – and existence – of the Collective Mindset (a.k.a. Organisational Psyche) is foundational to Organisational Psychotherapy. It is the thing with which every OP therapist interacts.

Organisation Psychotherapy asserts that culture is no more, and no less, than a read-only manifestation of an organisation’s collective mindset – of its collective assumptions and beliefs. Read-only because culture cannot be manipulated directed, but only via changes to those underlying collective assumptions and beliefs.

Are development teams affected by the organisation’s culture? By their own team culture? By the organisation’s collective assumptions and beliefs? By their own team-local assumptions and beliefs? Are they in a position to shift either?

I’’d say “Yes”.

Benefits

Given the influence of collective assumptions and beliefs on communication, productivity, teamwork, joy in work, and a host of other individual, team, and organisational concerns, shifting assumptions can lead the team to a more effective place.

Means

But by what means? There’s no specific ceremony in e.g. Scrum to surface and reflect on collective assumptions and beliefs (culture). Maybe our retrospectives can, from time to time, serve this purpose?

If we wanted to use a retrospective (or a part of one) to explore cultural issues, how might we go about that?

I’d suggest my self-help Organisational Psychotherapy book “Memeology” might be one place to start. It’s stuffed full of questions that a team or group can ask themselves to explore cultural assumptions.

Here’s one example meme (meme #15, “Who Matters” – excerpted from the free sample version of the book:

15. Who Matters

Suggested Preamble

Senior managers, stakeholders, team members, the Big Team, customers, users – call them what you will, they’re the people that we’re doing the work for. They’re the people to whom we deliver the fruits of our efforts. They’re the people whose reactions – and emotional responses – decide the success or failure of our endeavours. They’re the people whose needs matter to us.

By way of example, here’s a partial list of the groups and individuals that are candidates for inclusion on a list of who matters:

  • Your organisation’s senior managers and executives (“the higher-ups”).
  • Your organisation’s Core Group.
  • Your immediate manager a.k.a. “boss”.
  • Your project manager (for folks working in project teams or on a project).
  • Your product owner or manager (for folks working in product teams or on a product).
  • Your development team (the team in which you are a member).
  • Other development teams.
  • Operations people (the folks that keep your organisation’s websites, production servers, etc., up and running).
  • The Programme Management Office (PMO – if your organisation has such a thing).
  • Testers (when separate from the development teams).
  • The Process Group (the folks who stipulate how the work should work, or who support teams in their ownership of the way the work work – when separate from the development teams).
  • Quality Assurance (QA) folks (when present).
  • Your business sponsor(s) (internal budget holder, etc.)
  • Other people across your organisation.
  • Your (end) customer(s) (and their purchasing or procurement departments).
  • Commercial partners.
  • Regulators.
  • Wider society.
  • The planet (Gaia).
Suggested Opening Question

Who matters?

Suggested Follow-on Questions

How do we presently go about deciding who matters (and who doesn’t)?

How well (or poorly) does our approach to deciding who matters serve us?

How often do we fail to focus on key groups?

Can we safely exclude some people and / or groups from consideration?

Suggested Wrapping Up

What have we learned or come to realise, maybe for the first time, in our conversation here today on “who matters”?

How far apart or together are we now on the subject of who matters? Has airing the subject eased our concerns?

Is it time for action on who matters? And if so, how might we go about setting some action(s) in train?

Further Reading

Kleiner, A. (2003). Who Really Matters. Currency.

– Bob

 

 

%d bloggers like this: