Always liked Reinertsen’s post on reframing tech debt to deferred work.
“When we refer to postponed work as technical debt this automatically biases us to assume that both ongoing and future costs are more certain than they really are. This, in turn, causes us to overestimate these costs, leading us to be overly cautious about deferring work. If it is your intention to bias the decision against postponement, this is clearly the best term to use. However, if you are trying to carefully weigh of pros and cons of postponing work, I’d recommend using a more neutral term like deferred work.”
I know the intent is good (it is!) but this common notion that good design is a toolbox of fun little games really prevents the design function from getting taken more seriously. In the business world at least it ensures our seat at the kid’s table.
Worth remembering that priority and sequence are not quite the same thing.
There's a useful framework called RICE where you evaluate/score ideas by Reach, Impact, Confidence, and Effort. Sometimes assigning numeric values feels forced so I often use it as "dimensions to be thinking about" rather than a literal scoring system. [1]
There's some great stuff in Reinertsen's Flow book about different sequencing strategies and when to use each. Eg, When delay costs are homogeneous, do the shortest task first. When task durations are homogeneous, do the highest cost-of-delay task first.
The author's framework-"you just start small and only add one at a time as needed"-and given example illustrate exactly the process that leads to too many metrics. Pick a few metrics, add another, add another, add another. If you have 5 teams working on a product you quickly end up in the 50 metrics scenario.
Too many metrics can be a problem but it's not the real problem. The real problem is choosing metrics without any regard for the decisions they're supposed to inform.
When you understand that the purpose of all measurement in business is to reduce uncertainty for a decision to be made, everything comes into focus, and you'll have a natural constraint on your scope of measurement.
Can you explain what is invalid about it? The list of functional cookie permissions on the consent opt-in specifically mentions cookies to remember log in details.
“Zoom cookies are firstly written when the user connects to the website zoom.us and accepts the cookies options.”
That was the moment Zoom received your consent to store data transmitted by cookies. Adding a few more cookies to the pile, regardless of expiration date, doesn’t change the agreement.
Rummaging round the cookie bin on uninstall is a nice find and deserves a raised eyebrow but this doesn’t really have anything to do with GDPR.
"I'd assume that for banks all code that goes into production gets audited"
The point of tag managers is to let non-developers update production without going through a code deployment so the usual code review and oversight doesn't apply.
Also worth keeping in mind that this is the bank's marketing site. It's almost surely managed by a different team than the actual online banking site and probably has looser restrictions.
The Internet Archive rewrites contents of scripts to inject the archive URLs. A better explanation than OP's clickbait is that someone went to the archive to copy/paste misplaced tracking code.