. THREE PRACTITIONER INSIGHTS .

01

My most valuable team member doesn't write code.

She's a former business analyst who spent eight years in our lending division. She knows every process, every pain point, every stakeholder's real concern (not the one they say in meetings, the one they whisper in the corridor). When a business unit comes to us with "we want AI for X," she translates that into a scoped technical problem in 48 hours. Without her, our data scientists would spend weeks in meetings trying to understand the business context. With her, they start building on day three. I call this role "the translator." It's not in any AI team playbook. It should be the first hire in every one.

02

I stopped hiring for tools. Here's what I hire for instead.

My last three job descriptions didn't mention a single framework or language. Instead, I tested for: (1) Can you explain a technical trade-off to a board member? (2) Given this dataset and this business problem, what would you NOT do? (3) Tell me about a model you chose not to deploy. The answers to these questions reveal judgment, the ability to know when something shouldn't be built, when data isn't good enough, when a simpler approach beats an elegant one. I can teach someone PyTorch in a month. I can't teach them the instinct to say "this model works but we shouldn't ship it because the explanation story doesn't hold."

03

Three months in, I'm willing to say the dual-leadership structure is working.

For context: we split assistant team manager responsibilities into two roles, one owning people, process, and stakeholder management, the other owning technical depth and architectural authority. I was nervous about it. The conventional wisdom is that splitting accountability creates ambiguity, and conventional wisdom is right often enough that you should listen to it. In this case, it was wrong, at least for us. Here is what I did not anticipate: the technical authority role gave the more introverted, deeply technical person on the team a real path to influence without forcing them into management theatre they did not want. Decisions per week now routed through that role: roughly 8–12, most resolved in under 30 minutes. Decisions that previously came to me by default: I'd estimate I've reclaimed 4–5 hours a week, and the quality of decisions has gone up because the person making them is closer to the actual work. The warning I'd give anyone considering this: it only works if both roles publicly defer to each other in their own domain. The first time the people-manager overrules a technical call in front of the team, or the technical authority overrules a process call, the structure collapses. We had one near-miss in week six. We talked about it directly, and it has not happened since. If you are considering splitting a senior role, the test isn't whether the people involved can do their parts. It's whether they can refuse to do each other's.

- Two Use Cases -

→ WIN Embedded data scientists: 8 weeks → 2 weeks for first prototype

We moved from a centralized model, where business units submitted requests to the data science team through a ticketing system — to an embedded model. One data scientist sits in lending, one in compliance, one in operations. They report to the business unit head with a dotted line to me for standards and governance. The result: time from business request to first prototype dropped from 8 weeks to 2. Not because the data scientists got faster. Because they stopped needing a requirements document. They already understood the problem because they lived it daily. The central team I maintain is now focused on platform, governance, and cross-cutting capabilities, not on being a bottleneck that translates business tickets into technical specs.

→ LESSON Five PhDs, zero models in production after 12 months

A bank I know hired five PhDs, machine learning researchers with impressive publication records. Deep technical talent. After 12 months: zero models in production. The team was optimizing for accuracy and methodological novelty. They built architectures that required data pipelines that didn't exist and couldn't integrate with the bank's 20-year-old core systems. The models were elegant. They were also undeployable. The fix took humility: the bank paired each researcher with a senior software engineer whose only job was to ask "how does this get into production?" at every design decision. Within four months, two models shipped. The lesson isn't "don't hire PhDs." It's "don't hire a team of only PhDs."

◉ THE REGULATORY SIGNAL

[Written July 6th.] AI literacy under Article 4 of the EU AI Act has been in force since February 2025, and the enforcement signal is sharpening. The European AI Office's living repository of AI literacy practices is being actively expanded, and the pattern emerging from supervisor conversations is unambiguous: regulators want evidence of role-specific training, not a generic e-learning module the whole organisation clicked through last quarter. A board member, a model risk officer, a developer, and a customer-facing relationship manager need fundamentally different AI literacy. If your bank has one mandatory 30-minute module that everyone takes, that is compliance theatre, and supervisors are starting to recognise it for what it is. What to do this quarter: define four to six audience tiers (board, senior management, risk and compliance functions, developers and data scientists, business users of AI tools, customer-facing staff), build or commission different content for each, and — the part most banks skip — keep evidence of both completion AND comprehension. A 70% pass rate on a five-question scenario quiz is more defensible than an attendance log. If your AI inventory is the operational artifact regulators will ask to see, your AI literacy matrix is the cultural one. Both will get asked about. Build them as a pair.