Print
/ Ideas

The Sombrero of Shame

The Sombrero of Shame

Those who have heard me speak in the past will know that I’m a big fan of encouraging teams to design their own solutions when dealing with their own complex problems.

 

Today, I want to share some of my favorite stories about emergent solutions.

 

The Sombrero of Shame

 

Back in my days of working at Electronic Arts, we had a problem that really most development teams have. When a programmer is done with a certain piece of code that goes into a game, he must verify its quality and then add it to the common “branch”.

 

The branch is the official game code. 

 

If a programmer sends bad code to the branch, he can make it unusable for everybody. It’s called breaking the branch and it can be a rather annoying productivity sink because while the branch is broken, nobody can add new code.

 

As a manager how do you make sure that this happens as little as possible?

 

The truth is that your options are pretty limited to communicating the importance of quality checks and peer reviews.

 

The the real breakthrough came when one programmer returned from a vacation in Mexico with a huge sombrero. I’m not exactly sure how the tradition started after that, but at some point it became understood that whoever broke the branch would need to wear the sombrero for the rest of the day and the sombrero would then remain at their desk until someone else did the unspeakable.

 

Now imagine for a moment that Management came up with this measure and announced that “from this moment on, an employee who commits erroneous code is required to wear a sombrero for a period of one working day”. This would never be accepted as a top down measure.

 

But because it came from the team, it became part of the traditional fabric of the team. Something they were proud of and could spread to other teams, projets or business units. 

 

Ninjas

 

This next example comes from Hibernum Creations, Montreal’s hottest independent games studio.

 

When working in "Agile Sprints” team members commit to certain deliverables by the end of the sprint.

 

Part of the convenant is that no-one will add to their workload during the sprint or reduce their ability to focus on the tasks that they are committed to.

 

But occasionally, someone in the team might discover an unplanned dependency and might need to add a task to a peer’s bucketlist. So the team needs this person to take on a additional task while still delivering what they had committed to. As you can imagine this can cause some tension.

 

The emergent solution? The Ninja. A team member that is dealing with this unexpected curve ball would receive a Ninja figurine so that everybody would know that they are dealing with a “Ninja”. In really good teams, other team members might get coffee or lunch from this person or allow them to skip non-mandatory meetings so that they could remain focused.

 

This attitude of “we take care of our own” is another contributor to the building of team spirit. 

 

Closing words

 

The power of emergent solutions is the power to invent creative solutions that receive high adoption and actually reinforce the sense of belonging of individuals in a group. To be fair though, there needs to be a minimum amount of team cohesion for these practices to emerge.

 

A certain baseline of trust and desire to create together. How to get teams to that level is another discussion entirely. I'll get back to you on that. 

 

comments powered by Disqus