Working with Diverse Culture

When I was an engineer I mainly work with engineers from the Philippines and Japan. When I moved to my new company a few years ago, I started working with engineers from different countries around the world. At some point there were more 10 countries in the team.

As an Engineer, the programming language was our common language of communication. We share our thoughts in code reviews directly online. BUT as a project manager, I have to get information which are not necessarily code discussion and those are the times that can be a real challenge.

As an amateur on management I was lost most of the time. I did have some amazing mentors when it comes to Project Management but they also come from different countries which have different cultural background. Their style is still different and my team is also different. We need to find a balance and create our own team culture. Erin Meyer’s Book : The Culture Map is a lifesaver for me.

I’m not going be to discussing about the book, but how as a team we tackle each challenges and created our own culture.

Communication

What is communication? Well, according to Oxford “It is the imparting or exchanging of information by speaking, writing, or using some other medium”. Simple right? I wish.

When working with people with different cultural background, you need to set the ground rules for communication among the team members. As someone from Southeast Asia, I tend to be on the High-context side of communication. When I was an engineer, I did not to concern myself too much of this. The code speaks for itself, most of the time 😉 . I discuss technical things with fellow engineers based on the requirements and that’s it. BUT as a Project Manager, I need to talk to different stakeholders and most of the time they are not Japanese. Some are more direct than others and they don’t like to beat around the bush. Whether or not they are Japanese or Non-Japanese, I need to be able to communicate the project information as clear and direct as possible to avoid confusion.

BUT let me get back to the team. The leadership of the team was composed of members from France,Australia, Japan and Philippines. A good combination of High and Low context communication style. We cannot let our work/project suffer for lack of communication, so it was decided that when it comes the team will try to be as Clear, Precise and simple as possible (Low-Context). This means that wether the information is positive or negative, it will be shared the same way. Unfortunately, some people are not very good at dealing with Negative feedback (see next topic).

It was not an easy feat, but constant feedback from members and leadership slowly improved the communication style of the team. Of course the leadership have to make sure to set a vision/goal for the team and constantly follow it up. The support of management play a very important role in this as well.

On a personal note, when it comes to work I lean towards the Low-context style of communication but a personal matter, I tend to go back to Semi-High-Context style.

Culture Map, page 39
Low-Context : Good Communication is precise, simple, and clear. Messages are expressed and understood at face value. Repetition is appreciated if it helps clarify the communication.

High-Context : Good communication is sophisticated, nuanced, and layered. Messages are both spoken and read between the lines. Messages are often implied but not plainly expressed.

Negative Feedback

“Mr. XY is absent again? We have a review about his module today. I guess I will have to reschedule this.” This happened more than once already so I escalated to the manager about this situation. During my consultation with the manager, I realized the day before we were sharing project situation and giving the good and bad situation to the team. Each member was ask why they were delayed and how we can find a way to get back on track. I was the only Non-Japanese in the team so we were not even using very direct communication. It was during these meetings that the next day, the engineer will always get sick. I was baffled by this situation and to test a theory, I tried to give him a negative feedback (in a nice polite manner) in our next sharing and sure enough , he was absent the next day.

I cannot call him out on this behaviour because that would be harassment and mean. We were also concern about his mental health. The project requires time and lots of effort since it CANNOT and MUST not be delayed. With the help of the leaders, it was decided to rotate some of the members of the team. It was a risky move for the project but a better option than having someone get sick because of negative feedback or too much stress of the project.

The change was actually a good decision. The engineer was taking less leave of absence, looking less stress and the project was released successfully.

It was an eye opener for me and a really good lesson to remember about how each individual manage negative feedback.

Negative Feedback if not given properly can cause great stress and even mental issue to the receiver. Reaction’s differ from person to person or culture to culture but sometimes, you tend to forget these things as you manage more and more members. One thing I do specially if it is a new team and I have not worked with them before is too set 1-1 meetings and explain that when I’m sharing negative feedback, I’m not trying to be rude or mean. I’m not attacking you as a person, I’m just sharing my observation with regards to the team and the project. But people tend to forget so you have to regularly remind them.

On a personal note, I’m not also very good with negative feedback. I always tend to get into a defensive mode instead of listening with an open mind. It does not make me sick but it does makes me angry and that anger push me to show that person that I can do better. The output is sort of okay but my process is still not admirable I guess :D. It’s still a work in progress for me, one day I will be able to handle it with ease.

I don’t think there is a proper guideline for this but trying to keep an open mind and calming tea always help 😉

Women in Leadership

