ExpertsFM

Garrett Langley of Flock Safety on building technology to solve crime

Cheeky Pint · March 5, 2026

5 Selected Lessons:

heuristic · 2 framework · 2 reasoning_pattern · 1
Match technology sophistication to crime severity
framework based on: reasoning Garrett Langley

Source

Cheeky Pint — Garrett Langley of Flock Safety on building technology to solve crime (March 5, 2026) · at 28:37 ▸

When this applies

when deciding how aggressively to deploy a powerful but controversial capability across a range of use-case severities

The takeaway

Calibrate the permitted intensity of an invasive tool to the severity of the problem it's being used for, rather than applying one blanket policy.

Why it works

Blanket bans or blanket permissions ignore that the cost-benefit of an invasive tool varies hugely by stakes; tying authorization to severity captures benefit for high-stakes cases while limiting overreach on trivial ones.

One level up

Binary all-or-nothing policy on a powerful tool wastes its upside; tiered, severity-matched policy preserves both safety and restraint.

Where it stops holding

This stops working when severity tiers are hard to define cleanly in real time, or when any use of the tool (even for severe crimes) is itself deemed unacceptable by the public/legislature regardless of calibration.

Detail

procedure:
  • List the categories of crime society cares most about (homicide, crimes against children)
  • Permit the most powerful/controversial tools only for those categories
  • Restrict or forbid the same tools for minor offenses (shoplifting)
rationale: The severity of a crime should be commensurate with the sophistication of technology used to solve it.

In their words

You can't use it for shoplifting, but for homicides, crimes against children. Go to your list of things that we as a society care deeply about.
Risk-purchase the cheapest, highest-supply-risk components first
framework based on: lived experience Garrett Langley

Source

Cheeky Pint — Garrett Langley of Flock Safety on building technology to solve crime (March 5, 2026) · at 1:11:24 ▸ · at 1:14:40 ▸

When this applies

when building any physical product dependent on commodity components shared with much larger buyers

The takeaway

Identify and pre-purchase/stockpile the cheapest components with the least resilient supply chain, not just the most expensive ones, because cost and supply risk are not correlated.

Why it works

Even low-cost components can have fragile supply chains because global capacity is finite; a small company's modest order volume offers no protection when a hyperscale buyer absorbs the entire supply for 1-3 years.

One level up

Risk management should be allocated by fragility of supply, not by dollar value of the part.

Where it stops holding

This stops working when a company can't predict which commodity parts will spike (unknown future demand shocks from larger buyers), or when capital constraints prevent pre-purchasing/stockpiling.

Detail

procedure:
  • Audit the bill of materials for cheap, commodity parts (not just expensive leading-edge chips)
  • Identify which of those have concentrated supply that a much larger buyer could absorb overnight
  • Pre-purchase/stockpile those specific parts, and design in 3-4 alternative supplier derivatives for each
benchmarks: {"example":"a capacitor price went up 4x in near term, indicating a much larger company placed a massive order"}
rationale: we'll risk purchase not necessarily the whole thing, but the cheapest, highest-risk things.

In their words

when we look at a bomb of a product, we'll risk purchase not necessarily the whole thing, but the cheapest, highest-risk things.
Certainty of being caught deters more than severity of punishment
reasoning_pattern based on: observed outcome Garrett Langley

Source

Cheeky Pint — Garrett Langley of Flock Safety on building technology to solve crime (March 5, 2026) · at 32:35 ▸ · at 37:04 ▸

When this applies

when designing any deterrence system (compliance, fraud prevention, behavior enforcement)

The takeaway

To deter undesired behavior, raising the probability of detection/consequence is often more effective than raising the severity of consequence.

Why it works

Young or impulsive actors operate on a binary 'will I get caught or not' calculation rather than weighing the magnitude of punishment, so increasing detection probability changes behavior more than increasing penalty severity.

One level up

Behavioral deterrence models should target the perceived odds of consequence, not just its magnitude.

Where it stops holding

