When the problem crosses boundaries, so does the root cause.

What that looks like in practice¶

Here are two public examples of the same habit of mind, a decade apart.

• On the Mineshaft Gap ∷ A failed domain logon, a broken appliance integration, and a 32-bit authentication failure, traced to a shared design assumption: finite dates standing in for “never” in Kerberos, and what happens when implementations turn them into native time. Then the harder question: why nobody owned the migration.
• STIX 2.0 refactor ∷ Threat-intelligence tools that all “supported STIX” and still could not reliably exchange data. The interoperability problem was not simply bugs in the tools; the standard itself allowed too many valid ways to say the same thing. So we measured what communities were actually sharing, pared the model back toward that, and moved from XML to JSON. Within a year at OASIS, vendors were already writing code against STIX 2.0.

When to call:

• a supplier says a critical dependency is safe, but nobody can explain the assumptions behind that assurance;
• a recurring failure keeps returning, and each team’s account of it points somewhere else;
• a regulatory or product-security obligation crosses engineering, legal, security, and operations, and no single team owns the whole question;
• leadership needs to make a technical decision, but the experts disagree about what the evidence shows;
• a legacy, embedded, or time-dependent system nobody wants to touch is about to matter.

Focused assignments¶

A bounded problem, a clear deliverable, and a fee agreed in advance. Most fall into one of three kinds:

• Diagnosis: root cause analysis of incidents and recurring failures, especially where the cause sits between teams, vendors, or systems, and exposure reviews of legacy, embedded, or time-dependent systems.
• Product security: setting up or reviewing vulnerability handling and dependency management, or an independent assessment before a consequential decision. Increasingly, the trigger is regulatory: NIS2, DORA, or the Cyber Resilience Act.
• Decision support: memos, executive and board briefings, and facilitated working sessions, using ICA’s Technology of Participation methods, on questions that cross technical, organisational, and institutional lines.

The work needn’t be about timestamps. Some assignments stand alone; others are a first step before either side decides whether a continuing relationship makes sense.

See selected work and credentials →

The continuing relationship¶

You are not buying hours. You are buying continuity of context, independent judgement, and an established first call.

Over time, I learn your people, working culture, systems, history, and open questions. The retainer preserves that context, so that when something changes we can start with the problem rather than the background.

Two sizes¶

• About one day a month, roughly 5% of my working attention. It suits a senior leader who needs a thinking partner outside the reporting chain, or a team with one standing question.
• About two days a month, roughly 10%. It suits a team or organisation with several live questions and a steady flow of decisions.

Both are averaged across the quarter, with standing access in between for brief questions and rapid interpretation when something develops.

What the retainer is for¶

• Early interpretation: a prompt, independent read on a technical or regulatory development, an incident, or a supplier claim.
• Decision framing: clear options, trade-offs, and language suited to the people who must decide.
• Independent challenge: testing assumptions from outside the reporting hierarchy, without needing anyone to be wrong.
• Orientation: finding the relevant standards, institutions, specialist communities, and prior work.

In the quiet months, nothing is on fire. Good: that is when context gets built, and the reading gets done that urgency always postpones.

Terms¶

New relationships begin with an initial three-month term: long enough for me to become useful, short enough that neither side has to pretend certainty first. After that the relationship continues month to month, and either side can end it without drama.

The retainer buys continuity and priority, not a bank of unused days. Substantial new work is scoped separately. Fees are at senior advisory rates, stated plainly before either side commits.

This is not 24/7 incident response, staff augmentation, an outsourced CISO function, or unlimited deliverables. If something grows beyond the relationship, I will say so plainly and either propose a separate scope or point you to someone better suited.

If you need to explain it internally:

We retain Proper Tools so that, when something unfamiliar crosses technical, regulatory, and organisational boundaries, we already have an independent adviser who knows our context, has no stake in any particular answer, and can help us work out what it means and reach a workable decision sooner.

Why the public work matters¶

I co-chair FIRST’s Time Security SIG, drafted ITU-T Technical Paper XSTP.epoch, and coordinate international work on the 2036–2038 timestamp rollovers. That work is part of the advisory capability, not time away from it: standards bodies and incident-response communities are often where weak signals and ownership gaps become visible before they show up in ordinary reporting.

I take on a deliberately limited number of client commitments, so each receives meaningful attention and continuity of context. My public-interest research and standards work inform that advice, without taking precedence over agreed client obligations.

A retainer does not buy privileged access, confidential material, or influence over public processes. No client relationship determines what I contribute to them. What a client receives is advice from someone working in those communities, able to translate what is public and shareable into the client’s own context.

Sponsoring the coordination work¶

The coordination work takes real time, and its value depends on independence: the ability to convene vendors, operators, and standards bodies without being beholden to any one organisation’s commercial interests.

Sponsorship is designed to protect that. Organisations can support the work directly, a quarter at a time, by funding independent coordination capacity contracted through Proper Tools. Sponsors are acknowledged publicly, and receive no rights or influence over findings, priorities, or publication. Sponsorship is an arrangement with Proper Tools alone: FIRST, ITU-T, and the other bodies I take part in are not parties to it, and it confers no standing or influence in their processes. The aim is a handful of sponsors, so that no single organisation carries the work alone.

Until enough sponsors are in place, the plan is for paid advisory work to support it. If your organisation might sponsor the work, even for a single quarter, write to me and I’ll send the details.

Know someone this would help?¶

Most of the good things in my career have arrived by introduction. If someone you know is wrestling with a problem like these, forwarding this page is enough. A short introduction is better still.

If you need language for the introduction:

Trey Darley at Proper Tools works on problems whose root causes cross teams, vendors, or institutions. He’s independent, and he’ll tell you plainly whether he can help.

I will take it from there, treat their question with the same care as yours, and let you know how it went, as far as confidentiality allows.

Bring me the question as it currently exists.¶

Tell me what is happening, who is involved, and what decision or deadline is approaching. I will tell you plainly whether I can help, what shape the work might take, and what it would cost; if I am not the right person, I will point you somewhere better when I can.

Standard MSA, mutual NDA, and procurement documentation are available on request.