Or you could just fix all the bugs that are upsetting customers and causing them to flee.
I've been in the situation where the metrics were used at a detailed level. Net Promotor Score (NPS) was used by the company and I tried, somewhat successfully, somewhat unsuccessfully to use OKRs at the team level. I agree with everything that has been said in using these to set the overall the direction and strategy at a high/medium level but down on the front lines it's very hard to do anything that will move the needle in the right direction in a clear cause and effect way.
If you try and map tasks to strategic goal then you just up window-dressing everything to keep management happy and since the components of goal X are many any varied your chances of success are limited.
> If you try and map tasks to strategic goal then you just up window-dressing everything
If you don't understand how your daily work is related to management's priorities then probability is high that you are going to do a lot of work that isn't valuable to the organization.
So, either it should be a trivial exercise to rationalize how a task is related to the objective, in which case this is nothing more than a small overhead of working in an organization. Or if you find you have to make leaps of faith to make the connection to the objective then that's a signal that you need to consider why the task needs to be done at all.
>>> fix all the bugs that are upsetting customers and causing them to flee.
Well yes. I am just posting that it is possible to take a top level metric and build a backlog that represents sensible solutions to that metric.
But you first need
- a top level metric (preferably that measures what will make or break your business)
- a way to determine what things under your control drive that metric.
But yes, the things you do in the trenches will probably not move the needle far. That is for two reasons
- at some point the code base is so big that doing "one thing" won't make impact (i think this is around the 100k SLOC) level which is still fairly small
- and even if you can affect the whole code base, the code is at the bottom
of an inverted pyramid of "leverage to affect the business" - the CEO can chnage the business far far more be deciding to triple the price tomorrow than any bugs you fix.
But yes - in the end, if you have a working product right now the best thing to do is to go
find real customers, work out why they are upset (either with clever telemetry analysis or just fricking ask) and go fix that bug / missing feature.
If you don't have a working product there is no telemetry so ... fricking ask.
But find what's not working and fix it is a good plan. If what's not working however is "the business model" we are in interesting territory
I think a non working business model
is exactly the purview of software. I think that we shall
replace all non-coding business people
with coders who can business in a generation. But that this generation will see real opportunities
I've been in the situation where the metrics were used at a detailed level. Net Promotor Score (NPS) was used by the company and I tried, somewhat successfully, somewhat unsuccessfully to use OKRs at the team level. I agree with everything that has been said in using these to set the overall the direction and strategy at a high/medium level but down on the front lines it's very hard to do anything that will move the needle in the right direction in a clear cause and effect way.
If you try and map tasks to strategic goal then you just up window-dressing everything to keep management happy and since the components of goal X are many any varied your chances of success are limited.