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

July 3, 2020

How to get better at transforming a job you don’t like into your dream job

June 25, 2020

How to take back control of your life responsibly and safely during a COVID-19 pandemic

June 16, 2020

How to get better at protecting your privacy, security and safety in an internet-of-things world

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

November 16, 2019

Let’s start a conversation on integrating Essence into day to day activities as a thinking framework and general problem-solving tool

I received a question on the title of last week’s blog– “The value of listening to people who think differently from yourself.

To clarify, if it wasn’t already clear to you, there are two distinct groups of people I was referring to.  First, are the SEMAT volunteers from around the world who shared their different perspectives based on their own experiences and culture.  The second group is the reviewers of my “Shy Boys” book who– as I explained in the blog– shared their own experiences and perspectives in helping me write a better book.

This week I would like to start a conversation (or get your feedback) on an idea I received from one of those book reviewers that really appeals to me, and I am particularly interested in hearing the thoughts from those of you who are in the education field.

This reviewer was a software developer in industry and had gone back to the university to teach software engineering to our next generation of software professionals.

Let me first give you some context for the reviewer’s comment.

In Chapter Fifteen of the book I refer to a discussion I had with Watts Humphrey shortly before his passing in 2010 and I state:

Part of training in how to act professionally includes how to listen, learn, improve and work collaboratively as a team member. These essential elements to software engineering success are found within the Essence framework Team Alpha checklists.”

This reviewer made the following related comment:

“Most Computer Science programs have a Software Engineering class, but the common issue is that the ideas are isolated within that particular class. In many programs, mine included, the software engineering class  is presented in the third year, after the basics are taught. You highlighted in this book the idea that you believed Watts wanted to make sure graduates had the proper attitude. One class in a computer science degree, as I learned over the years, doesn’t influence students enough to keep it present. I think we need to take a wholistic approach… We need a curriculum that integrates these ideas into the day to day activities without having to detail the activity in a text. While I was pleased that you and your colleagues produced a textbook, I think it might be more helpful to use “stealth mode” within the classroom environment. How to accomplish this could be your next book!”

 This comment got me thinking about how such a “wholistic approach” might be implemented in a university environment and one idea that occurred to me was to use Essence as a thinking framework to aid problem-solving in multiple computer science courses.

Just to provide a few examples where I think Essence could be integrated into existing courses, consider the fact that most computer science curriculums today have distinct courses in Cybersecurity, Computer Ethics, Artificial Intelligence/Machine Learning, and Software Requirements/Design/Testing.

Each of the computer science courses mentioned above provides its own unique perspective into critical challenges related to developing software.  Each of these perspectives brings its own set of common problems, or challenges, that students need to be exposed to, and learn how to go about dealing with in a professional way.

As a common ground for all software engineering endeavors, Essence could be used in each of these classes to demonstrate to students how to go about analyzing such challenges, identifying related root causes, and assessing options and consequences of possible decisions.

What I am suggesting could provide a path to achieving the “wholistic approach” my reviewer referred to by helping to teach our next generation of software practitioners what it means to act professionally when it comes to the common challenges they are likely to face when they enter industry.

One potential advantage to this idea is that it doesn’t require university professors to make major changes to their existing course curriculums as Essence is integrated into the existing course material as a tool that aids critical thinking and problem-solving.  This approach also can help students learn practical ways to use Essence to address common challenges they are likely to face in industry.

Another potential advantage to this idea ties back to one of the potential problems we are trying to solve with Essence as I state in Chapter One of my “Shy Boys” book.  That is, the fact that “there isn’t commonly accepted software engineering terminology so when new graduates come out of school with computer science degrees and go into industry they have a whole new set of terms to learn, and then if they change  jobs and move to another company they  have to relearn a whole new set again.”

By integrating Essence into multiple computer science courses as a thinking framework and general problem-solving tool we can continually reinforce the Essence standard terminology so it becomes the natural language of choice for new graduating computer science students as they enter industry.

I am interested in hearing your thoughts on this idea, particularly from those of you within the education field.

If you believe this idea might have merit, I am also interested in hearing about any specific problem scenarios you may be currently using, or thinking about using, in your course material.

We can then use such scenarios to continue this conversation by providing practical demonstrations of the power of Essence as an aid to critical thinking and problem-solving related to these timely computer science topics.

To be clear, what I am suggesting is not intended to replace a first course in Software Engineering using Essence, but rather to show how Essence can be effectively integrated into other common computer science courses as an aid to critical thinking and as a general problem-solving tool.

Looking forward to hearing your feedback and keeping this conversation going!

November 8, 2019

The value in listening to people who think differently from yourself

