Give Your Metrics an Expiry Date(adrianhoward.com) |
Give Your Metrics an Expiry Date(adrianhoward.com) |
For example with Architecture Decision Records, put a 6 or 12 month expiry on them and evaluate to see if they can be renewed, should be changed or replaced with something that covers new insights.
Unfortunately that seems a very unpopular thing to do so I’ve never seen it work and companies end up with “we have always done it like this” type practices
Architecture should not be "we have always done it like this". If you don't write down why though it will become that. Often there are good reasons that things have always been done like that - those reasons may or may not still be valid but if you don't know what they are it is hard to evaluation. More than once I've seen someone rethink a "we have always done it like that" and discover the hard way why they always did it that way.
I've never seen a company with a good way to write down why they do things though. When someone even tries nobody reads those documents.
Or it might be an architectural decision to change the hierarchy of some organisational structure. Again, it could be the correct call for the time, but as things evolve over a year, it may not be sufficiant a year later.
A year isn't a bad time to review, and if the decision is just a "yeah, duh, of course we'll continue", then it's a really quick conversation, but at least you're thinking about things.
Keeps from changing up too often but also gives a conscious evaluation.
Then when new knowledge/technology/idle cycles come along they can take advantage to update/refine it in sensible ways.
Often the sensible way is "leave it, it works fine". But there's a big difference between arriving at that outcome via ignorance vs. deliberation. Too often management doesn't recognize the difference, but the former as your state of affairs will eventually lead your stuff to rot.
The metrics I think you’re referring to are the ones you collect throughout your product, which I think the article author would advocate you continue to collect and expand.
The “metrics” the article references is more actively tracking and referring to them in your workflow. So, tracking and acting on changes to conversion rate. If you “expire” them, you don’t stop collecting them, you just take them off your dashboard for now.
Or less politely, make it future citizens’ and another administration’s problem.
Your org chart should be tweaked every year - as should your architecture. However major changes should not happen often - if at all.
To clarify - budgets passed via the reconciliation are supposed to be revenue neutral. The reconciliation process takes away the Senate's filibuster. When the filibuster is in play, it effectively requires a 60-40 supermajority to pass anything.
(No this is not how the founders imagined the process going when they wrote the rules.)
So they do the thing where they set breaks to sunset in order to make the bill revenue neutral according to the CBO.
Then, later on, when the tax breaks are ready to sunset, they convince the CBO that the tax breaks constitute the new baseline. So now when they pass the next budget they are not considered "new" and they do NOT need to be balanced with cuts or increases any more.
It's a total end run around the intention of the process.