A fellow software engineer recently asked me: “If you had a few minutes to talk about only one thing in our company townhall, what would it be?” This is such a great question, it highlights this individual's desire to learn how other people think, they're a really great software engineer and thinker—that's a topic for another day.
My answer? I only needed to think about it for a few seconds, then it came to me:
“As an organisation, we should adopt the principle of optimising for fast feedback. When presented with multiple—seemingly equivalent—options, prefer the option that gives you feedback sooner. When viewing options with this lens, there's almost always a clear winner”.
I'm still not sure where that came from, obviously it's not from my own brain (anything I know I've learnt from others). Given an opportunity to discuss anything, in front of 100+ people, why “optimise for fast feedback”?
I reverse engineered my response for a while and I came up with the following rationalisation.
Fast feedback is widely applicable
It doesn't matter where you are in the org chart, it's extremely important to find out (measure) whether you're:
On the right track
Making the right decisions in your career
Trusted by your peers
Making the right product/project decisions that support that organisation’s initiatives
… (the list goes on)
Getting that feedback sooner is always going to be better, rather than finding out 6 months from now.
Seems reasonable, almost obvious and not really a novel concept, but, in my experience it's exceedingly rare in practice.
So, how does “fast feedback” manifest? What are some patterns and practices that an organisation or individual can implement to move them into this idyllic state of getting signals more timeously?
There are many ways, I’ll leave that research for another post, I just wanted to get this out of my head for now.
Great write up, Barry. Keep them coming!