Effective not Efficient

 How do you know if what you did today moved the needle? Delivered value to the business? And if you don’t know, why did you do them? [blog.mindrocketnow.com]

The answer to this last question normally boils down to being too busy to stop to think. Making time for reflection ends up being prioritised below real work, because there’s no immediate output. The name of the game is to produce as much output as possible, because that’s what can be measured, put into annual appraisals, paid a salary against, so we assume it’s an accurate proxy for delivering value.

There’s a logical thread from optimising output:

• To maximise output, we need to maximise utilisation;

• Which means we need to eliminate anything that impedes delivering output, anything that isn’t writing code;

• But we know that eliminating planning is bad, so instead, we do all our big planning up front;

• And we know that plans fail because of lack of contextual knowledge when the plans are made, so we need to do big design before big planning;

• To get the design right, we need to have clarity of the product we’re intending to put into market, so we need to put big market analysis and big product analysis before big design;

• This is a fair bit of work to do up front, with varying skill sets, probably from different teams, so we’ll need the various resource holders to agree that this is the right thing to commit their resources to = organisational alignment;

• To secure that commitment, we’ll need to prove that we’ve thought it through, and present a business case that associates output with investment;

• This business case is important, so we’ll need to put some thought into it, so we’ll need a little planning, little design, little analysis, little resourcing, little commitment…

• This is getting a bit recursive now 

Let’s look at the opposite position, where we aren’t optimising output, but focusing on creating the best output (let’s assume it’s software).

• We’ll probably have scrum teams with all the skills in-team to create successful, well-thought-out code;

• Because all the skills are in-team, we’ll be more nimble, responding to changes in context quickly, so the code will probably take less time to complete;

• We’ll probably be using DevOps techniques, so the code will have security, operability, quality baked in from the start;

But:

• We still won’t know if we’ve delivered any value, or merely great code.

Both cases are failures, because both rely on the assumption that output is a good proxy for value. It isn’t.

I once transformed a software delivery capability within a company that was overly focused on cost control, and therefore big everything up front, into one that was able to deliver quality code reliably without a big front, and so much more cheaply. Once the spend rate and code quality were no longer concerns, we were able to focus on what delivered value. And as it turned out, none of the features being mooted actually moved the market. Our investment was better made into marketing and content, rather than further app changes. So I pivoted the team to the next market, with a clear conscience knowing that done = Done.

Building software is complicated. Building the right software is not complicated, but it is harder. It requires trust that your process will yield good output, so the focus can be on understanding which is the right output.