Outputs create outcomes which have impact. Output is what we ‘physically’ deliver – typically that’s running tested software. The outcome is the net result our output produces – we helped customers to achieve the thing they wanted to achieve. Huzzah! Or maybe we didn’t. Bugger! Impact is the ripple effect of consequences from the outcome. Of particular note are the experiences we cause people to have – customers are ecstatic and tell their friends; we get more customers, more revenue, improved profitability. Or customers give up and look elsewhere for a solution to their problem. Another desired outcome might be certain technical debt is repaid. The impact? Perhaps an up-coming feature will now be cheaper to deliver and will carry less risk. Impact gives us reasons why. If our goal is to create a certain impact then we must consider the outcome and the output as hypotheses.

A measure of output alone, for example productivity, velocity or throughput, isn’t useful in determining how effective we are. We could be delivering the wrong thing; we could be delivering a load of wrong things.

Now I’m thinking out loud …


Successful in producing a desired or intended result

The degree to which something is successful in producing a desired result; success

Ok. So, if we are effective then we are successful in producing the desired impact. We caused people to have the experiences we wanted them to have and consequently they took the actions we wanted them to take. We helped them achieve whatever it was they wanted to achieve. We delivered the right thing. How impact is measured is entirely specific to that impact. And given the ripple effect an outcome is likely to have a different impact on different people in different contexts at different times. A measure of impact is not a measure of effectiveness. We might have had great impact but maybe we got lucky. Effectiveness feels like a performance characteristic – a measure of our ability to produce the desired impact. How could we measure effectiveness?

I’ve messed around with the idea of measuring effectiveness before. Back then I saw effectiveness as an indicator of a team’s ability to “sustain throughput (i.e. the number of stories released to production that deliver value) while fixing defects immediately and repaying technical debt to keep the amount of rework small“. I think the premise is still valid but maybe not the whole story. I’ve seen too many teams go on a feature-fest delighting the pants off pushy business owners but creating shit awful software. Every one eventually ground to a halt as the code became increasingly difficult and expensive to change. Technical debt comes back and bites! Surprise, surprise. Again, I think the idea of impact being ripples of concentric effects allows for a set of consequences from one outcome – delighted customers (problem solved); happy stakeholders (business value realized); healthy product (habitable code and hassle-free operations); healthy team (social capital).

Efficiently effective

Achieving maximum productivity with minimum wasted effort or expense

The state or quality of being efficient
The ratio of the useful work performed to the total energy expended

Pursuing efficiency without first being effective risks delivering the wrong things well. There are other wastes beside defects and rework. Basic coordination and transaction costs. If we are efficiently effective then we are producing maximum positive impact with minimum waste and expense. How could we measure efficiency?

Any thoughts? Please comment.