I was about to name this post “Pillars of TOC”, but after second thoughts I believe these pillars are equally useful outside of their immediate Theory of Constraints context.

Do you need to be able to think more clearly? Or maybe you know someone who would benefit from clearer thinking?

Goldratt asserts the pillars described below as foundational to “clear thinking”:

  • Inherent Simplicity
  • Every Conflict Can Be Removed
  • People Are Good
  • Never Say I Know

Pillar: Inherent Simplicity

This first pillar is a choice. An intention to look at situations as if they were always inherently simple. As if the nature of reality itself is simple (and harmonious).

“Reality is simple and harmonious.”

If we choose to proceed as if this were true, then we will be less likely to get trapped in looking for sophisticated explanations and complicated solutions. We will be less likely to channel our attention towards just those things we allow ourselves to see.

“The first and most profound obstacle is that people believe that reality is complex, and therefore they are looking for sophisticated explanations for complicated solutions. Do you understand how devastating this is?”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 213-215).

For clear thinking, we must choose to proceed as if we accept the idea of Inherent Simplicity, as a practical way of viewing reality, any reality. We may even go so far as to choose this as our approach to life in general.

“The biggest obstacle is that people grasp reality as complex when actually it is surprisingly simple.”

~ Goldratt, Eliyahu M.. The Choice, Revised Edition (Kindle Locations 219-220).

So what exactly do we mean by Inherent Simplicity? In a nutshell, Inherent Simplicity is the cornerstone of all modern science, as stated by Newton: “Natura valde simplex est et sibi consona.” We may translate this as “nature is exceedingly simple and harmonious with itself”.

Note: Goldratt states that with the Theory of Constraints, he takes a “Hard Science” perspective in all situations.

In practice, this means examining the cause-effect relationships within a given situation. And, contrary to our intuition, where we would expect some form of combinatorial explosion of complexity to result, Inherent Simplicity (and Newton) tells us that the system will converge, and common causes will inevitably appear as we drill down. If we drill down deep enough, we’ll find just a very few, or maybe even just one, root cause. So the result of systematically examining the cause-effect relationships in a situation leads us not to enormous complexity, but to wonderful simplicity.

If you doubt this, take a look at this article explaining the relative simplicity of two systems.

Hint: If I’m a scientist or a manager, I’m not so much interested in how difficult the system is to describe, but more in the difficulty of controlling and predicting its behaviour, especially when changes are introduced. The scientist or manager’s definition of complexity is: “the more degrees of freedom the system has the more complex it is.”

We’re not claiming that reality is not overwhelmingly complex; we acknowledge it in full. But what we are claiming that we can see things more clearly, think more clearly, when we choose to proceed on the basis that reality is exceedingly simple.

Note: We may begin to see how this perspective renders the idea of “complex adaptive systems” irrelevant.

Pillar: Every Conflict Can Be Removed

Let’s come back to the earlier proposition about Inherent Simplicity, that “Reality is simple and harmonious (with itself).”

We may choose to interpret “harmonious with itself” to mean that there are no contradictions in nature. In the material world. In “reality”.

“There are no conflicts in reality.”

For example, if we measure the length of a rod, by two different methods, and get two different answers, we don’t compromise. We don’t say “let’s split the difference and use the average between the two methods”. The contradiction between the two methods signals us that somewhere along the line we have made an erroneous assumption of some kind. And so we’ll go looking for that flawed assumption, and never accept a compromise. Such is the strength of our belief that there can be no contradictions in nature.

But this pillar is about conflicts, not contradictions. A conflict can occur any time we have opposing requirements, such as the need for an aircraft wing to be both strong and light. All undesirable effects (in the cause-effect relationships within a given situation) stem from such conflicts.

So this pillar is about choosing to proceed such that we treat every conflict like a scientist treats a contradiction. Which means, examining the conflict to uncover the inherent erroneous assumption(s), and refusing compromise as a way out.

“Don’t accept conflict as a given.”

Note: All forms of optimising and optimisation fall into the category of “compromising”. Such a waste of everyone’s time and talents.

Pillar: People Are Good

With this pillar, we come back again to the idea of harmony. This time we’re interested in another obstacle to thinking clearly: blaming others.

“Blaming another person is not a solution.”

In fact, in many cases, blaming others points us in the wrong direction, away from a solution. Even if the person we blame were to be fired, in most cases the problem will remain. Blaming is a sure-fire way to undermine the harmony in our personal relationships.

And we need that harmony, so that we can collaborate effectively with other people (our peers, our suppliers, our customers) in finding the solutions we seek.

