Tag Archives: Systems Thinking

Every Group Project – It needn’t be this way

These are bad symptoms - what's the cause?

This was posted on LinkedIn.  It’s representative of a common, in my view, belief that when things go wrong it’s the people that are the problem.  In fact when something goes wrong it’s usually fire someone that is the common reaction, a reaction only designed to placate stakeholders but never really attacks the root cause.  Sure it’s funny – but there is something more insidious here that warrants further explanation.

But am I being too hasty in my judgment.  I decided to undertake a poll.  Here are the results:

Poll Daddy Results for What's wrong with this picture 16 Mar 2014

The results tend to indicate a collective responsibility which is kind of on the right track.   However, I must note that the person who originally posted this on LinkedIn was a management by stick approach and more likely to blame the individuals.  This is common in my experience whereby scapegoats are routinely sought out.  The voters in this poll, it seems to me, are mostly an enlightened bunch.

It’s also common in conversation that people can routinely identify culture as a problem.  This observation is usually delivered in the whingeing/whining like I know it all style that draws sympathizing agreement, but hardly ever with any accompanying idea on how to solve it.  The types of responses fall into the blame culture.  It’s always someone else’s problem.  Really we need to be better than that.

The picture on LinkedIn drew in many Likes and comments directed at the people, but I was particularly encouraged by one opposing comment from Jayden McCorkell.

“It is funny in one sense, but thankfully we can pull together in business, which is why I don’t like the picture stereotyping a group project.  I would like to think that in our business we don’t have these problems, but if they do start to arise, our management team are quick to respond. The problem here is a lack of team effort and ability on the side of management to successfully steer the team. The team here doesn’t seem to know the company’s Vision, Mission, or core Values. How does your team stack up?”

This is most definitely on the right track. In fact famous writer and implementer of the famous work practices that exist today as the Toyota Way, W. Edwards Deming, says that if there is a problem then it’s most likely an issue with the system rather than the individual.  Deming was also a statistician and quantified this.  He says that 95% of the time problems are the cause of the system and not the individual within the system.  This thinking is within the realm of the subject called Systems Thinking.  Similar findings have been written about by others like Peter Drucker and Russell Ackoff.

So lets talk a little bit more about these root causes and feel free to add your own thoughts in the comments as well:


This is where failure has its root course.  Without an outstanding and robust vision, no matter how hard you try to get results and by whatever means you employ if it’s not based on a Vision then you’ll never achieve great results.  If you are aiming for a work force of mouse pushers, YouTube video viewers and Facebook food photo sharers then don’t bother with a mission.   But that’s not what you want I dare say.  The challenge for good managers and leaders is to define the vision.  Those in lower levels of management should be seeking it out and those higher up need to look past monthly and quarterly reporting to achieve the results they truly look for. These reports tend to drive gaming behaviour, creative accounting practices and local optimization at expense of the entire company.


Leadership naturally follows from a robust vision.  But what does it mean.  Well here’s my meaning.  Leadership is doing as you say.  It’s not about handing out orders.  It’s about collaborating with a group of people to produce results aligned to the vision.  Vision breaks down into many component parts and leadership means identifying the component part relevant to your area and acting on it.  It means rolling up your sleeves.  It means creating meaningful communication environments and means less meetings.   It means following the ideas of Robert Greenleaf and practicing Servant Leadership.  It means speaking out and not towing the line when things aren’t right.  It means laying your career on the line for what is right.

Purpose = Motivation

Purpose forms the backbone of Vision.  Without purpose we find ourselves showing up to work but not engaging.  We become cynical and conversations turn acidic and vindictive.  Blame culture dominates and we find it difficult to immerse fully in our work.   Daniel Pink summarizes it perfectly in his video on what motivates us.  We find that whilst financial reward is important to really excel we all need a transcendent purpose.  I’ll add it’s not the selfish purpose that bonus schemes encourage.  These encourage the wrong behaviours and almost always hurt others in the process.

Mastery = Motivation

Being allowed to master and become an expert in specific areas is an important motivator.  It also has benefits to the company as well.  In software development work we strive for elimination of technical debt.  This in turn allows access to talent to keep producing new value rather than attending to the issues of poor quality from prior work.   It also keeps the customer happy.

