Antimatter principle

We’re Still Working in the Dark Ages


Medievalism is a system of beliefs and practices inspired by the Middle Ages of Europe, or by devotion to elements of that period. Closely related to and encompassing Feudalism, and the Manorial system.


Medievalism’s foundations include Faith, Seigneuriage, and land lordship.


Despite many legal and social changes since the Middle Ages, from the perspective of folks working in organisations there’s not much difference between serfdom then and employment today. Employees are hired and remain employed at the whim of the Lords of the organisation, and dismissed with as little thought – or maybe even less thought – than serfs.

The relationship between employer and employees remains predominantly one of power-over. And although a relationship, it’s hardly ever a humane relationship. And thus hardly ever a positive contributor to organisational effectiveness.


Whilst any kind of universal solution remains a long way off, and dependent on widespread social change, individual organisations can address the issue and consequences through deploying ideas like nonviolence, the Antimatter Principle, and redefining the collection of The Folks That Matter. Above all, though, progress depends on us recognising the medievalism implicit in the way our work works, and our relationships with that, and each other. Are you bovvered?

– Bob

Further Reading

Kahane, A. (2010). Power and Love: A Theory and Practice of Social Change. Berrett-Koehler Publishers, Inc.


Telling hundreds or thousands of people [something, anything] is never going to result in anything other than bitterness and conflict. And showing them will have about the same (lack of) impact.

Would you be willing to arrange things such that they might invite themselves to find out for themselves?

Psychological Safety – Oh! The Irony

The march of time seems to have judged “psychological safety” as a passing fad. Not that it’s an irrelevant idea – far from it. 

I suspect psychological safety gained some acclaim because everybody wanted it for themselves. “Yes, please. I feel anxious, exposed and at risk when I speak out, so I’d really appreciate some psychological safety, thank you.”

We’ll skip over the unlikely prospect of any managers being interested in providing an environment of psychological safety (why would they need to do that?) and get straight to the irony.

The Irony

I’ve spoken with some number of colleagues who all attest to feelings of anxiety, being exposed and being at risk of judgement by peers in the software community when they speak out about certain, possibly contentious or unpopular issues. 

Aside : I suspect it’s more often fear of the consequences of speaking out that’s at the root of these anxieties, rather that fear of being judged per se. 

The irony being, of course, that whereas individuals are fine with accepting psychology safety provided by others, they’re far less interested in extending psychological safety in turn.

What are you doing on a daily basis to extend psychological safety to others?

– Bob

Further Reading (1 June 2015). Tired of Being Judged? Try This. | Psychology Today. [online] Available at: [Accessed 13 Sep. 2021].

“It is not enough that you should understand about applied science in order that your work may increase man’s blessings. Concern for the man himself and his fate must always form the chief interest of all technical endeavors; concern for the great unsolved problems of the organization of labor and the distribution of goods in order that the creations of our mind shall be a blessing and not a curse to mankind. Never forget this in the midst of your diagrams and equations.”

~ Albert Einstein

The Antimatter Principle invites us to:

“Attend to the needs of the Folks That Matter™

We might choose to amend this to read:

“Attend to the needs of the Holons That Matter™”

This modification is brought to you courtesy of Adam Kahane and his book “Collaborating with the Enemy: How to Work with People You Don’t Agree with or Like or Trust“.

How To Predictably Deliver Great Software

What is “Great Software“?

Great software is software that meets the needs of the Folks that Matter™. The more needs met, and the more comprehensive the coverage of all the Folks That Matter, the “greater” the software.

Aside: I invite you to consider how the Needsscape plays into the above definition.

Ironically, when we dig into the needs of all the Folks That Matter, we find that great software often means no software. Strange?

Further, we regularly find that the needs of the developers and ancillary development staff trump the needs of the users and other customers. So we get software, even though users and other customers rarely need it.


Let’s assume for a moment that predictability (e.g. due date performance) is among the needs of some of the Folks That Matter. In this case, predictability is part of the “great” we were just talking about.

Predictability comes from anticipating and managing risks – actively, deliberately and competently. Formal approaches such as set-based concurrent engineering (SBCE) help manage the risk of finding oneself unable to bring a particular aspect of the solution to completion, for a variety of reasons. Identifying the Folks That Matter and their needs helps manage the risks involved in building the wrong thing, as does consideration of the Cost of Focus. Predictability demands we keep on top of all significant risks. (See: the All Holes in the Boat principle Cf. Gilb).


Know what needs you’re attending to. And whose.
This is not always possible, a priori. So identify as many of the Folks That Matter as you can (expect more to come to light as you proceed). Concurrently, investigate their needs through quickly delivering early exploratory things such as mock-ups, paper-prototypes, sketches of various kinds, and conversations. “Quickly” here means in a few hours, or days at most. Expect to have to iterate on this.

