Decisions’ memento mori

TTL means Time To Live

TTL 3

👋 Good Morfternight, this is Paolo Belcastro, with the third issue of: TTL: Tools & Thoughts for Leaders.

Here on TTL, we’ll dig into practical leadership tips and effective strategies, with a particular focus on tech leadership and managing distributed teams (that’s what I do every day).

Whether you’re steering a tech startup or leading a remote team, these insights are designed to help you navigate the complexities of modern leadership.

Today, let’s dive into the concept of TTL.

No, we’re not talking about this newsletter, nor tools or thoughts or even leaders!

We are going to discuss TTL in a geekier way: Time To Live, a fancy acronym that tech folks love to toss around.

---

What is TTL?

Alright, let’s break down TTL:

Time to live or hop limit is a mechanism which limits the lifespan or lifetime of data in a computer or network (thanks to Wikipedia for always having our back!).

Imagine TTL as a countdown timer on your data’s life in the digital world, just like the expiration date on a carton of milk.

It’s a mechanism to ensure data doesn’t overstay its welcome. It can be a counter or a timestamp attached to your data, ticking down its lifespan. When the countdown hits zero, the data either gets kicked out of the party or needs to show a fresh invite to stick around.

In the world of computer networking, TTL stops data packets from wandering aimlessly forever. Without TTL, these packets could be lost. By setting a limit, TTL makes sure the data doesn’t just float around endlessly, eating up resources and causing chaos.

In computing applications, TTL is commonly used to improve the performance and manage the caching of data.

TTL in computing

This concept is familiar to me, since I’ve been working with DNS (Domain Name System) since 1994.

In that case, TTL helps balance data freshness and performance.

Think of it like this: with a short TTL, your DNS records are like hot gossip – they get updated superfast, so everyone knows the latest scoop. But, just like gossip, it means more trips back to the source to check for updates, which can slow things down, as DNS requests will very often have to go as far as the DNS root servers.

A long TTL is like a good novel – it stays the same for a long time, so fewer checks are needed, speeding things up, as most DNS requests can be cached at the local, router, or ISP level. However, if there’s a plot twist (like changing a DNS setting), everyone sticks to the old story until the TTL timer runs out.

TTL in the decision-making process

Now, how can we apply this to our work?

Let’s talk about Decisions.

Yes, we kind of already did, but in A Framework for Better Decisions, we used a 2×2 matrix to determine when team members should consult leaders.

Now, we’re going to use another 2×2 matrix to determine when leaders should consult their own decisions.

Many decisions, laws, and techniques can become outdated if they’re not periodically reviewed and updated.

In Milan, the law compels you to smile. It’s prescribed by a city regulation from Austro-Hungarian times that was never repealed. (But funerals and hospitals are exempted). Meanwhile, in France, an 1800 law forbidding women to wear trousers has only been revoked in 2013 (although exceptions had been added for when a woman is riding a bike or a horse).

It’s pretty obvious that these laws are outdated, and they vastly outlasted their purpose. Why? Because no one thought of checking on them.

This generally isn’t too big of an issue in the context of the law, courts of justice are there as safeguards after all, but it might become a problem for your team.

Regular check-ups

Let’s break it down. A leader’s job most often involves deciding not to do things, and occasionally deciding to take action.

Both types of decisions should get a regular check-up.

• It’s important to review the “do” decisions later to check what worked and what didn’t, so you can learn to make better ones.
• The “don’t do” decisions might need revisiting because context and priorities shift, potentially requiring action down the road.

Implementing a TTL (time to live) parameter for decisions in software development is a practical approach to ensure they are revisited and potentially revised based on new information or changes in context. You need to know when to kill your darlings as taught by Stephen King, or keep’em alive if they’re still useful.

Now, let’s talk about how to do it practically.

The matrix

Let’s look at two key dimensions when making decisions:

1. How impactful will it be? Is it a minor tweak or a major game changer?
2. How certain are we about the outcome? Are we rock-solid confident, or pretty unsure?

If we plot these on two axes, we get:

• Horizontal axis: Uncertain → Certain The horizontal axis ranges from Uncertain, where outcomes are unpredictable and confidence is low, to Certain, where outcomes are predictable, information is ample, and confidence is high.
• Vertical axis: Low Impact → High Impact The vertical axis ranges from Low Impact, representing minor tweaks with minimal effect, to High Impact, representing major changes with significant effects and requiring substantial resources.

This gives us four quadrants:

1. Certain/Low Impact (bottom-right): No need for a TTL, as these are minor decisions.
2. Uncertain/Low Impact (bottom-left): Set a TTL far in the future (years).
3. Uncertain/High Impact (top-left): Set a short TTL, as these need close monitoring (weeks).
4. Certain/High Impact (top-right): Set a medium TTL (months).

Practical Application:

To apply this matrix in your decision-making process, follow these steps the next time you make a decision:

1. Evaluate Impact and Uncertainty: Assess that decision’s impact and its level of uncertainty.
2. Plot on Matrix: Place it in the appropriate quadrant of the 2×2 matrix based on your evaluation.
3. Assign TTL Values: Based on the quadrant, assign a TTL value to the decision.
4. Schedule Reviews: Create a task in your calendar at the appropriate date, with a link to the decision and any notes you may need.

Automating reminders for these reviews ensures that no decision is overlooked, providing a systematic way to revisit and potentially revise decisions.

---

→ Add me on LinkedIn

That’s it for today. If someone forwarded this to you,
you can subscribe to get your copy next week.

I also publish on paolo.blog and monochrome.blog

Cheers,

P.S.:  If you enjoyed reading this, please share it.