Calculated Risk

Calculated risk is choice weighted by uncertainty and understanding. It attempts to identify and quantify all the variables, and then calibrate those it can towards the desired outcome. It isn't about reduced uncertainty so much as weighing potential avenues for failure against the rewards for success.

Calculating risk is often only half the work. The greater goal is to learn from missteps and then iterate better. Having the means to track and measure the outcome is what makes the process repeatable and open to refinement.

A baking recipe is, at its core, a ledger of calculated risk. By controlling temperature and time, by measuring ingredients and mixing them in a precise order, a baker attempts to repeat what has worked before. Every bit of it is intended to control or mitigate variables like environment, humidity, protein reactions, aeration and ultimately flavor and texture. They become precious understandings, handed down over time, because they have reduced risk to the point that they repeatedly produce success.

Well, mostly ... and that's key to understanding the topic, and also how a single failed bake is a small price to pay compared to the next product you launch.

Take new hires, for instance. Organizations spend months vetting new candidates, provide comprehensive benefits packages and vacation time, and nurture their development through training and mentorships, following up with performance reviews and evaluations. All of these are attempts to manage the probability of success. Even though the efforts are mostly subjective, they are based on previous understandings and experience.

Effort

Where it all falls down is visualizing effort. Effort in this instance describes the amount of time an individual spends against the company's product, whether that's sales, manufacturing or a service. Many things outside the product consume capacity, such as meetings, travel, training or planning. Understanding the organization's actual available "effort capacity" is core to calculating risk.

And yet, few organizations can tell you with certainty where their employees' time is pointed at on any given day. It's understandable. Even when the tedious effort of time tracking is enforced, it is applied against loose categories and described more than defined. There's no way to aggregate "was on a sales call" against "follow up with client" if they are just words in a ledger. Even if somebody was reading those descriptions ... and let's be honest, nobody is ... the information is sparse. You capture the hours, but still can't quantify the effort.

Another commonly unexamined risk is visualizing how effort is spread over tasks unrelated to the role the hire is meant for. Accountants bogged down by HR tasks, developers scattered across interdepartmental meetings, sales teams on the road more than in front of clients.

Effort is one of the most significant controllable inputs in an organization, making it a primary candidate to track and measure against risk.

Measuring Effort

In order to calculate effort, you need reliable, repeatable measurements. If I record the time it takes me to finish my morning run, that information isn't valuable unless I also record the distance. Remove one input and the other becomes meaningless because there is nothing to measure repeatability against. Measure both and you have a yardstick. Compare them run-over-run and you start seeing how longer distances, run frequency and intermittent sprints affect the ongoing quality. Those are all measured inputs, and collectively they inform risk of injury, exhaustion and overall health.

By reducing the number of variables to repeatable measures, we reduce the risk of any one of them reducing our chances of success. Maybe. See, we also have to understand what changes in that input will affect. Running faster isn't a solution if it increases the rate of injury. Running slower affects stamina and muscle tone. This is the next part of the equation: understanding the effect of each measurement on the result.

Let's take a simple hypothetical: Andrew thinks he spends too much time in meetings, Cornellia too little. It matters because they are the VPs of their departments, and each provides valuable insights and experience to the team members they interact with, but both also do important work on their own.

The measurement problem is this: if either modifies their behavior, they'll have no way of meaningfully testing the outcome. Does less interaction force the team to increase their own understanding instead of relying upon a single source? Does more interaction provide more insight and better outcomes?

Each choice is uncalculated risk because there is no way to track the outcome. Subjectively it might feel right, but six months and a failed project later, who's to say if one of those decisions, or both, affected the outcome. It is an expensive problem to have.

Enter time

The key to measuring effort comes down to several things, both in measurement and enablement.

Let's tackle measurement first. Tracking time without tying it to the work done is almost entirely pointless. It puts a tick on a ledger for billing and attendance, but little else. To be meaningful, to track effort, it has to be applied against the thing it moved (or didn't move).

Here's a practical example: two hours on "Monday morning catchup" where the entire team talks about product and shares understanding. As an equation, that's sum(2h * 20 attendees). That's 40 hours of combined overhead that informs but doesn't directly (and hang on to that word) move the product.

Then sum(20h * 2 teammates) against "certified the product for production". It's the same block of hours with an entirely different outcome, and yet the two are intimately related. If the first hadn't happened, would the time in the second have been doubled, tripled, or ever have been reached?

