I might have picked the wrong word "measurable". It's better to stay away from ultra-narrow measurement. "When a measure becomes a target, it ceases to be a good measure" Instead, put the phenomenon in their head. Make it their responsibility. Point out the impact of readability to the team velocity.
Or maybe, examine if the introduced complexity is actually incidental and not essential. IF it is essential, it makes more sense to upskill the rest of the team. Hold sharing session to hear everyone's thought. Hear what the smart guy thought about the code. Sometimes, what someone need to unlock a heap of more horse power forever is just a little nudge that makes them click. Create team conventions for making things easier for everyone, e.g. indirection through naming in which you need to pay a bit in performance.
I might have picked the wrong word "measurable". It's better to stay away from ultra-narrow measurement. "When a measure becomes a target, it ceases to be a good measure" Instead, put the phenomenon in their head. Make it their responsibility. Point out the impact of readability to the team velocity.
Or maybe, examine if the introduced complexity is actually incidental and not essential. IF it is essential, it makes more sense to upskill the rest of the team. Hold sharing session to hear everyone's thought. Hear what the smart guy thought about the code. Sometimes, what someone need to unlock a heap of more horse power forever is just a little nudge that makes them click. Create team conventions for making things easier for everyone, e.g. indirection through naming in which you need to pay a bit in performance.