“You are too aggressive!” The reaction from a male colleague after I was asking him about some project issues.

Looking back , I wonder if my colleague will say the same thing if the person giving him the feedback is a male. His reaction might be different but he left already so I will never know.

BUT there will be a chance that someone in your team will have issues about having women in leadership and it’s a sensitive topic and you will need management support. As a Project Manager, you are not a people manager so collaborate with your Manager or your Team’s manager in case this kind of issue happens.

On a personal note, I don’t like competing for leadership. If someone, male or female wants to lead the team, I will gladly give it to them. My only request is “Don’t come running to me when you mess this up !, Good Luck !”

Know what you are capable of, be confident and say what’s right but politely.

Cultural Background

“Idel-san, in India we usually take time to have some tea and interact with other members.” A colleague suddenly approached me while I was trying to be busy 😀

Me: No one is telling you not to have tea or talk with other people.

This was just a light conversation with a colleague from India who joined the team after about two months. Even the manager who was sitting near me popped in to join the conversation.

We all have different Cultural Background and sharing it with the team is a good way to get to know each other. You don’t need to be best-friends but it’s a good start to understand why a person acts the way he/she acts.

There was a time where a team in Tokyo have a “Weekly Tea-Time” where they spent at least 30 minutes sharing their countries traditional food and a relaxing chat before tackling some work.

Another one is Valentine’s day, even though most of the members are Japanese, we still celebrate it the Japanese way. Meaning the female gives the guys chocolate and by March it’s the opposite.

How does the management reacts to this? No violent reaction that’s for sure 😉

This kind of cultural exchange among the team actually strengthen the bond of each members and made them more comfortable to communicate with each other. With better communication works gets done faster , so productivity goes higher.

I’m not an expert on this subject. What I have written here are based mostly on my experience. A few books that have helped me are The Manager’s Path by Camille Fournier and The Culture Map by Erin Meyer.

I will be working with different more people with different background in the days to come and it will still be a challenge and I will probably be pulling out my hair every now and then because of frustration BUT it’s all part of learning and Learning is always fun 🙂

Becoming a Project Manager

Idel, you have switch to the dark side .

Did I really? If you read my old intro page, I was a programmer or software developer by profession for around 15 years till , as my colleague said, switch to the dark side which is Project Management.

The BIG Question now .. WHY DID I SWITCH??

To say it bluntly, because it was something new for me and a BIG challenge. As a Software Engineer, I don’t have to deal with human interaction. I only need my PC , my code and as long as I have all the requirement needed I’m happy in nice corner of the virtual world writing my codes.

Why Project Management?

One thing I like about my company, is the opportunity to try other career paths. I mentioned to my manager that I was interested in Product Management moving forward with my career. I want to give it a try before deciding on becoming a tech lead.

BUT mid 2016, a project which some of my teammates are working on was in trouble. They needed someone to be able to communicate with the team in India, Tokyo and Osaka. Someone who understands the system and can speak both Japanese and English. It was a temporary thing. One week later, Project Sponsor asked me to be full time Project Manager for the project. It was a scary request since I don’t have any idea about the role itself. My choice was a “YES” or a “yes”. I choose the latter of course.

As Boss Panda mentioned ,” Try Fast, Fail Fast” I plunge head on and I have never looked back ever since.

What skills do you need to be a good Project Manager?

This is the very common question I get and to be honest I don’t have a direct answer. This always gives me a pause.

If you need to understand Project Management : PMP, Prince 2 and so on are all available online. There are also lots on training in Udemy , Pluralsight and so on. You can even get certificates to prove that you have the basic knowledge. I don’t have those certificates except for the one offered in the company itself.

BUT is it enough to say you are a good project manager? Definitely not.

Success of the Project is of course the priority as a PjM BUT how you get there is also important. PjMs are not people manager BUT we need to work closely with all the stakeholders so having a good communication , trust among each member is one of the things we need to established.

We work closely with different managers to keep the team motivated, resolve any conflict. We also need to gather information timely to make decision making faster and accurate as possible. We need to be aware of each member cultural background to avoid stepping or offending someone’s culture.. etc. These are just some the interpersonal skills that I have to cultivate to improve.

You need to find a balance between your hard and soft skills to make sure you are leading the project team in the right direction. In this regards, it’s a constant improvement. I’m constantly learning from all the people I have worked with.

Will I ever go back as an Engineer?

As of this writing, maybe not BUT even though I don’t write codes anymore, I still prefer working with Software Engineers and learning about new technologies they are working.