So, we choose to proceed with the deep conviction that harmony exists in any relationship between people (even though in most cases, by default, we don’t bother to find and implement it). We choose to proceed on the basis that

“Win-Win is always possible.”

This perspective allows us to think more clearly, and find solutions that work for all parties involved, not just one side. Yes, it’s more work, but it gives our solutions much more stickability.

And, incidentally, for effective harmonious relationships, we have to care about the people involved. We have to invest the time and effort into knowing them and their true needs (cf. The Antimatter Principle).

Pillar: Never Say I Know

When we choose to proceed on the basis that we know about a situation, we’re unlikely to seek improvements, to check for holes in our logic or understanding, or to believe that the situation can be improved.

So, let’s always proceed as if we DON’T know. This choice can help us think more clearly, examine the situation afresh, and discover different, more effective ways of doing the things that need doing.

“Every situation can be substantially improved.”


You may see the above pillars as largely philosophical, as a way of looking at the world. Personally, I choose to see them as pragmatic, as a way of interacting with the world. And, returning to the notion of harmony, we may begin to see how all these pillars complement each other, harmoniously.

Harmony: “the quality of forming a pleasing and consistent whole.”

– Bob

Further Reading

The Choice ~ Eliyahu M. Goldratt and Efrat Goldratt-Ashlag


The One Perfect Way to Develop Software

[Tl;Dr: Being a Master of the perfect way to develop software is more of a handicap than an asset.]

Let’s imagine you’ve received a Matrix-style download of all the knowledge and skills necessary for Mastery of the perfect way to develop software. And you’ve applied this knowledge, and honed the skills, in several or many software development endeavours. And have the results to prove it.

Then you join a new-to-you organisation, and a new-to-you team, where of course you want to share your profound, highly valuable insights, capabilities, knowledge and skills with your peers, with a view to you all basking in the sweet success of the One Perfect Way.

Setting aside secondary issues such as the probability that there is no ONE perfect way, and that software development per se is maybe not what our customers are really interested in, what could possibly go wrong?

I’ll leave this question hanging. If I receive some expressions of interest, I propose to return to it in a future post.

– Bob

Further Reading

Characterizing people as non-linear, first-order components in software development ~ Alistair Cockburn


Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.


Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.


Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob


Tasks – or Deliverables

In most every development shop I’ve seen, folks’ planning vocabulary has been founded on the task as the unit of work. Long ago, at Familiar, we discovered that a different vocabulary offers some key advantages. Ever since then I’ve found that a planning vocabulary when deliverables are the default unit of work suit me much better.

Some Key Advantages

  • Planning in tasks encourages (subconsciously for the most part) busywork (a focus on activity).
  • Planning in deliverables encourages a focus on outputs (ands thus, closer to outcomes).
  • Deliverables are closer to what stakeholders seek (i.e. having their needs attend-to, or even met).
  • Tasks are generally one stage further removed from needs than are deliverables.
  • Deliverables are, to a degree, ends in themselves – tasks are means to ends (and hence more disconnected from outcomes).
  • I find it easier and more useful to quantify aspects of deliverables than aspects of tasks. YMMV.

Mayhap a focus on outcomes directly would be a further step in the right direction, but for most of the development groups I’ve seen, a single leap from tasks to outcomes might have proven infeasible.

May I invite you to trial a change of vocabulary, and of focus, next time you have the opportunity?

– Bob


Nine Aspects Of Top Developers


Ask a hundred people what’s their definition of a “top software developer” and you’ll likely get a hundred different answers. Many definitions may cluster around “someone who can make the computer jump through hoops”, i.e. a technical virtuoso of some sort.

Personally, my definition of a top developer is somewhat different. My definition is someone who:

  1. Understands people and how they – as e.g. users – might find joy in interacting with software.
  2. Understands people and how best to get along with them – e.g. in a team, a business – to create “solutions”.
  3. Understands people and their needs – and how to attend to those needs by e.g. writing software.
  4. Understands herself or himself – e.g. her or his own biases, tastes, limitations and capabilities.
  5. Looks to improve themselves and – together with other people – the way their work works.
  6. Has a broad range of life experiences to draw upon for e.g. inspiration and insight.
  7. Is widely read and informed – and especially, not just technical books, articles, blogs, etc..
  8. Is different and thinks different – to the other people around them. A.k.a. Diversity.
  9. Seeks out and takes ownership wherever and whenever folks’ needs aren’t getting met.

Technical virtuosity, aptitude, coding talent, experience, domain knowledge, numeracy, ability to learn quickly, etc. are all nice-to-haves, but not core to being a “top developer” – at least, from the perspective of e.g. folks paying their wages.

