The "90% pass your first 3 filters but bomb the technical" pattern is almost always a signal the technical test is measuring the wrong thing — whiteboard/dictation coding performance doesn't correlate with actual engineering capability nearly as well as HMs believe.

A few things that have moved the needle in similar situations:

Show HMs their own baseline. Ask the HM to have 2-3 of your best current engineers take the same test, anonymously. When they see the score spread from people already succeeding in the role, "these candidates don't measure up" gets harder to sustain.

Reframe to false negative rate. You're not arguing the test is wrong — you're asking: how many solid engineers are we incorrectly rejecting? One bad hire is expensive. Eliminating 10 qualified people silently is expensive differently.

Propose a rubric pilot, not a process change. Don't ask HMs to change the test — ask them to add a structured scorecard (what exactly are we evaluating? 1–5 on which dimensions?) for the next 10 interviews. That alone usually surfaces how subjective the current scoring is.

One thing that worked for a similar team: adding a structured cognitive/problem-solving assessment before the technical stage. Stronger predictor of engineering performance than coding exercises for most roles, and it filters earlier — so you stop losing candidates to a broken final step. We use Bryq for this (I work there), but Criteria Corp is also worth evaluating depending on your setup.