It’s fun working with different team and different individuals. Being a PjM, I get to be able to do this. It’s not easy, it’s even frustrating and annoying sometimes that you want to pull out your hairs. But at the end of the day, you work together as a team and deliver something good.

What’s next for you?

Since last year, I have joined in-house training group to train employees in Project Management. This was also another challenge which I enjoyed a lot. It was scary, giving training, mentoring members and even giving final reviews. BUT meeting all these people, working with different senior project managers is really a great way to learn. Everyday you learn something new, for now that is enough, who knows in the next few years.

Till then.

The Art of Retrospecting

It’s been ages since my last entry , lots of things have happened. New career, covid-19 and a little bit of traveling.

This post will not be focus on any of my normal topics ; travel, books or sewerage covers, instead it will be a little about work.

A few years ago, I change my career path from Software Engineer to Project Manager and have since tried different framework, methodology or ways to improve the way I handle projects and interact with the team. That story is out of scope for this article and will be shared in the next one. For now I want to focus more on “Retrospective“.

Retrospective is defined as: Retrospective is a meeting held after a product ships to discuss what happened during the development with a goal of improving things in the future based on those learnings and conversations.

How did you get introduce to it?

For more or less than 15 years, I was developing mainly middleware and it was very waterfall. My team was never agile or use the scrum framework. The only time I conversed with my colleague at work was during specification discussion or any Q&A sessions. When I joined my team at my new company, it was the first time I heard about agile, scrum, huddle or retrospective. I have no experience with all of these, so I have to learn fast to understand it better.

How was your first Retrospective Experience?

I had no idea what was going on. I was told to write something I observed on a sticky note. Then there was a discussion about it and it was group together , someone took a picture and made a page in confluence and that was it. I did not hear anything afterwards.

The event itself was okayish. Majority of the members were quiet and barely spoke anything. There are some who monopolizes the conversation. It was not a productive 30 minutes and at that moment I feel that retrospective was just a waste of time.

You said “A Waste of Time”, When or How did your view change?

My team went to different organization changes as well as process improvement which gave a chance to learn different ways of team management, and no I’m not a manager :D. I also had the chance to join different team who are doing retrospective.

The latter was probably the biggest factor. Seeing how other teams communicate, sharing their views and idea of team improvement and actually checking the actions if it was executed properly and what was the impact to the team.

Of course it was not all peachy, I joined some team whose retrospective turned into a ranting and blaming sessions without any productive output.

It all depends on how the team views this event and of course proper facilitation.

Is there a style that you recommend?

It should be based on what the team is comfortable with. There are different style that I have tried over the years which I listed below (Not in specific order)

Spotify’s Squad Health Check – a colleague introduced me to this model which I really like since it helps the team visualize, discuss and assess the current situation and have a focused action plan. Before the Covid-19 Pandemic, I dowloaded the cards, printed it and laminated it for the team. It took several tries but we got used to it and was able to focus on what we really want to improve and set realistic action plans. The team agreed to use this style once or twice a month to get a clearer idea on the results.

Unfortunately because of Covid-19, we could no longer do the face to face version. One colleague got very creative and created a game version in Kahoot (?). As for me, I wanted a simpler version with Japanese translation so I created a survey style using Microsoft . Please check the end of this post for the Japanese version.

Moving Motivators – Others might say this is best for 1-on-1 with Managers and I agree But doing this as a team was actually fun. We did it every month and found out our motivation changes depending on the team situation and maybe personal mood. The team kept a monthly record in one location to see the changes easily. We also shared to our managers to give them an idea what motivates each member in the team.

KPT method (Keep Problem Try) – Historically speaking, this method was made by Toyota for continuous improvement. It’s still very useful and simple enough. It’s a good style for a new team who is new to doing retrospective. BUT as you continue with doing retrospective it can get a little monotonous, so it is good to combine this with Squad health check or any other style.

There are different style of doing retrospective, the team can give it a try and the best fit for everyone and with the Covid-19, it gets a little more difficult to do retrospective but fear not there are ways and I’m sure many teams out there have already used different online tools to continue the team improvement. Miro , Ideaboardz are just some of the online tools that can be helpful.

You share the result to Management?

Definitely. There are actions plans that the team cannot do on its own or requires management support and its up to the leader of the group to make sure it get to right person. But make sure that the members will not be criticized or targeted by the management. Each opinion from each member should not impact their evaluation or performance review.

Do you think Retrospective is important?

Very. A team needs to find ways to always improve, without it the team will become stagnant. Discover the best practices your team have and make sure to continue it. It can also be a chance to say appreciation to each member. Focus on the positive side and find ways to improved. Never resort to name-calling or blaming or you will loose the real meaning of retrospective.