Admittedly, the correlations of overhead (time not on a task) to work (time on a task) are both imprecise and complex ... that's where using the term "directly" would fall down badly. It takes managers with precise understanding of the business to see the relationships, but that is also their entire wheelhouse. The difficulty has never been sensing the drift or feeling the friction, it has been measuring and visualizing it, proving out gut feelings. Once you have the data and start "adjusting the knobs" with purpose, effort vs. outcome reveals itself.

Signal vs Measure

There are different classifications of measurement, and some are closer to signal than measure.

RoE: task hours / total hours

This is return on effort at its most basic. The total number of hours on tasks against all hours. On its own it doesn't speak to risk inputs like quality, profit, percentage of rework or what ended up in the bin.

It also doesn't separate types of work. Product hours are a very specific thing, but tasks could live in error tickets, internal maintenance or product support. All are important, but none of those directly ship product, so the risk assessment has to dig deeper into return on product effort.

RoPE: product hours / total hours

That baseline is closer, but even then you need to introduce other measurements.

• Momentum: the speed at which you can apply product hours

• Throughput: the rate at which you deliver product

• Accuracy: how well you are estimating the number of hours needed to finish a task within the allotted days

• Rework: how often the task returns from "done" back into "doing"

• Waste: how often tasks are abandoned without being marked "done"

...and then taking each accumulation of tasks related to a goal or feature (an Epic in developer terms) and tying it to a value metric (i.e. dollars).

So:

RoPE ↑ + Throughput ↑ + Accuracy ~1.0 = probably healthy

While:

RoPE ↑ + Throughput ↓ + Rework ↑ = something is seriously wrong

The relationships that matter are tied to your organization's workflow. Rework might be constantly high because you have a prototype+iteration workflow. Accuracy may be low or zeroed out because you don't estimate hours (much more common in an AI agentic engineering workflow, where planning hours now greatly outpace build hours).

The important thing is establishing a metric, and then comparing it segment-over-segment to identify hazards or signal improvement.

Enablement

Isn't this all easier said than done? Up until a few years ago, I would have said absolutely. There have always been tools and tricks to make time tracking both easier and better, but most have been either invasive or so broad (20h in MS Word) as to be useless. AI has, like so many things, changed that.

Statistics are raw and new, but AI usage within organizations is only rising. Gallup reports that nearly two-thirds of professional-services employees use AI at work, with more than a third using it several times a week or more. Thomson Reuters reports that organization-wide GenAI adoption among professional-services respondents rose from 22% to 40% in a year, while more than 80% of professionals already using GenAI now use it at least weekly.

AI agents are ideal conduits for accurate time entry. They are able to securely connect to professional tracking apps via MCP to both query and write entries. When recording time through an agent, a user doesn't have to fumble around with input forms or flip between screens. "Log 2 hours against the Jenkins file" or "record that time against the Unicorn project" becomes time, task and context all at once.

Even more, if the work is performed within an AI agentic application, as is increasingly the case for software engineers today, the time recording can be done silently in the background because the agent walks through all of it. Given agency and within proper guidelines, the agent can reliably record time and tasks with a precision and depth (think full-context documents instead of "fixed the login screen"). I know this to be true because it has been my working state for months, and my ledger is now always full, accurate and in perfect sync with how and where my effort landed.

And yes ... I can sense the "but what about privacy?" thoughts in your head. Privacy is a serious matter, which is why for my choice of tool (AbleTime, obviously) every entry is a private draft that only I can see, and only I can approve.

Risk Managed

All through my career, my professional frustration has been the absence of measurable insight. Of having to make decisions based on opinion, vibe and assumption, only to discover too late that capacity, workload, understanding and estimation were incorrect, mistakes that ultimately consumed the bottom line. The same mistakes repeated, because nothing was measured, and no risk could be calculated.

If AI has given us anything, it is the ability to capture and record information, and then break it down in meaningful ways. Its imperfections can't be papered over, so we still need strong systems with reliable outputs to ensure what we are looking at is anchored to reality, but it finally gives us the ability to deeply manage risk without also increasing friction and distraction.

Understanding your return on effort isn't the whole fight, but it is the terrain. Managing your return on effort, understanding how to A/B test your decisions, understanding how throughput and momentum and pressure affect your profitability and organizational health ... those are learned skills. The good news is we finally have the tools and cognitive space to understand them.

Unmeasured effort is a vector for risk in any organization. My advice is to learn how to measure it, gain the advantage of insight over your competitors, and measurably improve the quality of your workflow.

AI usage stats:
https://www.gallup.com/workplace/701195/frequent-workplace-continued-rise.aspx
https://www.thomsonreuters.com/en/reports/2026-ai-in-professional-services-report