Filed under: Software Engineering Method & Theory (SEMAT) — pemcmahon @ 8:18 pm
Tags: , ,

October 30, 2019

In 60 seconds, motivation for my latest book: “Shy Boys”

June 9, 2019

Scaling “Essence in stealth mode” and why you should care

Filed under: Software Engineering Method & Theory (SEMAT) — pemcmahon @ 12:57 pm
Tags: ,

In this blog I would like to address one of the comments I received on my last video-blog, titled, Using Essence in “stealth mode” to help solve a Cybersecurity Challenge.  

Following is the comment in italics:

“I think it is a great approach for a lone consultant. ‘Stealth mode’ seems to me by definition to be ‘not a scalable model’, since what you are making visible and selling is very specifically ‘the consultant’ and very specifically not Essence (which remains completely invisible to the customer).

 One might ask of this example, ‘Which really comes first here, and plays the primary and critical role throughout?’: the knowledge, experience and analysis skills (“wisdom”, if you will) of the consultant OR the Alpha State checklists. Realistically, the critical success factor in this scenario are consultancy skills and knowledge like:

         Listen first – listen deeply and seek to understand

         Start by trying to understand the problem

         Do root cause analysis

         The critical importance of the big initial “buy, build, reuse” decisions

         The critical importance of dependencies on external organizations

         The need to control key risks relating to competitors and IP

         Adopting “need to know” principles in such circumstances as this one

         Knowing the true meaning and role of good leadership 


Put another way – one gets the feeling in this case that Paul would probably have been basically successful here even if he didn’t know Essence, and likewise a less “wise” consultant would not have been so successful even if armed with a pack of Alpha state cards …”

I think this is a great comment which is why I am devoting an entire blog responding to it.   There are four points I want to make in response.

First, it is a misunderstanding to think that Essence remains completely invisible to the customer when used in “stealth mode”.   Let me give a concrete example.

When I use stealth Essence as in the referenced video-blog I don’t tell the client about it upfront because what they care most about is getting their problem solved.  Once we have accomplished this, then they are much more likely to listen and be interested in learning about Essence because it has proven itself.

In the Cybersecurity video-blog reference about nine minutes and thirty seconds into it on slide 10 when my client says,

“I like this approach and I am starting to see how our team can now meet this challenge.” 

This is where I might reply to the client with,

“I was able to help you partly because of my experience. But that is not the only reason.  If you are interested in learning about a framework that I use and could teach your team members to use so they could solve similar challenges themselves in the future we can discuss this further.” 

Often, at this point, my client is interested and this is where I discuss Essence with them more explicitly.  The right time to make a customer aware of Essence and how to use it, is after it has proven its value, not before.

Second, let’s address the issue of the “knowledge, experience, and analysis skills” of the consultant versus the value of the Essence checklists. It is certainly true that when I help my clients I am relying on my experience that I have gained over many years.   But when we developed the Essence checklists many experts from around the world came together and shared their own experiences.  Through numerous discussions over a period of two years (often held weekly) we arrived at what was agreed to be the “essence” of our common experiences which were captured succinctly in the Essence checklists.

Now, when I conduct training and when I work with my clients on specific challenges, such as the referenced Cybersecurity challenge, I utilize more than just my own experiences.  When I use Essence, as I say “in the back of my head”, it isn’t just my experiences anymore, but rather I am accessing the broader community of experiences that were captured in the Essence standard.

Third, let’s address the point of “stealth Essence” not being a scalable model.  Just as the Essence checklists strengthened my own base of experiences that I draw from in helping my clients so can each practitioner use it the same way to broaden their base of experiences they draw from to help make better decisions, regardless of their own level of experience.

Today, I don’t just use Essence to help clients by giving them recommendations based on my own stealth Essence approach.   I use it to coach practitioners in how they can access this same base of experiences in making their own decisions.

I have often said that my primary job as a coach is to “work myself out of a job,” by teaching my clients to solve their own problems so they don’t need me anymore.  This is what I believe all coaches and consultants should be doing.  Our goal should be to teach practitioners how to make their own decisions and how to help their less experienced teammates.  Teach your practitioners how to use Essence as a thinking framework to help solve their own problems and watch how fast it scales almost by itself across your organization.

Fourth, with regard to the final point about my being successful even if I didn’t know Essence, and a “less wise” consultant being less successful even if “armed with a pack of Alpha state cards”.   I do not disagree with this point, but by providing concrete examples, such as the Cybersecurity example, demonstrating how experienced consultants and coaches use Essence to solve problems we can teach others how to do the same thereby raising the competency level of our less experienced team members faster.  And isn’t that the real goal we are all searching for?

As always, feedback is encouraged.

Next Page »

Blog at