Many developers assume that someone else will be handing them a list of the Folks That Matter along with a definitive statement of the needs of those folks. If that other party is competent and sufficiently resourced, this can work. I’ve never seen it. I prefer to have the developers own this crucial information, and the gathering and updating thereof too. This is not popular in many organisations, shining a light as it does on the inadequacies of the way the work works, the management, the analysts, the product owner(s) and so on.

In parallel with these investigations, make a start on building the solution. In particular, those parts of the solutions which seem relatively stable, and where you feel the needs are relatively well understood. This can even involve writing some software – if you really must. Manage the risk of not knowing how to build certain things through e.g. “Spikes” and other risk mitigations.


“Surely there’s more to it that this?’ I hear you ask.
Well, actually, no. We’ve been hoodwinked into thinking that software development is “the most complex endeavour known to man” ~ Jim McCarthy

Actually, if tackled appropriately it’s quite a pussy cat. People make it much more difficult than it really is. Will the industry ever grow up?

– Bob

Further Reading

Waltzing With Bears ~ Tom Demarco and Tim Lister
Sketching User Experiences ~ Bill Buxton
Principles of Software Engineering Management ~ Tom GIlb
Beyond Command and Control ~ John Seddon

First Principles

I was reading the other day about how Elon Musk “reasons from first principles“. And I was thinking, “Well, d’oh! Doesn’t everyone do that? I know I do.” And then, upon reflection, I thought, “Hmm, maybe most folks don’t do that.” I certainly have seen little evidence of it, compare to the evidence of folks reasoning by extension, and analogy. And failing to reason at all.

Now, allowing for journalistic hyperbole and the cult of the celebrity, there may just still be something in it.

So, in case you were wondering, and to remind myself, here’s some first principles underpinning the various things in my own portfolio of ideas and experiences:

The Antimatter Principle

The Antimatter Principle emerges from the following basic principles about us as people:

  • All our actions and behaviours are simply consequent on trying to get our needs met.
  • We are social animals and are driven to see other folks’ needs met, often even before our own.
  • We humans have an innate sense of fairness which influences our every decision and action.


Flowchain emerges from the following basic principles concerning work and business:

  • All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
  • When Cost of Delay is non-trivial, the speed of bringing new products and feature to market is significant.
  • Flow (of value – not the Mihaly Csikszentmihaly kind of flow, here) offers the most likely means to minimise concept-to-cash time.
  • Autonomy, mastery and shared purpose affords a means for people to find the intrinsic motivation to improve things (like flow).
  • Building improvement into the way the work works increases the likelihood of having sufficient resources available to see improvement happen.


Prod•gnosis emerges from the following basic principles concerning business operations:

  • All commercial organisations – excepting, maybe, those busy milking their cash cows – are in the business of continually bringing new products, or at least new product features and upgrades, to market.
  • Most new products are cobbled together via disjointed efforts crossing multiple organisational (silo) boundaries, and consequently incurring avoidable waste, rework, confusion and delays.
  • The people with domain expertise in a particular product or service area are rarely, if ever, experts in building the operational value streams necessary to develop, sell and support those products and services.  


Emotioneering emerges from the following basic principles concerning products and product development:

  • People buy things based on how they feel (their emotional responses to the things they’re considering buying). See: Buy•ology by Martin Lindstrøm.
  • Product uptake (revenues, margins, etc.) can be improved by deliberately designing and building products for maximum positive emotional responses.
  • Quantification serves to explicitly identify and clarify the emotional responses we wish to see our products and service evoke (Cf. “Competitive Engineeering” ~ Gilb).


Rightshifting emerges from the following basic principles concerning work in organisations:

  • The effectiveness of an organisation is a direct function of its collective assumptions and beliefs.
  • Effectiveness is a general attribute, spanning all aspects of an organisation’s operations (i.e. not just applicable to product development).

The Marshall Model

The Marshall Model emerges from the following basic principles concerning work in organisations:

  • Different organisations demonstrable hold widely differing shared assumptions and beliefs about the world of work and how work should work – one organisation from another.
  • Understanding which collection of shared assumptions and beliefs is in play in a given organisation helps interventionists select the most effective form(s) of intervention. (Cf. The Dreyfus Model of Skills Acquisition).

Organisational Psychotherapy

Organisation psychotherapy emerges from the following basic principles concerning people and organisations:

  • The effectiveness (performance, productivity, revenues, profitability, success, etc.) of any organisation is a direct function of its collective assumptions and beliefs about the world of work and how work should work.
  • Organisations fall short of the ideal in being (un)able to shift their collective assumptions and beliefs to better align with their objectives (both explicit and implicit).
  • Having support available – either by engaging organisational therapists, or via facilitated self-help – increases the likelihood of an organisation engaging in the surfacing, reflecting upon, and ultimately changing its collective assumptions and beliefs.

– Bob

5x Productivity

