Velocity Is Not a Performance Review

Written by Alanna Gray, 2025

Finance ran this experiment a long time ago, and I spent years auditing the results. The experiment is called a budget.

A budget is a forecast. It is a department's honest best estimate of what the year will cost and what it will produce, made so the company can plan. And a budget stays honest exactly as long as nothing personal rides on it. The moment a manager's bonus depends on landing precisely on that number, the number stops being a forecast. Estimates get padded in October "just in case." Money gets spent in December on things nobody needed, because unspent budget is next year's cut. Work that would pay off in eighteen months gets quietly avoided, because it looks bad this quarter. As an auditor, I sat in the variance meetings afterward, listening to smart people explain numbers we all knew had been managed instead of earned.

Velocity is the same instrument in a different department. It exists so a team can predict itself: we finish roughly this much work per sprint, so that release is about three sprints out, give or take. That is a planning estimate, and it is a useful one. But the day velocity walks into a performance review, it becomes a budget with a bonus attached — and it will be managed the same way.

An estimate is only honest when nothing rides on it

Watch what happens, because it is the audit trail I know by heart. Story points inflate, the way expense estimates do when nobody checks them against reality. Stories get split into smaller and smaller pieces, the way invoices get split to stay under an approval limit — technically compliant, and completely beside the point. Teams take the safe, countable work and steer around the hard, valuable work that might score badly. And the forecast, the one thing velocity was actually for, becomes fiction, because no one reports a number that can be used against them.

There is an old line in economics: when a measure becomes a target, it stops measuring anything. Auditors could have written it. We call the result "theater" — documentation that looks like control and controls nothing.

What to look at instead

If the forecast is not the scoreboard, what is? The same things a good post-audit looks at. Three of them.

Did it do what it was funded to do? In finance, after a big project ships, someone eventually asks whether it produced the result in the proposal. Ask that about delivered work. Not tickets closed — outcomes in the hands of the people they were built for. Did the fix land? Did the complaint stop? Any strong employee can talk about that with specifics, and the conversation tells you more about their judgment than any point total.

Is work finishing, or just starting? I run operations now, and the rule is the same in a building as in a backlog: a room half-cleaned is not inventory. Work in progress is money sitting still. Watch where finished work waits — on a review, on a decision, on an approval only you can give. In an audit, we called those control points, and they were where things went to die. Clearing them is management's actual job.

How good is the range? No honest forecaster gives you one number. Finance gives guidance in ranges because the future has width. Ask a team for the range and the one risk most likely to move it, then write it down. Check back in a quarter — not to grade anyone, but to learn how your organization actually forecasts. Over time, that teaches you whose estimates you can plan a business on. That is real performance information, and no dashboard hands it to you.

The conversation, without the scoreboard

Most of the damage happens in the review meeting itself, when it opens like an interrogation: walk me through your numbers. The employee hears justify your existence — the same tone as a variance meeting where the verdict was decided before the questions were asked.

Open differently. What did you deliver this quarter that mattered most, and what got in its way? Where does your work sit waiting, and whose signature unsticks it? What did we start that we should stop? Those are audit questions, in the best sense: they find the obstacle, the judgment call, the priority somebody was afraid to name.

And if you are the one being reviewed, bring outcomes, not activity. "I closed fourteen tickets" is an activity report. "The change I shipped cut our biggest complaint in half" is a result. Results are what get remembered, funded, and promoted.

Where I would start

1. Take the forecast out of the review. Velocity, budget adherence, any planning number — if it is used to plan, it cannot also be used to grade. Say why, out loud: you want estimates you can believe.
2. Audit one finished piece of work. Pick something that shipped last quarter. What was promised, what actually shipped, what did it do? One honest look backward teaches more than a year of dashboards.
3. Ask for ranges and risks from now on. Write them down with dates. In ninety days, compare — to calibrate your planning, never to punish the forecaster.
4. Change one question in your next review conversation. Ask what mattered most and what made it hard. Then listen longer than feels natural.

Keep velocity. A team that can predict itself is a team you can plan around. Just keep it in the planning meeting, where estimates belong, and out of the review, where people learn to stop giving you honest ones.

The Return-to-Office Wars: What the Data Said

Here's something most RTO commentary never touches: before COVID, I already worked remotely. Not as an experiment — as my actual job. And it worked. Better focus, no travel tax, faster output. Remote work didn't need to be proven to me in 2020. It had already been proven, by me, for years.

So when the pandemic sent everyone home and the great remote-work debate kicked off, I watched with interest — because what I saw wasn't a uniform experience. It was three completely different ones.

The three camps

The resentful. These folks hated being home from day one. Felt disconnected, adrift, cut off from the energy of the office. Their productivity dropped — not because they were lazy, but because the environment was wrong for them. Some people genuinely do their best thinking around other people, and no amount of "just adapt" changes that.

The social-dependent. A quieter group. They didn't hate remote work exactly — they just slowly came apart without in-person interaction. The hallway conversations, the lunch table, the ambient sense of being part of something — for them, that wasn't a perk. It was load-bearing. Their mental stability depended on it, and when it went away, everything got harder.

The externally-driven. This is the interesting one. These people didn't realize how much of their productivity was borrowed — borrowed from the presence of others. The colleague at the next desk heads-down at 9 AM. The meeting they couldn't dodge. The social pressure of being seen working. Take all that away, put them alone in a room with a laptop, and their output collapsed. Not from rebellion. From the removal of scaffolding they never knew they were leaning on.

Three camps. Three completely different relationships with remote work. And here's the thing the RTO debate kept missing: all three were telling the truth about their own experience, and none of them were describing everyone else's.

The universal solution to a non-universal problem

Then came RTO — imposed universally. Same policy for the person who'd been productively remote since 2018 and the person who fell apart without an office. Same mandate regardless of role, personality, workflow, team structure, or proven track record.

And let's be honest about what drove it, because in most cases it wasn't productivity. The data on output was mixed at worst and favorable at best. What drove RTO was:

• Real estate. Those leases didn't sign themselves, and empty floors are hard to explain to a board.
• Managerial discomfort. Some managers manage by presence — by seeing people working — and remote took their instrument away.
• Optics. "We're back" plays better in certain rooms than "we're distributed."
• Hierarchy. The office is where the org chart is visible. Some leaders missed being able to see it.
• Facilities and contracts. Vendors, services, campuses — an entire ecosystem needed bodies in seats.

None of that is about output. All of it got sold as if it were.

The pattern nobody names

Here's the deeper pattern: remote work had already proven itself for many roles long before COVID. I was the evidence. Plenty of others were too. The pandemic didn't test whether remote work could work — it revealed that people function differently, and that the right answer depends on the person, the role, and the work.

RTO took that revelation and did the opposite of what it suggested. Instead of differentiating — instead of asking which roles, which people, which moments benefit from presence — it imposed one answer on everyone. It treated a diverse workforce as if everyone had the same needs, in service of drivers that had nothing to do with productivity.

The irony is thick. The same leaders who spent 2020 marveling at how differently their people responded to remote work spent 2022 mandating as if they'd all responded the same way.

What the data actually supports

The honest summary, stripped of team jerseys: remote work succeeded for many roles long before the pandemic proved anything. The forced experiment exposed real differences in how people function — differences worth respecting, not flattening. Presence genuinely matters for some work and some people: onboarding, complex collaboration, the socially-sustained. And for others, the office was always just overhead with a parking lot.

The question was never "office or remote." It was always "which work, which people, which moments" — answered case by case, grounded in actual output, not in leases and optics.

That's a harder answer than a mandate. It's also the only one the data supports. And it's the one we already knew, before any of this started — some of us were living it.

Notes from the Security Shelf

Every few years I pull the old books off the shelf — not the ones about specific tools, which age like milk, but the ones about how systems fail and how people think about them failing. The tools change. The failure modes rhyme. Here are the ones I keep coming back to, and what they taught me that no certification course ever did.

The Cuckoo's Egg, by Cliff Stoll

Published in 1989. Stoll was an astronomer managing computers at a national lab who noticed a 75-cent accounting discrepancy and ended up tracking a hacker across international networks for the better part of a year. No SIEM. No threat intel feeds. Just stubbornness, a notebook, and a willingness to follow a tiny anomaly until it became a big one.

What stuck with me: the investigation worked because Stoll refused to let go of something small that didn't make sense. Most security failures I see aren't failures of tooling — they're failures of curiosity. An alert fires, someone glances at it, it looks like noise, they move on. Stoll's whole book is an argument for the opposite instinct. The 75 cents mattered.

I reread it whenever I catch myself dismissing something because investigating it would be inconvenient.

Security Engineering, by Ross Anderson

The big one. Anderson's textbook is the closest thing this field has to a canon — not because it tells you what to do, but because it teaches you how to think about what can go wrong. The core lesson, repeated in a hundred different contexts: security is about the system, not the components. You can have perfect cryptography and still lose because the threat model assumed an honest user, or because the failure mode nobody considered was the one that happened.

