Conclusion: Who works on what – Comparative advantage part 3 of 3

HeadacheiStock_000014496990Small-2017-12-21-17-24.jpg

In my last two posts – Who should work on what? part1 and part 2 – I’ve tried to apply the comparative advantage model from economics to the question of which software developer should work on what. The model has come up with two different answers:

  • If productivity (measured by quantity of features is the goal) then it probably makes sense for everyone to work on the product that they are comparatively most productive on (comparatively being the key word here.)
  • If value produced in the goal then it may well make sense for everyone to work on the most valuable features (or product) regardless of personal strengths.

Along the way I’ve highlighted a number of difficulties in applying this model:

  • If common resources are being used, or if doing one piece of work impacts another, then the model doesn’t work.
  • There is no consideration of time or urgency in the model. When urgency enters the picture then productivity may well suffer.
  • Over time things may change: backlogs will stratify and people will learn.
  • Operating this model in practice requires data which is usually unavailable and so getting the data would itself take time.

At this point it is tempting to throw ones hands up in the air and say: “We’ve learned nothing!”

But I don’t think so. I think there are lessons in here.

Right at the start of this I knew this was a difficult question to answer, trying to answer it has shown just how hard it is to get a definitive answer. There are still more assumptions which could be relaxed in this model and still more variables that could be added.

The model has also shown how important it is to have a sense of value. Not only between products but between features. That in turn demonstrates the importance of both valuing work in the backlog and regularly reviewing those valuations.

However, the first big lesson I think that needs learning here is: you have to know what your intention is.

You need to know what you are trying to optimise.
You need a strategy.

For example:

  • Do you want to maximise the quantity of features delivered?
  • Do you want to maximise the value delivered? (probably measured in money)
  • How much do you want to allow for urgent work? And to what standard are you going to hold those requests?
  • Do you want to promote specific knowledge (so one person can become more productive in one domain) or spread knowledge around (so many people can work on many different things)?

In many this is going to be a self-fulfilling prophecy, the result will be what you put in. That is, if people only work on one product then moving people between products will get harder and less productive. If people follow the value then value delivered will increase as people become more productive in the products with the higher value.

Knowing what your intention is should be the first step to formulating a strategy. And having a strategy is important because answering that question – “who should work on what?” – is hard.

To answer that question rationally one needs to create a model, a model far more complex than my model, then calculate every variable in the model – plus keep the variables up to date as they change. Then to apply that model to every work question which arises.

Phew.

Alternatively one can formulate a rule of thumb, a heuristic, a rough guideline, a “good enough” decision process. This might sound a bit amateurish but as Gerd Gigerenzer says in Risk Savvy:

“To make good decisions in an uncertain world, one has to ignore part of the information, which is exactly what rules of thumb do. Doing so can save time and effort and lead to better decisions.”

To build up such rules of thumb requires experience and reflection, something which might be described as intuition.

So to answer my original question in terms an economist would recognise: It depends.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

Leave a Reply