111–120 of 125 posts
Earlier quoted context omitted.
This is exactly what we do. We reserve about 25% of every team's capacity for "other" stuff, e.g. maintenance. The PMs/leaders have to acknowledge for that when they compile their OKRs.
This just means someone somewhere has an unstated objective that things be maintained. Make them write it down, and then your 25% capacity supports that.
> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by 10% I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Someone needs to do the research, analys…
Say, for the above: KR A being test the hypothesis for churning using XYZ analysis method and KR B bring peer review that with specialist named Klopvital, Tartirius and Mochalatet. Then, once you improved an answer, I would think you have achieved a partial goal - and if that is data to someone else then it comes the choreography of things.
. . .
The whole reason of a system of goals is to have one work and what OKR helps relates to accountability - what is a measure that validates the goal. Of course, the complexity comes when one goal system is chained with the other - the orchestration.
Your case "Someone needs to do the research, analysis, and leg work of finding potential areas to exploit." partially opens the door to it for the idea of Committed OKR (the kind of OKRs that one can do, solvable).
On your point "And then someone needs to have at least some amount of vision or inspiration about how to solve that problem." this seems to be about the idea of Aspirational OKR. In this regard, I agree that many things in the entrepreneurial outset starts with a north and not a precise thing. Certainly OKR is not a system to work on requirements - do it and that is that. The OKR approach is influenced by short feedback reviews for goals — that is derived or inspired by Andy Grove insights about MBO vs feedback vs planning that goes on like a) point to a roadmap b) work on it with a temporary plan in an accountable transparent way c) review the plan and review the roadmap.
But I hear your strong statement that "but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results." and would love to talk with you to understand more your experience. From the book I read I came upon cases that some of the success cases too years to fix their OKR system.
* Some of the ideas here I was inspired by the Measure What Matters book by John Doerr. But of course it's my limited interpretation.
The way we thought about it was that OKR should not dictate 100% of effort. OKR is about prioritizing the changes that leadership wants to make at the productivity frontier of the organization. OKRs alone are not enough to direct company efforts. Leadership also needs to specify what % of energy should be spent on OKR vs other responsibilities. The OKR effort goal could be between 0-100 for different teams, or the company as a whole.
For instance, a company that needs to pivot or will die is probably close to 100% OKR effort on all teams.
This approach gets around the need to assign OKR to every activity and allows OKR to be more salient and less diluted as a tool for alignment and goal setting.
This put my thoughts on OKRs into words better than I ever could. At my last two companies, I've been beating the drum that the closer to an individual level you get the less useful OKRs are. The backward process of, "we know what we are going to do, how to we make it fit the OKR formula" drives me insane. Personally, I actually like OKRs at the organization or large sub org level. I think they are great at getting e…
Exactly. Individuals are far away from the actual organization goals. In my yearly review I have to categorize my achievements by stuff like "Supporting growth", "Fueling worldwide expansion", "Increasing customer satisfaction" and so on. I am very far away from any of these so either I indirectly support all of them or you could also say I support none of them. Just filling this out makes it clear that most of the c…
The hilarious thing where I work is at the end of each week I have to manually enter the hours I worked and I have N charge numbers to split up those hours. If you read the line item for each charge number it's basically a synopsis of one or more OKRs.
All this to say, from an engineer's point of view it seems with just a few tweaks in JIRA and Gitlab, review input could be created by running a report on commit history over the date range the review covers.
Earlier quoted context omitted.
I believe it should work like this - 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…
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/…
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.
> Joe Cannatti
Anyone else put off by the author quoting himself?
Earlier quoted context omitted.
I believe it should work like this - 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…
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/…
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
Earlier quoted context omitted.
If you’re not making some effort to measure the value and impact of what you’re doing, then how do you know if it was the right thing to allocate your effort on? Presumably the new message queueing system had some effect on customer experience or developer velocity - can you try to measure that? It doesn’t have to be perfect, but most teams would have a lot more impact if they spent some of their time getting at leas…
As a concrete example here you should be able to translate a new queueing system into something that has business impact. Maybe the new system requires 75% of the servers the previous one did, leading to increased revenue. Maybe it’s quicker, resulting in customers experiencing better service, and so churn is reduced from the pool of people who said “I like it, but it’s too slow”. A queueing system in itself isn’t of…
If you're an average developer at a non-startup you've likely been asked to put together a queuing system. You didn't decide to do that work, and you probably shouldn't be spending weeks trying to gather the information you might need to justify that work.
Your job wasn't to figure out 13.2% of your customers opt out of your paid reporting services because they experience slow responses and unrecorded data.
Your job is usually much closer to -
PM - Can we make this service faster? We're losing customers on this feature because it's slow.
TeamLead - Probably, we can re-implement our queuing to be quicker and more reliable.
Dev - Ok, I'll investigate [x] queuing library or service
Then you should be spending your limited time and energy on actually producing that result. The technical task is usually quite complicated (ex: here's just the table of contents for RabbitMQ https://www.rabbitmq.com/documentation.html).
The justification for the work wasn't your job to put together (although asking sane questions is usually a good call). Your justification was simply "My PM/TeamLead asked me for it".
----
I sure as hell don't want every junior dev on my team going out and trying to tease out the intrinsic business value of every task I give them.
That's a waste of my resources. That doubles up the effort that I already expect my PM to be doing. That leads to disagreements about priorities when those junior devs don't have the context about why a business decision was made and either infer it incorrectly, or spend lots of time asking when it really just doesn't impact them all that much.