What I take from it, practically: every time someone proposes a security control, ask what happens when it fails. Not if — when. The control that fails open is a different control than the one on the architecture diagram. Anderson made me permanently suspicious of any design where the security story only works if everything goes right.

The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford

Yes, the DevOps novel. Yes, everyone has read it. I'm including it because the security lesson in it is usually missed: most of the disasters in the book aren't caused by attackers. They're caused by the organization's own processes — the untested changes, the hero culture, the work that bypasses every control because the controls are slower than the business need.

That's the threat model most security teams forget to include. We spend our energy on the adversary outside the firewall and ignore the fact that the biggest source of production incidents is us — our deploys, our config changes, our 2 AM "temporary" fixes. The Phoenix Project is a security book wearing a DevOps costume. The villain is toil and chaos, and the fix is boring, disciplined engineering.

Threat Modeling, by Adam Shostack

Short, practical, and built around four questions that I have taped to the inside of my skull: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job?

The reason this book endures is that it makes threat modeling something a normal team can actually do, instead of a specialized ritual performed by consultants. Shostack's real contribution isn't the methodology — it's the permission structure. Anyone can ask "what can go wrong?" in a design review. You don't need a certification. You need the habit.

I've watched teams transform their security posture with nothing but those four questions asked consistently. No tools purchased. No headcount added. Just a better class of conversation, earlier.

Secrets and Lies, by Bruce Schneier

From 2000, and the central argument has only gotten more true: security is a process, not a product. Schneier was saying it when the industry was selling boxes with blinking lights, and he's still saying it now that the industry sells cloud dashboards with blinking lights. The products changed. The point didn't.

The line I carry around from this one: the security of a system is only as good as the people and processes around it. Every "silver bullet" product pitch I've sat through since has been a live demonstration of the book's thesis. If someone is selling you security as a thing you buy rather than a thing you do, they're selling you the problem.

None of these books will tell you how to configure your EDR. That's the point. Tools expire. The thinking doesn't. The shelf stays.

The Quiet Power of the Internal Tech Blog

Somewhere in your company there's an engineer who knows why the payments service has a retry policy that looks insane. They know because they were on call the night it earned that policy — the night a downstream provider went flaky for six hours and the naive retry logic turned a partial outage into a self-inflicted DDoS. That knowledge is in one person's head. When they leave, it leaves with them.

Unless someone wrote it down.

Documentation nobody reads vs. writing people remember

Let's be honest about internal documentation: most of it is a write-only medium. Wikis go to die. The architecture decision record that was supposed to capture why we chose the message queue gets written six months after the decision, by someone reconstructing it from Slack threads. The runbook covers the happy path and three of the sad ones; the fourth sad one is the one that pages you.

But there's a different kind of internal writing, and it works. It's the incident retrospective that reads like a story instead of a template. It's the "here's what I learned migrating the auth service" post that an engineer writes because they need to think it through, and then it turns out half the org needed to read it. It's the decision record written before the decision, while the tradeoffs are still alive and contested, instead of after, when everyone's just justifying what already happened.

The difference isn't format. It's honesty. The writing that gets read is the writing that tells the truth about what happened — including the parts where someone made a bad call at 3 AM and the system survived anyway.

Incident lore is an asset

Every company has incident lore: the outage everyone references by name, the deploy that became a verb. "Don't pull a Jenkins on the database migration." That lore is doing real work — it's compressed experience, transmitted orally, and it shapes behavior more than any policy document.

The problem with oral tradition is that it doesn't scale and it doesn't survive turnover. The new hire in the satellite office doesn't know what "pulling a Jenkins" means. The lore becomes an in-joke instead of a lesson.

Writing it down fixes this, but only if the writing captures the actual story. A good incident write-up has a narrative arc: here's what we believed, here's what happened, here's what we believe now. It names the surprise. The surprise is the valuable part — it's the thing nobody's mental model predicted, which means it's the thing everyone's mental model needs to absorb.

The best internal incident writing I've seen reads less like a report and more like a field note from someone who was there. Because it is.

Decision records, written when they matter

Architecture decision records have a timing problem. Written after the fact, they're archaeology — interesting, maybe, but nobody's mind is changed by them. The doc exists to make the decision better. The fact that it also becomes a record is a bonus. Teams that get this backwards — writing the ADR to satisfy a process, after the decision is already made — get the worst of both worlds: the overhead of documentation with none of the clarity.

I've started treating decision docs as discussion documents with a shelf life, not as monuments. The doc exists to make the decision better. The fact that it also becomes a record is a bonus. Teams that get this backwards — writing the ADR to satisfy a process, after the decision is already made — get the worst of both worlds: the overhead of documentation with none of the clarity.

Write in public (internally)

Here's the part that makes people nervous: the best internal writing is visible. Not in a private doc shared with three people, but somewhere the whole engineering org can stumble across it. The junior engineer who reads a senior's migration post-mortem learns more in twenty minutes than in a month of ticket work. The team in another timezone avoids a mistake because someone wrote down the mistake they made.

Yes, this requires a culture where writing honestly about failures doesn't get you punished. That's a leadership problem, not a tooling problem. No wiki platform ever fixed a blame culture.

But if you have even a pocket of that culture — one team that writes real postmortems, one engineer who documents the weird retry policy and why — protect it. Feed it. That person is doing the most undervalued work in your organization: turning experience into something that outlives the people who had it.

The payments service retry policy looks insane until you know the story. Write down the story.

CISA's Secure by Design, One Year In

CISA's Secure by Design pledge asked software vendors to do something radical: take responsibility for the security of the products they ship. Not document the risks and hand them to the customer. Not sell the secure version as the premium tier. Build it in from the start.

A lot of vendors signed. The pledge asked for concrete commitments — things like eliminating default passwords, publishing vulnerability disclosure policies, and working toward reducing entire classes of vulnerabilities rather than whack-a-moling individual bugs. On paper, it was the most meaningful shift in the vendor-customer security relationship in years.

So where are we?

What the pledge got right

The core idea is sound, and it's worth saying plainly: the customer should not be the QA department for a vendor's security. For decades, the industry's unspoken deal was that buyers would configure, patch, monitor, and generally babysit products into something resembling secure — and vendors would sell them the tools to do the babysitting. Secure by Design flips that deal. The radical part isn't the technology. It's the accountability.

The pledge also did something subtle and important: it gave security-conscious buyers language. Before the pledge, asking a vendor "what are you doing about entire classes of vulnerabilities?" got you a blank stare and a brochure. Now there's a shared vocabulary. Procurement teams can point at the pledge and ask where a vendor stands. That's real progress, even if it's boring progress.

Where it gets wobbly

Here's the uncomfortable part. A pledge is not a regulation. There's no enforcement mechanism, no audit, no penalty for signing the thing and then quietly doing nothing. The vendors who were already serious about security signed it and kept doing what they were doing. The vendors who weren't... also signed it, in many cases. A signature is cheap. Secure defaults are expensive.

And there's a deeper structural problem the pledge can't fix on its own: the market doesn't reliably reward secure products. Buyers say they care about security, and then they buy on features and price, like they always have. Until procurement genuinely penalizes insecure products — until "we can't buy this because your secure-by-design posture is weak" is a sentence someone actually says in a buying decision — the pledge runs on goodwill. Goodwill is a fine fuel for a pilot program. It's a terrible fuel for an industry transformation.

The other wobble: "secure by design" is easy to say and genuinely hard to define at the margins. Eliminating default passwords? Clear. Publishing a disclosure policy? Clear. But "reducing classes of vulnerabilities" is a spectrum, and every vendor gets to grade its own homework. Without independent verification, we're back to trusting the brochure — just a nicer brochure with better vocabulary.

What it means for buyers

If you're evaluating vendors, the pledge is useful but insufficient. Here's how I'd use it:

First, treat a signature as a starting point, not a credential. Ask what specifically changed in their development process since they signed. If the answer is vague, the signature is decorative.

Second, ask about the classes of vulnerabilities, not the count of CVEs patched. A vendor that eliminated SQL injection across their product line through parameterized queries and framework guardrails has done something real. A vendor that patched forty SQL injection CVEs last year has done something too — something that suggests the first thing never happened.

Third, look at the defaults. This is the fastest test in the book. Install the product the way a tired admin at 11 PM would install it — next, next, finish — and see what you get. If it's secure, they mean it. If it takes a forty-page hardening guide to make it safe, the pledge is a poster on the wall.

The pledge moved the conversation. That's not nothing. But conversations don't patch vulnerabilities, and signatures don't change defaults. The idea is right. The follow-through is still an open question — and it's the buyers, not CISA, who get to decide whether it was real.

The vendors are waiting to see if we meant it. We should probably decide.

DORA Metrics: Are We Measuring the Right Things?

There's an old line, usually attributed to an economist, that goes: when a measure becomes a target, it ceases to be a good measure. Engineering leadership has spent the last decade learning this one the expensive way, one dashboard at a time.

