Emilien Macchi is a Senior Principal Software Engineer at Red Hat. He is French and lives in Canada. He contributes to OpenStack nearly since the inception of the open-source project.
I had the pleasure to get Emilien on Le Podcast to discuss how learning and sharing were essential ways of growing his career in Software Engineering.
We covered many topics: peer reviews, pair programming, remote work (he thinks that collaboration is easier and better remotely). Of course, I also asked what he thinks are the most important things to develop as a coder (spoiler, it is not only technical skills).
In today’s episode, Jérôme Bourgeon and I will explore the question of cultural differences and their influence on the adoption of agile.
Spoiler, we don’t think that cultural differences are the real problem.
Jérôme is an agile coach with Zenika. He is based in Singapore.
Together we discussed:
build trust take a different amount of time
culture of companymatters more than countries (Jérôme used the model proposed by Frederic Laloux in his book Reinventing Organizations)
beliefs of people matter more than anything else
the power of appreciative inquiry and how to use it
accepting differences that are important for people
I am eager to hear your feedback, so drop me a note at alexis@monville.com, on Twitter or LinkedIn. You can also use those channels to propose the next question you want Le Podcast to answer. We can even record the answer together!
Team Agreements are critical to the success of a team. By writing your team agreements, you define your standard. You set the baseline that you will improve in the future.
In the team agreements, you answer the question: How do we behave?
What aspects do you want to cover in your team agreements?
How do the team handle information?
What kind of information do we need to achieve your work?
How do we share the information inside and outside of the team?
How do we know what everybody is doing?
How do the team communicate.
What are the tools the team uses to communicate?
Phone or video conference: why do we prefer phone calls or video conference for some conversations?
Instant messaging: for what kind of message, what time of the day…
Email: do we use emails inside the team or do we communicate using the tool we use to track our work? Do we use bcc?
Do we always reply to all calendar invitations?
When do we want not to be interrupted? How do we signal that to others? How do we handle external interruptions? Do we nominate an interruption handler?
How do we collaborate.
How do we produce documents, code…
When do we use pair programming or mob programming?
Why do we have meetings? What are their purposes?
How do we behave in meetings? How do we handle devices? How strict are we on time? On attendance? On multitasking? On side conversations?
How do we provide or receive feedback.
Do we have a specific time, setup, tools… to provide or receive feedback?
How do we handle conflict?
How do we manage performance?
How do we hire new team members?
The list of questions could be infinite. The practice is beneficial when you start small and when you review your agreements regularly. This is a place for the team to experiment with various approaches and to improve.
For example, with a team in which half the people are collocated and the other half distributed all over the world, we change our way of handling meetings. The agreement is now that we behave as if everybody was remote and join the video-conference from our offices. Why are we doing that? Because we noticed that when the conversation become passionate in the meeting room, we were ignoring the “remotees” that were enabled to have a say in the discussion.
It is also very useful to define team agreements for meetings that will gather people from different teams or organizations. To do that, try the Social Contract, shared on the Open Practice Library.
A book is an opportunity for learning through discussions with others. I already discussed the advantage of a book discussion club, and by offering a book, I wish to have those conversations, with each person. And yes, I am also planning a book discussion club.
When you give a book, some conversation could start surprisingly fast, like last year when I gave “Joy” to colleagues, and one of them told me immediately: “Is there a message? Do you think I make my employees unhappy?”. This conversation took me by surprise and I probably just mumbled meaningless words to try to escape it.
Sometimes it seems that the conversation will never start. So either, you can forget about it, or you can push to have it. Sometimes it is just that people don’t read, don’t read business books, have other things on their reading list, and that’s ok.
With Radical Candor, I had the first conversations quite rapidly. The first one was about the 2 x 2 matrix used in the book. You are up on the vertical ax of the matrix when you care personally. You are on the right of the horizontal ax of the matrix when you challenge directly.
The conversation evolved around the principles described by Dale Carnegie and how they fit the matrix. (in “How to win friends and influence people,” his book first published in 1936, and still reedited today.)
I will take two examples:
Become genuinely interested in other people
Give honest and sincere appreciation
Become genuinely interested in other people, is, of course, an excellent way to demonstrate that you care personally. And, as you can see in the matrix, if you are doing it without challenging people directly, you will fall in the “ruinous empathy” quadrant.
Give honest and sincere appreciation, is, this time, more tricky. If I consider that I will only speak about the positive behaviors that I can see in other people, I will fall in the bottom left quadrant “manipulative insincerity”. If I don’t care personally, and I give honest feedback, I will fall into the “obnoxious aggression” quadrant. If I care personally and that I am honest, this time I can act in the upper right quadrant.
The way you will give feedback is of course key to the success of your message. Kim Scott explain this point with reference to what Ben Horowitz called the shit sandwich in “The Hard Thing About Hard Things” another book that I enjoyed. The shit sandwich is his way to qualify a classic way to give feedback: start with complimenting, then pass the difficult message, and finally value the strengths of people. The problem with the approach is that experienced people will see you coming and each time that you will start with a compliment, they will wait for the difficult feedback.
The point is that if you care personally for people, you will develop a relationship that enables to give and to receive honest feedback without the need to give a not so nice sandwich.
Once, I was in the audience at a conference, and one of my colleagues was giving a talk. The guy is excellent, I love his way of thinking, he can present an appealing overall vision and go deep to the right level of details when it’s appropriate. The talk was ok, and I was frustrated. Why? Because he made basic public speaking mistakes that he could have easily avoided. I wait that the long line of people wanted to thank him, and to talk with him vanished, and I told him: “Great work Steve! I have some feedback, do you want them now or later?”. Steve: “Now would be fine.” Me: “Do you want them direct, or do you want me to dress them up a little bit?” Steve: “I am a big boy, go for direct.” At this stage, I would have gone for direct anyway, and I guess you understood that I cared enough for that.
I will relate another conversation I had about the book in a future article about Rock Stars and Super Stars.
Trust, as a foundation for efficient and sustainable teams, is a recurring topic on that blog. In Beyond Measure, I covered the simple exercise proposed by Margaret Heffernan to initiate a relationship between team members. I tried to nudge you to try The Evolution of Trust from Nicky Case. And, of course, I regularly referenced The Five Dysfunction of a Team, as a must-read to build a team.
Paul J. Zak, the author of Trust Factor, explains how the scientific work conducted on Oxytocin, aka the love hormone, helps to understand how the culture of an organization is working.
You can benchmark your organization on the eight key factors presented in Learning from the neuroscience of trust by answering the 16 questions of the Ofactor Pulse test (I encourage you to read the book and respond to the test when triggered).
Questions are based on observable behaviors, which make them relatively easy to answer. For example, one is: “My leader treats setbacks and mistakes I make as a valuable opportunity to learn and try something new”. From “Strongly Agree” to “Strongly Disagree”, you can find where you stand.
Your overall trust score could push you to dig more, and the full ratings a good idea of where to start investigating the potential changes in your behavior to create the conditions you want.
Trust is the foundation of the human relationship and the foundation of an effective team. I recently shared how our behavior will create or destroy trust in the article The Evolution of Trust, and more about trust as the foundation of a team in the article The Five Dysfunction of a Team.
We could use the 8 behaviors as discussion points with teams to improve our way of working. The question could be, How are we doing on:
Recognize excellence: personal public recognition from peers that occurs immediately after the fact, tangible and unexpected has the largest effect on trust.
Induce “challenge stress”: stretch goal, but a still achievable goal, assigned to a team will intensify focus and strengthen the social connection.
Give people discretion in how they do their work: autonomy and self-organization, is another important contributor, being trusted creates trust.
Enable job crafting: trusting people to choose what they will work will ensure focus and motivation. The author gives the example of Valve, the gaming software company, I recommend their employee handbook to have an idea of how they work, and inspire the conversation with your teams.
Share information broadly: uncertainty and stress undermine teamwork, openness, transparency and daily synchronization are the proposed antidotes.
Intentionally build relationships: encourage people to care for each other will make them happier and more productive.
Facilitate whole-person growth: meet frequently and give constant feedback on personal and professional growth.
Show vulnerability: asking for help, and acknowledging what we don’t know, help to build credibility.
Could this discussion be the Retrospective on Trust for your team?
Looking at how people behave towards hierarchy is not enough to understand what kind of leadership style they will expect. A second dimension needs to be taken into account: attitude towards decision making.
Coming from France, I was making a simplistic association of hierarchy with the top-down decision making and was puzzled by the Japanese who were clearly experts in getting to a consensus while they were still hierarchical.
Of course, generalizing the expected behavior for an entire country is not fine grained enough, and you could expect different behavior from people of those countries.
The key is to understand that hierarchy and decision making are 2 different dimensions to discuss when you are building the team agreement on how you work. And when you are working with teams that are made with team members coming from all over the world, this is key to the success of the team.
For example, my understanding of Self-organization is egalitarian and consensual, and it’s for me the opposite of the top-down and hierarchical approach. The managers and team members, involved in a transformation towards a self-organization model, could struggle with defining their roles, especially if they are more comfortable in the 3 other quadrants.
When forming a team, or starting to work with a team, I usually start with the foundation of a team: Trust.
I even used several times, the book from Patrick Lencioni: The Five Dysfunction of a Team, obviously because the “Absence of Trust” is the base of the pyramid.
I remember playing 2 times, with large teams, a game based on the game theory, and a variant of the prisoner’s dilemma. The effects with one of the team were really great, for the one, where one of the participants betrayed not only the other team but also his own team, the results were not so good, for him and for his relationship with others in the larger team.
So I am always struggling with the idea of bringing that game to build trust, because we could have someone in the group that will betray the others, and after that, it is difficult to deal with it. One of the participants told me one time: “at least, now, we all know”.
The sense of belonging is an important experience to have. Belonging means that we are accepted as part of, as a member of the group, the team, the company.
We want to be part of a team because what defines the team identity is appealing to us. The team is defined by its vision and its working agreements.
When you are building software the open source way, you can identify 3 main categories of team identity:
Upstream project
Downstream product
Jobs to be done
1- Upstream project
The team members belong first to the upstream project. They will tend to prioritize what they think is the best for the upstream project. They will be progressively disconnected from the people that are using the technology they build. They could even miss new needs and be surprised that people switch to another technology that is not so different/better/other qualifiers…
2- Downstream product
The team members belong first to the product they build. They will tend to prioritize what they think is the best for the product. They will tend to forget that building the open source way is a great way to understand why people want to use the technology by confronting your point of view and requirements with those of the other members of the community. The extreme is that they will end up being alone, and disrupted by another product.
In short, the Jobs to be done theory explains why people are making choices, hiring or firing a product or service, by focusing on the understanding of the jobs, the problem they are trying to solve.
The teams that identify themselves to the jobs to be done are stronger because they can work on technologies in the open, curate technologies that they need, invest in new technologies that could replace their current core technologies, without losing their identity. They can envision their solution as a sole product, or integrated into other products knowing that the most important thing is the jobs to be done. They can partner with other knowing precisely what they are partnering on without feeling that they could lose/win something in the partnership. They can focus on their users and solve a specific problem, a specific “jobs to be done” without the temptation to expand the scope of what they are doing.
I guess that the jobs to be done should be the first thing you want a team to agree upon.
