Ask HN: _How to get past “saving face” or other cultural differences?

Hey all, I'm trying not to turn this into a culture war, please let me know how to be respectful about this topic. How does one get past the "saving face" or obedience / Confucius mindset on software teams? Have other people experienced this issue below? Picture a scene: * We have a critical bit of work that needs to get done, make a current implementation of something work with new data-types. ASAP, it's quoted to be 2 days work roughly (i eventually took it over and got it done, so it is around that size.) * Current implementation is a boiled down, maybe "non-intuitive" version. (It's to deal with money amounts, and with a bit of maths, you can figure it one way quicker than the brute-force/naive implementation). * We give the work to team-mate who says "yes i get it" to the problem, and "yes i get it" to the solution / implementation that we need to change. "do you understand why we do it this way?" - "yes" * 2 weeks pass, for what is meant to be a 2 day change - he's spinning wheels. adding little changes to 3000 tests trying to make all the tests work to whatever his version is. getting stuck in the debugger for tests, not understanding what the tests are trying to do, etc, not understanding why the tests aren't working. getting frustrated. * i take it over, 3-4 changes at the right place makes all tests pass and implementation good to go. * he won't admit that he didn't understand it, because it makes him sound dumb (his word). He understood, but he understood his version, which was different to reality (this is how he explained it). -- any further "ok, that's acceptable, how do we test our assumptions against reality?" causes him to worry and get upset, and walk it back "no i did actually understand it." - there's a notion of "saving face" here because he doesn't want to be the person who didn't know this. * There's also no answer to "why don't we just delete the code? why do we have this code in the first place?" * After a short whiteboard session, he does understand it. it clicks for him, he know how we do it, but still agrees that he would do it the brute force way because that is more easily understood by looking at the code at first glance. We have a debrief: "did you learn something from this whiteboard session?" "yes, i've said that multiple times, it was good!" "does that mean you got something new from it?" "yes" "... to get something new, it means that you didn't have that knowledge before the whiteboard session, right?" "... no. perhaps that is an overstatement, i already understood everything, but this was good overview." We try to encourage an open "no stupid questions" mindset across the team, and everyone for the most part gets it. We find it acceptable for people to not even understand the tests they wrote 6 months ago (because we have a big problem domain so naturally people forget) - but this is a case where the person needs to be comfortable with the notion that they don't understand something.. I've had Chinese friends talk about saving face culture (not to look bad) and the Confucius / cram-schooling /copy-the-master methodology in China and other communist countries: the master knows all. if you don't understand it, you will fail/be beaten, so you must understand and don't question the master. If teammembers don't feel comfortable saying they don't understand, they won't get help to unblock them, and so work slows down. I don't feel like it came from our team, this has to be more the cultural aspects at play, like looking at the code like a master, rather than having mastery over the code itself. Has anyone had similar?