DORA metrics — deployment frequency, lead time for changes, change failure rate, and mean time to recovery — started as genuinely good ideas. They came out of real research into what separates high-performing engineering teams from the rest. For a while, they were a mirror: hold them up to your org and see yourself honestly.

Then they became targets. And the mirror became a funhouse.

How good metrics go bad

Take deployment frequency. The research says elite teams deploy on demand, sometimes multiple times a day. That's a real signal of a healthy pipeline and a team that isn't afraid of its own release process.

But the moment a VP puts "deploy daily" on a slide, something changes. I've watched teams split one sensible release into eleven meaningless ones to hit the number. Nobody got faster. The change didn't get smaller in any meaningful way. The dashboard turned green and the engineering didn't change at all.

Lead time for changes is worse. It's supposed to measure how long it takes an idea to go from commit to production — a proxy for how much friction lives in your pipeline. But once it's a KPI, watch what happens: the clock starts at the commit, so engineers start committing earlier, in smaller fragments, sometimes before the code is even coherent. The metric improves. The review process gets harder. Nobody wins except the chart.

The perverse incentives nobody talks about

Change failure rate is the sneakiest of the four. It measures what fraction of your deployments cause a failure in production. Sounds reasonable. But "failure" is doing a lot of heavy lifting in that sentence.

Who defines a failure? If your team defines it as "a deploy that triggered a rollback," then congratulations, you've just incentivized never rolling back. If it's "a deploy that caused an incident," you've incentivized downgrading incidents. The teams with the most honest postmortems will always look worse than the teams with the most creative definitions. The metric punishes exactly the culture it was supposed to reward.

And mean time to recovery? Lovely idea. Also trivially gamed. If the clock starts when the incident is declared, then the rational move is to declare it later. Nobody does this maliciously. It just... happens. The definitions drift, the numbers improve, and everyone politely agrees not to notice.

Measure anyway, just differently

I'm not arguing against metrics. Flying blind isn't a strategy. The DORA four are still the best starting framework we have, and a team that ignores them entirely is probably ignoring other things too.

But here's the thing I keep coming back to: metrics are for diagnosis, not for judgment. The moment a metric is attached to a performance review, a bonus, or a promotion decision, it stops measuring the system and starts measuring the team's ability to game the measurement. This isn't cynicism. It's just how incentives work on actual humans.

The teams I've seen use DORA well all share one trait: the metrics live with the teams, not above them. The team looks at its own lead time and asks "where's the friction?" — and then fixes the friction. The number is a conversation starter, not a verdict. Nobody's getting a bad review because their change failure rate ticked up in a quarter where they were doing genuinely hard work.

There's also a quiet fifth metric nobody dashboards, and it's the one that matters most: do the engineers trust the measurement? The day your team starts arguing about definitions instead of arguing about engineering, you've lost the plot. The metric has eaten the thing it was supposed to measure.

So yes, measure deployment frequency. Track your lead time. Watch your failure rate and your recovery time. Just keep them in the team's hands, keep the definitions honest, and the next time someone proposes putting them on an executive scorecard, ask what exactly they're hoping to learn — and what they're afraid they'll incentivize instead.

Goodhart's law doesn't care about your dashboard. It just waits.

Ransomware's Mature Playbook

There's a comforting story defenders tell themselves about ransomware: that each attack is a novel crisis, a unique adversary, a situation requiring fresh thinking. The ransomware crews would like to thank us for this story. It makes their lives much easier. Because on their side of the glass, there is nothing novel happening at all. They're running a business, and businesses run playbooks.

Understand the org chart and the mystique evaporates. Modern ransomware operations have a division of labor that would look familiar to any mid-size company. Initial access brokers specialize in getting the first foothold — phished credentials, exploited edge devices — and sell that access wholesale. Affiliates buy the access and deploy the ransomware-as-a-service platform, which is exactly what it sounds like: the core developers lease out their malware the way Salesforce leases out CRM. The developers take a cut of every ransom. Some operations even run help desks — negotiation portals with support staff who will patiently walk your incident response team through the payment process. They have QA: decryptors get tested, because a decryptor that doesn't work is bad for repeat business. They have marketing: leak sites with countdown timers and press-release aesthetics, designed to create exactly the urgency they're supposed to create.

This is not a metaphor. It's the literal structure. Law enforcement takedowns keep confirming it — when a major operation gets disrupted, the affiliates don't retire. They shop for a new platform, rebrand, and get back to work. The individuals are replaceable. The business model isn't.

And the business model keeps evolving in rational, predictable ways. Double extortion — encrypt the data and threaten to leak it — became standard because encryption alone stopped working once backups got better. Defenders adapted; the business adapted back. That's not innovation in the heroic sense. It's product-market fit.

Here's what this maturity means for defenders: stop preparing for the last attack's specifics and start preparing for the business model. The crews don't care about your industry, your tech stack, or your threat intel reports with their names on them. They care about three things: can they get in, can they move laterally, and can they make recovery painful enough that paying looks rational. Every defensive investment should be measured against those three questions, because that's the only exam that matters.

Get in: that's phishing-resistant MFA, patching internet-facing systems, and killing the VPN concentrator from 2019 that everyone forgot about. Move laterally: that's network segmentation, privileged access controls, and actually monitoring east-west traffic instead of assuming the perimeter held. Make recovery survivable: that's backups that are tested, offline, and immutable — tested being the word most people skip, right up until the restore fails during the incident.

Notice what's not on that list: knowing which crew it is. Attribution is interesting. It's occasionally useful. It is almost never the thing that determines the outcome. The affiliate running last month's playbook against you doesn't care what you call them, and your recovery doesn't go faster because you identified the strain. The industry's obsession with naming and tracking crews is mostly theater — useful for journalists, marginal for defenders.

The uncomfortable truth is that ransomware works because the economics work. As long as enough victims pay, the business funds itself, hires talent, and improves its product. Every paid ransom is R&D funding for the next campaign. I'm not moralizing about individual decisions made under existential pressure — if paying is the difference between the company surviving and not, that's a business decision, and I wasn't in the room. But collectively, the payments are the revenue that keeps the machine running, and no amount of takedowns changes the arithmetic.

So here's the mature defender's playbook, to match theirs: assume breach, segment ruthlessly, back up like your business depends on it — because it does — and practice recovery until it's boring. The crews are running a business. The only way to beat a business is to make it unprofitable. Make getting in hard, make moving laterally harder, and make recovery a non-event, and their unit economics fall apart.

They're not geniuses. They're not ghosts. They're a supply chain with a playbook. Learn the playbook, and the mystique goes with it.

Vendor Consolidation and the Platform Play

Every security vendor is a platform now. Check any vendor's homepage and you'll find the word within the first scroll — platform this, unified that, one console to rule them all. The industry has decided, collectively and loudly, that the future is fewer vendors doing more things.

There's a real argument underneath the marketing. Any security leader will tell you the integration tax is brutal: a dozen best-of-breed tools means a dozen agents on every endpoint, a dozen consoles, a dozen data models that don't quite line up, and a SIEM in the middle trying to translate between all of them. Alert fatigue isn't just a staffing problem; it's an architecture problem. When your EDR, your email security, your cloud posture tool, and your identity provider all see the same attack from different angles and can't agree on what happened, that's not defense in depth. That's confusion in depth.

Consolidation promises to fix this: one agent, one data model, one console, one throat to choke. And in fairness, when it works, it's genuinely better. Correlating an endpoint detection with an identity anomaly and a cloud misconfiguration in a single timeline — without building custom integrations — is the kind of thing that makes analysts' lives materially better. The platform vendors aren't selling nothing.

But let's talk honestly about the tradeoffs, because the pitch decks don't.

First, best-of-breed exists for a reason: depth. The vendor that does one thing obsessively is usually better at that one thing than the platform vendor's fifth acquisition, still half-integrated, wearing the platform's logo. Consolidation means accepting "good enough" in categories where you used to have "excellent." Sometimes that's the right trade. Sometimes the category where you downgraded is the one the attackers walk through. Nobody puts that in the business case.

Second, lock-in is real and it's priced in. Moving to a platform is easy; moving off one is a multi-year migration touching every team. The vendors know this. The discounts are generous in year one and the renewal math is different in year three. I'm not saying it's a trap — I'm saying it's a commitment, and it should be evaluated like one, with eyes open about exit cost.

Third — and this is the one that keeps me up — concentration risk. We spent last summer learning what happens when a single vendor's bad update can take down 8.5 million machines. The platform play, taken to its conclusion, is more eggs in fewer baskets, by design. A unified platform means a unified failure domain. The vendors will tell you their testing and staged rollouts make this safe. They told us that before, too.

None of this means consolidation is wrong. For a lot of organizations — especially ones drowning in tool sprawl with a three-person security team — fewer, better-integrated tools is obviously the right answer. The mistake is treating it as a strategy instead of a tradeoff. "We're consolidating" isn't a plan. It's a direction, and directions need destinations.