People ask me where does the 5x uplift in productivity come from when software development is done right. It’s not one factor, but a combination of a bunch of factors that together cause the uplift.

These factors include:

  • Motivated people. As we now know, forget extrinsic motivators – these only serve to reduce productivity in collaborative knowledge work. Intrinsic motivation’s the thing.
  • The social dynamic. This delivers the environment for employee wellbeing and organisational health – the environment in which joy emerges and intrinsic motivation can let rip.
  • Teaming.
  • Defect prevention. It’s more productive to prevent defects before they happen, than to find them after they have.
  • Change. Making experiments and finding new, better ways of doing things, on a regular basis.
  • Skilled dialogue. Understanding emergent problems and collaborating on quickly finding neat solutions requires people to talk with each other. Skilled dialogue has a part to play here.
  • Courage. Courage to attempt novel approaches. Courage to buck trends. Courage to speak up and tackle thorny issues.
  • Attending to folks’ needs. (Key impact: improved social dynamic).
  • Identifying all key Folks That Matter, and their critical needs. And then attending to those needs (and no others). “Maximising the amount of work NOT done.”
  • #NoSoftware. Writing as little software as possible. And minimising the cost of each component of a solution by intelligently selecting the appropriate solution tech (often, not software).
  • Quantification. Bringing clarity to all aspects of work by elimination confusion of qualitative terms by using quantification.
  • Structure. Uplift morale, engagement and discretionary effort with organisational structures – such as self-organising, self-managing teams and flat organisations – suited to collaborative knowledge work.
  • Physical environment. Having available a range of workspaces suited to the modalities of collaborative knowledge work.
  • Tooling. Provide tooling best suited to the work style and preferences of each individual.
  • Hiring for what matters. You know what matters, don’t you?
  • Relationships. See: Social dynamic.
  • Remuneration. Pay people enough that their living expenses are no issue for them. Don’t pay so much that you attract mercenaries. Ideally, give people agency to each decide their own personal wages, hours, places of work, terms and conditions, etc.
  • Treating people like trusted adults. See also: Social dynamic.
  • Flow. Focus on economies of flow, rather than e.g. economies of scale.
  • Failure demand. Reduce and then eliminate failure demand.
  • Shared purpose. Allow folks a real say in the purpose of the organisation. To invite buy-in and a sense of personal ownership.
  • Whole-systems thinking. Steer the organisation as a whole, not as compartmentalised subunits.
  • Monitor variation, uncover the causes and reduce or eliminate.
  • Learning. Invite people to develop themselves (and others). Provide support of all kinds for this.
  • Replacing “work” with “play” (Cf Schrage ~ Serious Play).
  • Building eustress, reducing or eliminating distress.
  • Identifying and managing risks, actively and continuously .
  • Reducing and eliminating conflicts – and the inevitable waste – caused by differing assumptions and beliefs about how work should work.
  • Technical skills and competencies. Yes, there is a place for having folks that know what they’re doing.
  • Working fewer hours. The Rule of Four: Four day weeks or 4 hour days.
  • Obliquity: Don’t chase productivity. 5x productivity comes from chasing the things that result in productivity. In fact, better to forget the notion of productivity entirely.
  • Measuring. By all means measure. But never measure individuals nor teams. Invite folks to identify what matters to the Folks That Matter, and invite them to come up with measures for those things.

What did I miss?

A long list, to be sure. But then, software development always has been a complex adaptive system. If you want simpler: just attend to folks’ needs.

– Bob


An Overabundance of Planning

“The minimum you can get away with is always far less than you think you need.”

~ @FlowchainSensei

A Common Objection

“We’d be inundated if we attended to even a fraction of all the needs of all the Folks that Matter” is one common objection I regularly hear to the Antimatter Principle.

And yet, in most software development projects, the team is inundated with things to do, based on “the Plan” – regardless of whether that’s a big up-front plan, or an incremental plan (running backlog) assembled by degrees over time. A mountain of work (features, tasks, etc.) stretching out to the misty blue horizon, and back to the dawn of (project) time.

Research (see, for example, Capers Jones’ book “Assessment and Control of Software Risks”) highlights that much of what gets planned, and thus gets done, is pointless and proves unnecessary when (finally) made available to users. This reality is also reflected in the now highly controversial series of CHAOS reports from the Standish Group.


So, I regard the aforementioned objection as specious. Not intentionally so, most often. But specious never the less.

For me, “Attending to Folks Needs” means doing the least (responsibly) possible, and then seeing if the need (or a need) of the folks in question has been met. Most often those need(s) will not have been entirely met – and maybe not even partially – but the team then has the option to have another go – based on some solid information.

This approach has at least two benefits:

  • The person (customer, user, etc.) in question will feel that they matter, that their opinion counts, and that the team is focussed on them as a human being.
  • The team will have solid information upon which to validate or invalidate their earlier guesses (and yes, they will always be guesses until so validated).

