What I'm seeing here is two needs:
1. Trust the tech/maths capabilities of hires who pass the new interview process.
2. Clearly represent that need to others in the org who are more conversation-focused.
Do I have that right?
------------------------------
1. Design interviews as close as you can to the day-to-day work -- like pair-programming and pair code-review, but for maths.
When interviews resemble the work, it is easier for the new hire to trust that they can do the work. Some of the best interviews I've done (from both ends) were pair programming and code-review based. When I started an interview by writing tests first and then got hired for that, led me to feel a higher sense of psychological safety during the day-to-day work. I trusted that my need for TDD was aligned with the org's needs and that my ability to discuss technical tradeoffs were sufficient to deliver results. If new joiners trust that their skills are a good fit for their role, it is easier for them to speak up in otherwise-tough conversations.
For more on this, read The Speed of Trust or this blog post summarising a piece of it:
http://eliteaming.blogspot.com/2016/09/core-3-capabilities-p...
2. Represent the value of a solid base of technical expertise to folks who think in terms of conversation and creativity.
First, refer to the need for trust to enable high-quality conversations.
Second, refer to the need for folks who can make technical details accessible.
"We need people with the depth of expertise that can allow them to explain deep technical issues clearly, correctly, and accessibly. That clarity is necessary so everyone in the room can play with those ideas and see unexpected opportunities -- and so they can offer an off-the-wall idea knowing that we'd clearly see its technical risks and make a high-quality decision about it."
https://kottke.org/17/06/if-you-cant-explain-something-in-si...