Here's what I'd actually evaluate, stripped of the slideware: can you get your data out, in a usable format, on demand? How good are the APIs really — not the documented ones, the ones you'll actually need at 2 AM? What's the honest exit cost, in engineering months, not license dollars? And does the platform's weakest module cover a category where weakness gets you breached?

The vendors all want to be your platform. That's their business model, and it's a fine one. Your business model is different: it's not getting breached. Keep those two models separate in your head, and the consolidation decisions get a lot clearer.

AI Agents in the Enterprise: Hype vs. Production

Every vendor demo this year follows the same script. A smiling presenter gives an agent a vague instruction — "handle the onboarding for our new hire," "triage these support tickets" — and the agent proceeds to do ten magical things in sequence: reading email, querying systems, drafting documents, updating records. The audience applauds. The pilot gets approved.

Then the pilot meets production, and production has questions the demo never asked.

The gap between the demo and the deployment is where agentic AI currently lives, and it's wider than the marketing suggests. Not because the technology doesn't work — it does, often impressively — but because a demo is a controlled performance and production is an uncontrolled environment. The demo has clean data, cooperative tools, and a presenter standing by. Production has expired credentials, APIs that changed last Tuesday, ambiguous instructions from tired humans, and edge cases nobody wrote down.

Start with the most boring problem: permissions. An agent that can "handle onboarding" needs access to HR systems, IT provisioning, badge systems, and half a dozen SaaS tools. In the demo, someone handed it a god-mode service account. In production, your identity team takes one look at that and has a completely reasonable panic attack. Scoping an agent's access to least privilege — while keeping it useful — is a genuine engineering problem that no framework hand-waves away. Every enterprise running agents in production has a war story about the agent that could read everything and write to more than it should have.

Then there's the 3 AM test. A demo runs for eight minutes with a human watching. Production runs unattended, at night, when things break. What does your agent do when the third tool in its chain returns an error it's never seen? The honest answer, for most current implementations, is: something unpredictable. Maybe it retries in a loop and burns through a budget. Maybe it hallucinates a workaround. Maybe it just stops, silently, and nobody notices until morning. Building agents that fail loudly and safely — that know when to escalate to a human instead of improvising — is the actual work, and it's the work nobody puts in the keynote.

Cost is the sleeper issue. Agentic loops consume tokens the way a teenager consumes data: constantly, and more than you estimated. A single complex task can involve dozens of model calls, tool invocations, and retries. Multiply by real volume and the bill arrives with an expression you haven't seen from finance before. The teams succeeding here instrument everything — per-task cost, per-tool latency, retry rates — and treat the agent like a system to be optimized, not a magic box.

And then there's evaluation, the least glamorous and most important discipline in the whole space. How do you know the agent did the right thing? "It looked right in the demo" doesn't scale. Production agent teams are building eval harnesses — replaying historical tasks, scoring outcomes, catching regressions when the model or the tools change. It's testing, basically. The industry spent fifty years learning that software needs tests, and now we're rediscovering it for agents, one incident at a time.

I want to be clear about where I land on this: the technology is real. I've seen agents do genuinely useful multi-step work that would have been science fiction three years ago. But the deployment discipline is years behind the demos. We have 2025-era agent capabilities wrapped in 2015-era operational maturity — no serious evals, no cost controls, permissions by vibes.

The enterprises that will win with agents aren't the ones running the most pilots. They're the ones doing the boring work: scoped credentials, failure modes, evals, observability, cost accounting. The demo gets the applause. The plumbing gets the production deployment.

The TPM Identity Crisis

Ask ten companies what a Technical Program Manager does and you'll get eleven answers. At one company the TPM is a glorified project manager with a Gantt chart. At another they're basically a product manager who can't say no to engineering. At a third they're the person who runs the incident bridge, the release train, the dependency spreadsheet, and the quarterly planning circus — all before lunch.

I've watched this role get redefined roughly every eighteen months for the better part of a decade, and I've started to think the identity crisis isn't a phase. It's the job.

Here's the pattern. A company centralizes its TPMs into one org, because leadership wants "program discipline." Eighteen months later, product teams complain the centralized TPMs don't understand their domain, so the TPMs get embedded into the teams. Eighteen months after that, nobody can see across teams anymore, dependencies start slipping, and leadership centralizes them again. The pendulum swings, the job descriptions get rewritten, and the actual work barely changes. I've seen TPMs survive three reorgs doing exactly the same thing under three different titles.

Part of the problem is the name. "Technical Program Manager" sounds like it should mean something specific, but it's doing a lot of quiet work in that title. Technical how? I've known TPMs who were former engineers and could read a design doc critically, and TPMs whose technical depth topped out at "I can spell API." Both were called TPMs. Both were, at different companies, considered good at the job. The title promises a combination — technical credibility plus program leadership — that the hiring process rarely verifies on both halves.

Then there's the permanent confusion with product managers. The boundary between "what should we build" and "how do we get it built across six teams" sounds clean on a slide. In practice, it's a knife fight. Weak organizations let the boundary blur until the TPM is writing PRDs and the PM is running standups and everyone is mildly annoyed at everyone. Strong organizations draw the line clearly and defend it. Most organizations are neither, which is why the TPM-PM relationship is the most renegotiated border in tech.

So what do the good ones actually do? Stripped of the title inflation, it's unglamorous and specific: they make cross-team dependencies visible before they become surprises. They force decisions out of people who would rather defer them. They run the machinery — planning, releases, incident coordination, compliance gates — so engineers don't have to. They translate between teams that use the same words to mean different things. And they tell leadership the truth about schedule risk early, when it's still cheap to act on, instead of late, when it's a status update.

None of that fits neatly on a job ladder, which is why the role keeps getting redefined. Companies keep trying to hire one person who is simultaneously a project manager, a product strategist, and a credible engineer, then act surprised when the job description reads like three jobs stapled together. The TPMs who last aren't the ones who fit the description. They're the ones who figure out what their organization actually needs — usually clarity and follow-through — and supply it relentlessly while everyone else argues about the title.

The identity crisis will continue. It always does. The good news is that it's mostly a crisis for org charts. The work itself has never been mysterious. Someone has to keep the trains running on time across teams that would rather not coordinate. Call it whatever you want. The trains still need running.

Eleven Months After CrowdStrike: What Actually Changed

Last July, a bad content update from CrowdStrike blue-screened 8.5 million Windows machines in a single morning. Airlines grounded flights. Hospitals went to paper charts. Banks couldn't bank. It was, by most measures, the largest IT outage in history — and it wasn't even an attack. Nobody breached anything. A trusted vendor pushed a trusted update and the world fell over.

Eleven months later, I keep asking people in this industry what actually changed. The honest answer is: less than the think pieces promised.

The loudest legacy was the kernel debate, and to be fair, that one produced real movement. CrowdStrike's sensor ran in kernel mode, which is why a bad update could take down the whole machine instead of just crashing an application. Microsoft convened the endpoint security vendors that September and started the long, unglamorous project of moving them out of the kernel. That's genuine architectural progress — the kind of boring infrastructure work that actually prevents the next one. Credit where it's due.

But here's the part nobody likes to say out loud: almost nobody diversified their vendors.

In the weeks after the outage, every board deck had a slide about concentration risk and single points of failure. And then, one by one, companies looked at what it would actually cost to rip out their EDR platform and replace it — the retendering, the detection-rule retuning, the months of dual-running, the retraining — and decided to renew instead. I don't entirely blame them. Switching endpoint security vendors is one of the most disruptive projects an IT organization can take on, and doing it in a panic is how you end up less secure than when you started. But let's not pretend the lesson was learned. The lesson was admired from a distance.

What did genuinely change is that resilience testing got a budget line. Chaos engineering stopped being a curiosity associated with one streaming company and started showing up in enterprise roadmaps. "What happens when our security tooling itself fails?" is now a question that gets asked in architecture reviews — a sentence that would have earned blank stares in 2023. Update rollout practices got scrutiny too: the industry had a real conversation about staged rollouts and canary deployments for security content. The vendors pushed back, reasonably enough, that threats don't wait for canaries — but there's middle ground between "everyone gets it at once" and "wait a week," and most of the industry now lives somewhere in that middle.

The lawsuits are still grinding along in the background. Delta's case against CrowdStrike and Microsoft is the one to watch — not because of who wins, but because it will establish, in legal language, where responsibility sits when a vendor's routine update breaks your business. Every enterprise contract caps the vendor's liability at some multiple of fees paid. The courts may eventually have opinions about whether those caps hold when the failure mode is this total. That ruling, whenever it lands, will be quoted in every vendor negotiation for a decade.

My take, eleven months on: the industry treated CrowdStrike as a vendor failure when it was really an architecture failure. Any single piece of software with that much privileged access, pushed to that many machines on that aggressive a schedule, can do exactly this. The next one won't be CrowdStrike. It'll be someone else's updater, and we'll all act surprised again.