This stops working for actors who already perceive near-certain detection but are undeterred by severity differences, or for crimes driven by factors other than rational cost-benefit calculation (e.g., extreme desperation or ideology).

Detail

approach: Model the offender as making a binary get-caught/not-caught judgment rather than a severity calculation, and target the probability side of the equation.
signals:
  • Cobb County near-100% violent crime clearance correlates with falling crime
  • San Francisco PD publicizing solved cases creates a deterrent effect
  • teenagers don't care about punishment severity, only whether they'll get caught
rationale: You operate on a Boolean mindset. I will get away with this, therefore I will do it... You don't care if the punishment is being grounded for a week or a month.

In their words

the unintuitive or the counterintuitive point on crime is that most people would intuitively say, Oh, if the punishment's really, really bad, people will do less of it
Data retention windows limit abuse without eliminating value
heuristic based on: lived experience Garrett Langley

Source

Cheeky Pint — Garrett Langley of Flock Safety on building technology to solve crime (March 5, 2026) · at 14:48 ▸ · at 19:57 ▸ · at 1:19:01 ▸ · at 1:22:32 ▸

When this applies

when designing any system that collects sensitive data and must balance utility against misuse risk

The takeaway

Set data lifespan to match the window where legitimate use value drops off fastest, rather than storing everything indefinitely by default.

Why it works

Recent data is disproportionately useful for legitimate investigative purposes while being much less useful for long-term profiling/stalking, so a short retention window captures most of the value while sharply cutting the abuse surface.

One level up

Design constraints (like forced deletion) can be a feature that builds trust, not just a limitation on capability.

Where it stops holding

This stops working when legitimate use cases genuinely require long historical lookback (e.g., cold cases), which is why the speaker argues for warrant-gated exceptions to extend retention.

Detail

rule: Keep sensitive surveillance/location data for a short, defined window (days, not years) unless a warrant justifies extension.
threshold: Live video ~7 days, LPR data ~30 days by default (Flock's stated practice); 21 days was called 'pretty good' in Virginia's law.
rationale: It's not good to wait a day [for data to propagate]... but also fresh data has a really fast drop-off in relevance versus year-old data for criminal investigations.

In their words

There's a beautiful... really fast drop off of where have you been in the last couple days versus like where were you a year ago. It's very irrelevant in a criminal investigation.
Design around the real success metric, not vanity specs
heuristic based on: lived experience Garrett Langley

Source

Cheeky Pint — Garrett Langley of Flock Safety on building technology to solve crime (March 5, 2026) · at 1:31:34 ▸ · at 1:35:22 ▸

When this applies

when designing a product and multiple possible specs could be optimized, but only one actually drives the outcome that matters

The takeaway

Before optimizing, identify which specification variable actually drives the outcome you care about, and design the whole system around that, discarding impressive-sounding but non-causal metrics.

Why it works

Optimizing a secondary, intuitively-appealing spec (speed, payload weight) that doesn't directly drive the outcome wastes resources; optimizing the spec that is causally closest to the desired outcome (time-on-scene via long-range vision) delivers the goal more efficiently.

One level up

The same historical pattern recurs across industries: chasing 'feeds and speeds' instead of the true mission objective produces inferior designs (illustrated by the analogy to Boyd designing fighter jets around energy maneuverability, not top speed).

Where it stops holding

This stops working when the 'obvious' spec actually is the causal driver of outcome (e.g., for a delivery drone, payload capacity genuinely matters more than optical range).

Detail

rule: Identify the true outcome metric (e.g., 'time on scene') and reverse-engineer product specs from that, rather than defaulting to intuitively impressive specs like speed or payload.
threshold: One Flock drone covers a 30-square-mile radius and reaches a scene virtually 'under a minute'; San Francisco needs only ~12 drones citywide as a result.
rationale: if you have a payload that can see really far away, you don't have to fly there. So actually, you get there faster virtually... That's why we fly high, because physics allows you to see farther.

In their words

for us, the spec we track is like time on scene