Unlock the Untapped Potential of ChatGPT: Beyond Coding!

Isn’t it a bit disheartening to see software developers using ChatGPT primarily for writing code? It’s true that ChatGPT can indeed churn out code, but we can ask much more of it. If only developers would realise the potential for quicker, cheaper, and more valuable #NoSoftware solutions, they, their bosses and their customers would surely be amazed.

Imagine the possibilities. It’s high time we tapped into ChatGPT’s innate ability to provide creative, intelligent solutions that don’t just stop at code, but bypass it entirely.

What’s more, ChatGPT can even offer a hand in strategic planning, brainstorming innovative ideas, and making data-driven decisions.

We’re all missing out by limiting such a versatile tool to coding when there’s so much more on offer. It’s not that coding isn’t important, but let’s not forget the bigger picture. There’s a world of opportunities waiting to be explored if we’d only broaden our horizons.

So, let’s not be too quick to commit the heinous sin of pigeonholing ChatGPT as just a code-writing automaton. Why not embrace its full potential and reap the rewards of its remarkable capabilities? After all, it’s not every day that we come across such a powerful, transformative technology

#NoSoftware: Prioritising Business Flow Over Premature Software Implementation

Also known as “Software Last Of All”.

Businesses are often tempted to jump into implementing software solutions to optimise their operations. However, the #NoSoftware movement advocates for deferring software implementation until the business flows have been settled. This approach emphasises the importance of understanding and streamlining business processes before introducing any software solutions.

The primary objective of the #NoSoftware movement is to ensure that businesses have clear and effective workflows in place before integrating software into their operations. By doing so, companies can avoid the common pitfalls of premature software adoption, such as wasted resources, misaligned priorities, overblown costs, delays, and the need for constant readjustments.

One of the core principles of #NoSoftware is to place human interaction and creativity at the center of business operations. This involves designing and implementing business processes that cater to the needs and strengths of the workforce and customers, fostering collaboration and innovation. Once a solid foundation has been laid, businesses can then consider (minimal) software solutions to enhance their operations.

By prioritising business flows over software, organisations are better equipped to identify and address inefficiencies and bottlenecks in their processes. This ultimately leads to more effective and resilient business operations.

Furthermore, the #NoSoftware movement encourages businesses to choose software solutions that complement and enhance their established workflows, rather than disrupting them. This not only helps companies avoid the risk of adopting software that fails to meet their needs but also ensures that technology serves as an enabler of growth, rather than an obstacle.

In summary, the #NoSoftware approach promotes the idea of refining business processes in vivo before incorporating software solutions. By prioritising business flows and human-centric approaches, organisations can create a robust foundation for growth and innovation, ultimately leading to more sustainable and successful outcomes.

Girls Who Don’t Code

Girls and women are ideally placed to become real developers (by my definition*) and yet they want to CODE?

*My definition:

A real solutions developer is not so much someone who possesses technical expertise, but rather has the ability to connect with people and truly understand their needs.This requires a high level of emotional intelligence and empathy, as well as excellent communication and interpersonal skills. A real solutions developer builds relationships with clients, collaborates with team members, and creates solutions that meet the unique needs of each individual and group. By putting people first and prioritising human connections, a real solutions developer is able to deliver truly transformative solutions that make a difference in people’s lives.

See also: #NoSoftware

Quickie: Not A Software Developer

I’ve not called myself a software developer for at least thirty years. That’s not to say I’ve stopped coding. Far from it. But the end in mind has changed. From “developing software” to “attending to folks’ needs”. Seems to me that latter frame offers far more potential for satisfaction – both for me and for those I serve – than coding ever did. See also: #NoSoftware and the Antimatter Principle.

Quickie: Write Code Like…

Write code like the sound of one hand clapping…

Quickie: Muntzing

Hardware design / development has had Muntzing since the 1940’s. How about importing the idea into software design / development?

Could this facilitate the spread of #NoSoftware?

Or are programmers too self-indulgent to cut out much of their crap?

 

Quickie: Love Of Coding

After all these years, I still love coding (as in writing software).

It’s just that it’s tainted by the certainty that there’s so many other more effective ways of adding value and meeting folks’ needs.

Spending time coding feels so… self-indulgent.

The #NoSoftware Option

One of the many things that distinguishes The Quintessential Group from the Software Delivery also-rans is that our Quintessential Teams service provides our clients and prospective clients with a #NoSoftware option. John Seddon and his company, Vanguard Consulting, advise deferring software automation of new business processes and process steps at least until those steps have been trialed and proven through manual implementations – Post-its, paper-based processes, manual steps, etc. For those organisations that buy into this perspective, our #NoSoftware option means our teams will deliver these non-software solutions quickly and cheaply.

Also known as “software last”, a #NoSoftware solution is one that minimises the amount of software in a solution – in particular minimising the amount of custom-written software – ideally to the exclusion of software from the solution entirely.

As Steve Jobs famously said:

The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.

~ Steve Jobs

The Benefits of #NoSoftware

• Less maintenance overhead

The fewer lines of code in any given solution, the less needs to be spent on keeping that code up to date in line with e.g. changing requirements and discovered defects.

• More flexibility

Did you know that the term “software” was first coined back in the 1950’s to reflect the idea that software could be changed more easily, quickly and at lower cost than the hardware solutions that then predominated? It was supposedly easier to change a line of code than to reroute traces on a PCB, or swap out soldered components. Nice wishful thinking, but it hasn’t turned out that way. Software is notoriously expensive, inflexible and difficult to change. Less software means increased flexibility and business agility.

• Savings on up-front costs

Software costs money to write, even before it goes into service. Not only to pay for ever more expensive programmers and their friends, but also the opportunity costs of having to wait for the software to be ready to deploy. In most organisations this can mean months or even years of waiting.

• Minimal automation

When a new business process or process step is implemented, it’s rare for the implementors to fully understand what’s needed, and to anticipated the unintended consequences of their choices. Premature automation can lock in inappropriate or suboptimal design choices. Once a process or process step has been up and running live in a manual form for some time, it’s generally easier to see where (limited) application of software-enabled automation may bring benefits. Hence “software last”.

• Try before you buy

Use a #NoSoftware solution live in your business to prove your process or process steps to trial the solution before committing to implementing a software-based solution. You may actually find that a software-based solution is in fact unnecessary, or can be much more limited in scope – and cost – than originally imagined.

Attending To Folks’ Needs

Implicit in the idea of #NoSoftware is the imperativeb of attending to folks’ needs – the primary focus of The Quintessential Group. Generally speaking, folks have little need for software per se. As the old adage goes; folks don’t need a 1/4″ drill so much as they need a 1/4″ hole. When considering the means for attending to – and meeting – folks’ needs, software is often the default, but rarely the optimal means.

Chat More?

We’d be delighted to discuss the idea of our #NoSoftware solution option and how it will be suitable for your business or organisation. Curious? Please get in touch.

– Bob

Further Reading

Seddon, J. (2019). Beyond Command And Control. Vanguard Consulting.

Quickie: Value Engineering And #NoSoftware

Invitation to discuss:

#NoSoftware is the acme (or logical extreme) of Value Engineering in software development?

Quintessential Product Development

In my most recent book “Quintessence” I map out the details of what makes for highly effective software development organisations.

As fas as software development organisations are concerned, it’s a bit of a moot point – as software is generally something to be avoided, rather than sought (see also: #NoSoftware).

“The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs 

Foundational Concepts

There are just a few complementary concepts that mark out the quintessential product development company. These are:

• Whole Product.
• Systematic Product Management.
• Whole Organisation (systems thinking).

Whole Product

The quintessential product development organisation embraces the concept of “whole product”. Which is to say, these organisations emphasise the need to have every element of a product i.e. core product elements plus a range of “intangibles” – everything that is needed for the customer to have a compelling reason to buy (Mckenna 1986).

Systematic Product Management

Quintessential product development organisations take a systematic approach to flowing new product ideas and features through a number of stages – often in parallel (Ward 1999) – to predictably arrive at a successful new product in the market:

• Inception – spotting a gap in the market, a.k.a. some (potential customer) needs going unmet, interesting enough to do some discovery.
• Discovery – uncovering and proving the real needs of customers, the things they value, the likely usability of possible solutions, the feasibility of meeting everyone’s needs, and the viability of a product as a means to these ends. In essence, the key risks facing the proposed product. 
• Implementation – building a whole product solution, i.e. both core elements and “intangibles”.
• Launch – Placing the product on sale (or otherwise making it available to customers).
• Feedback – Seeing how the market responds.
• Pivot or Augmentation – Acting on feedback to either reposition the solution (in response to unfavourable feedback) or to incrementally update / extend the “whole product” offering to continually strengthen the product’s value proposition and appeal.
• Cash Cow – Reap the commercial rewards of a strong product and market share.
• Sunsetting – Wind down the product in a way that meets the ongoing needs of all the Folks That Matter™️ (e.g. continued support, spare parts, etc.; easing customers’ transition to newer products; etc.). 

Whole Organisation

It’s common for organisations to think in terms of silos. A Product Management or Product Development silo being but one more silo in a long and ever-lengthening list. 

In the quintessential organisation, the whole organisation is geared around – amongst other things – the task of regularly and predictably getting new products and new product features/updates out the door and into the hands of customers. In the longer term, new products are the life blood of most organisations, especially in the technology industries.

We only have to look e.g. Toyota and their TPDS (Toyota Product Development System) to see both an example of how this works in practice, and the huge benefits of the whole-organisation approach.

Quintessential product development organisations embrace a range of progressive ideas such as Prod•gnosis and Flow•gnosis.

– Bob

Further Reading

Marshall, R.W. (2013). Product Aikido. [online] Think Different Available at: https://flowchainsensei.files.wordpress.com/2013/04/productaikido041016.pdf [Accessed 13 Jan. 2022].

Mckenna, R. (1986). The Regis Touch: New Marketing Strategies for Uncertain Times. Reading, Mass.: Addison-Wesley Pub. Co.

Perri, M. (2019). Escaping The Build Trap: How Effective Product Management Creates Real Value. O’Reilly.

Ward, A.C. (1999). Toyota’s Principles of Set-Based Concurrent Engineering. [online] MIT Sloan Management Review. Available at: https://sloanreview.mit.edu/article/toyotas-principles-of-setbased-concurrent-engineering/. [Accessed 13 Jan. 2022].

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].

Quickie: Coding to Other Things Ratio

When building a software-based product or service (not in itself a sound thing to do, see #NoSoftware), how much time and effort goes into coding vs other things like:

• Requirements gathering
• Architcture
• Design (of various sorts)
• Wranging tools
• UI and UX
• Testing
• Documentation
• Meetings
• Marketing-related
• Debugging
• Etc.?

I’ve long held the view that 10% is a sound number. Your view/experience?

How Much Do You Care?

In recent times I have noted an upswing in the frequency of conversations about the ethical dimension of software development. Although still early days, many aspects of the social implications of software are beginning to receive more attention.

Effective Software Development

The dog’s breakfast that is Agile in the real world today exemplifies, for me, a key aspect of these ethical questions. Not that ethical questions are at all limited to the software industry.

What am I talking about? I’m talking about how people with a clear understanding of e.g. Agile software development (yes, there are some) tolerate, even support, a pallid, ineffective version in their workplace because their jobs and livelihoods depend on not rocking the boat. I’m talking about how folks go along with an ineffective and crippled approach for an easy life. Although how easy is it to stand by and watch project after project fail or limp along, with the consequent frustration and angst for all concerned?

With the oft-reported woefully low levels of employee engagement in most organisations, it’s hardly surprising that people just let such things slide by with little or no comment, complaint or action.

Satyagraha

We might take a leaf out of Gandhi’s nonviolent campaign playbook. He placed the idea of satyagraha at the heart of his toolkit of civil resistance. What is satyagraha? Online references describe it as “truth-force” or “the force that is generated through adherence to truth”.

Note: In this context, I choose to regard “truth” as referring to ethical imperatives such as justice, fairness and righteousness, and not simply factual truth. And yes, everyone has their own “truths” a.k.a. assumptions and beliefs. As do groups, such as organisations.

At the core of satyagraha is the willingness to suffer for the truth. Spiritual, emotional and physical suffering, borne in public, serves to emphasise the degree to which the satyagrahi care about the issue upon which they are campaigning.

Do You Care Enough to Suffer?

In the case of Agile, as with other aspects of how organisations run themselves today, it’s fair for folks to ask:

“Is it any of my concern? Don’t senior people with much higher pay grades than me hold the responsibility for these things?”

How is this any different from the old defence “I was only following orders?” 

Do you care? Do you care enough to start to say “No.”? In a civil and polite way, of course.

Are you prepared to suffer to see things become better for all concerned?

– Bob

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.

Predictability

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).

Approach

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.

Done

“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

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.

Specious

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

Afterword

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.

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).

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.

Industry

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

 

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

 

Beyond Command and Control – A Book Review

John Seddon of Vanguard Consulting Ltd. kindly shared an advance copy of his upcoming new book “Beyond Command and Control” with me recently. I am delighted to be able to share my impressions of the book with you, by way of this review.

I’ve known John and his work with e.g. the Vanguard Method for many years. The results his approach delivers are well known and widely lauded. But that approach is not widely taken up. I doubt whether this new book will move the needle much on that, but that’s not really the point. As he himself writes “change is a normative process”. That’s to say, folks have to go see for themselves how things really are, and experience the dysfunctions of the status quo for themselves, before becoming open to the possibilities of pursuing new ways of doing things.

Significant Improvement Demands a Shift in Thinking

The book starts out by explaining how significant improvement in services necessitates a fundamental shift in leaders’ thinking about the management of service operations. Having describe basic concepts such as command and control, and people-centred services, the book then moves on to explore the concept of the “management factory”. Here’s a flavour:

“In the management factory, initiatives are usually evaluated for being on-plan rather than actually working.”

(Where we might define “working” as “actually meeting the needs of the Folks that Matter”.)

Bottom line: the management factory is inextricable bound up with the philosophy of command and control – and it’s a primary cause of the many dysfunctions described throughout the book.

Putting Software and IT Last

One stand-out section of the book is the several chapters explaining the role of software and IT systems in the transformed service, or organisation. These chapters excoriate the software and IT industry, and in particular Agile methods, and caution against spending time and money on building or buying software and IT “solutions” before customer needs are fully understood.

“Start without IT. The first design has to be manual. Simple physical means, like pin-boards, T-cards and spreadsheets.”

If there is an existing IT system, treat it as a constraint, or turn it off. Only build or buy IT once the new service design is up and running and stable. Aside: This reflects my position on #NoSoftware.

John echoes a now-common view in the software community regarding Agile software development and the wider application of Agile principles:

“We soon came to regard this phenomenon [Agile] as possibly the most dysfunctional management fad we have ever come cross.”

I invite you to read this section for an insight into the progressive business perspective on the use of software and IT in business, and the track record of Agile in the field. You may take some issue with the description of Agile development methods as described here – as did I – but the minor discrepancies and pejorative tone pale into insignificance compared to the broader point: there’s no point automating the wrong service design, or investing in software or IT not grounded in meeting folks’ real needs.

Summary

I found Beyond Command and Control uplifting and depressing in equal measure.

Uplifting because it describes real-world experiences of the benefits of fundamentally shifting thinking from command and control to e.g. systems thinking (a.k.a. “Synergistic thinking” Cf. the Marshall Model).

And depressing because it illustrates how rare and difficult is this shift, and how far our organisations have yet to travel to become places which deliver us the joy in work that Bill Deming says we’re entitled to. Not to mention the services that we as customers desperately need but do not receive. It resonates with my work in the Marshall Model, with command-and-control being a universal characteristic of Analytic-minded organisations, and systems thinking being reserved to the Synergistic– and Chaordic-minded.

– Bob

Further Reading

I Want You To Cheat! ~ John Seddon
Freedom From Command and Control ~ John Seddon
The Whitehall Effect ~ John Seddon
Systems Thinking in the Public Sector ~ John Seddon

#NoSoftware

I wrote a post some time ago about No Hashtags (hashtags on e.g. Twitter which use the #No… prefix). My tweets occasionally mention various #No… hashtags, including #NoEstimates, #NoTesting and #NoSoftware.

I’m thinking it’s about time I delved just a little into the #NoSoftware hashtag. Like most of my posts on Think Different, this one will be brief. #NoSoftware is a deep subject, upon which I could write a whole book, had I but the inclination (or demand).

To whet your appetite, and illustrate the possibilities of #NoSoftware, we need look no further than the story of Portsmouth City Council housing repairs, where an existing, expensive and inflexible IT system was switched off, replaced with manual controls, and only later some limited software support reintroduced, once the needs of all the Folks That Mattered had been fully understood and catered to.

Payback

Let’s start with the payback of #NoSoftware.

As Steve Jobs wrote:

“The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s the fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write.”

~ Steve Jobs

A pretty clear alignment with #NoSoftware (yes, I’m coming to that presently) wouldn’t you say?

Let’s just dissect that statement:

Eliminating lines of code we have to write

We’re not talking about writing denser code – cramming more functionality into fewer lines. Fewer lines of code means we’re done quicker, having spent less time, effort and money on the writing of code. That’s a saving in and of itself.

Never breaks

So the lines of code we don’t write means we don’t have to worry about their quality (no matter whether you use defect prevention or testing as your go-to strategy in that arena). More time, effort and money saved.

Doesn’t need maintenance

By maintenance here, I’m thinking about changes to the code occasioned by the changing needs over time of the Folks That Matter, or changes necessitated by changing technical environments. I’m not dwelling on remediation efforts (bug fixes to production code).

More Payback

But the payback of #NoSoftware doesn’t stop with the above aspects. In the bigger picture, it’s not just about writing fewer lines of code. It’s about eschewing software-based solutions more or less entirely in favour of considering the alternatives. More payback includes:

Happier customers

It’s an old saw that “folks don’t want an 8mm drill, they want an 8mm hole”. Similarly, folks almost universally don’t want software, they’re looking to have their needs met. And software for many of these folks has too many negative impacts to be their preferred option. Software is generally written to save (suppliers) costs, not to improve customers’ satisfaction. Most people hugely prefer to interact with other human beings, rather than a computer controlled by – generally lame and inflexible – software.

Opening the Door to Changing Thinking

Software systems as generally conceived, ordered and delivered institutionalise – or “lock-in” – the existing collective mindset. Once installed and paid for, the “sunk cost” fallacy undermines any possibility of changing the existing set of assumptions and beliefs about how the works works. In the vast majority of cases the software system locks the organisation even more tightly into its existing Command & Control (a.k.a. Analytic Mindset) ways of working.

#NoSoftware – Definition

When I use the #NoSoftware hashtag, I’m inviting folks to think again about what, often, are near-autonomic responses. In this case, the System One (cf Kahneman) response – “fast, instinctive, emotional, stereotypical, unconscious and automatic” – when faced with some needs of some Folks that Matter, to satisfy those needs with a software-based solution.

I guess some folks assume that I’m advocating zero software. A kind of Luddites’ heaven. This is not my position. In using the #NoSoftware hashtag, I’m basically saying

“Under some circumstances, maybe there are other, more effective means to meet folks’ needs than the default assumption/strategy that we have to do so via software”.

“How about we think about, talk about, and consider those various circumstances, and means?”

In this way, the #NoSoftware hashtag is a metaphor for

“Would you be willing to think again, and maybe join the search for more effective, relevant or alternative means of meeting the needs in question?”

Example

Some years past, I was working with a company that offered a software product to the corporate market. The product had been in the market for some years, and it was clear that one of the blockers to market penetration was the complexity of the problem and the challenges corporate customers faced in dealing with that complexity. The company chose to build more and more software into their product to help their customers handle the complexity. No one ever discussed the options of offering a consulting service and/or a managed service, using human expertise, to replace or augment their software product. Consequences were, customers remained challenged, and the company’s revenues suffered.

Blockers

As Upton Sinclair’s Dictum tells us:

“It is difficult to get a man to understand something when his salary depends on his not understanding it.”

~ Upton Sinclair

How much more difficult, then, when it’s the revenues of a whole industry we’re calling into question. If the software industry changed tack and stopped writing software, what then? Financial ruin? World collapse?

There’s a multitude of smart people who currently waste much of their time – and lives – writing and delivering solutions to folks’ needs in the form of software. I suggest that to have this multitude refocus and retrain themselves to consider, and deliver, other forms of solution – solutions with less or no software – would make the world a better place for all the Folks that Matter. And “better”, as far as customers are concerned, would mean increased demand and more revenues for savvy suppliers.

Uptake

Like many of my invitations, I find #NoSoftware has few people willing to consider it as an alternative strategy to the status quo of just getting on with writing (more and more) software. I guess this signifies the general learned helplessness, and lack of engagement, autonomy and mastery, we find in most workplaces and employees today. So be it.

– Bob

Further Reading

Why Doctors Hate Their Computers – Atul Gawande
Forget your people – real leaders act on the system ~ John Seddon
Dangerous Enthusiasms: E-government, Computer Failure and Information Systems Development ~ Robin Gauld, Shaun Goldfinch