And without further ado, I will now turn it over to yield the floor to Claude.
Thank you very much, sir.
Can you hear me?
Does this work?
All right.
It's working.
Thank you.
Okay.
I'm here today to talk about cultural relativism as a prism for constructing cross-cultural
communities.
And let me start first by saying that the opinions expressed in this talk are mine.
They don't necessarily reflect FOSDEM, my employer, or the projects that I work on.
And in the course of this talk, there may be images or phrases that offend, but any
such offense comes from lack of knowledge on my part and is unintentional.
So who am I?
I'm Claude Warren.
I am a member of the Apache Foundation.
I've been a member and a leader of cross-cultural teams.
You can see my social media links there.
I'm not on Wikipedia.
That's my father.
And if you look my father up, you will also find a link to my mother.
And if you look them both up, you will find that they went to Northwestern University
where they became immersed in the practice and theory of cultural relativism.
They were students of Melville Herskovitz, who was himself a student of Franz Boas,
who we will get to in a moment, but just tries it to say that both of my parents were cultural
relativists and I grew up in a framework of cultural relativism.
So let's start by defining culture.
Culture is learned behavior.
It's what you learn in your social framework.
So it's what you learn from your family, from your friends, from your school, your city,
your state, your country, they all have culture that influences you and helps you develop your
culture, activities you participate in, any place that people gather, you develop a culture.
So as an example, culture is not that you eat, but what you eat.
On the left here is a picture of a durian fruit.
Comes from South East Asia.
There are signs in the Singapore transit stations that say don't bring this in the station,
don't bring it on the vehicles.
It's an acquired taste, I tried to acquire it, I couldn't.
I'm told that it is just absolutely lovely once you've acquired that taste, but to me
it smells like rotting flesh and I couldn't get past it.
So the second one obviously is a cow.
Most of the people in this room are going to look at that cow and say cow, milk, cheese,
butter, maybe leather, beef perhaps.
But if you're Hindu, that's a sacred animal and none of those things will come to mind.
So let's look at another culturally determined perception.
So it's not that you perceive time, but how you perceive it.
So the Amaya people in the high Andes perceive time that the past is in front of them.
So for about seven generations as they're talking about people, they will speak as though
that person is in front of them and then beyond that time goes left to right.
But this means that the future is behind them.
So for us, back to the future is a great play on words and a fantastic movie title.
For the Amaya, it's the way they perceive time, it's the normal way to perceive things.
So to tell somebody from the Amaya culture to go forward to the future would sound just
as ridiculous as somebody telling us to go backwards to the future.
Okay, so now that we have some idea of the kinds of things that are involved in culture,
let's look at cultural relativism.
So cultural relativism is the idea that you can only understand beliefs and practices from
within the construct of the culture itself.
Now this is separate from moral relativism, which we're not going to talk about today.
Cultural relativism has been used recently to make arguments for the continuation of
human rights offenses on the grounds that are culturally based.
And anthropology, cultural relativism is a means to get outside of your culture and
understand another.
So it's how do you step outside of your culture and get rid of those biases so that you can
understand what's happening in another culture.
But for people who are managing cross-cultural teams or multicultural teams, we can use cultural
relativism as a prism through which we can discover miscommunication and we can discuss
interactions between members.
Cultural relativism was first defined as a, first recorded as a concept by Herodotus,
who was a Greek historian from 484 to 425 BCE.
And he was writing about Darius the Great.
And Darius the Great was a Persian ruler from 522 to 486 BCE.
Darius was inquiring about funerary customs in his empire, and as you can see, his empire
was fairly vast.
Now it turns out that in the eastern edge of his empire, the funerary custom was funerary
cannibalism.
And on the western edge, it was cremation.
And when those two populations were told about the custom of the other population, they
both were dismayed and abhorred the other process.
This is the first recorded case of this concept of cultural relativism.
Now it was established as axiomatic in anthropology in the early 20th century by Franz Boas.
Franz Boas was appointed professor of anthropology at Columbia University in states in 1899.
He is called the father of American anthropology.
And he first articulated the idea of cultural relativism in 1887.
But he didn't coin the term.
That felt of Alan Locke.
Now Alan Locke is a distinguished, is the first African American Rhodes scholar.
He was reviewing this book by Robert Lowey.
And Robert Lowey was a student of Franz Boas and was writing about cultural relativism.
He was a cultural relativist as opposed to a cultural evolutionist, which was popular
in the Victorian era.
And when reviewing this book, Alan Locke was talking about Robert Lowey's extreme cultural
relativism.
And that's the first time the phrase occurs in print.
Okay, so why do we care about cultural relativism?
Well, we care about cultural relativism because the tools that anthropologists and ethnographers
built to understand the culture, we can use to find the friction points between cultures
in our cross-cultural teams.
And those friction points are going to lead to misunderstandings.
And misunderstandings can lead to a cohesive breakdown within the team where people on
the team think they're being undercut or that other people are working against them, sabotaging
their efforts.
It can also lead to a misunderstanding of what your work assignment is.
What is it that we're trying to build?
And if you get that wrong, your app to build the wrong tool altogether and your project
will have high potential to fail.
And as I said, it can cause failure of the project.
So let's look at a couple of examples of cultural relativism in action.
Poplight.
Well, as it says here, with the exception of people with color vision deficiencies, everybody
perceives color the same way.
The light enters your eye, hits the cone, nerves fire, brain gets the message, color.
Except some languages have no word for the color green.
They instead use the color yellow or blue.
So for those cultures that use those languages, stoplight only has two colors.
And the phrase go on green makes no sense.
In Irish, the color of a person is the color of their hair.
Okay?
So Eric the red, okay, he was an Irish, but you get the idea.
If you want to speak about a person of color, so a dark, complexed person, that person
is blue.
So the translation of black lives matter and blue lives matter into Irish becomes the same
phrase, right?
So a distinction that is so important and so prevalent in American U.S. culture is lost
in translation.
So talk about icons, phrases, and gestures are all culturally centered and that is rather
obnoxious, so let me make him stop.
All right, so the thumbs up gesture generally means okay, all good, let's proceed, something
along that line, some sort of approval.
However, in some cultures that is a rude gesture.
In ancient Rome, it was contrary to popular belief, the symbol that the gladiator should
be put to death.
In addition, in online forums, the definition has begun to modify and it is changing from
approval to really a passive aggressive way to shut down a conversation.
So all of this indicates that symbols, the meaning of symbols drifts over time and space.
Now I moved from the U.S. to Ireland a little over 10 years ago and discovered that there
are two countries separated by a common language.
For example, the phrase just about, as in I just about caught the bus.
Now in the U.S., you would say I just about caught the bus, that means I ran after it
and it left without me, I missed it.
In Ireland, I just about caught the bus means I ran after it and my gosh, I managed to get
on the thing and I got a lift.
So they describe the same phrase, both in English, both in the Western culture, describe
two sides for opposite outcomes of the same event.
So idioms are obviously another source of misunderstanding.
So phrases like, there's more than one way to skin a cat, which means there's more than
one solution and is perfectly acceptable in a lot of cultures, but there is obviously
a chance of misunderstanding here, I actually had somebody ask me why would you skin a cat?
Valid question, but I don't know, it's just one of those things I learned in my culture.
And then we'll get to the nodding head guy now, in general we think of that as the nodding
head meaning yes, but in Bulgarian culture that means no, and in fact shaking your head
from side to side means yes, go figure.
Now one more example here is that in some cultures it is acceptable and appropriate to
interject a short word at the end of sentences of speakers during expositions.
So this indicates that you're listening, you're paying attention.
Now in English you can see this when people say yes at the end of somebody's sentence
all the time.
The BBC television show Antiques Roadshow has examples of this all the time.
This is a very valuable place, yes, yes, they know that, but they're just, you know, let's
keep the conversation going.
However, in other cultures that's considered very rude to interrupt your speaker.
My example three, there are words and phrases that are unacceptable in certain cultures.
There are symbols and phrases that it would like to use them here would probably get me
reported for a violation of the code of conduct and derail this entire conversation.
Yet those words and phrases are acceptable in other cultural settings.
So what cultural relativism teaches us is that when in a multicultural setting, if one
is confused or triggered by a symbol, gesture or phrase, one should ask what it means.
So Nelvo Herskovitz, judgments are based on experience and experience is interpreted
by an individual in terms of their culture.
As I said, Nelvo Herskovitz was a student of Franz Boaz and my parents' instructor.
So let's look at a couple of examples of cultural relativism in cross-cultural teams.
I worked on a project where we were transitioning the development from one culture to another,
from one team to another.
Really we're separate cultures.
In the one receiving culture, it was not permissible to show failure.
This was a career limiting move, don't fail, don't show failure.
It was also not acceptable to disagree with somebody who was perceived to be of a higher
rank or status.
And we're trying to do open source development where everybody does everything in the public
so that you can see what's happening.
So this was a problem for us as we're trying to move this across.
And so we came up with a couple of techniques that we used in this project to get around
this problem.
And the first problem was actually understanding what the problem was.
You know, it was like, well, I don't want to check that into the source code control
system.
I don't want to do this.
I don't want to do that.
Why?
Because we just don't do that.
And then you have to work a little bit, you find out what the problems are at the base
and figure out how you can work around this, work a solution.
So what we did was we made it safe to fail, and we exhibited failures on the original
team.
And one of the things we did was, you know, our source code control system, you would
check stuff in any branch, and it would build the branch.
And most of the time, that's going to fail if you're working on a development branch.
So we exhibited that.
We showed you, look, this happens all the time.
All of the developers that have been working on this team, this always happens.
Don't worry about it.
Nobody's going to look at your failures unless you ask them to.
I mean, if you want somebody to come in and say, you say, I can't understand why this
is failing.
Can you help me out?
They're going to come look.
But otherwise, they're going to ignore that.
Don't worry about it.
It's safe.
We pointed out that developers were not allowed to change the main branch of code, couldn't
check stuff in directly to it.
There really wasn't a way to break that.
There were permission controls in place that were going to prohibit that.
And in fact, if you were able to do that as a new developer, come in and put something
in the main branch of code, then you had just found a bug in the permission system and you
should be congratulated.
We showed that all developers were following the same process.
There weren't senior developers doing something different, had more ability to do stuff.
We're developing code and they did have permission to do stuff that was different.
But development of code, development of what the project was always the same for everybody.
We also said that no code would be reviewed unless it was in the version control system.
So this gave us the advantage we're a distributed team.
You got to be able to look at the code and know that we're talking about the same code,
the same lines, all of those great things that people we know about.
And as a secondary effect of this, it meant that when desktops and laptops crashed, we
had the code in the version control system, so a great benefit there.
Nothing really out of the ordinary.
We also made it safe to disagree.
And doing this was probably an anathema to some agile purists here because we made it
so that in the stand-up, we would have discussion and dissent.
And so normally your agile thing is, what am I doing today, what did I do yesterday,
what's blocking me, done.
Now we're going to have discussion and dissent.
And what this did was it meant that the new members were able to see how within the team
we would discuss these issues and we would bring these problems up and talk about them
and that this was okay, it was acceptable and over time they began to open up and to
disagree and to present their perspectives on things and ask questions.
And it really, they became very strong contributors to the project.
And the other piece here is ask the questions and those indelicate questions need to be,
it needs to be acceptable to ask indelicate questions.
And this is because if I don't understand what you've said and I'm trying to understand
that, at some point I'm going to ask a question that to you is going to be rude, not acceptable.
And it needs to be okay for that to happen because we can't figure out where that point
is and what that issue is if we can't talk about it.
So you've got to be able to both ask the indelicate question and you've got to be ready to receive
the indelicate question.
Okay, so the net result here was we established a project culture.
And the project culture wasn't, this is our culture and it's great, it's better, come
do what we do.
It was this is the culture of the project and let's make this work and let's all contribute
to it and we can change the culture and do all of the things that we do.
But make the culture of the project and live by that.
So the second example, this all occurred in western culture and the conversation occurred
on Slack.
And basically there was a conference coming up and I said, what time do the doors open?
I want to know what time do we start and close at the end of the day.
And I was told, oh you go to this website and you'll see the times.
So I went and I said, can't get there unless I'm registered.
If you're not registered, why do you care?
And so my co-workers came to me and said, well that was rather rude.
And I thought, well, all right, yeah, I can see that as it could be rude.
But I had worked with these guys for a number of years.
They're planning a conference, they're under a lot of stress because we're getting close
to the time.
And they're trying to get through all their questions in a day to see, you know, you're
coming in, you're going to get through all the questions, get those answers out the door,
get to the next process.
Let's see if we can get this project done and get this conference running.
So the people I've known for a long time, and to me it would just take too long to say,
I don't see why anyone attending, not attending the conference would be interested in starting
times.
Can you elaborate on why you want to know?
All right.
So yes, that would be a much politer way to say that.
But I understood that they didn't have the time.
So what I want to point out here is that the written word, it is often difficult to understand
what's meant in the written word.
You have no vocal or facial cues, and then I want to point out that those are culturally
based as well.
All right.
So let's look at how to succeed, to find the culture of the project, not just in terms
of words, but in actions.
You want to talk about inclusivity and sensitivity, and you want to do the training for that?
Brilliant.
That's great.
That tells you what to do.
But it's the practice and the execution of the training that builds the culture.
Practice makes the culture.
You need to consider cultural differences when we're talking about discussions.
We're going to have discussions about things.
If you're talking about planning documents, you're trying to do planning for your project,
you talk about use case definitions, you talk about documentation.
Any of those things are rife, fine fields for finding cultural conflicts.
Make it safe to disagree and to ask questions.
Make it psychologically safe to fail.
And the disagreements will surface the misunderstandings before they become, before the misunderstandings.
The failure is a result of a misunderstanding that didn't rise to the level of a disagreement.
So you make it safe to disagree, but then it didn't come up, and then you get a failure
because there was a misunderstanding that wasn't a disagreement.
So you want to explore both of those, in any case.
You want to explore them both as possible friction point between cultures.
So when you see either of those in your project, as you're working your teams, think about
is there a cultural difference that might be contributing here?
So exhibit the culture of the project.
Again, practice builds culture.
I can't stress that enough.
Management has to lead by example.
If I like to say no executive washrooms, do everything in public, failure must be public.
By public I mean, obviously, if you're working in a corporate environment, that's going to
be within the firewall of the project.
Management work items, with the exception of personnel and other legally encumbered topics,
must be in the public within the project.
What is management doing?
What is our goal?
That's really going to help facilitate the communication up and down.
Treat everyone, every objection, every suggestion, every point of view with respect.
Assume that everyone working on the project is working towards success, and never attribute
to malice what can be explained by ignorance or cultural difference.
So in closing, when we're connected to others, we become better people, and the art of cross-cultural
team management is to be a better person.
So if I've offended anyone with any image or phrase during this talk, please accept my
apology and understand that it was unintentional, but also let me know so that I can adjust my
approach in the future.
Thank you.
Thank you, Claude.
That was lovely.
Very much appreciated.
If you are open to taking questions, we certainly have some time for questions.
Oh, dear.
Okay.
Would anyone like to ask a question of our speaker?
Excellent.
I'm headed your way.
I should have spoken slower.
Thank you for a wonderful talk.
I wanted to ask you if you were in a position where you were leading a project or a team
that is very multicultural, and those things also keep changing, you get new people, some
people leave, and it's just a great diversity in the team, how would you approach learning
more about their cultures and what is and isn't acceptable, and then trying to find
a mesh that works for everyone?
Okay.
So the question is, if you're having a multicultural team where people are coming and going, lots
of cultural change from the people that are in the team, how do you find a way to understand
what everybody's culture is and what's acceptable for everybody?
I think to answer the second part, I'm not sure that you can find something that's acceptable
to everybody, that there's always going to be somebody who's a little tweet, I suppose,
by things that go on, but it is being open to realizing that the problem is there, it's
the first part, and then asking questions, and basically I think if you want to talk
about documentation or something like that, then it would be documenting how you are open
to these, how these questions can be asked, and what makes this a safe space to ask these
questions.
I don't know that there is a generic answer that says, this is how you do it, and it works
across everything, because there are just so many differences.
I have lots of great horror stories if somebody wants to come ask, but then they're all different,
and they all have different solutions.
You talked about the challenges that you saw in your projects, where people think in a
very hierarchical way and don't want to engage or interact with someone that they perceive
as higher ranks, and also people wanting to do everything in a perfect manner, and your
resolution to that was to flatten the structure, enable communication, and everyone can fail,
which is a very western way of thinking.
So you try to bring them across to your culture.
Have you ever tried to do it the other way, tried to engage in a project or let the project
go in a more hierarchical way and make sure that people were rewarded on not making errors,
and if so, what were your experiences?
That's a really good question, and yes, it was.
It ended up being a very western way of looking at it.
I recognize that.
I will say in defense of this one project is that we were moving from the western framework
where we were working, and the project was working, and everybody was sort of depending
on the project working, that all of our users were sort of dependent on the way the project
had worked, so there was a lot of pressure to sort of stay the same course.
Have I worked in other, if I think about it, I can probably come up with one, but no, it's
probably the most honest answer.
I haven't had a, I have worked in very hierarchical structures, that US corporate structure works
that way, and that's why I'm an open source, that's about all I can say, without getting
myself in serious trouble.
Hey Claude.
Hey Ferdinand.
Fancy seeing you here.
So you work for Ivan, which is originated in Finland, is there any fun story that you
can share from the very Finnish culture that Ivan has?
No.
Well done, sir.
I saw a handout here.
How do you get from that?
I don't know about that.
Thank you.
I would say, and it's not an exact answer, but in reference to the previous thing, so
in some cultures, like at the meeting, you never actually discuss the thing, all the
conversations happen in one-to-one conversation around the meeting, and you show up the meeting
and the leader says, we should do this, and everyone says yes.
But the meeting doesn't happen until a consensus is already gained, right?
And that's actually, when there's a very controversial decision, I found that to be
like actually a useful technique.
Like I know that if we just have the meeting straight up, like we're going to have a huge
argument.
So like I go and talk to each of the people individually, I try and sort of canvas a solution
so that then when we actually have the meeting, everyone has already agreed.
So that's at least one situation where we can learn from other kinds of cultures and
import that.
Yes.
Yeah, I would agree.
It makes for very short meetings.
I love that.
All right.
Folks, we're going to go ahead and begin to transition to the next speaker.
Thank you.
Greg Claude.
Very much appreciated.
Thank you.
Thank you very much.