The fix was never "pick a better vendor." It's "design like your vendors will fail you." Most of us still haven't.

Shadow AI: Your Employees Brought Their Own Models

Somewhere in your company, right now, an employee is pasting customer data into a public chatbot.

They're not a bad person. They're not trying to exfiltrate anything. They've got a deadline, the sanctioned tools are slow or useless, and the chatbot on their phone writes a better summary in ten seconds than the approved software manages in ten minutes. So they paste, they summarize, they move on. Multiply by a few thousand employees and you've got a data governance problem wearing a productivity costume.

This is shadow AI, and it's the return of a very old movie. A decade ago it was shadow IT — employees spinning up cloud accounts on personal credit cards because procurement took six months. Before that it was shadow Dropbox, shadow Gmail, shadow everything. The pattern never changes: official channels are too slow, people route around them, and security finds out a year later during an audit.

The standard corporate response is also unchanged: ban it. Block the domains, write a policy, send a stern email from Legal. And it fails the same way every time, because the ban doesn't remove the need — it just moves the behavior somewhere you can't see it. Employees don't stop using the tools. They stop using them on the corporate network. Congratulations, you've traded a visible risk for an invisible one.

So let's talk about what actually works, starting with the hardest pill: you have to give people something better.

If your sanctioned AI tool is worse than the public one — slower, dumber, wrapped in so many guardrails it can't answer a simple question — nobody will use it, and your policy is fiction. The approved path has to be at least as good as the unapproved one. That's not a security requirement, it's a product requirement, and security teams ignore it at their peril.

Second: data classification that humans can actually follow. Most classification schemes are written by lawyers for auditors, and employees treat them accordingly — as background noise. If your policy says "don't put confidential data in AI tools" but nobody can tell you what counts as confidential without a flowchart, the policy doesn't exist. Three tiers, plain language, examples from real work. That's the whole trick.

Third: make the sanctioned tools the path of least resistance. Enterprise agreements with the major model providers, SSO integration, data processing terms that keep company data out of training sets. When the approved chatbot is one click away and the sketchy one requires a personal account and a VPN dodge, most people take the easy road. Most people aren't adversaries. They're just busy.

Fourth: logging, not surveillance. There's a difference between "we can see which sanctioned tools are being used and what data classes flow through them" and "we read everyone's prompts." The first is governance. The second destroys trust and drives the behavior further underground. You want visibility into the sanctioned path so you can improve it — not a panopticon that teaches employees to hide better.

And here's the part I want the security folks to sit with: the employees doing this are your allies, not your problem. They're showing you exactly where your tooling falls short. Every pasted spreadsheet is a feature request. The person summarizing support tickets with a public chatbot is telling you, for free, what your internal tools should have done two years ago. Treat them like informants, not criminals, and you'll learn more in a month than a year of surveys.

The companies that get this right won't be the ones with the strictest bans. They'll be the ones that looked at the shadow behavior, understood the need behind it, and built the sanctioned version worth using.

You can't ban the tide. You can build a harbor.

The Non-Human Identity Explosion

Here's a number that should make you uncomfortable: in most enterprises, machine identities — service accounts, API keys, workload identities, automation credentials — outnumber human identities by something like fifty to one. Fifty to one.

Now here's the follow-up question: can you name all of yours?

Most organizations can't. They know their employees — HR onboards them, IT offboards them, there's a ticket for everything. But the service account created three years ago for a migration that never got decommissioned? The API key baked into a container image that's been copied across four environments? The automation credential with admin rights that nobody remembers issuing? Those live in the dark, and there are thousands of them.

This is the identity crisis nobody budgeted for. We spent two decades building mature processes for human identity — joiners, movers, leavers; SSO; MFA; quarterly access reviews. And the entire time, the machine population was quietly multiplying in the background, with none of that discipline attached.

The consequences are exactly what you'd expect. Stale credentials with excessive privilege. Keys that never rotate because rotating them might break something and nobody knows what. Service accounts owned by people who left the company two reorgs ago. Every one of these is a standing invitation, and attackers have figured that out — compromising a forgotten service account is quieter than phishing an executive and often more powerful.

I work in key management, so I have opinions about the fix, and the fix is aggressively unglamorous.

First: inventory. You cannot secure what you cannot see. Every non-human identity needs to be discoverable — who created it, what it can access, who owns it now. This is tedious work. Nobody wants to do it. Do it anyway.

Second: least privilege, for real this time. The service account that needs to read from one bucket does not need write access to the whole project. The CI pipeline does not need production admin. We say "least privilege" about human accounts and then hand machines the keys to the kingdom because it's convenient. Stop that.

Third: rotation with an owner and a schedule. A credential that never rotates is a credential waiting to leak. And rotation only works if someone owns the credential — an actual human, with a name, who gets paged when the rotation breaks something. "Owned by the platform team" is not ownership. "Owned by Priya" is ownership.

Fourth: deprovisioning. Machines need offboarding too. When the migration finishes, when the project sunsets, when the vendor contract ends — the identities go with them. Build the offboarding into the project plan, not as an afterthought six months later when someone finally asks "what is this account for?"

Notice what's not on this list: a shiny new product. The industry would love to sell you an NHI security platform, and some of those tools are genuinely useful for the inventory problem. But no product fixes the underlying disease, which is that organizations treat machine identity as plumbing instead of as identity. The discipline is the product.

There's a deeper point here about how security thinking lags reality. Our mental model of "identity" is still a person with a username, because that's what the last twenty years trained us on. But the population inverted while we weren't looking. The machines are the majority now, and they're the ones with the broad access and the thin oversight.

The good news: this is a solvable problem. It's not a cryptography breakthrough or an AI moonshot. It's inventory, least privilege, rotation, and offboarding — the same boring fundamentals that work everywhere else in security, applied to the population we forgot to count.

Boring is underrated. Boring is what keeps the lights on.

Platform Engineering Ate DevOps

The rebrand is complete. Somewhere along the way, every DevOps team became a platform team, every runbook became a golden path, and every engineer with a Terraform repo started calling it an internal developer platform. DevOps didn't die. It got a new job title and a bigger budget.

I'm not mocking it. The shift is real, and mostly it's an improvement. But if you're a TPM or a security person trying to figure out what changed and what you're supposed to do about it, it's worth being clear-eyed about what platform engineering actually is versus what the conference talks say it is.

What it actually is: a product discipline applied to internal tooling. Instead of each team building its own deployment pipeline, its own observability setup, its own way of provisioning a database, one team builds the paved road and everyone else drives on it. The pitch is that developers spend less time on undifferentiated plumbing and more time on the thing the company actually sells.

That pitch is mostly true. The part nobody puts on the slide is that the paved road has tolls. Somebody has to build the platform, maintain the platform, secure the platform, and — hardest of all — convince teams to actually use it instead of building their own thing anyway. Platform engineering done badly is just centralized DevOps with better marketing and slower ticket queues.

For TPMs, the work didn't change as much as the vocabulary did. You're still reducing toil, still shepherding migrations, still translating between the people who build the thing and the people who depend on it. The difference is the interface: instead of coordinating fifteen teams' deployment practices, you're managing one platform's roadmap and its adoption curve. The politics moved up a level. The spreadsheets got bigger.

For security folks, though, the platform shift is the best thing that happened in a decade — and most of us haven't fully grasped it yet.

Here's why: "shift left" mostly failed. Telling every developer to become a security expert didn't work, because developers have a job and it's not security. What works is putting the guardrails *in the platform* so the secure path is the easy path. Container images scanned by default. Secrets injected, never hardcoded — because the platform doesn't give you another option. Network policies applied at deploy time, not as a wiki page nobody reads.

The platform is where security goes from advice to architecture. That's a profound change, and it's the part of the rebrand that actually matters.

But — and there's always a but — the platform is also a single point of failure and a single point of compromise. When every team deploys through the same pipeline, whoever owns the pipeline owns the kingdom. Supply chain attacks, poisoned base images, a misconfigured admission controller: the blast radius of a platform compromise is the entire engineering org. We traded fifteen small attack surfaces for one enormous one, and we'd better be securing it like the crown jewels.

So the honest version of the story: platform engineering is DevOps with product management, and that's genuinely better. It gives security a place to live that isn't a checklist. But it concentrates risk, and it only works if the platform team treats security as a feature of the platform rather than a tax on its users.

The rebrand is complete. Now comes the hard part: making the thing worthy of the name.

Written by Alanna Gray, 2025

The Backlog Is a Garden, Not a Warehouse

Most backlogs I have ever seen — and I have audited, inherited, and run more of them than I can count — are managed like warehouses. Everything anyone ever requested gets received, labeled, and shelved. Storage feels free. Nobody throws anything away, because throwing things away feels like a decision, and decisions can be argued with. So the inventory grows, and quietly, it rots. Items written for a system that no longer exists. Requests from people who have left the company. Features whose whole reason walked out the door two reorganizations ago. The list gets longer, the team gets more cynical, and eventually nobody believes the backlog at all — including the people who maintain it. A list nobody believes is worse than no list. It is process theater with a search box.

