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.


12 responses to “Every Group Project – It needn’t be this way

  • Nick

    A response from a LinkedIn group was interesting http://www.socialillusions.com/

  • Nick

    Good point from Mob Programming group

    Nicolas Umiastowski

    Internet – Agile – mikolj.wordpress.com

    I have just posted a related article on my blog about team collaboration: http://mikolj.wordpress.com/2014/03/16/mob-programming-is-a-team-sport/
    I would add that to determine the cause of a failure you should ask five times “Why”, as it was explained by Taiichi Ohno.
    If you do so, you will certainly not put the blame on one person. You will instead most likely detect a defect in the process.

  • Grabe

    You want root cause? Me too. But nowhere here has anyone even scared root cause. The problem is not necessarily an individual (however, could be really bad management), but rather human nature allowed to flourish wildly (you know the more primitive part we all know about but don’t know how to describe and would never admit).

    Unfortunately, the problem can be a bit more complicated than those trying to solve the problem are educated for.

    The cultural-causes you dismissed here are actually the elusive side of the system. Don’t dismiss culture just because people whine about it in ignorance. Take a look at all the things you mention should exist. If they do exist then they are part of the culture. If they do not exist and people know they should, they probably don’t exist because of the culture. As former IBM chairman and CEO Lou Gerstner, once said, “Culture isn’t just one aspect of the game, it is the game.” And research has revealed that when culture is neglected, it can inhibit the success of other organizational initiatives such as listed the checklist you mentioned.

    Without the education to understand, blaming the system may be the closest bet one has to blame. It makes sense because we see features missing in the system we believe we’ve seen in successful teams. But the system and the culture are really two vantage points of the same phenomenon. The system or culture has two parts: the explicit one and the implicit one. The latter often wreaks havoc on the former if they are too incompatible. If the implicit side is unknown and not managed (usually is not) and is hindering the effectiveness of the systemic components you mentioned, the implicit side must be addressed. But who knows how to do that? (Well, some of us do.)

    Remember, whether on purpose or from just default “wild” human nature, the culture and the system originate from people. And it doesn’t always matter how much education you have. Education is often employed to rationalize after the fact – a wise tail on the emotional dog.

    1: “So are people to blame?” 2: “Yes”. 1. “Well who then?” 2. “Everyone.” 1. “What do you mean, I’m the person doing 99%?” 2. “Team problems originate from the nature of our species.” 1. “No, we’re people not animals.” 2. “We’re both. The problem is collective human nature, which originates in individual human nature but manifests in groups”. Sorry, it isn’t a simple dichotomy.

    If the manager who posted the picture is like many colleagues I’ve known, she or he likely suffers frustration with the disparate agendas and capabilities of team members – but mostly in discovering that each team member tends to have a different view of what is expected of them, how far they should go in that expectation (maybe they want more pay), and what is above and beyond expectation. There may be some truth to the picture, but the exaggerated truth. We tend to do that when we’re frustrated.

    Only one part of your favorite post hit close: “lack of … ability on the side of management to successfully steer the team.” If the team doesn’t understand the vision/mission, whatever, it is the fault of management (lack of education and effective leadership).

    Think of typical college group projects. The picture above is fairly representative of college group projects, isn’t it? Why? Because the group is not managed, and specifically, it’s members are not held accountable. (Unfortunately, the traditional college and university methods of instruction are not too compatible with meaningful and fair group projects.) So if a manager is seeing what is shown in the picture, then why the heck isn’t the manager doing something about it? In my experience, barring stupid/bad management, the managerial culture may be involved.

    Managers need to step up and get educated instead of blaming the team. Front line managers of complex projects have a tough job to get the most out of the team. First, they need to hire the right players. But once they have their team they need to manage the culture of the team, understand the spectrum of disparities within the team and develop a way to level out the disparities as much as possible without force or micromanagement. This is no easy tasks even if you do have the education. And if you want a high performance culture, you will need to establish a self-improving system to create and maintain it.

    So what is the message in what I wrote? Managers, stop waiting for team “supers” and take the bull by the horns. Get educated and start leading your team.

  • Nick

    Maybe I should’ve mentioned something about cynefin. i.e. How problems are dealt with according to the domain they fall in. Most of us react from disorder and apply our biases which could be wrong. This could also have effects on the type of team we form. http://en.wikipedia.org/wiki/Cynefin

  • Simon

    Great post. I like your different views on problems.

    It is easy to stop at the people.
    Take this example:

    The project failed because of the people: This usually occurs when a single individual manager has an issue with people under him who know more than him.

    When he hires people who know less than him so he cant be ‘shown up’ those people do not have an amazing level of expereince only an adequate one. Initially, these people dont do so well, so they get promoted to somewhere else. They then hire more people who are not as good as them for the same reason. This then leads to the entire branch of staff that are not expereinced.

    I have seen this is several organisations both public and private and it always ends in catastrophic failure of project at the last momment right before delivery. This is hidden due to gaming of progress.

    At this point, you might say people are to blame.

    However, read on….

    These projects are nearly always waterfall.

    By using an Agile approach such as Scrum, and having demonstrations of working software to users each release or iteration ensures progress cant be gamed. In this way, if the team is unable to deliver for any reason, this is known early and the approprate training, bringing in more expereinced people can be done.

    The three pillars of Agile (Transparency, Inspection, Adapt) stop these kind of issues being too big.

    So is it a process issue or a people issue?

    Having the right process involves at least someone in the organisation who has Agile knowledge and experience, who has influence, being able to affect change. Without this person, the organisation can blame process, people or any number of other factors. They will fail and who they blame will be irrelevant.

    I think my point here is that all factors need to work together, people and process and it takes experience to make it work.

    • Nick

      Hi Simon,

      Thanks for your comments. You first thing is known as the Peter Principle documented some years ago. Yeah I been there as well. Too much reliance on job title and the incorrect link to competence.

      Yeah Agile is gong to help if it’s done honestly. Experience is key as well like you say.

  • Best Posts for 2014 | Nikola Zdunić

    […] review of Lean Enterprise got at least one visceral response.  I also wrote about my feeling of dysfunctional teams after seeing the Hangover Picture constantly posted on […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: