The Big Bucket Problem

A couple months back I had the chance to volunteer with Bridges, a program that helps build basic infrastructure in impoverished areas in Lima. I learned that people who don't have other places to go set up makeshift homes in the hilly outskirts of Lima. These makeshift communities offer a very hard life, even access to clean water means carrying water on foot from further down the hills as water delivery can't make it up to where these communities have sprung up without better roads. Without basic infrastructure the social programs that aim to help with community development don't apply. It's a bit of a chicken-and-egg situation, until the community qualifies as a legitimate community the help to make living conditions better are not available. This is where the Bridges program comes in. From building stairs to make access to hillsides better and improving dirt paths into navigable roads they help set up the basics to get the makeshift communities qualified as real communities for the next step at building a standard of living for the poorest people in Lima.

The project we were working on the day I volunteered was a rock and cement retaining wall to help support the roadway. Once complete the retaining wall would enable water delivery truck to make it to the next set of houses up the hillside.

We were a loose band of volunteers. Some of the group had volunteered with Bridges before, many had not. Some had worked on this particular project before, many had not. We arrived on two tour busses, and our first task was to free the second bus which had become hung up on makeshift electrical wires that were hanging low over the parking area. Once we made if by foot up to the work area, having no civil engineering experience, I hung back and watched how the operation would be set up to see where I could help. The work started with our group of about 30 being split up between hauling rocks down to the wall from further up the road and mixing cement.

Always curious about how teams work together, I started observing how the teams formed, what roles people took, how did organization emerge. The cement team had more of a technical nature so it started with volunteers who had experience, those who could identify where the necessary materials were and where to set them up. They ended up in 3 groups setting up 3 cement mixing locations. The rest of us located the pile of rocks further up the hill and formed a relay line to pass rocks down. A couple "runners" would pick the rocks from the pile and feed them to the head of the line. We eventually came to a consistent pace with 3 runners able to feed the line. When we tried it with a fourth runner we found there was too much waiting at the head of the line, we had created a bottleneck based on the pace of the line, so the fourth runner went back to the line- we had found our local optimum. I also noticed that it took some time to sort out the right amount of space between people in the rock-relay line. We didn't have enough people to stretch the line all the way between the rock pile and the wall we were building without some of the people in the line moving their feet to bridge some gaps. It took a little experimentation and negotiation but eventually we had a pretty good equilibrium where those that had the most energy and strength were able to bridge the gaps and those less able only had to fill their spot. It didn't take any external coordination, people just settled into a natural equilibrium.

After some time of my group hauling rocks and the other group mixing cement we had enough of both to start the days layer of construction on the wall. I'm not sure how the decision was made and it didn't really matter, all of sudden the relay line dispersed and started forming a new line around the 3 cement mixing sites.

The same model we had used for the rocks was adjusted slightly for transporting the wet cement from the mixing sites to the wall. A line was formed for the majority of the distance between the mixing sites and the wall and runners would collect buckets of wet cement, feed the line and repeat the cycle. The line's objective was to keep pace with the 3 runners and try not to get backed up. The process was more complex than what we had for the rocks because instead of just picking up rocks the cement had to be mixed and collected in buckets. Other runners had to continually add water, sand and cement mix to keep cement supply going. Mixers mixed the cement and filled 1 gallon buckets. Runners had to coordinate to be as quick as possible but to avoid spilling and collisions with the other runners. A tosser relay emerged to return empty buckets so they didn't have to go back through the line in the opposite direction.  Everyone had a role and specific tasks emerged.

But the process wasn't static This process went on for a couple hour and there were many changes in roles. People from the community started pitching in so the line could get tighter and faster. When the line got too fast the end of the line became a runner, why not, she could see a full bucket right there ready to go.  Mixers would become runners when the material feed started running slow. The line would adjust as people dropped out for a break. Everyone improvised and took on whatever needed to be done to keep things going.

Could we have improved our output with some training and "best practices"? Maybe, but for a one day event things went pretty smoothly, considering we didn't even all speak the same language.

But not everything we smoothly. We did try some things that didn't work. For example, at one point someone decided to use the water buckets for cement as well. They were bigger, and if the 1 gallon buckets were working well then a 5 gallon bucket could multiply our rate by 5 and increase the number of buckets in the system! But there were problems. The 5 gallon buckets were way, way too heavy. They wouldn't really be lifted by one person at all so they were only filled half way. Even half full, the pace we had nurtured on the relay line fell apart when a big bucket came through. Instead of handing from one hand to the next we needed to fully use both hands to support the extra weight and the receiver had to be ready- there were a couple spills when a big bucket came through the line unexpectedly. Some spots in the line started carrying the big buckets as a team or carrying them around the line members who couldn't handle the heavier weight. These improvisations left holes in the line and throughput sputtered. Besides just slowing down the line for the bigger buckets, the system was disrupted. New bottlenecks arose, the bigger buckets couldn't as easily be tossed back for the return trip and small buckets started piling up at the end of the line. We eventually mostly ditched the big buckets but every so often one would still come through. We almost started to get used to it, but then we were done for the day.

We enjoyed some water and bread with the locals who had come to help. Their kids asked to be picked up and asked if we had any candy with us.

The big bucket problem feels so familiar. I've seen it many times, though not necessarily with buckets of cement. In my day job I write software, and instead of buckets of cement we tend to break the units of work into logical buckets. We have teams made up of different people with different specialties and different roles. We work really hard to bring our "buckets" from initial idea to something our clients can use as quickly and efficiently as possible. Different elements go into those ideas; technical design, visual design, feedback, etc. Things tend to work best when members of the team can easily change up their role to fit what's most needed at the time. 

So, is the moral of the story, always use small buckets? Not exactly. The bigger buckets were an experiment and experimenting can lead to some really good outcomes. An experiment lead to the empty buckets being thrown back to the start of the line rather than disrupt the line by trying to have it work in two directions at once. That was a great success. I think the moral of this story is more that you should understand the limitations of your system. Expecting to pipe twice the output from a system that has been tuned a certain way could have the opposite effect. In this case it did, but we also figured it out.

And what about the role of a manager, or a coach? If we were working so well together without an identified leader or a "boss" to tell us all what to do, doesn't the prove that leadership is unnecessary? Well, not exactly. I think that a lot can be said for a supporting leader. Someone got us to the work site, together at the same time with the tools and materials to get the job done. We didn't have a shared vision spontaneously, someone shared a vision with us. I also think there is a lot of value to a leader recognizing when she can step back, allowing a team to work through things itself. We didn't need anyone to tell us what to do but there was coordination that went into identify the problem and pull together the resources to allow us to work on it together, and then we were able to take things from there.