Rules versus guiding stars ... and a lot about soccer

· August 1, 2013

Rules versus guiding stars … and a lot about soccer

In Sweden, there’s a radio show every summer, every day. It has the creative name “Summer”. It has been playing every summer since the 50s and is a Swedish institution. The concept is simple: invite Swedes who have done interesting things in the past year or so and let them talk about their lives for 1.5 hours, mixed with music of their choice.

This year, I’ve only caught a few of them, and the one I’ll tell you about now I only heard 5 minutes of. The program was hosted by the former manager and coach of the Swedish National team in soccer - Lars Lagerbäck. He has had a great career as a coach but has always been very shy and in the background, so you don’t know much about his leadership style. Obviously, he did something good since the team has done well in recent years.

It was really just a single quote that stuck in my mind and got me thinking about our industry. On his leadership style, he said:

“I’ve always strived to have as few rules as possible and instead have guiding stars for how to do and behave. With rules comes consequences, and I think that’s really painful to handle.”

In this post, I’ll examine that a bit closer and see if that mentality has room in our industry.

Mr. Lagerbäck has a great point here in my opinion. If you lead with rules and regulations, you must have some sort of consequence for not following those rules; otherwise, the rules have no meaning. Mr. Lagerbäck mentioned that in his radio program, recalling an episode from a 2006 training camp:

One of the few rules that the Swedish National team has is that you should be at the hotel by 11:00 PM the day before a game. A reasonable rule, I think. However, in 2006, three of the biggest stars of the team (Zlatan Ibrahimovic, Olof Mellberg, and Christian Wilhelmsson) stayed out later than that.

A rule was broken, and now the consequences had to be met. There was not much to talk about really since the rule was clear: the three players were sent home. One of the hardest decisions in Lars Lagerbäck’s career.

What if this had not been a rule, but rather a guiding star like: “in order to be in the best possible shape for the games we play, we strive to be in bed at a reasonable hour the day before the game.” The player would still have gone out, and that would have been bad, but the discussions that followed would have been much easier to hold, interesting, and most importantly, consequences were not on the table.

  • “Do you think coming home at 1:30 AM the day before a game is reasonable?”
  • “Why is this bad?”
  • “What can we do differently to make sure that we understand this guiding star better?”
  • “How do you feel that you supported the team in this situation?”

There could still be consequences, of course, but that would then come out of a discussion with the players, maybe even as suggestions from them.

Software development

I’ve never in my life written this much, or even thought this much, about soccer before. Let’s get back to software development. What are the rules in our business? How can we apply this thinking in the software development process?

The first thing I came to think about is estimates and predictions and how we hold people accountable for these.

“Do you COMMIT to these estimates?”

I’ve even heard about teams doing a quick estimate (“with what we know now and the 3 hours we put in estimating this, we think it’ll take us 3-6 months”) having their estimate (3 months, of course) put into the company-wide plan and even changed on a slide that they were presenting!

Dan North says it best:

“We would rather be wrong than uncertain”

So what if that poor team had to COMMIT to that plan? Here I use the word commit in the worst possible, but still most widely used, sense;

“commit to these estimates by writing your names here on the dotted line.”

That kind of commit has an implied consequence connected to it. You could almost hear the “or else” in that last sentence, right? There has to be an or else when you require people to COMMIT to their estimates. People will be yelled at, someone might get demoted, we need to tell them to get their act together if they fail and in the worst case, in repeated offenses, someone can get fired.

Just for reference, there’s another kind of commit as well (see, not ALL CAPS). This is the type of commitment you get from a team that is involved and engaged in the product. The sad (?) news is that this cannot be pushed on someone. You cannot scare a team into being committed - no matter what you say after your “or else”. It’s something that grows out of happiness, responsibility, and autonomy. Now where have I heard that before. Commitment comes with motivation.

Now think that we took another approach. Something a little more like a guiding star, for example:

“these are our goals and we will work to the best of our ability to reach them during the next 6 months. After that period of time, we will evaluate and see where we are.”

Sure, we don’t know where we would end up, but are we really more certain of that when we require COMMITs? The approach with the guiding star is also showing a lot of trust in the people that will do the thing. And acknowledge the fact that we really don’t know what is the best approach.

Also; we know exactly how much it will cost to run this team of 4 people under 6 months (4 ppl 6 months monthly salary). Now - how do we want to spend that money? What is the best way of investing in this team so that we get closer to our goal? These are much nicer questions to ask than to have to handle the consequences of failing our deadlines and plans.

Summary

Estimates are still a big thing in many organizations that I visit. There are people working with organizing the people that are doing the estimation in some cases. We then require one part of the organization to COMMIT to the estimates … or else!

These are rules that we impose on each other. With rules comes consequences. With consequences comes suffering.

Since we are imposing the rules we can also stop using them and start relying on each other and work from goals and guiding stars instead.

Finally; has any customer ever phoned you up and thanked you for those detailed plans? No, because they don’t care about plans. They care about features in your software, or great service, or fast handling of their case or … Never plans and estimates.

Thank you, Andreas, for your input on this article.

Twitter, Facebook