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: /2012/05/22/so-you-really-want-to-be-an-agile-developer/ [Accessed 30 Dec. 2021].