- Board to CTO : Increase Retention (decrease churn)
- CTO to DevLeads:
* Build a daily report emailed to the board showing 30 day moving average of churn
* Build a business event log - every time a user does something on the system log it to a easily queryable system (customer signs in, customer raises invoice or customer deletes widget) This can get very deep very fast. Start with Graphite / carbon and get more sophisticated later.
* hire a data scientist / convert DBA into one and find correlations between customers who churn and events in the log. Not logged in for 30 days looks like a good start.
* Write split testing into the (SaaS) app such that we can randomly segment customers at risk of churning (indicates by event activity) and see if we can keep them
* also add in "have you tried this feature emails", or "holy crap what do you mean the invoice page does not align right anymore"
All of these things (for a SaaS app) are doable projects for any development team.
This is of course based on the idea that the Board has told the CTO "fix this thing as top priority". If they have not that's their problem. The CTO should then go to the board and say "I am going to fix this thing as top priority"
Then we start the fun job of actually monitoring what developers do work on compared to what we planned to work on. Most times priorities chnage, legacy weighs us down and friction burns is.
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
- Board to CTO : Increase Retention (decrease churn)
- CTO to DevLeads: * Build a daily report emailed to the board showing 30 day moving average of churn
* Build a business event log - every time a user does something on the system log it to a easily queryable system (customer signs in, customer raises invoice or customer deletes widget) This can get very deep very fast. Start with Graphite / carbon and get more sophisticated later.
* hire a data scientist / convert DBA into one and find correlations between customers who churn and events in the log. Not logged in for 30 days looks like a good start.
* Write split testing into the (SaaS) app such that we can randomly segment customers at risk of churning (indicates by event activity) and see if we can keep them
* also add in "have you tried this feature emails", or "holy crap what do you mean the invoice page does not align right anymore"
All of these things (for a SaaS app) are doable projects for any development team.
This is of course based on the idea that the Board has told the CTO "fix this thing as top priority". If they have not that's their problem. The CTO should then go to the board and say "I am going to fix this thing as top priority"
Then we start the fun job of actually monitoring what developers do work on compared to what we planned to work on. Most times priorities chnage, legacy weighs us down and friction burns is.