At some point, it’s likely all the critical needs of all the Folks That Matter will have been met. And that point will like have arrived much earlier that with more traditional approaches. And with reduced costs and effort.

– Bob


Some readers may argue that the above approach looks a lot like Agile. In practice (sic) I see enough differences to reject that comparison. For a deeper insight into why, may I invite you to consider #NoSoftware.

Artefact Driven Delivery

My preference when approaching solution delivery (I use that term in preference to software delivery, because #NoSoftware) has for the past 25 years centred on artefacts as opposed to tasks. I’m not going to retread here the arguments in favour of the artefact as the unit of progress. This post covers the use of artefacts in incremental development environments, and lists the core artefacts we use in our approach to solution delivery.

Incremental Delivery

Delaying work on implementing and delivering a solution until we have fully defined the requirements, designs, etc., for that solution magnifies the Cost of Delay, defers feedback significantly, and inflates other risks too. Yet we don’t want to skip having clear requirements and designs, either.

The approach we adopted starting circa 1994 is to establish a set of standard artefacts, at the outset of work on each new solution. From Day One, these artefacts will be empty scaffolds, based on standard templates, each artefact being elaborated just-in-time, immediately in advance of their contents being needed for implementation and delivery purposes.

In this way, we avoid B*UF (e.g. Big Design Up Front, Big Requirements Up Front, etc.) and the delays and risks associated with a Big Bang approach.

Standard Artefacts

The following is a list of all the standard artefacts we create on Day One of the inception of each new solution on which we embark. Note that each artefact is based on a standard template, with, from the outset, little or no solution-specific content (i.e. empty).

  • Control Document
  • Articles of Understanding
  • Glossary of Terms
  • Statement of Purpose
  • Case for Action
  • Vision
  • Folks That Matter™ and their Needs
  • Risk Parade
  • Top Risks
  • Functional Requirements
  • Non-functional Requirements aka QQOs
  • Critical Success Factors
  • Feature Schedule
  • Quality Plan
  • Test Plan
  • Change Control
  • Cycle Plans
  • Cycle Reviews

Artefacts and Deliverables

We share some or all of the above artefacts with our clients (the folks on whose behalf we are developing solutions) continually, and at their request. These artefacts are available for sharing throughout the duration of the development. And serve as a running history of the endeavour, too. The deliverables of any solution (code, data, policies, documentation, configs, databases, etc.) augment these standard, evolving artefacts. Typically, a set of deliverables will fall out of the work according to some cadence or rhythm (for example, weekly or every two weeks).


For a fuller (if rather dated) explanation of each particular artefact (some now carry slightly different names), see the Javelin white paper.

In a following post I’ll be showing how you might insinuate the Antimatter Principle into your existing approach to developing solutions, using the Artefact Driven Delivery approach.

– Bob

Six FAQs Explored

Recently, Adelbert Groebbens (@agroebbe) made an observation on Twitter to the effect that getting other people to understand what we’d like them to understand is a fool’s errand. He illuminated the point with a reference to my Six FAQs post. Al Shalloway expressed his disagreement with many of the points therein. This post explores the subject, via a dialogue between Al and myself, conducted over email recently, and in the context of the original Six FAQs post.

Note: the # numbers relate to the numbered points in Al’s original tweets.

The Dialogue

@alshalloway: (Opening): Thanks. but i disagree with most of the points there [in the original Six FAQs post].

@FlowchainSensei (response): Thanks Al for providing your take on this post. Maybe you’d be willing to enter into a mutual exploration of the subject of e.g. motivation? I guess your comments (provided via Twitter and copied, below) reflect your experiences when working with developers and teams? Likewise, my original post [link] reflects my experiences in similar environments (with a little borrowing from Bill Deming, Russell Ackoff, Marshall Rosenberg and Carl Rogers, to name but a few). It comes as no surprise to me that our experiences differ somewhat, and that our respective conclusions differ likewise. That’s not to say I’m right, or you’re right – we could both be right. Or wrong. Or somewhere in between.

The Annotated Original Post 

Questions I’m frequently asked about software and product development organisations.

Q1: How can we motivate our workers?

A1: You can’t. [see: Al’s #1 follow-up comment, below] Oh, you can dream up incentive schemes, bonus packages, and so on, but there’s plenty of research – and experience – to show that such attempts at extrinsic motivation of knowledge workers only make folks’ performance on the job worse. On the other hand, intrinsic motivation is very powerful – but that comes from the workers themselves. The only thing you can do is to work on creating an environment where maybe, just maybe, some folks feel a little better about themselves, their colleagues, and the common purpose. And hope – yes hope – that some intrinsic motivation emerges, here and there. You can’t change someone else’s intrinsic motivation – only they can do that.

@alshalloway: #1:  Pretty much agree but don’t like tone. Most workers will respond to not being de-motivated. the “maybe, just maybe” is what i don’t like.

@alshalloway: #1: (Follow-up): you can’t motivate, you can only stop demotivating. In other words, you can’t motivate them, but you can do other things that are useful. 

@FlowchainSensei: #1: I guess your assessment of the “tone” here differs from mine. How often do e.g. managers or others responsible for the workplace “environment”, when attempting to cultivate a climate conducive to intrinsic motivation, succeed in those attempts? My experiences suggest “occasionally”. I guess you concur on the main point here: that intrinsic motivation can only come from the folks themselves (the emergence of same being aided by efforts to reduce or remove demotivators – shades of Drucker, Herzberg)? 

@alshalloway: Agreed that most managers don’t do this [attempt to cultivate a climate conducive to intrinsic motivation]. But much of that is because it’s never been explained to them [as] a new role they can fill.

@FlowchainSensei: Explaining presupposes they’re motivated to listen to explanations. I’m minded of the following quotations:

“Most of what we call management consists of making it difficult for people to get their work done.”

~ Peter Drucker 

“If you want people to do a good job, give them a good job to do.”

~ Frederick Herzberg

Q2: How can we change the organisation’s culture?

A2: You can’t. [see: Al’s #2 follow-up comment, below] Culture is read-only. A manifestation and a reflection of the underlying, collective assumptions and beliefs of all the folks working in the organisation. To see any cultural changes, you have to work on – by which I mean work towards a wholesale replacement of – this underlying collective memeplex. And that involves working with peoples’ heads, and in particular, collective headspaces. You can’t change other people’s assumptions and beliefs – only they can do that. 

@alshalloway: #2: you can’t change an org’s culture directly, but you can change it indirectly. See my post “Improving Your Company’s Culture”. 

@alshalloway: #2: (Follow-up): you can’t change culture directly, but there are ways to do it indirectly. You can’t change it directly since culture is a result of many things in your company.

@FlowchainSensei: #2: I totally agree that “culture” can be changed indirectly (but not directly). To elaborate on this question, I propose that changing culture through examining assumptions and beliefs (more specifically, supporting folks who are interested in getting together to examine their own *collective* assumptions and beliefs) offers a way forward. For which see: Organisational Psychotherapy.

@allshalloway: I don’t think you need to change minds directly. Rather change how they [people] work.  It’s consistent with the idea “it’s easier to work your way into a new way of thinking than to think you’re way into a new way of working.”

@FlowchainSensei: I’d clarify that as “I don’t think you can change minds directly. Rather enable and encourage change to how the people doing the work choose to work. (See also:The People vs System Conundrum).

Q3: How can we change the mindset of managers?

A3: You can’t. Managers – anyone, really – will only change their mindset when they see how their present mindset is ineffective at getting their needs – and the needs of others – met. Change (of mindset) is a normative process – it emerges from direct personal experiences of e.g. the way the work works now – and the problems inherent therein. You can’t change someone else’s mindset – only they can do that.

@alshalloway: #3: I’ve changed mindsets by guiding people through their beliefs and showing them better ones. I’ve had special training in this.

@alshalloway: #3: (Follow-up): changing mindset is only possible when people are open to it.

@FlowchainSensei: #3: I agree with your follow-up statement. It’s been my experience that folks have difficulties when left on their own in this regard, even when open to the idea of “changing mindsets”. I have found that help, or support, or (your term) guidance can be valuable here. Hence, btw, Organisational Psychotherapy (support-for-changing-assumptions-and-beliefs-as-a-service).

@AlShalloway: Changing mindsets is difficult, and even when possible, takes a long time. It is important to show managers new opportunities and new ways they can interact with the people they work with.

@FlowchainSensei: When and if these managers are motivated to see and learn – see Q1. 

Q4: How can we get teams to take responsibility?

A4: You can’t. You can threaten, cajole, plead, bribe, appeal to folks’ better nature, etc. But again, research and experience both show these only serve to undermine folks’ goodwill and commitment. If you need folks to take more responsibility, maybe the best way is to just be honest about that, explain your need, and make a refusable request? What would you like the reason to be for them doing as you request? You can’t change someone else’s willingness to take responsibility – only they can do that.

@alshalloway: #4. Pretty much agree. But again, it’s the skeptic’s tone i object to. Many are ready to take responsibility, but like motivation, we’re de-motivating them to do so.  You could argue we agree – but it’s not clear.

@alshalloway: #4: (Follow-up): You can’t get people to take responsibility, but for those that are willing, you can remove the barriers to it.

@FlowchainSensei: #4: I guess our experiences differ here. I wonder how much that difference has to do with geographies and national cultures (I.e. UK vs USA)? In my experience (UK, and Europe too), many are not ready/willing to take responsibility, often through long experience of being punished or sanctioned for attempting to do so, or even for simply suggesting it. Is “Learned helpless” more prevalent in the UK, I wonder? I agree wholeheartedly with your follow-up statement.

Q5: How can we get managers to trust their teams?

A5: You can’t. Managers will only choose to trust their teams – or anyone else – if they find they have a need to do so. And that need only becomes obvious enough to spur action when managers come to understand just how trust helps them get some of their other needs met better. You can’t change someone else’s willingness to trust others – only they can do that.

@alshalloway: #5 Building trust is not easy but it’s possible. Most of the way Agile does it doesn’t work. You can’t presuppose it [trust] or blame people for not having it. Lean management can be helpful here.

@alshalloway: #5: (Followup): You have to build trust, and not everyone is willing to have this built.

@FlowchainSensei: #5: Agreed, especially with your observation that there are some folks who are, on the face of it, unwilling to participate in trust-building. I would love to hear more about the aspects of Lean management which you have in mind. For myself, I have found the Antimatter Principle and Nonviolent Communication both useful in trust-building efforts.

@alshalloway: Trust grows over time as people work together. An expectation that managers will all of a sudden trust their teams is doomed for disappointment. But we can teach managers how to work with people to build trust. Why am I not trusting their [the manager’s people] judgement? What is it that people need to know?

@FlowchainSensei: Agreed. Again, allowing for managers being willing (or unwilling) to be “taught”.

Q6: How can we develop people’s competencies?

A6: You can’t. You can, however, create conditions where those folks who want to develop their own competencies can do so more easily. So the question then becomes, how can we get folks to want to develop their own competencies? Which is Q1 (see above). You can’t change someone else’s willingness to learn – only they can do that.

@alshalloway: #6. Your title is inconsistent with what you say. You admit to being able to change competency if they are willing to learn. So it’s not possible.

@alshalloway: #6: (Follow-up): You can only improve people’s competencies when they are already willing to learn. 

@FlowchainSensei: #6: I’m unsure as to the meaning of your original comment. If your follow-up comment serves as a clarification, then I agree entirely. 

In a nutshell, the direct answer to all the above questions is: you can’t. But you can do at least one thing to make progress on all these questions: consider the Antimatter Principle.

Are you willing to be that radical? For that is what it boils down to. 

“We can’t solve problems by using the same kind of thinking we used when we created them.”

~ Albert Einstein

– Bob


@alshalloway: (Closing) I object mostly to the skeptic curmudgeonly style of the posts – the absolutism of it.  

@FlowchainSensei: (Closing): I guess I’m well-known and loved for my skeptical, curmudgeonly style. :}

Cost of Focus Revisited

[Recent conversations suggest that my post on Cost of Focus failed to explain the idea clearly enough for readers to grasp easily or quickly. As, for me at least, it’s a simple idea, I thought I’d summarise it in brief with a new post (this one).]

Cost of Focus

Let’s start with a definition in a nutshell:

Cost of Focus is the cost incurred when we fail to include key stakeholders* in our deliberations**.

* I generally refer to these folks, collectively, as The Folks That Matter™.
** By deliberations, I have in mind what old-school folks call “requirements capture” or “requirements analysis”, and what I, nowadays, refer to as “needs investigation”.

Put another way:

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs.

Note: I could have chosen the name “Cost of Flawed Focus” (the cost of focussing on less relevant stakeholders and less relevant requirements), but this seemed a little less snappy than “Cost of Focus”.

Typically, the costs in question accrue from rejection of part or all of the delivered project / system / product / software application by one or more key parties (such as users) whose needs have not been adequately addressed  – and these costs can be massive. In any number of cases, whole systems have had to be abandoned because one or more key stakeholder groups have refused to use the new system. And even when not totally abandoned, oftentimes major costs have accrued from the delays and extra work required to remediate the original errors of focus. (See also Cost of Focus’ kissing cousin – Cost of Delay).

The Folks That Matter™

[The following excerpt first appeared in my blog post The Folks That Matter™. I repeat it here for the convenience of the reader:]

Cost of Focus

Don Reinertsen states that the Cost of Delay – the financial or economic cost of delaying a given feature by prioritising another – is rarely considered in most organisations. Put another way, the way in which delivery priorities are selected and adjusted, the frequency and means of such adjustments, etc., are rarely discussed, and rarely even discussable.

I propose that Cost of Delay is a subset of the wider question stated above, i.e. the question of Cost of Focus.

By definition, we are failing to meet some folks’ needs when we choose to or otherwise exclude certain folks with their particular needs from the set of The Folks That Matter™.

Maybe those excluded folks and their needs are indeed irrelevant, or their exclusion has little impact – financial or otherwise – on the success of our endeavour. But maybe, contrariwise, some of those excluded needs are in fact critical to our “success”. How would we know? The arguments for Cost of Focus are much the same as for its golden child, Cost of Delay.

FWIW, I’ve seen countless projects stumble and “fail” because they inadvertently omitted, or chose to omit, some crucial folks and their needs from the their list of The Folks That Matter™. Get Cost of Delay wrong (prioritise less valuable features), and we lose some money. Sometime a little, sometime a lot. Get Cost of Focus wrong, and we more often lose big time. Cost of Focus often has a much more binary, black-and-white impact.

What is Cost of Focus?

Cost of Focus is a way of communicating the impact – on the outcomes we hope to achieve – arising from excluding or including specific folks and their needs. More formally, it is the partial derivative of the total expected value with respect to whose needs we focus on.

“Cost of Delay is the golden key that unlocks many doors. It has an astonishing power to totally transform the mind-set of a development organisation.”

– Donald G. Reinertsen

Similarly, I’d say that unless and until we have a handle on Cost of Focus, the golden key of Cost Of Delay remains firmly beyond our grasp.

Put another way, until we have a means for deciding to whose needs to attend, the particular order in which we attend to those needs (cf. priority, Cost of Delay) is moot.

– Bob

Further Reading

Cost of Focus ~ Think Different blog post
The Folks That Matter™ ~ Think Different blog post
Cost of Delay ~ Wikipedia entry

Structurally Broken

“When you have a system in which structural failure is embedded, nothing short of structural change will significantly improve it.”

~ George Monbiot

He was talking about the UK’s transport infrastructure, but I’ve long believed the world’s “Software Industry” system is structurally broken, too. Even the very name “software industry” signals dysfunction. (Of course, this observation applies to many industries, not just software).


“The great Harvard marketing professor Theodore Levitt used to tell his students, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!” Every marketer we know agrees with Levitt’s insight. Yet these same people segment their markets by type of drill and by price point; they measure market share of drills, not holes; and they benchmark the features and functions of their drill, not their hole, against those of rivals.”

~ Clayton M. Christensen

We’ve heard time and again that people (customers, the general public) don’t want software, they want the utility that software can bring. Yet we call our industry the software industry, condemning us to build and deliver stuff that our customers don’t want. Granted, “that cat’s outa da bag” as Lt Columbo would say. Renaming the whole industry as something like “the pain solving industry” or the “attending to folks’ needs” industry ain’t going to happen any time soon, if ever.


Why do we describe the <name to be argued over> field as an “industry” anyways? Images of factories and satanic mills and slave plantations and the Apple “1984” advertisement come to mind. “Art” is rarely labelled as an industry, for example.

Structural Change

So what kind of structural change or changes might bring about some improvements?

#NoSoftware points the way. Analogous to the Paris 15-minute city idea (by implication, #NoCars).

And until customers stop asking for drills (software) and begin explicitly asking for holes (their needs met) we’ll likely not see much change.

What kind of structural changes can you envisage, suggest?

– Bob

Further Reading

Beyond Command And Control – A Book Review ~ Think Different blog post


Why We’re All So Angry All The Time

In his book “The Surprising Purpose of Anger” Marshall Rosenberg tells us that anger stems from situations where our needs are not being met. When a need is unmet, we’re likely to feel frustrated and react aggressively (see: Blair, “Considering Anger from a Cognitive Neuroscience Perspective” . And, being human, we’re also likely to look for other people to blame for our needs going unmet.

That may be so. Indeed, Rosenberg’s perspective is a key element informing the Antimatter Principle.

But I have another theory. Or at least, a complementary theory. What if we’re so angry all the time – at a whole host of different things – because we have a need to feel angry? What if we find some real joy, delight – or at least catharsis – in feeling angry?

The theory: We’re all so angry all the time because we like it that way. We delight in the rush of adrenaline and flow of blood to the amygdala – and related parts of the brain – that accompanies our feelings of anger.

This might help explain some of the behaviours I see time and again in work and life. And note in myself, too.

“There’s something delicious about finding fault with something, Especially when our egos are involved (which is nearly always the case), we may protect our anger. We justify it and even feed it.”

~ Perma Chodron

Moral Imperative

We see lots of self-help articles about moderating or dealing with our anger. I suspect an underlying moral imperative along the lines of “anger is bad”. I don’t subscribe. Anger, like any other emotion, strikes me as neither bad nor good – it just IS. Of course, emotion-led responses borne of anger can lead to unfortunate outcomes – such as deterioration in our relationships with others. Which we probably would find useful to avoid, not least in the context of the workplace.


Some research suggests that when we attempt to tackle our emotional state head-on, it only makes things worse:

“…when experimental subjects are told of an unhappy event, but then instructed to try not to feel sad about it, they end up feeling worse than people who are informed of the event, but given no instructions about how to feel. In another study, when patients who were suffering from panic disorders listened to relaxation tapes, their hearts beat faster than patients who listened to audiobooks with no explicitly ‘relaxing’ content. Bereaved people who make the most effort to avoid feeling grief, research suggests, take the longest to recover from their loss.”

~ Oliver Burkman


In conclusion, may I suggest we recognise and acknowledge the feeling, embrace the delicious joy of anger, use it as fuel for our spirit, and don’t get caught up in moralistic judgments of ourself or the emotion. And remember, we don’t have to ACT on our anger.

– Bob

Further Reading

Considering Anger from a Cognitive Neuroscience Perspective ~ R. J. R. Blair
The Surprising Purpose of Anger: Beyond Anger Management: Finding the Gift ~ Marshall Rosenberg
Anger And Domination Systems ~ Marshall Rosenberg
How To Get Rid Of Anger: 3 New Secrets From Neuroscience ~ Eric Barker
Buddhism’s Solutions for Anger ~ Barbara O’Brien
The Power of Humane Relationships ~ Think Different blog post

Better Antimatter Customers

[Some years ago I wrote a post entitled “Better Customers“. This is an update of that post, reframed using the AntimatterPrinciple]

More effective organisations need better Folks That Matter™. Where “better” means more demanding discerning. Less gullible.

Folks that demand their needs are met, or as a minimum, attended-to, not tech, nor features, nor hand-wavy “value”.

Folks that refuse to pay when their needs are ignored, met poorly, or not addressed at all.

Folks that hold a healthy skepticism for unevidenced claims and promises.

Folks that disrupt the cosy hegemony of the technologists (see e.g. #NoSoftware).

Folks that push back against complex and expensive non-solutions.

Folks that push through the embarrassment of failure to call suppliers to account.

Folks that understand THEIR Folks That Matter™, and look for partners that want to help them in that.

Folks who see the value in relationships, trust, and evidence, whilst rejecting faith-based arguments.

Folks that buy on criteria other than lowest (ticket) price (cost being just one need amongst many).

Folks that embrace the human element and humane relationships in the world of business.

Folks that understand their own strengths – and their weaknesses, and act accordingly.

Folks that generously share the laurels of success, and share responsibility for failure too.

There are so many folks that feel a need to do better, but desperately need the support of their Folks That Matter™ to make that happen. Without better Folks That Matter™, the reforms and improvements we need will indeed take a long time in coming.

– Bob


Your REAL Job

Students of Ackoff and Deming will be aware of Deming’s First Theorem:

“Nobody gives a hoot about profit.”

W. E. Deming

This reminds us that senior executives are demonstrably less interested in the welfare of the organisations they serve than in their own well being.

“Executives’ actions make sense [only] if you look at them as taken in order to maximise the executive’s well being.”

~ Russell L. Ackoff

Of course, it can be career-limiting to bring this issue to general attention. As the well-known psychiatrist R D Laing said:

“They are playing a game. They are playing at not playing a game. If I show them I see they are, I shall break the rules and they will punish me. I must play their game, of not seeing I see the game.”

~ R. D. Laing

And yet, if we look at the implications for “doing a good job” – a preoccupation of many in employment, we can draw the following conclusion:

We’re doing a good job when we’re maximising our executives’ (our bosses’) well being. We’re not doing a good job when we ignore that in favour of focussing on e.g. making the company successful or profitable. This probably rings true with you if you but think about it, in your own context, for a few moments.

This underscores a hidden reality for many: our declared job is a FAUX job. Our REAL job is undeclared, unexamined, unspecified – and being good at THAT is therefore a matter of pure dumb luck and random chance. How often do you have a conversation with your senior executives about how you might contribute to maximising their well being? How can we attend to their needs – as folks that matter – without such a dialogue?

– Bob

Further Reading

Nobody Gives a Hoot About Profit ~ The W. Edwards Deming Institute Blog post

What Is A Customer?

In the world of Agile, and the world of business too, we hear a lot about “customer value”. Folks seem to have some kind of handle on “value” (although not everyone can agree on that one – see my post “What Is Value” for my take, based on Goldratt and his Theory of Constraints).

And for the record, we might also choose to frame the question of value within the Antimatter Principle frame, and vocabulary:

Value: The degree to which folks’ needs, in aggregate, are being (or have been) met.

But what about “customer”? So simple and straightforward. Do we even need to define it? I thought not, until a recent conversation on Twitter gave me pause for reconsidering. Specifically, the idea that maybe folks are talking at major cross-purposes, with significantly differing assumptions and definitions for the term. If we can’t agree on a basic term like “customer”, what chance alignment of a whole host of fundamental questions about software, products and business generally?

Here’s my definition, again using the Antimatter Principle as a frame:

Customer: Someone (could be either a person, or a collection of people) whose needs we’re attending to.

I’m pretty sure you’ll have a different definition of customer. I’d love to hear your take.

Before I close this post, here’s a different definition, informed by Crosby and his Zero-Defects (ZeeDee) approach to quality:

Customer: Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else.

This definition canonises Crosby’s idea that we’re all customers. And we’re all suppliers, too. And as suppliers, it falls to us to ensure that what we’re supplying is what our immediate customer needs to supply their customer(s).

– Bob

%d bloggers like this: