These are some of the topics – other than Rightshifting – upon which I continue to think and work:


FlowChain is my model for how to organise a knowledge-work business along flow, synergistic and systems thinking lines. Organisations in the real world that have discovered and implemented (some) of the aspects of FlowChain include Reaktor (Finland) and Motek (California).

FlowChain In Practice

In my blog post “Software Kitchen Nightmares“, I illustrate some of the FlowChain principles through a restaurant kitchen analogy.

David Peterson has written an explanation of Flowchain in his own words (Note: link amended to point to Wayback Machine copy of original post 28 April 2021). (Note: post contains some minor inaccuracies).

I’ve recently (August 2013) written a post describing the basics of FlowChain as a System of Continuous Improvement.

There is also an (early, 2008) introduction to FlowChain in the second half of this slide deck (slide #29 onwards), and a Pecha Kucha slide deck with a few additional slides from an Agile Practitioners London meeting of September 2013 (pdf).


“Emotioneering” is my portmanteau term for “Emotional Engineering”.

Modern neuro-scientific and neuro-marketing research (see e.g. “Buyology” by Martin Lindstrom) tells us unequivocally that people buy things because of the emotions association with the “buying journey”. The software development industry in particular has spent decades barking up the wrong tree, working on more and more effective means to discover, articulate and document the functional and (sometimes) qualitative requirements for new products, without ever considering that people simply do not buy products because of these functionalities, but because of how the products – and the buying of them – make them feel.

My work on Emotioneering has resulted in a deliberate, methodical and teachable approach to:

  • soliciting the emotions that designers and Product Owners would like their products to evoke in potential purchasers and users
  • recording those desired emotions – using a formal notation – such that designers and engineers can collectively discuss and understand what it is they’re trying to achieve by way of product design elements, to evoke said emotional responses.
  • a means to measure the relative success of these design efforts, when the product goes to market.


“Covalence” is a term I’ve co-opted from the domain of the chemist, and applied to Product (and Software) Development:

To be able to claim real success in any significant endeavour, we must take into account the needs and wants of all the stakeholders, and must balance those needs and wants such that everyone is satisfied at or above certain thresholds.

Here, “needs and wants of all stakeholders” effectively means “what these folks value, each in turn and together as a whole”. Hence “covalent”.

See also “What is Value?” for an introduction to a teachable method of calculating business value of e.g. proposed new product features, user stories, improvement stories, etc.


See separate Prod•gnosis page


NoCV is a low-key awareness campaign I have been running on Twitter. It proposed the abolition of CVs and Resumes as tools in the recruitment process, in favour of recruiting people on the basis of their mindset “fit” with the recruiting organisation.

The core argument is defined in the blog post “Rightshifting Recruitment“.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: