Am I the only person in the world interested in improving the effectiveness of organisations? In making organisations better places to work, better places to play, better places to learn? Is it just me? Most days it seems like it is.
The 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).
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?
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].
It’s easier to teach stuff, when you don’t know the stuff you’re teaching.
A Steady Job Makes For Increasing Ignorance
Having a “steady job” means folks’ needs for safety and security are most likely (by definition) being met. In such situations, where does the need for learning new things, keeping abreast of industry developments, and innovating in the way the work works come from?
Note: A “steady job” is one that is routine and pays a decent but not a high amount of money. It is also a safe job. In the software development business, most steady jobs also pay very well.
- The job demands these things (very rare to never).
- Intrinsic motivation.
I regular meet folks in steady jobs, from junior developers through to senior and C-suite managers and executives, all of whom are woefully ignorant of what’s happening in the software industry, of new discoveries, and of know-how published since 2000-ish (and many times, even earlier).
Do organisations care? I doubt. Maybe if they did care they might do something about it?
And how about your job? Is it steady? And how up-to-date are you with e.g. what’s happening in the software industry, of new discoveries, and of recently published know-how? What would it take for you to pay some attention in this space?
Rother, M. (2010). Toyota Kata: Managing People for Continuous Improvement and Superior Results. Mcgraw-Hill.
Chin, R., Benne, K.D. and Bennis, W.G. (1969). General Strategies for Effecting Changes in Human Systems. Holt, Rinehart and Winston Inc.
People think they know what they’re doing when it comes to developing software, but they really don’t. The higher up one looks in organisations, the more incompetence one sees. That’s not to say they can’t learn, but mostly they won’t learn.
A Plea for Connection
I’ve not come across this article before, so having just read it – and been both comforted and enlightened – I thought I might share it with you:
Fun Times at Familiar
I’m minded to write something positive for a change (!) so I thought I might share how much fun a quintessential development organisation can be to work with. (I say work with, because we had almost no power structures, no managers, no bosses, and everyone was a colleague, a fellow.)
Familiar was a software house and consultancy, based near Reading UK (some forty miles west of London), which I started and led circa 1996-2000.
The years at Familiar was, for many of us, enormous fun. We were doing great things for our clients, bonding as a group, and learning loads about how to become a Quintessential organisation. The social side was just as much fun as the business side. Indistinguishable, really. We placed a lot of emphasis on the social aspects of the organisation:
- Company-funded weekends away in plush country hotels – for the folks in the company along with their significant others.
- Regular dIning out as a group, on the company’s expenses.
- Collaborative sessions (sprint planning and the like) in each others’ homes.
- Other group social events (e.g. exhibitions).
- An office configured for socialising – and learning – as much as for work (lounge, sofas, library, books, kitchen, etc.).
This was all made possible by the success we had commercially – a virtuous circle where fun led to great work for clients led to high margins led to funds for more fun…
It was the kind of win-win-win (clients, us, suppliers) that quintessential organisations regard as normal.
If you have any questions, I’d be happy to answer them.
It seems clear to me that my skills, experience and insights have become irrelevant to the majority of folks toiling in the software industries.
We might say that they have no need of my ideas or my help.
And as my views and ideas are mostly directed at improving the effectiveness – and results – of software development efforts, I draw the inference that their employers and managers have no interest in such things.
This seems a relatively recent phenomenon. Even five or ten years ago, organisations and managers seemed at least marginally more interested in productivity, effectiveness, success, and so on.
I suspect it’s connected to COVID and the consequent Great Resignation.
Ironically, my works – Organisational Psychotherapy, the Antimatter Principle, FlowChain, Product Aikido, etc. – are an ideal fit to addressing the issues wrapped up in the Great Resignation. But I guess folks are already too resigned to bother.
What might be more relevant content for these times? “How to Find a Fulfilling Job”? “How to Suck Up to Your Boss”? “How to Give the Finger to the Man”? “How to Whack the Employees You Have Left”? “How to Look Like You”re Doing Something Without Risking Your Credibility”? Probably more relevant content. But not quite my style.
If you’re one of the very few who haven’t given up just yet, enjoy studying new ideas and learning for its own sake, I’m always happy to help. Pro bono or pro pretio, either, both.
Visual Walkthrough Explaining Rightshifting And The Marshall Model
For those who prefer looking to reading, here’s a visual explanation (with some annotations) briefly explaining Rightshifting and the Marshall Model.
1. Context: Organisational Transformation
Rightshifting illuminates the tremendous scope for improvement in most collaborative knowledge work organisations. And the Marshall Model provides a framework for understanding e.g. Digital Transformations. Don’t be too surprised if folks come to regard you as an alien for adopting these ideas.
2. Imagined Distribution of Effectiveness
How most people imagine effectiveness to be distributed across the world’s organisations (a simple bell curve distribution).
3. Contrasting Effectiveness with Efficiency
Many organisations seek efficiency, to the detriment of effectiveness.
4. If Effectiveness Were Distributed Normally
5. The Distribution of Effectiveness in Reality
The distribution of organisations is severely skewed towards the ineffective.
6. Some Corroborating Data from ISBSG (1)
7. Some Corroborating Data from ISBSG (2 – Productivity)
8. Some Corroborating Data from ISBSG (3 – Velocity)
9. Rightshifting: Recap
10. Plotting Levels of Waste vs Effectiveness
Showing how increasing effectiveness (Rightshifting) drives down waste.
11. Plotting Levels of Productivity vs Effectiveness
Showing how increasing effectiveness (Rightshifting) drives up productivity.
NB This the the canonical “Rightshifting Chart”.
12. From Rightshifting to the Marshall Model
Starting out with the Rightshifting distribution.
13. The Adhoc Mindset
Collective assumptions and beliefs (organisational mindset).
“Ad-hoc organisations are characterised by a belief that there is little practical value in paying attention to the way things get done, and therefore few attempts are made to define how the work works, or to give any attention to improving the way regular tasks are done, over time. The Ad-hoc mindset says that if there’s work to be done, just get on and do it – don’t think about how it’s to be done, or how it may have been done last time.”
14. The Analytic Mindset
“Analytic organisations exemplify, to a large extent, the principles of Scientific Management a.k.a. Taylorism – as described by Frederick Winslow Taylor in the early twentieth century. Typical characteristics of Analytical organisation include a Theory-X posture toward staff, a mechanistic view of organisational structure, for example, functional silos, local optimisation and a management focus on e.g. costs and ‘efficiencies’. Middle-managers are seen as owners of the way the work works, channelling executive intent, allocating work and reporting on progress, within a command-and-control style regime. The Analytic mindset recognises that the way work is done has some bearing on costs and the quality of the results.”
15. The Synergistic Mindset
“Synergistic organisations exemplify, to some extent, the principles of the Lean movement. Typical characteristics include a Theory-Y orientation (respect for people), an organic, emergent, complex-adaptive-system view of organisational structure, and an organisation-wide focus on learning, flow of value, and effectiveness. Middle-managers are respected for their experience and domain knowledge, coaching the workforce in e.g. building self-organising teams, and systemic improvement efforts.
16. The Chaordic Mindset
“The Chaordic mindset believes that being too organised, structured, ordered and regimented often means being too slow to respond effectively to new opportunities and threats. Like a modern Jet fighter, too unstable aerodynamically to fly without the aid of its on-board computers, or sailing a yacht, where maximum speed is to be found in sailing as close to the wind as possible without collapsing the sails, a chaordic organisation will attempt to operate balanced at the knife-edge of maximum effectiveness, on the optimal cusp between orderly working and chaotic collapse.”
17. Transition Zones
As organisations progress towards increasing effectiveness, they encounter discontinuities which the Marshall Model labels as Transition Zones (orange hurdles). In these transitions, one prevailing mindset must be replace wholesale with another (for example, Analytic to Synergistic, where, amongst a host of shifts in assumptions and beliefs, attitudes towards staff transition from Theory-X to Theory-Y). Cf. Punctuated Equilibria.
18. What Each Transition Teaches
A successful Adhoc -> Analytic transition teaches the value of discipline (extrinsic, and later, replaced with intrinsic).
A successful Analytic -> Synergistic transition teaches the value of a shared common purpose.
A successful Synergistic -> Chaordic transition teaches the value of “Positive Opportunism”.
19. The Return-on-Investment Sawtooth
Incremental (e.g. Kaizen) improvements with any one given mindset show ever-decreasing returns on investment as the organisation exhausts its low-hanging fruit and must pursue ever more expensive improvements.
Each successful transition “resets” the opportunities for progress, offering a new cluster of low-hanging fruit.
What has this walkthrough shown you? I’d love the opportunity for conversation.
Here’s a video in which the great Russel L. Ackoff explains the difference between knowledge and understanding, and thereby the difference between analytic and synergistic thinking (Cf. Rightshifting and the Marshall Model).
Organisational Psychotherapy on Slack
For those folks who prefer their interactions via Slack, there’s a new Slack workspace for Organisational Psychotherapy. Check it out and join up now. 🙂
PS. Please let me know it there are any other aspects of my work for which you’d like to see a dedicated Slack workspace.
Are “software developer competency” and “software product delivery” complementary, compatible, or oppositional?
Nobody Needs Learning
Or at least, nobody seems willing to talk about learning – or more precisely the almost universal absence of learning – in the context of work. Oh yes, folks like to pretend to others, and delude themselves that they’re learning – via what we might call “learning theatre”. But the actually work of learning? That’s too hard.
Definition: Learning has taken place ONLY when behaviour has changed.
I cite as an example the total lack of response to a recent post of mine: “Scope of Ignorance”.
It’s almost as if there’s no connection between learning and career advancement (something I do see as folks’ needing, at least in terms of increasing wages, if not actual increasing responsibility and scope of influence.
I put it down largely to the Mexican standoff between organisations and their people, of which I might write soon, given any kind of demand. But that might imply a need to learn about that. Unlikely?
How about you? Is learning something you need? And in the unlikely case that you might answer “yes”, what learning are you realising – at work, and through work?
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?
If you love books, and in particular books about business, organisations and software and product development, you’ll probably love Memeology. There’s more than 90 chapters, and almost every chapter has a host of references, in context.
(Aside: I’ve personally read almost every book and paper referenced in Memeology).
PS. I expect Memeology to reach 100% completion in just a few days now.
If you wanted to create an education environment that was directly opposed to what the brain was good at doing, you would probably design something like a classroom.~ Dr. John Medina
Scope of Ignorance
Most of the developers and development teams I used to work with when I was a software development consultant had a relatively narrow view of the skills and knowledge necessary to be “competent developers”. Here’s an illustrative graphic:
Generally, to make progress on improving things, and to earn the moniker of “software engineers”, a wider scope of skills and knowledge was necessary. Not only did these development teams lack this wider scope, they were both ignorant of the many additional areas of knowledge and resistant to learning about them. The common response was “What are all these strange topics, and NO WAY! do we need to know about them”:
Aside: Now I’m an Organisational Psychotherapist, their ignorance is no issue – and no stress – for me. They can learn or not learn in their own time. Progress is on them (and their higher-ups).
An Overabundance of Planning
“The minimum you can get away with is always far less than you think you need.”
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.
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.
Note: This is one of those rare posts (for me) where I have few to no suggestions as to how to proceed.
Islands of Ignorance
In my travels, I have seen many organisations from the inside, and many more from the outside.
In almost all cases, these organisations strike me as like little islands of ignorance in a huge sea of knowledge. As a mariner myself, I’m well aware of the bounty of these seas. So, maybe better placed than most to see the shortfalls in our organisations’ uptake of this bounty.
Seas of Knowledge
It’s never been easier to keep up with developments (sic) in praxis – in whatever fields of human endeavour interest us. And that’s probably even more true for the fields of collaborative knowledge work, software development and product development than for any other.
And yet, almost every organisation I see operates on principles – from the executive management suite to the workers at the coal face – utterly disconnected from the seas of knowledge surrounding them. Principles grown stale and musty with the dust of ages past.
Some organisations, having an inkling of their disconnection, make token efforts to bring outside knowledge in – with brown bag sessions, encouraging folks to attend meet-ups and conferences, hiring consultants from time to time, and so on. But like fishermen on the shore with fishing poles and spears hooking the occasional fish, this ain’t so effective. Few indeed are the organisations that build trawlers and send them out with nets, sonar, radar and the like to harvest the plenty of the seas.
Why is This?
What makes organisations so inept at finding and using the huge repositories of knowledge out there – in books, on the internet, in people’s heads, and so on?
I have some suspicions that the education system is partly to blame. I’ve seen many graduates who, upon doing the workforce, act as if their learning days are behind them.
And short-termism, the bane of UK industry in particular, contributes. With the implicit idea that learning, being more valuable in the longer term, has little or no value in meeting next week’s delivery schedules, or this month’s financial targets.
I guess, too, that like navigating our planet’s vast oceans, the seas of knowledge are so vast now that special navigation equipment is necessary to tackle the challenge. And whilst a fish is a fish, a idea or item of know-how is a much more slippery thing. How to sort the wheat from the chaff? Maybe systematic experimentation can help (see e.g. Toyota Kata, or Popcorn Flow from Claudio Perrone)
So. There you have it. No elegant ideas for addressing the situation. Just an appeal to you, dear readers, to share your experiences, perspectives, and maybe a hint or tip or two for the rest of us.