Presenter: David Anderson in an "open jam" session.
Liquidity is the ability to easily turn one asset into another (not just money!). Anderson’s idea on liquidity in a software organization relates to the skills of the people on the team and how we assign them to roles/tasks.
Let’s say we have three skill areas that are relevant for projects: A, B, and C. We have four engineers available with the following profiles (the number is their skill level, ranging from 1 {novice} – 5 {world class}):
E1: A3 B3 C3
E2: B2 C4
E3: C2
E4: C2
Now let’s assume we have three roles to fill:
R1: requires B
R2: requires C
R3: requires C
How do you think most organizations typically allocate resources to those assignments? If you didn’t say:
R1: E1
R2: E2
R3: E3
… you are cheating. This is exactly how we typically assign resources to projects (and often, people to roles within projects). Why wouldn’t I want my best available designer designing? My best Java guy on a Java project?
But what if a task, project or crisis arrives later that requires skills A or B? We have already assigned our competent+ people and they aren’t available anymore. It is quite likely that the cost of having a novice B doing B is a lot more than the money saved by having an expert C over competent C. We have reduced our ability to take work and our talented people and turn it into business value for our customers. If your experts are already assigned, you have to make costly choices such as putting someone not-quite-ready into a role or moving resources between projects, both sub-optimal solutions.
What Anderson is telling us is that we should be paying attention to our current liquidity and making decisions that optimize it for the whole organization rather than optimizing performance on a specific project. We optimize it by NOT assigning our generalists. The right answer for maximized liquidity in the above example is to assign our specialists (those with a more narrow skill set) first, and hold our generalist in reserve.
R1: E2
R2: E3
R3: E4
He is even going so far as to explore numerical values associated with this (a liquidity score, if you will). I’m reserving judgment on the value of going that far … might not make sense in an organization of SEP’s size. Or, it might be a nice dashboard metric for us to have in staffing and hiring. We have a career path skill assessment system in place that may be a good starting point for this, though they don’t consider strength in different technologies, which is highly relevant in staffing decisions. At this point, I’m planning to incorporate this into my own planning as just a “good thing to do”.