I’ve worked in the public and private sectors.  In the public sector I’ve been involved in a bug fix that two weeks to change one line of code.  This was because of the unnecessary and cumbersome designs put in place that were never re-factored.  Keeping the code clean would have resulted in a half day fix.  That means the efficiency gained can be diverted to delivering more value for the public.  As taxpayers we should be mortified that this is allowed to occur.  In the private sector I’ve been asked to fix up issues to placate an irate customer.  This was assumed to take a month or two.  There were 5 full time resources devoted to this at one time.  I hear from former colleagues more than a year on that problems still exist and lawyers have been involved to enforce contracts.

So the main point from these examples is encouragement of mastery mitgates against these events.  In the software world that means continuous build environments, refactoring, test driven development and simple/supple designs.  These subjects areas are out of scope for this article, but I’m sure similar practices are applicable in other forms of work.  This quote from Capers Jones who has been writing on the quality in software for 30 years is apt:

High-quality software is not expensive. High-quality software is faster and cheaper to build and maintain than low-quality software, from initial development all the way through total cost of ownership.

Autonomy = Motivation

Autonomy permits workers to unleash their creative energies without the hindrance and stress of an overlord or master.  But one must be careful there still needs to be boundaries and frameworks like Scrum and Kanban can assist here with check in points via iterations as in Scrum or Service Level Agreements as with Kanban.   Providing servant leadership and assisting to remove blockers and encouraging free thought we can remove the overhang of management tyranny that tends to place stress on workers.  Furthermore, one does not need to pay for better output either.  Simply allowing autonomy increases output and produces better quality and prevents the self centered and selfish behaviour that bonus schemes tend to induce.


Respectful critique is a good thing.  Going back to our photo one can get a feeling that not a peep be heard amongst the project participants. The Brad Cooper character assumes control and the others get out the way as shown in the behaviours produced.

Safety, Safe to Fail

One of my favourite sayings that I heard at an ill-fated engagement at a Government Department was this:

“At the … Department, it’s more important to not be wrong.”

Startlingly, whilst experts were brought into advise and build solutions, those at higher levels would find ways to stiffle and trample on solution ideas and at the same time not encourage free thinking.

Another utterance at included,  “Single wringable neck”  How can this produce great results.  Not providing safety also causes health problems via stress and relationship breakdown amongst colleagures and in personal life.  Work Stress has been known to cause death.

Sometimes RolledUpNewspaper is required

An an ending note, a word of caution.  Yes allowing greater freedoms produces great results but no ones perfect and we do stray from time to time.  I do like and apply the eXtreme Programming idea of applying what they call the Zen slap with the metaphorical rolled up newspaper.  I do this with the utmost care as I know that damaging an ego can also have deleterious effects on output.  Apply sparingly, allow your team to police it self catching out undesirable behaviour.


So going back to our photo.  One could cynically make the assumption that Brad Cooper’s character is all that is required to do the work.  That may be the case – and sometimes that is the correct thing to do.  But we are a team and as a team we can produce better and more meaningful results in a fraction of the time.  We need to attend to these dysfunctions by at least applying the values and principles I outlined earlier.

These aren’t supposed to be the be all and end all of it.  These aren’t a silver bullet and I don’t have all the solutions.  It requires everyone’s attention and never ceases.  But please make a start so we can all be satisfied without our work lives and further enrich our lives in general.


Project Phoenix: A light introduction to Systems Thinking, Theory of Constraints, Lean –> DevOps

 For me this was not a great read despite the hype surrounding the book.  But don’t let that stop you from reading this book.  In fact if you are interested in learning something about Systems Thinking, Theory of Constraints, Lean and Kanban this is the perfect introduction in the form of a business novel.

Now a novel is usually read for enjoyment, but I found the rubber doesn’t hit the road till about Chapter 14.   It’s a bit a long introduction til we start getting into solutions.  Then it starts to shine and the disaster looking like having a horrible death goes through a remarkable transformation.

Again if you’re not familiar with any of the concepts this is a great introduction.  If you’re interested in improving the state of your workplace grab yourself a copy.  It’s especially important for demonstrating the need for a more symbiotic relationship between all parts of service delivery and hence the rise of DevOps.