Bottom Line

My bottom line: I’d regard someone a “top developer” if they are highly effective in attending to folks’ needs. Although, just the idea of labelling someone “top”, or not, makes me feel uneasy for its implicit judgmentalism.

“it’s not what you say, or know, or even who you are, it’s what you do that matters.”

I guess my definition is just one amongst that hundred.

– Bob

Further Reading

The Three Virtues ~ Cf Larry Wall

Business Development

The word “development” in the phrase “business development” has always meant something very different than in the phrases “product development” or “software development”. The term “business development” is generally taken to mean finding new customers, building customer relationships, and such like. And thus responsibility primarily resides in the Sales & Marketing silo.

Maybe this is one reason why the idea of “developing” a business, in the same sense as developing a product or a software system, is pretty much unknown to business folks. Many’s the time I have invited business folks to consider the merits of taking a “development”approach to the construction and evolution of their business, only to receive little response other than a sea of blank faces.

Which makes me sad, because there’s an enormous amount of “development” practice, expertise and skills available to apply to the challenges of developing a business or other organisation. I’d say that some 80% of the know-how involved in developing products or software systems is directly applicable to “developing” an organisation.

Have you ever suggested to business folks that “development” know-how could have a massive impact on their bottom line? Or otherwise effectively meet many if not all of their core needs? What kind of reactions have you seen?

– Bob

Further Reading

What, Exactly, Is Business Developoment? ~ Scott Pollack
Prod•gnosis In A Nutshell ~ FlowchainSensei

Out Of House FlowChain

When I conceived of FlowChain, some six years ago now, my immediate context was development shops with their own in-house developers, and other supporting staff.

But it strikes me that with just a few adjustments, it’s also suitable for organisations that sub-contract out most or all of their development projects to third parties.

These adjustments centre around arranging for the various third parties (assuming, in the likely case, that there’s more than one) to each contribute staff to the “Pool” (see diagram). These arrangements include:


How will the third parties be paid? Some UK government functions use function points as a measure of “work done”, with a set price for each function point “delivered”. See: Output-based contracts. I can imagine other contractual arrangements, too.


How will the third parties’ staff integrate or form healthy relationships with the in-house commissioning staff (a.k.a. product owners)? Will there be shared spaces? Regular visits to and fro? Some more technical forms of communication (Twitter, chat, video conferencing, etc.)? Remember, each backlog item is sized for two to three people working together for two to three days.


Third parties remain free to pull items from the backlog as they see fit (just as with in-house FlowChain), and use their own tools, languages, etc.. I foresee some advantages in having a common code repository, coding and other standards, agree requirements around test suites, and so on.

Delivery Into Production

Maybe the organisation contracting the third parties has its own Ops department. In this case the interface between development (teams, third parties) and Ops would probable best be standardised and agreed (like an API). If the third parties have their own Ops folks, then they can do DevOps in their own space and time, and serve the “production” services – or even micro-services – they each operate, directly to users.

Shared Backlog

For clarity, this variant of Flowchain retains the enterprise-wide backlog, with user stories, improvement stories, etc. being prioritised by some black box (or white box) prioritisation algorithm, committee, manager, or whatever. The only real change is in how the Pool is constituted. Note: I see no particular reason why the general FlowChain principle of “ANY unassigned development folks from the Pool can coalesce around each new top backlog item” cannot stand, here.

There may even be emergent advantages in having e.g. developers from different third parties coming together to collaborate on specific backlog items. How weird would that be? Again, policy would guide folks’ actions here.

Who would “manage” the backlog?  This could be done by a small in-house staff, or itself subcontracted out to one or more third parties. Note: the backlog in FlowChain is largely self-managing, in any case, given an effective prioritisation algorithm or approach.


Flow (of e.g. software into the hands of those whose needs are being attended to) remains the key objective of the whole approach.

Growing An In-house Capability

For organisations without an in-house development capability, this approach provides a simple(r) path to establishing and growing an in-house development capability. In-house developers can be added, one by one, as and when circumstances (budgets, priorities, etc) allow. These new folks can work alongside – and learn from – third-party staff already used to Pool working, and the balance between in-house and out-of-house staff, skill sets, etc. adjusted dynamically as needs dictate.


The key drawback I foresee is in the matter of dev-ops integration (DevOps). This could prove more difficult, in the case where developers, etc. are out-of-house and Ops in-house. This seems a special case of the issues of outsourcing and offshoring, generally. But I’m sure a bunch of smart developers and smart ops can work this out, especially with some help and guidance.

– Bob

%d bloggers like this: