Egoless Practice: Becoming the Best in your Field

[Full post on other blog.]

Jerry Weinberg coined the term, "egoless programming" in his 1971 book "Psychology of Computer Programming". Jerry describes the practice and mindset, and in 1977 co-wrote with Friedman, the definitive manual for practitioners:  "Handbook of Walkthroughs, Inspections, and Technical Reviews: Evaluating Programs, Projects, and Products".

Is there a precise definition of "egoless programming" that could be expanded to a generic Professional Behaviour of "egoless practice"?

Johana Rothman is quoted by Jeff Atwood, presumably from a book, as saying:

Egoless programming occurs when a technical peer group uses frequent and often peer reviews to find defects in software under development. The objective is for everyone to find defects, including the author, not to prove the work product has no defects. [my italics]

When asked for a modern definition, Jerry pointed at Jeff's Ten Commandments of Egoless Programming.

The field of Reliability Engineering is aimed at creating near-Perfect (i.e. highly reliable) operation from imperfect parts and sub-systems. This approach can work very well, even when maintenance and fixes can't be done: the NASA Mars Rovers, Spirit and Opportunity, exceeded their 90-day design life by around 15 times, working from 2004-2010.

A working definition (unfortunately, of many parts).

Egoless Practice is:

• a Professional Behaviour
• designed to 
• routinely and reliably achieve
• as Perfect as Possible outcomes
• for the Client or Service Recipient
• by knowledgable and skilful
• Practitioners
• supported by systems, processes and procedures
• that actively monitor, examine and report performances,
• for both failures and successes,
• to systematically and without-backsliding improve 
• Quality, Performance and Process
• of Individuals, Teams and Organisations.

To Err is Human isn't a syllogism, it is an Iron-Clad Law.

It's the basis of the unending, relentless Professional Challenge:

• we're not machines,
• we cannot ever exactly repeat a process, not even twice, let alone the many times every day needed in Professional Practice, and
• our Minds and Bodies are always letting us down or tricking us in some way.

Simply stated: We are constantly making mistakes, inadvertently or not.

The "Blame Spiral": How a blame culture destroys Projects and what to do about them.

[Full post on other blog.]

James T. Reason has a very well developed model of the "Blame Cycle", e.g. "Diagnosing “vulnerable system syndrome”: an essential prerequisite to eVective risk management" (2001, Qual Health Care 2001;10:ii21-ii25 doi:10.1136/qhc.0100021) and "Managing the Risks of Organizational Accidents" [1997].

It is based on:

• The Fundamental Attribution Error: misidentifying the root cause of an event (a person who chose to do it, rather than a multi-factorial Organisational Error).
• A "Person Model" not "Organisation Model" of errors, and
• if informed, people will just stop making mistakes.
• [and there is much more to it than this]

The remedy to the "Blame Cycle" is creating a "Safety Culture" which is where, in Deming's words, "Drive out Fear", is conscientiously and consistently practised.

All of which is correct, but doesn't explain three things:

• Why after around 25 years of writing, research and implementations by Reason and Perrow and around 75 years since H.W. Henrich's "Industrial Accident Prevention, A Scientific Approach" (1931) are Blame Cultures still the norm, rather than the exception, even in High Safety environments like Healthcare. Aviation and space flight (e.g. NASA) seem to be leaders in the implementation and practice of the "Safety Culture" approach.

• After more than a century of definitive, proven Management Science theories, why does the Default Management Style, of which the "Blame Culture" is one aspect, still prevail? It isn't just that better techniques/systems aren't known or aren't practiced, but that organisations revert from their good practices. World leaders, like Kodak and General Motors, stop their successful practices and go back to known worst practices and suffer terminal decline. How can this be so in a rational, well-informed world?

• Individuals in teams and projects start out with good intentions and high hopes, only to end up mired in the tarpits of Blame. How can this happen over and over again? What is the common, systematic element, or where are the payoffs?

---

Summary:

James Reasons' "Blame Cycle" is detailed, correct and useful, but misses two important points clearly seen in I.T. Projects:

• The interaction of Blame with the non-rational, uninformed "Default Management Style", and 
• the psychological dimension: the predictable reaction of individuals, groups and organisations to Blaming in circumstances that can spiral out of control.

Simplistic Safety and Quality systems, based on formulaic, inflexible action/response "protocols" not only cannot cope with the complex, variable everyday challenges of systems with intangible, undefined Outcomes, but push the organisation down the "Blame Spiral" into Toxic collapse and overwhelm.

Demings' exhortation of "Drive out Fear" is the solution, but must be imposed from the top down. This requires determination and consistency of purpose all through the management chain. Along with the identification and elimination of perverse incentives and outcomes.