Memeology For Developers

“The greatest determinant of organisational performance is the way we think about the design and management of work.”

~ John Seddon

And, therefore, the greatest determinant of the performance of self-organising software development teams is the way those teams think about the design and management of their work.

Aside: For teams and individuals that are not self-organising, the original quotation pertains.

Memeology is For Whole Organisations, not Teams

I suspect many developers and development teams might see “Memeology” (my new book) as irrelevant to them. As a book that lists memes of little interest, and as a book that surfaces assumptions and beliefs more relevant to senior management – which, to be fair, is the books primary audience.

And yet, as organisational psychotherapy speaks to an organisation’s collective psyche, “Memeology” invites addressing of the collective assumptions and beliefs of everyone in the organisation. So, as far as involving people in the discussions around “Memeology”, I’d suggest encouraging everyone to become involved.

In most organisations, however, local rules apply. Different groups may well be interested in memes specific to their own specialisms. For example: Finance, Operations, Logistics, HR, and yes, Product and Software Development.

I’m chary of promoting local optimisations – for example, the improvement of software development practices in isolation from the rest of the organisation. But developers in Analytic-minded organisations outnumber by far those in Synergistic-minded organisations (the latter being more prone to taking system-wide issues into consideration). Are we to deny a self-help book such as “Memeology for Developers” on the grounds that discussing development-specific memes in isolation might perpetuate specialisms and concomitant local optimisations confined to the “development silo”?

Prospective Content

Here’s just a few of the many memes that “Memeology for Developers” might cover:

• Requirements (when to capture them, who’s responsible for such capture, formalisms and representations, etc.)
• Code ownership (individual, group, other, and the trade-offs and consequences)
• Defect tracking
• Performance (of the software when in production)

I have a long list of such memes. I’m sure you can suggest memes for such a list, too.

Question

Does the idea of “Memeology for Developers” pique your interest? Would it be a useful book, promoting as it would not only the surfacing and reflection on the assumptions and beliefs developers hold in common, but also promoting experimentation to improve self-organising software teams and the way they work?

I’d love to hear your thoughts.

– Bob