Thursday, June 20, 2013

Do it right, then Do the Right thing online

I was at the Nordic Developer Conference (NDC) in Oslo last week (well, me and about 1700 other people!). I took a risk, I spoke to the title “Do things right and then do the right thing” (now on SlideShare). I was deliberately challenging accepted management practice.

In many ways this was an experiment itself, the presentation is based on a feeling I’ve had for a few years now - dating back to the Alignment Trap - but never really sat down to argue in full. In part I was looking for people in Oslo to shoot down my argument - or support it! I’m glad to say that so far most of the comments I’ve had have been broadly supportive.

Basically my argument is this:

  • It is incredibly difficult to know “the right thing”
  • Therefore it is better to try something, get feedback (data etc.) and adjust ones aim; and repeat
  • However, in order to do this one needs an effective delivery machine
  • In other words: you need to be able to iterate.
Thus organizations need to “do things right” (be able to iterate rapidly) and then they can home in on the ultimate “right thing.”

I used the analogy of using of trying to hit a target with a gun. First you shoot, then you use what you learned to adjust your aim and shoot again. Again you use the feedback to refine your aim.

You might choose to use a machine gun, rapid fire, rapid feedback. Cover the target in approximate shots.

Alternatively you might use a sniper rifle. One perfectly aimed shot and bang! Hit first time.

While I’m sure many organizations would like to think they are using a snipers rifle (one bullet is cheaper than many) I’d suggest that many are actually using something with significantly poorer performance. An older weapon, one without sharp shooter sights, on which requires manual reloading, one which is prone to breaking.

As a result they try to make every shot count but they just aren’t very good at it.

While one might like to think that organizations make a rational choice between these different approaches I think it is more a question of history - or path dependency to use the economic term. You use the weapon you have used before. You use the weapon which your tools provide for.

I’m not saying this argument is universally true but I think it increasingly looks like the logical conclusion of Agile, Scrum and Lean Start-Up. I am also saying you need to try many times.

In technology our tools have changed: when teams worked with Cobol on OS/360 making every shot from your 1880 vintage gun count was important. But for teams working with newer technologies - especially the likes of Ruby, PHP and such on the web - then a trial and error approach might well be the best way.

Possibly the right answer is nothing to do with your organisation but rather a question of your competitors. You want to choose a weapon which will allow you to out compete the competitor, perhaps through asymmetric competition.

Of course the key to doing this is to work fast, and fail fast, and fail cheap. If you take a long time to fail, or if it is expensive then this technique isn’t going to work.

After the presentation Henrik Ebbeskog sent me this blog post via twitter which is beautiful example of exactly what I’m talking about: You Are Solving The Wrong Problem.

Then I went to the PAM Summit conference in Krakow were James Archer included a wonderful quote in his presentation:

“Faced with the choice between changing one's mind and proving that there is no need to do so, almost everyone gets busy on the proof.” economist JK Galbarith.

This adds another dimension to my hypothesis: that when we invest a lot of time, energy and/or money in detraining what the “right thing” to do it it becomes more difficult to change our mind.

For example, suppose we invest a lot in building a new feature on our website, and suppose that in the week after launch the new feature performs poorly, or at least less well than other recent new features. Those who have invested a lot in arguing for the feature, those who feel closely associated with the feature may be more prone to say “Give it another week, lets get more data” while those who are more distant might be prepared to review what is happening sooner.

In order to accept “failure” we cannot invest too much of ourselves in any feature, shot or attempt.

I’m still not completely convinced by my own argument. The management doctrine “Do the right thing, then do it right” is so strong in me - and so logical. Although I can build reasonable argument for “Do it right, then do the right thing” that I’m still uncertain that I believe it.

What do you think?

Truly, I’d love to have more comments on this.


  1. Cannot agree more on this. If I have choice between an effective or an efficient team or developer, I'll always choose efficiency. Doing the right things is great, but as you already stated, it's pretty hard to know (exceptionally often) what is the right thing at this exact moment. So it's always better do the most obvious that brings some benefit and reflect on the direction it goes. Running fast in the wrong direction and turning early is preferable to running slow but long. In the end, you lose time to market and that is, what is really important in the end.

  2. Reminds met of the OODA loop, where the essential lesson is the importance of generating and maintaining tempo in command in control. In other words, speed is an essential element of effective command and control [MDCP 5].

    It is not about making good decisions. It is closing that loop really fast. Maneuver warfare.

    Also depends on context, IMO. See Cynefin model as well.

  3. (Whoops, Tony Edwards ( left a comment on this blog but I accidently hit the "reject" button not the "accept" button. Sorry Tony, here is his comment)

    How do you know when something is not right? When you review or do the right thing and notice something could be better. I can propose what's right, but won't know until I try to do it.
    One 'right' needs the other, either way - its a bit like the chicken and egg question.


Note: only a member of this blog may post a comment.