A simple enabling rule revisited
I like when we can make things simple – I hope that comes across in my writing and the ideas which I shared here!
A simple idea I like a lot is that of simple enabling rules… One that I have written about before (in fact twice) is something I learned from a Mind The Product post (there shared as an anecdote) although unfortunately have never been able to track who’s actually behind the phrase:
What you build will own you!
Please notice the nuance – chances are you may make a best pattern matching to what’s typically refer to a kind of maxim for DevOps: you build, you own it. But this goes levels deeper, if you really think about it. Almost flips it on its head, and with that communicates something even more fundamental (in my personal opinion).
To put it bluntly – it can be a trap! We can trap ourselves in an endless build mode which brings about more and more complexity, until things could become unmanageable. I think it’s a pretty sound principle and rule to follow as a product person, particularly if from that we follow through some of the actual enabling extrapolations of what we can do about it:
Minimize Time to Value: Is this the smallest thing that we can deliver?
Solve for Need: Will this help solve the customer’s problem?
Excel at Change: Can we keep the cost of change low?
I have always found insightful as you can connect each of those dimensions as roughly having a “center of gravity” on the product trios setup (often advocated to get better at managing products):
Minimize Time to Value → very linked to Design choices
Solve for Need → pretty much the job of a Product Manager
Excel at Change → a clear contribution of Engineering
By now, if you have been following this for a while, you may have also picked up on that I am a bit of a visual guy, as well as someone who likes to think in (mental) models (although I am also aware of the limitations of that concept – still somewhat useful on a practical level)... And this is a more recent insight that builds in the previous statements: the idea that we can think of that dynamic as a kind of potential flywheel effect…
It works whatever you want to have a starting point… For example…
If we get better at minimizing time to market chances are it will be easier to make those changes (because it probably imply smaller batches of work, at minimum, but maybe also simplified workflows, stuff like that)...
If we improve the ability and excel (at making) changes, that tends to breed a mentality of doing (first) only what is absolutely needed and be prepared to be responsive to feedback and learnings (which tends to sharpen in turn even further our ability to excel at change)...
That surely should benefit and in fact mimimize time to market.
I am convinced that teams and organizations that master that dynamics are better off to face the challenges of the fast-moving influx world we live in… You don’t even need to be perfect at it (likely no one truly will ever be…) – it’s largely the intention combined with deliberate consistency in (attempting) doing the right thing that goes already a long way.
Just don’t count on me in falling to the trap of calling that out as a just of matter of “mindset”. Not that such a thing doesn’t have any utility as a practical matter, but just that it’s not action-oriented.
So to me, really the call out is what does that mean on a practical level in your context? What are the things you can do right now, and then what can come next, that will help you nurture that kind of thinking and way to go about development work?
To get a bit more practical, with a couple of examples (or “nudges”):
Where are you currently with you CI/CD discipline? Does having the ability technically truly mean working software at hands of users (earlier)? Or does that just means code has been integrated and perhaps even deployed – but no idea if actually being used (yet)?
When was the last time you truly questioned a demand that come your way, on a fundamental level? Truly attempting to separate a “want” from a “need”? And maybe once you did that, you agreed to first make a sensible try out first (which could be done faster) so that you’d gain more insight before committing all the way!?
What I alluding to in all of this is that the simple enabling rule won’t naturally come to picture just because you thought of it, and it resonated. It will depend on actions to bring that to life on a practical level and the consistency to keep doing that right thing to get better and better at it… Day in, day out…
It’s a journey – but one that I believe is at reach by any team or organization, at least to some extent. And maybe that’s the starting point and the spark for something bigger by influence and spreading… After all, there’s an element of “contagion” to things that are working out – at least that’s on the realm of possibilities and empirical evidence shows that it can happen!
I guess one way of putting it is that the “be water” (like in this example from a previous post) thing can be accompanied by a kind of “virus”... But it’s a good one – if such a thing would exist.
So why not attempting to spread this simple enabling rule in your context? What you build, will own you!
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. I’m passionate about leading to achieve better outcomes with better ways of working. How can I help you?