Each team is also different. If you work with a diverse team, make sure to set a baseline so that you don’t step or accidentally insult other member’s cultural background.

Disclamer:

All information here are based on my experience and my personal opinion only. There are lots of books on Agile , Scrum or working with a diverse team. Some of you out there might not agree with me and that’s fine.

I’m not a professional translator (Japanese). The translation below was made with the help of my Japanese colleague who fixed my Japanese grammar :D. You are free to use the translation at your own risk.

Squad Health Check Japanese Version. English Version is here

Delivering Value ・価値を提供する

  • 青 : 誇りを持って良いものを届けています。ステークホルダーも満足しています。 ・ We deliver great stuff! We’re proud of it and our stakeholders are really happy
  • 黄 : ままです
  • 赤 : 残念なものを届けています。恥ずかしいです。ステークホルダーにも嫌われています。・ We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us

Easy to Release ・ リリースが簡単

  • 青 : リリースはシンプルで安全で簡単で、ほぼ自動化されています。・Releasing is simple, safe, painless and mostly automated.
  • 黄 : 悪くない
  • 赤 : リリースはリスクが高くて、大変で、手動でやることがたくさんあって、すごく時間がかかります。・ Releasing is risky, painful, lots of manual work and takes forever.

Fun・楽しい

  • 青 : チームと一緒に仕事をするのはとても楽しいです。・We love going to work and have great fun working together!
  • 黄:悪くない
  • 赤: つまらない。。。。 ・Boooooooring…

Health of Codebase・コードベースの状態

  • 青: コードの品質に自信があります。きれいで、読みやすくて、テストのカバレッジも高いです。・We’re proud of the quality of our code! It is clean, easy to read and has great test coverage.
  • 黄: リファクタリングした方が良い
  • 赤: コードはすごく汚くて、技術的負債はもう全然手に負えません。・ Our code is a pile of dung and technical debt is raging out of control.

Learning・学習

  • 青:いつでもたくさん面白いことを学んでいます。・We’re learning lots of interesting stuff all the time!
  • 黄:学ぶ時間が少しあります
  • 赤:学ぶ時間が全くありません。・We never have time to learn anything.

Mission・ミッション

  • 青:なぜ自分たちがここにいるのかを正しく理解していて、ワクワクしています。・ We know exactly why we are here and we’re really excited about it!
  • 黄;聞いた事あたが、あまり認識していない
  • 赤:ハイレベルのビジョンや目標もなく、なぜ自分たちがここにいるのか全く分かりません。ミッションは不明確だし、モチベーションもあがりません。・ We have no idea why we are here, there’s no high lever picture or focus. Our so called mission is completely unclear and uninspiring.

Pawn or Players・駒なのかプレーヤーなのか

  • 青:自分たちの運命は自分たちでコントロールしています。何を作るのか、どのように作るのかを自分たちで決めています。・ We are in control of our own destiny! We decide what to build and how to build it.
  • 黄:気にしない
  • 赤: 私たちはチェスの駒のようなただの傀儡です。何を作るか、どのように作るかに意見を出すことはありません。・ We are just pawns in a game of chess with no influence over what we build or how we build it.

Speed・スピード

  • 青:本当に素早くやり遂げます。待つことも遅れることもありません。・We get stuff done really quickly! No waiting and no delays.
  • 黄:普通
  • 赤:何も達成できていないように感じます。行き詰まったり、中断したりし続けています。依存がたくさんあるため、作業も進みません。・  We never seem to get anything done. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies.

Suitable Process・適切なプロセス

  • 青:働き方はぴったり!・Our way of working fits us perfectly!
  • 黄:まあああ。。普通
  • 赤:働き方は最悪!!・Our way of working sucks!

Support・サポート

  • 青:必要なときにはいつでも素晴らしいサポートやヘルプが得られます。・We always get great support and help when we ask for it!
  • 黄:たまに
  • 赤:助けを求めてもサポートしてもらえないので、行き詰まったままになります。・ We keep getting stuck because we can’t get the support and help that we ask for.

Teamwork・チームワーク

  • 青:素晴らしいコラボレーションを備えた楽天のスーパチームです。・We are a totally gelled super-team with awesome collaboration!
  • 黄:特に気にしていない
  • 赤:他のチームメンバーのやっている事には興味がなくて、気にもしないメンバーの集まりです。・ We are a bunch of individuals that neither know nor care about what the other people in the squad are doing.