A garden works on the opposite principle. A garden is finite on purpose. Things are planted deliberately, tended on a schedule, pruned without sentimentality, and — this is the part warehouse managers can't stand — some things are simply not planted at all. What isn't tended in a garden dies honestly, out in the open, instead of sitting on a shelf pretending to be alive for three years. Your backlog should be so lucky.

Prune on a schedule, not on a whim

Gardeners don't prune when they feel brave. They prune when the season says to. Steal that. I run a pruning review once a quarter — spring is as good an anchor as any, because March is when you can see exactly what survived the winter and what didn't. Ninety minutes, the whole list, three possible verdicts per item: keep, kill, or park it (more on that below). The rule that makes it work is that pruning is a calendar event, not a courage event. Nobody has to work up the nerve to delete a senior person's pet idea in a random Tuesday meeting. The review deletes things. That's just what the review is for.

Give every item an expiration date

Here is the practice that does the heaviest lifting: an age limit. Any item older than a set threshold — I use twelve months for most lists, six for fast-moving ones — expires automatically unless someone re-argues for it. Not re-estimates it. Re-argues it: states, out loud or in writing, who it serves, what it costs to leave undone, and why now.

This sounds harsh until you watch it work. An item nobody will re-argue for was already decided. The team decided it the last fourteen times they picked something else. The backlog just hasn't admitted it yet. Expiration doesn't kill ideas — it forces the honest paperwork on decisions that have already happened. And sometimes the re-argument surprises you: someone makes the case, the room hears it fresh, and an old item legitimately jumps the queue. That's gardening too. Things come back into season.

A parking lot is not a warehouse

Every backlog needs a place for "not now," and this is where most teams cheat. A warehouse is indefinite: no owner, no date, no review — items go in and are never seen again. A parking lot, run properly, is deliberate. An item goes in with three things attached: a reason it isn't being done now, a date to look at it again, and a condition that would change the answer ("when the vendor contract renews," "when we hire the second tech," "if bookings hit the spring target"). When the date arrives, the item gets its hearing and one of the three verdicts. The difference is not the list. The difference is whether the list is a commitment or a landfill.

Saying no is a service

Auditors learn this early: a clean "no, and here's why" is kinder than an indefinite "we'll get to it." The requester whose idea sits in your warehouse for two years has planned around a maybe. They've told their own boss it's coming. They've skipped workarounds because the real fix is supposedly in line. A timely no lets them escalate, re-scope, build the workaround, or argue the case harder with better information. Silence dressed up as a backlog slot does none of that. Pruning is not disrespect for the requester. It is the first respectful thing you've done for them in months.

The pruning ritual

Here is the whole practice, small enough to run this week:

1. Sort the list by age and look at the number. Count how many items are past your threshold. The count itself is diagnostic — if half your backlog is expired, you don't have a backlog, you have an archive.
2. Hold the ninety-minute review. Owners present, requesters invited where practical. Every expired item gets a verdict: re-argued and kept (with today's reasoning written on it), parked (with a revisit date and a condition), or deleted.
3. Delete in the meeting, in front of everyone. Not "we'll clean it up later." Later is where warehouses come from. Watching items actually leave the list is what rebuilds the team's belief that the list is real.
4. Write the nos down. For every deleted request, send the requester two sentences: what was decided, and what would change it. Thirty seconds each, and it turns a silent burial into a service.
5. Schedule the next pruning before you leave the room. Same quarterly rhythm, same threshold. A garden is not a project. It's a practice.

Do this four times and something shifts: the backlog gets shorter, the arguments get better, and the list starts meaning something again. Teams don't lose faith in backlogs because the work is hard. They lose faith because the list lies to them. Tend it like a garden — finite, pruned, and planted on purpose — and it will tell you the truth.

Prompt Injection Is the New SQL Injection

In the early 2000s, SQL injection was everywhere. Every web app built a query by smashing user input into a string, and attackers typed ' OR '1'='1 into login forms and walked right in. It was embarrassing, it was pervasive, and it took the industry the better part of a decade to dig out — mostly through parameterized queries and frameworks that made the safe thing the default.

Prompt injection is the same movie with a different cast.

The shape of the vulnerability is identical: untrusted input gets mixed into a trusted instruction stream, and the system can't tell which is which. Only now the "database" is a language model, the "query" is a prompt, and the "input" is whatever the user — or a webpage, or a document, or another agent — decided to feed it.

We've seen the demos. The résumé screener that gets told to ignore all other candidates. The support bot that gets jailbroken into handing out refund codes. The agent with access to your email that reads a phishing message and helpfully follows its instructions. Every one of these is the same bug wearing a new hat: the model treats data as instructions because nobody built a wall between them.

And here's the part that should worry you: we're repeating the timeline. SQL injection was a known, documented, exploited vulnerability for years while the industry shipped framework after framework that concatenated strings by default. Today we're shipping LLM features that concatenate prompts by default, and the security guidance is still mostly vibes.

So what does defense in depth actually look like for LLM apps? Not a single silver bullet — SQL injection didn't die because of one product, it died because of layers.

First: treat model output as untrusted. The model's answer is data, not a decision. If your agent can send email, move money, or change access, the model's output should be a *proposal* that something else validates — not a command that executes directly.

Second: least-privilege tool access. Your customer support bot does not need write access to the billing database. Your document summarizer does not need your inbox. Every tool you hand the model is an attack surface, and the model will use them exactly as creatively as an attacker tells it to.

Third: separate the channels. System instructions, user input, and retrieved content should be structurally distinct, and the model should be trained and configured to treat them that way. This is the parameterized-query equivalent — the thing that makes the safe path the default path. It's not perfect, and researchers keep finding bypasses, but it's the foundation everything else stacks on.

Fourth: filter the outputs, not just the inputs. Input filtering is a losing game — attackers are more creative than your blocklist. But you can validate what the model *produces* before it acts: does this response match the expected schema? Is this action within the allowed set? Is a human in the loop for anything consequential?

That last one deserves emphasis. The industry spent years trying to make the model itself the firewall — better alignment, better refusal training, better guardrails baked into the weights. That's like asking the database to sanitize its own queries. It helps, but it's not a security boundary. The boundary lives in your architecture, not in the model's mood.

The people building LLM features aren't careless. Most of them are moving fast on a platform that's genuinely new, and the security playbook is still being written. I get it. But the playbook has a first chapter, and we've already read it once.

We know how this story ends. The question is whether we spend another decade learning it.

Technical Debt Has Interest Rates

Every team I've ever worked with has a pile of technical debt, and every team describes it the same way: like it's one thing. One big gray blob labeled "the stuff we should have done better."

It's not one thing. Technical debt has interest rates, and the rates are wildly different depending on what you borrowed against.

Some debt is a mortgage. You took it on deliberately, you know the monthly payment, and it's attached to an asset that's appreciating. The quick-and-dirty integration you shipped to land the enterprise customer? Mortgage. You'll pay it down on a schedule, and it bought you something real.

Some debt is a car loan. Depreciating, annoying, but manageable. The hand-rolled deployment script that only one person understands. It costs you a little every month in toil and anxiety, but it doesn't threaten the business.

And some debt is a payday loan. It compounds while you sleep, and by the time you notice the rate, you're working for the debt instead of the other way around. The authentication library pinned three major versions behind because upgrading it breaks everything. The database schema that makes every new feature take twice as long. The shared service with no owner that five teams depend on.

Here's the thing about payday-loan debt: the interest doesn't show up as a line item. It shows up as velocity decay. Features that used to take a week now take a month, and nobody can point to why. Engineers start padding estimates. The good ones leave, because they can feel the building rotting around them even if management can't see it.

So how do you tell which kind you're holding? I've got three questions I ask.

First: does this debt slow down *every* future change, or just some? A messy module that one team touches twice a year is a car loan. A tangled core that every feature has to route through is a payday loan. Compound interest applies to the critical path.

Second: does the debt block security work? This is the one that keeps me up at night. If you can't patch a vulnerability in under a week because the upgrade path is broken, your interest rate just became a breach waiting to happen. Debt that degrades your security posture isn't technical debt anymore. It's unpriced risk, and the market always collects.

Third: who owns paying it down, and when? Debt with an owner and a date is a mortgage. Debt with no owner and no date is a payday loan, full stop. "We'll fix it when we have time" is how you say "never" with extra syllables.

The uncomfortable truth is that most organizations are excellent at taking on debt and terrible at pricing it. Leadership sees the feature ship; they don't see the 40% tax on every subsequent sprint. And engineers, bless us, are complicit — we warn about the debt in the abstract and then quietly work around it instead of putting a number on it.

So put a number on it. Not a story-points-are-made-up number. A real one: this module costs us roughly two engineer-weeks per quarter in workarounds. This upgrade path means a critical patch takes nine days instead of one. Translate the debt into time and risk, because that's the language budgets understand.

And then refinance the payday loans first. Not all of them — you can't pay down everything, and trying will just stall the roadmap. But find the one piece of debt that taxes every future decision and kill it. The relief is immediate. Teams can feel the difference within a sprint, and suddenly the next piece of debt looks payable too.

Debt isn't the enemy. Unpriced debt is.

The interest is always compounding. The only question is whether you're the one collecting.

Pricing Is a Promise: Honest Signals in a Discount Season

Written by Alanna Gray, 2025

December is the loudest month in business. Every inbox fills with countdown timers and “almost gone” banners, every storefront promises the biggest sale of the year, and the pressure on a small operator to shout along is real. I run short-term rentals in Atlanta, and I feel it too — the empty weeknight on the calendar starts whispering that a fake “40% off, today only!” banner would fix it.

I don’t run that banner. Not because discounts are wrong, but because a price is a promise, and a demand signal is a statement of fact. The moment either one stops being true, you’re not marketing anymore. You’re just hoping nobody checks.

Scarcity you invent is a lie with a deadline

“Only 2 left!” is a claim about the world. If there are actually nine left, the claim is false, and it doesn’t become true because everyone else is doing it. In my old life as an internal auditor, we had a simple test for numbers we put in front of people: could you show your work if someone asked? A price should pass the same test. If a guest asked why this week costs what it costs, I should be able to answer in one honest sentence.

There is real scarcity in hospitality — a calendar date genuinely is one of one. When it’s booked, it’s gone. That makes honest scarcity more valuable, not less: when I say a weekend is sold out, it is sold out, and guests who’ve been told the truth before believe me. The operators who cry “almost gone” all month train their customers to ignore every signal they send, including the true ones.

Say the seasonal part out loud

Holiday weeks cost more in my business. Christmas week in Atlanta, a big game weekend, a festival — demand is real, and pretending otherwise helps nobody. What I won’t do is bury that in a mystery “fee” at checkout or dress it up as a discount off a price nobody ever paid.

The honest version is a sentence: rates are higher this week because the whole city is full, and they’re lower in mid-January because it isn’t. Guests understand seasons. Farmers’ markets have run on this logic forever — nobody feels cheated that peaches cost more in June than peach-flavored anything does in February. What people resent is discovering the rules were hidden. Transparent seasonal pricing turns a potential complaint into plain information, shared before money changes hands.

A real offer has a real end

Discounts themselves aren’t the problem. I run offers — a quieter-week rate, a thank-you for a returning guest. But a real offer has three things the seasonal noise usually lacks: a real starting price it comes down from, a real reason, and a real end date that I honor. When the date passes, the offer ends. If I quietly extend every “final day” sale into next month, I’ve taught everyone that my deadlines are theater — and a customer who learns that lesson applies it to everything else I say, including the checkout instructions and the house rules.

Hold quality when the race goes down

December also brings the temptation to cut quietly: thinner cleaning between stays, slower replies, the small services dropped because the margin feels tight. That’s the discount nobody advertises, and it’s the one guests actually remember. An auditor learns to watch what an organization does under pressure, because pressure reveals the real controls. A small business is the same. The season when it’s hardest to hold the standard is exactly the season that decides whether people come back in the quiet months — and whether they tell their friends.

What an honest operator can do this season

None of this requires a marketing department. It’s a handful of practices, most of them one-time decisions:

• Audit your own signals. Read every word your listings, site, and ads say about price and availability. Anything you couldn’t prove with your calendar or your books comes out today.
• Publish your seasons. Name your high-demand periods and say plainly that rates rise then — and when they fall. One honest paragraph replaces a year of suspicion.
• Give every offer an end date, then keep it. Put the date in writing, and let it expire even if it stings. The credibility is worth more than the extra bookings.
• Never say “sold out” as a strategy. Say it only when the dates are actually gone. Real scarcity, stated plainly, is the strongest signal a small operator has.
• Cut costs where guests can’t feel it. Renegotiate supplies, tighten your own schedule, fix the leak in your process — not the experience you promised at the price you charged.

December will be loud whether I join in or not. I’d rather be the business whose prices people trust in January, when the shouting stops and the guests who remember being told the truth come back.

Post-Quantum Isn't Coming. It's Here.

For years, post-quantum cryptography lived in the same category as flying cars: technically real, practically distant, something you'd get to eventually. Then last August, NIST published the actual standards — FIPS 203, 204, and 205 — and "eventually" became "now." The math is done. The algorithms have names. The migration clock is running.

And here's what I want everyone to understand: this is not a math problem anymore. It's a program-management problem.

I say this as someone who's spent a career in key management, so I know exactly how unglamorous this sounds. Nobody's giving keynotes about inventory spreadsheets. But the hard part of post-quantum migration was never the algorithms — NIST and a few hundred cryptographers handled that. The hard part is finding every place cryptography lives in your organization and changing it, in the right order, without breaking anything.

Think about what "every place cryptography lives" actually means. It's the TLS libraries, obviously. But it's also the VPN concentrators, the code-signing infrastructure, the HSMs and whether their firmware supports the new algorithms, the IoT devices with crypto baked into silicon that can't be updated, the third-party SaaS vendor who handles your data and hasn't published a migration plan, the backups encrypted with algorithms you're about to retire, the certificates with ten-year lifetimes issued back when ten years felt safe.

Nobody has a complete list. I'd bet money on it. Most organizations can't fully inventory their current crypto usage, and now they need to migrate all of it. Discovery alone is a multi-quarter program for any company of size.

Then there's the sequencing problem, which is where it gets genuinely tricky. You can't just flip a switch. The new algorithms have different performance characteristics — bigger keys, bigger signatures, more computation. That matters for constrained devices, for high-throughput TLS terminators, for anything where latency is measured in microseconds. Hybrid approaches — running classical and post-quantum together during transition — are the sane path, and they're also twice the operational complexity.

And the vendors. Everyone's waiting on everyone else. Your HSM vendor is waiting on firmware validation. Your cloud provider has a roadmap but the dates are soft. Your auditors haven't decided what "compliant" means yet. Coordinating a migration across a supply chain where every link moves at a different speed is pure program management — dependencies, critical paths, escalation, the works.

The quiet urgency behind all of this has a name: harvest now, decrypt later. Adversaries are collecting encrypted traffic today on the assumption that they'll decrypt it once quantum computers mature. If your data has a secrecy lifetime longer than the migration timeline — and for a lot of regulated data, it does — then the window that matters isn't "when quantum computers arrive." It's already open.

So what should you actually do? Start with inventory. Not a pilot, not a working group to discuss forming a working group — an inventory. Where does crypto live in your environment? What algorithms, what key lengths, what lifetimes? You can't migrate what you can't see, and most organizations are about to discover they're blinder than they thought.

Then prioritize by data lifetime and exposure. The stuff facing the internet, protecting long-lived secrets, goes first. The internal system with a three-year refresh cycle can wait its turn.

And staff it like the program it is. This needs someone running it full-time — tracking vendors, sequencing migrations, managing the hybrid period, reporting to leadership in terms of risk reduced rather than algorithms deployed. The cryptographers did their part. Now it's our turn.

The quantum apocalypse isn't coming. It's a migration project. And migration projects are won by people with spreadsheets, not people with whiteboards.

The Sprint Retrospective Is Dead

Every two weeks, teams gather to perform a ritual. Someone opens the board. Three columns appear: what went well, what didn't, action items. Everyone says something polite. The action items are written down. Nobody ever looks at them again.

The sprint retrospective isn't a practice anymore. It's theater. And we all know it.

I'm not against reflection — I'm against the performance of reflection. There's a difference, and most teams are doing the second one. The evidence is everywhere: the same complaints sprint after sprint, the action items that age like milk in the backlog, the facilitator asking "anyone else?" into silence while everyone stares at their cameras.

Why did this happen? A few reasons, and none of them are anyone's fault, exactly.

First: psychological safety became a slogan instead of a practice. Every company says they want honest feedback. But the retro happens in front of the same manager who does performance reviews, and everyone in the room can do that math. So people share the safe complaints — "too many meetings," "unclear requirements" — and keep the real ones — "our tech lead doesn't listen," "this deadline was fantasy" — for the group chat. The retro gets the press-release version of the truth.

Second: the action items have no teeth. "Improve communication" is not an action item; it's a wish. Real action items have an owner, a deadline, and a way to verify they happened. Most retro action items have none of these, because assigning them would require someone to actually change something, and changing things is uncomfortable. So the board fills up with good intentions and the team learns, correctly, that nothing said in a retro matters.

Third: the cadence is wrong. Two weeks is simultaneously too often and too rare. Too often for anything meaningful to have changed — you're just re-litigating the same sprint. Too rare for the things that actually need reflection, which are usually specific moments: the deploy that went sideways, the decision made in a hurry, the week the team worked nights. By the time the retro rolls around, the moment has cooled and the learning has evaporated.

So what does honest reflection actually look like? In my experience, it's smaller, more specific, and less comfortable.

It looks like a fifteen-minute conversation right after something happens, not a scheduled ceremony two weeks later. "That deploy was rough. What did we miss?" — while everyone still remembers.

It looks like the manager going first. Not "what could the team do better" but "here's what I got wrong." The fastest way to make a retro honest is for the person with the most power in the room to demonstrate that honesty doesn't get punished. Everything else is decoration.

It looks like fewer, harder action items. One thing, with a name attached and a date. If you can't name who's doing it and when it's due, it's not an action item — it's a feeling.

And sometimes it looks like admitting the format isn't working and trying something else. A written retro. A one-on-one. A "what should we stop doing" session with no "start doing" allowed. The format is not sacred. The honesty is.

I'm not saying kill the retrospective. I'm saying kill the ritual — the empty performance of a practice that used to mean something. The teams that reflect honestly don't need a template. The teams with a template usually aren't reflecting.

The retro is dead. Long live actually talking to each other.

Your AI Wrote That Code. Who Reviewed It?

Somewhere in your organization, right now, a developer is shipping code they didn't write. Not copied from a forum — generated, in seconds, by an AI assistant that read the comment they typed and produced forty lines of working code.

This isn't a prediction. It's Tuesday. The assistants are everywhere: in the IDE, in the pull request, in the terminal. Developers love them, and honestly, for good reason. The boilerplate, the test scaffolding, the "I know what I want but not the exact syntax" moments — the machines are genuinely good at this. Velocity is up. Morale, in a lot of places, is up too.

Here's the part nobody planned for: the review bottleneck.

Code review was already the scarcest resource in most engineering orgs. Now we're generating code faster than ever, and the review capacity didn't change. Every team just quietly widened the gap between "code produced" and "code actually understood by a human." That gap has a name, and the name is risk.

And AI-generated code has a particular flavor of risk that's worth understanding. It's not that the code is bad — most of it compiles, most of it passes tests. It's that it's plausible in a way that resists review. A human junior developer writes code with tells: the awkward variable names, the over-complicated loop, the comment that doesn't quite match. You can see the thinking, including the flawed thinking. AI-generated code has no tells. It's smooth. It's confident. It's wrong in ways that look exactly like being right.

There's also the training-data problem. These models learned from the entire history of public code, which includes the entire history of public mistakes. The injection patterns of a decade ago. The crypto implementations that were state of the art years back and deprecated since. The model doesn't know what year it is. It knows what was common. "Common" and "secure" have never been the same thing.

So what's the answer? It's not banning the tools — that ship sailed, and besides, your developers are using them on their personal machines anyway. It's not blind trust either, which is just outsourcing your judgment to a statistical model trained on the public internet.

The answer is treating AI-generated code as what it is: code from a very fast, very confident junior developer who has read everything and understood nothing. You'd never let a junior's pull request merge without review. Don't let the machine's merge without review either.

Practically, that means a few things. First, the review process has to acknowledge the volume. If your team generates twice the code, "just review harder" isn't a plan. You need to be deliberate about where human review goes: authentication flows, authorization logic, data handling, crypto, anything touching money or personal data. Let the linters and the scanners have the boilerplate. Spend the humans on the blast radius.

Second, threat-model the generated code specifically. When a human writes auth logic, you review their decisions. When a machine writes it, there were no decisions — there was pattern completion. Review it accordingly. Ask "what assumption is baked in here?" instead of "what was the author thinking?" The author wasn't thinking. That's the point.

Third — and this one matters — keep humans writing the critical stuff. Not because humans are better at it (often they're not), but because the act of writing is the act of understanding. The developer who hand-writes the auth flow can debug it at 3 AM. The developer who accepted the suggestion can read it. Maybe. The understanding gap is the real vulnerability, and it compounds.

The teams that get this right won't be the ones that generate the most code. They'll be the ones that kept their judgment while everyone else automated theirs.

Your AI wrote that code. Make sure somebody — a person, with context and accountability — actually reviewed it.

Passkeys Finally Grow Up

For about a decade, passkeys have been the future of authentication. You know what that makes them now? The present. Somewhere along the way — while we were all arguing about password managers and MFA fatigue — Apple, Google, and Microsoft just shipped them. To everyone. They're in your phone right now, whether you've noticed or not.

This is the part where I'm supposed to explain what a passkey is, but honestly, the best thing about them is that users don't need to know. That's the whole point. No password to invent, remember, rotate, or reuse across fourteen sites. You want in, you look at your phone or touch the sensor, and you're in. The cryptography underneath is genuinely clever — a key pair where the private key never leaves your device — but the user experience is just: it works.

And it's phishing-resistant in a way passwords never were, because there's nothing to phish. You can't trick someone into typing a passkey into a fake login page. There's nothing to type. The credential is bound to the real site. This is the thing security people have wanted for twenty years, and it arrived not with a bang but with a software update.

So why isn't everyone celebrating? Because for the teams running authentication, the passkey isn't the hard part. The transition is.

Here's what nobody's keynote mentioned: account recovery. What happens when someone loses their phone? What happens when they get a new one and the keys don't come along? Every auth team I know is spending more time on the fallback paths than on the passkey implementation itself. The happy path took a sprint. The "I dropped my phone in a lake" path is taking a quarter.

Then there's the cross-platform mess. Passkeys work beautifully inside one ecosystem. Step outside it — the person with an iPhone and a Windows laptop, the shared workstation, the odd Linux box in the corner of the lab — and things get interesting. Synced passkeys helped. Device-bound keys for high-assurance scenarios helped. But "it just works" still has an asterisk, and the asterisk is where your helpdesk tickets live.

And the legacy systems. Oh, the legacy systems. Somewhere in every enterprise there's an application from 2009 that barely tolerates modern single sign-on, and it's not getting passkeys. Ever. So now you're running two authentication worlds side by side, and the security of the whole thing is the security of the weaker one. Passkeys don't fix the app that still accepts "Password123!"

None of this is an argument against passkeys. It's an argument for honesty about the work. The industry spent years treating the cryptography as the finish line. It was the starting line. The real project is migration: recovery flows, cross-device stories, helpdesk training, user communication, and the long tail of systems that will never support any of this.

For users, though? It's already better. My mother will never understand what a passkey is, and she doesn't have to. She touches the fingerprint sensor and she's in. That's the victory. We spent decades building authentication that required users to think like security engineers. Finally, we built one that just requires them to be a person with a face.

The future arrived quietly. Now comes the paperwork.

The 2025 Security Budget Conversation

It's budget season, which means somewhere right now a CISO is building a slide deck full of breach headlines, red arrows, and the words "threat landscape" in 48-point font.

My advice: delete the deck.

I've sat on both sides of the budget table, and I can tell you the fear pitch stopped working a while ago. Not because the threats aren't real — they are — but because the room is already scared. The CFO reads the same headlines you do. The board has already done the tabletop exercise. Fear gets you the meeting. It doesn't get you the money.

What gets you the money is the same thing that gets anyone the money: a clear explanation of what it buys, what it costs, and what happens without it — in terms the business actually uses.

That last part is where most security leaders lose the room. We walk in speaking in vulnerabilities and they hear static. Try this instead: don't ask for a WAF. Ask for the thing the WAF protects, priced in the language of the P&L. "Our checkout flow processes X dollars per hour. This control costs Y per year and closes the most likely path to taking it offline." That's a conversation a CFO can have. "Advanced persistent threats are evolving" is not.

And here's the move that builds real credibility: bring your cut list.

Every security program has spending that made sense three years ago and doesn't now. The tool nobody logs into. The feed nobody reads. The consultant engagement that quietly became a subscription to nothing. Walk in with the things you'd cut, and two things happen. First, you prove you're a steward of the money, not just a spender of it. Second, you get to redirect those dollars to the thing you actually need, which is a much easier ask than new money.

Finance people love this. It signals that you think like an operator, not a doomsayer. And honestly, most of us could cut ten percent of our program without changing our risk posture at all. We just don't, because cutting things feels like admitting we were wrong to buy them. Get over it. The threat changed; the budget should too.

The other shift worth making: stop selling security as insurance and start selling it as enablement. Insurance is a grudge purchase — everyone resents paying for it and hopes they never use it. Enablement is different. "This investment lets us launch in the EU without a six-month compliance scramble" is a growth conversation. "This lets the sales team answer the security questionnaire in a day instead of three weeks" is a revenue conversation. You're not overhead. You're the reason the deal closes.

I know some of you are thinking: but my leadership only responds to fear. Maybe. Some cultures run on it. But even there, I'd argue the fear pitch has diminishing returns, because every year the scariest headline gets scarier and the budget stays flat. At some point you're just the person who cries breach, and the room stops flinching.

The security leaders who win budget in a cost-conscious year aren't the loudest. They're the clearest. They know what everything costs, what everything protects, and what they'd cut first. They speak in dollars and outcomes, not acronyms and anxiety.

Nobody ever got a budget approved by being the scariest person in the room.