3 Simple Steps to Help Overloaded Teams

dublin-rain-491-390x285It was a wet and dark morning in Dublin when I sat with team X for the first time.

I had been told: “Gus, these guys are struggling, they really need your help. They are always late, and everybody complains about the quality of their work, it’s bad, very bad”.

I expected a demotivated team of technically poor developers with its members playing video games or youtube videos instead of doing their job, but I was wrong.

No developer was slacking or pretending to work, on the other hand, I saw people with worried faces shuffling around, some listening to angry customers, some head down into code, some testing and quietly cursing.

To a newcomer, they looked super busy and doing their thing.

I perceived the first hint of trouble later in the day. I went to talk to some of them, just introducing myself and telling them that I was going to work with them to try to make their life easier. Each and every one of them was too busy to talk. All of them had something urgent, being a production issue, being a customer waiting behind their backs, or a release they had to finish by 5pm. Sorry, sorry Gus, I really can’t now, I have this blah blah…

I took it in and let them alone for the day. The day after, I kept on observing without saying a word. The amount of pressure that I saw applied on to these poor kids was frightening. In the same day I saw 8 different people go to the same developer and demand he finished something he was meant to have finished already. The requesters were different people and asked for 8 different things, all quite angrily.

The subsequent days, my observations stressed more and more this situation, the people were pushed over the limits and by trying to finish things quickly and relief some of the pressure were skipping steps and introducing new problems, new issues to work on, and so on.

I kept on observing and asking questions here and there, but the people saw me as somebody that couldn’t help them with the code, hence quite useless. I had to do something different.

On the 4th day, in the morning, after their standup, I told them to stop doing what they were doing and come and have a chat with me.

Believe it or not, It was almost impossible to get them off their seats.

no-thanks-were-too-busyThey felt they could not leave the sinking ship, they needed to continue trying to flush the water out with their hands. Did I have a powerful drain pump and could save the boat easily? They didn’t have time to learn how to use it, they needed to keep on shovelling with their bare hands.

I eventually got them into a room. We had a retrospective. I disguised the retro to be something else, because I had heard from one of the developers: “we don’t do retrospectives anymore, what’s the point if we don’t have the time to change anything?”

That’s a very valid question. Very.

The team was obviously overloaded and didn’t have the maturity and the necessary negotiation skills to express that to their customers and stakeholders. They had reacted to the overload with what I call the “headless chicken approach”. It works like this: “Just do all you can, forget about quality, process, product, customers, just run for your life and even if your work product is terrible, people won’t be able to blame you, as you work like a donkey every day.”

fuck-it-let-s-just-panic-and-run-around-like-headless-chickensDo you think this is uncommon? Well think again.

The first step we took was to visualise the work in progress. The guys were using Jira with no physical board and didn’t realise how much work they were really taking on. The board was scary, full scary I mean.

As the work came from many different products, another thing that we did was separating the products into different classes of service.

By doing this we immediately saw that one product had most of the tickets, why? We don’t know yet, but at least we are aware of it now.
After this very simple step  the team members started having conversations that were beyond the need to finish MyNewFeature, they started looking at current priorities and talking about the whys of the bad situation they where in.

Then they started talking about experiments to fix it.

They were improving the system.

I looked outside the window, the sun had come out.

What were the 3 steps we made that enabled the behavioural change?

  1. Acknowledge we were in an unsustainable situation that needed changing
  2. Agree the team had the responsibility and the authority to improve it with my support and management agreement
  3. Visualise the work they were already doing


Just this small change had transformed a group of intelligent people acting like headless chickens into people that were trying to improve a complex system, not bad for a weeks work I’d say!

If you are curious stay tuned and I will tell you what happened next, no more chickens, I swear.

The new episode of the story of Team X is out

19 thoughts on “3 Simple Steps to Help Overloaded Teams

  1. Agree and this solves the crying need of team. This boost the WoW(way of working factor) and enhance the trust of employee engagement. We had faced the similar situation and by visualizing the visibility through trello boards the transparency is achieved at all levels thus resulted in cross team collaboration in achieving the end result. This is very useful in reusable type of work or production jobs.

  2. Yes, I completely agree. Knowing there really is something you can do to improve your situation is very important. I’ve seen teams who have given up. I like how you disguised the retro. Cool move. Visualizing work in progress is my core tool. I’m not sure what I would do without it. Its a technique that’s undervalued and misunderstood. I’m glad you were given the opportunity and time to create a board. I had one manager tell me we didn’t have the time to do such a thing. I just kept it on my computer so no one could see it and used it so at least I was aware of what I could do to help. I sure wish I could have had the team see it. I look forward to see how things continue to go with your team!

    • Thanks for your comment Dan. The team that give up is the start of the end of an organisation, it is fundamental to act immediately and get the creative juices flowing again before it is too late.

      When managers tell you “we don’t have time to learn” then leaders within the team fight back and more often then not save the day. I see your attempt of mitigating the manager fuck up and defending the team with your visualisation of the WIP as an example of leadership, never give up.

      Next time I suggest you buy a $10 write on sheet that you can statically stick to any wall in 30 seconds and create your low cost whiteboard, once the manager sees how wrong he was, he will come to thank you!

      Thanks for commenting also because I discovered your blog! Read a couple of articles and I will certainly be a new reader. I am a fan of Deming too, if you see my twitter profile you’ll understand 🙂

      • Cool. Thank you. As my old scrum teacher said, this manager who wouldn’t let us use a Kanban board was a “horse’s ass.” I never gave up, but I certainly saw the writing on the wall and knew I needed to move on. I’m somewhere else now. I’ll never forget how useful a tool that board was, though.

  3. I am currently seeing a team in exactly this scenario, however, they have the awareness that they need to stop and assess. Their biggest problem is that ‘the business’ (AKA Project Manager) blocks any attempt to enable them to improve their situation. What fight there was in the team has long since left the building, along with a lot of very talented engineers. It’s very frustrating – they are the proverbial ‘hamsters in the wheel’ – running fast in circles, never making any progress. I look forward to reading the next instalment!

    • Sam, thanks for your message.
      I have to say, what you say makes me sad, thinking about people being stuck between a rock and a bad Project Manager is very sad, but despair you not.
      Is there something you can think of doing to trigger change? Can you call a retrospective and initiate a small experiment? Sometimes the smallest change can cause a big improvement and re-energise people.

      In the situation I described in the post, my remit was to help the team, I also encountered people trying to stop me from doing so, oh yes I did, but I took them on and challenged the status quo.
      Change is never painless, in your case the team are suffering and in the end the organisation will too unless somebody does something. Can you do something, can I help you to do something? I’d be happy to have a private conversation (mail or skype) if you think I can help. (free of charge BTW).

  4. Great post. I see and I’ve lived and experienced situations like this plenty times. It’s hard to go against a sloppy management that do not let you stop and realize that you’re working on a loose end track.
    Dear Augusto I ask permission to translate your post to Spanish to be published on my blog: http://solucionesqa.com, actually is a bit outdated.
    Thanks in advance.

  5. Good one but the problem is initially they were great minds. but due to management not listening to them, or listening but not agreeing any time
    people have become headless chicken.

    Yes but they have to solve their problem instead of acting like donkey

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