Essence and Problem Solving Blog

August 19, 2020

The single most important software team success factor reinforced by two software engineering giants

The single most important software team success factor, and one I always share relevant stories about when coaching software teams, is the need to create an environment where all team members feel safe in raising any issue that bothers them—even small ones.  This essential for success is captured in two Essence thinking framework checklist items from the Team Alpha, Collaborating State:

  • Communication within the team is open and honest
  • The team is working as one cohesive unit

The importance of this factor was reinforced for me through recent interactions I had with two software engineering giants—Alistair Cockburn and Larry Constantine.  Let me share a little about these experiences.

After I completed the initial draft of my “Shy Boys” book [1] in July, 2019, I asked Alistair Cockburn if he would review the book and let me know if he was okay with what I said. He quickly got back to me letting me know he was fine with all the parts that mentioned him.  I share quite a bit about Alistair and his focus on the people side of software engineering in the book. Later that day while on a plane he read more of the draft book and sent me another email saying:

“It occurs to me that what drives me is this question: ‘What leads a team to a higher likelihood of success?’ If you see me emphasizing the human component more and more, it’s because my experiences show it affects success more than other things.”

Larry Constantine also got back to me after reading the book saying:

“I would like to set the record straight on a couple of matters.

 First, I did not say that Ed Yourdon and I ‘missed the people side’ when we were developing structured design (and later structured analysis). What I did say in Zurich (and on other occasions) was that Ed and I left out design of the human interface (along with database design). It had always been my intention to make the original book comprehensive, but we ran out of time, our hand being forced by the publication of the IBM Systems Journal article and the threat of being scooped by Glen Myers. Moreover, the concepts of interaction design and the user interface were hardly well developed at that point. We also concluded that others were doing a fine job on database theory and architecture, so we went with what we had. Of course, as you know, I did return to interaction design and the human interface later.

 The reality is that, from the beginning, everything I did in the computer field was about ‘the people side.’ My thesis at MIT was on the psychology of computer programming; the conceptual basis underlying coupling and cohesion is rooted in cognitive complexity theory; and the graphic models were obviously all devised for the people doing design and engineering of software, not for the computers. Ed and I had always been highly focused on the people side of software engineering and were instrumental in spreading such key ideas about project organization as Conway’s Law and Mealy’s Law.”

For those who may not be familiar, Conway’s Law states that:

“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”

What I find most interesting about this law/principle (and relevant to this blog post) is the fact that two distinct organizations with differing communication structures are likely to have conflicting preferred design approaches and collaboration difficulties.  I observed this phenomenon first-hand on multiple occasions with clients and I have written about it extensively in numerous publications. [2]

Recently, I got thinking again about the challenges of getting people to work well together as I listened to an interview Alistair Cockburn did with Richard Atherton in April, 2019. [3]

About 38 minutes into the referenced interview Alistair shares part of his theory of software engineering and how you can develop explanatory and predictive models using levers you can touch to influence project success.  In the middle of this discussion he hesitates and says:

“And what I love is that the lever you can’t touch is human personality.”

After explaining what he means by this with a few examples, he goes on to say:

“The question in my mind is how do you simplify so its actionable?… Scrum is pretty good.  It has very few rules, but it doesn’t tell you if anything goes wrong how to fix it. SAFe went the other way and added a bazillion rules that are very very hard to follow, but claims to be complete….

So, what I did is reduce all of this to just four words Collaborate, Deliver, Reflect and Improve… This is not going to surprise you…. As people collaborate better, things go better, as people collaborate worse, things go worse…  That’s not rocket science.  It’s astonishing how quickly we forget it.”

What I particularly like about this part of the interview is that Alistair goes on to explain why people quickly forget the importance of collaboration. He does this by connecting collaboration to things we don’t always think of as collaboration, like fear and trust.

Then he asks: “What are people afraid of?”

His answer is:  They’re afraid of looking bad, not getting a raise, getting fired, not getting their idea implemented and on and on…

And he goes on to explain further that the root of the problem often isn’t in process, but it’s in things like Executive bonuses and human resource appraisal systems which often fail to consider effective team collaboration.

This all made sense to me based on my own experiences, but it also caused me to reflect on my own approach to this challenge with my own clients which I will explain in a moment.

Alistair then tells a brief story about a client who said to him:

“Alistair, … Tell me what to tell the bosses to tell the troops.” 

Alistair replies:

“I am not going to tell you anything… I am going to dialogue with you about how to dialogue with your bosses about how to dialogue with the people… We are trying to create a culture of listening… The Execs should dialogue with the people to find out what they know…”

Alistair’s client replies:

“I’ve been trying that but the Execs tell me I’m not here to dialogue with you. I hired you to tell me. You are the expert. Tell me.”

Alistair then says,

“That’s fine. That’s not your client. You don’t have to have all the clients in the world.  If our tone is dialogue based, people will self-include and exclude… Today more and more people in the world are growing up in dialogue, rather than edict.”

This part of the interview particularly resonated with me, as it caused me to reflect on my own thinking when I started my consulting business in 1997.  At that time I wrote the following words that still remain true 23 years later and are still on my website:

“If when you think of a ‘consultant’ you think of someone with real project experience who can come into your organization, understand your key issues, and give you the kind of help that pays high dividends rapidly, then one could refer to our services using this term.  We often don’t use this term because too often it conveys a notion of examining a client’s problem from a distance –and then telling the client what they should do… We work directly with our client’s team first understanding their strengths…We share with our customers practical techniques that make sense in today’s challenging environment.” [4]

The key point here relevant to this blog post is to listen first.  Then I operate more in what I think of as a facilitator of dialogue (rather than a “consultant”) helping the client discover their own best solution.

The reason I take this approach is because when the client discovers their own solution they are far more likely to own it, and believe in it, and implement it leading to a lasting solution. I have also referred to this approach in other publications and training courses as using Essence in “Stealth Mode” [5, 6, 7]

One example of a practical technique I have shared with clients to improve collaboration is to enhance their appraisal system by using inputs from teammates and customers when appraising personnel. When team members know their appraisal and potential salary is tied to how team members view them, their attention to team collaboration often improves rapidly. Whatever is measured gets attention.

These recent reflections have led me to start thinking again about what we should be teaching our next generation of software professionals, in particular with respect to organizational cultures, collaboration and essential team skills.

It seems to me, at a minimum, we should be making them aware of the existence of varying organizational cultures—such as organizations with cultures of “just follow the rules” and those with cultures that encourage  “listening and dialogue.”

These differences, of course, aren’t new.  They existed 50 years ago and although more and more of the world seems to be moving toward the “listen and dialogue” approach as Alistair has observed, I suspect these differences will continue to exist for many years to come.


[2] Numerous stories of conflicts arising when organizations with differing communication structures and cultures attempt to collaborate can be found in my Virtual Project Management book and related articles. Refer to



[5] For an example of  using Essence in stealth mode refer to

[6] For online training in using Essence as a thinking framework with numerous examples of using Essence in “stealth mode” refer to

[7] For more general information on Essence refer to

June 9, 2020

How big tech companies are trying to control your time and how to get better at fighting back

Filed under: Essence and Problem Solving — pemcmahon @ 6:17 pm
Tags: , ,

June 2, 2020

How “big data” is being used to misinform and how to get better at fighting back

May 26, 2020

Three Essentials To Getting Better At Anything

May 19, 2020

Slow Down and Go Faster

Filed under: Essence and Problem Solving — pemcmahon @ 9:42 pm
Tags: ,

May 12, 2020

The Secret to Solving Any Repeating Specific Weakness

Filed under: Essence and Problem Solving — pemcmahon @ 10:55 pm
Tags: ,

Blog at