The Challenges, and Opportunities, of Managing a Global Workforce. Part Three, Opportunities and Solutions

This is the third installment of a three-part series on managing a globally distributed workforce.  In part one of this series we covered the challenges of time zone and in part two we covered language and culture, both in the sense of national culture and engineering culture.    In this third and last part we are going to cover the opportunities that managing a global workforce brings us as well as some of the ways to overcome the challenges. 

I do want to note that it will help to better understand what is written below if you’ve read the first two installments in the series as I won’t be able to recap the first two parts in part three without making the whole article too long to be a quick read. So, with that out of the way lets dive right in.

In part one we covered time zones where we defined three primary ways of how people on global teams work.  Time Shifted work, when one location will work the business hours of the primary location.  Overlap Time, when both or one of the teams work a little bit later or come in a bit earlier so that there is some/more time in each day when both teams are working at the same time.  Local Time work, when each team works their local business hours. 

In the three approaches, the primary challenge is always going to be communications; it does not matter if you are working the same hours or have no hours in common.  People are just not going to be in the same room no matter what.  Therefore, the way to overcome the challenge is to be regimented and flexible at the same time.  I know this sounds contradictory on the face of it but stick with me as I explain.  Regimentation means having a set of standing touchpoints and meetings around specific tasks and agile ceremonies.   Aside from the standard daily Scrum meeting for each of the dev teams you must also have a predictable schedule of all of the other standard Agile ceremonies (or whatever other ceremonies and meetings are defined by your preferred SDLC) and you must always have them.  These need to be part of the core rhythms of the teams and should be the beat that they set their lives to.  I recommend having the scrum meeting schedule be the same time of day and day of week for each team the entire year and scheduling the rest of the agile meetings at the beginning of each quarter.  This means that your backlog grooming, planning, demo, retro, Scrum of Scrums, etc.  meetings should never be a surprise or a last-minute thought that will lead to scheduling conflicts and less than full participation.  Supplement these meeting with whichever other meetings your team needs to have on a regular basis.  On my team for example we also have a weekly design and whiteboarding meeting where we, as a team, actively design, architect, troubleshoot and creatively ideate.  In times of need we also have a standing troubleshooting and bug fixing meeting every morning to ensure we are focusing on resolving whatever crisis may have come up.  It does not matter if it is a new security issue (anyone remember the Log4J fun a few years back?) or just a bad release that has to be salvaged.  I also recommend having a quarterly planning meeting as a team to ensure that we are all on the same page for the upcoming quarter.   Some of these meetings are going to be within each of the global teams and some are going to have to be cross team.  So, if you have a team in Manila, one in Glasgow, and one in New York each will have its own separate calendar with all of these meetings but they all need to be happening at the same time so we are all working to the same rhythm.  All of your teams also need to be on the same sprint cadence, release windows, and quarterly calendar!  I know the above might sound obvious, but ask yourself how many of you work like this and how often have you seen this done, and I mean the whole thing, not just parts of it.

Ok, so that was the regimented part, what about the flexible part?  The flexibility comes in knowing when to change the preset schedule if it is needed.  Let’s say that you are taking care of a Log4J scale issue, you are going to have to move things around to let the team focus on this critical vulnerability, but you need to do it in a way that keeps the team rhythm in step across all of your teams. Flexibility also comes in on the personal level.  While many of these meetings are going to be within a single team location, some are going to involve meting across teams and global locations. For these types of meetings, it is crucial to identify the key participants, you don’t need everyone on the team to stay up way past a reasonable hour or get up egregiously early, so you must focus on who the key participants are.   It is also crucial that, if at all possible, it not be the same few people, because if it is you will burn these people out.  You must take turns.  All of the meetings that need cross global team participation should not always be at the convenience of the home office. This will engender a culture of us and them!  I suggest rotating the time of the meeting, sometimes it’s your 9PM and sometimes it’s your 9AM.  Always lead with empathy and put yourself in the place of the folks offshore when making these scheduling decisions.    

Finally, email and chat vs Jira and Confluence.  Email and chat are great communications tools, although as our workforce gets younger you will see a stronger preference toward real-time chat vs asynchronous email communications.  They are an effective way for teams to communicate without having to be in the same room or time zone, but you must not mistake them as a way to document, manage or track your work and projects.  The team must use dedicated tools for all feature, bug tracking, issue resolution, story, specification and clarification related communications.  It all has to be in the Jira ticket and Confluence Story, or whichever your tool of choice is.  You do have specific tools for this, not just docs and email, right?  By ensuring that we are all putting all of our thoughts and decisions into these documentation and tracking tools, we ensure that there is always a single, undisputable, source of truth.  Oh, and by the way, always make sure that you have version control turned on so that you can track the history of all changes, this also helps to ensure that there is no confusion as to who made what changes when. 

Language is an interesting concern as most of the offshore teams will already speak English with varying degrees of proficiency.  The challenge is not in the words but in the nuances of the words and the clarity of the concepts that are being communicated.  In other words, did you get your point across effectively and does the team really understand what you need them to do? The way to mitigate this is by having truly multi-cultural teams in the home office, not just in the engineering team but also within the business teams writing stories or giving specifications.  Having team members from different nations and cultures, especially if they already speak more than one language will multiply the effectiveness of your communications by several orders of magnitude!  The second language spoken does not have to be the same language spoken by the offshore team, it is enough that people in the home office team speak a second language because they understand the issues in communicating effectively in two different languages.  I am a native speaker of Spanish, I was born in Chile and migrated to the US as a child, but because English is my second language I understand, instinctively, that what makes sense in English does not make sense in Spanish.  Whether in terms of phrasing, word choice, colloquialisms, idioms and parsing of sentences.  The off shore team may speak English but they might not think in English and they might not understand the implied meaning of what you are communicating.  Also remember that they might have learned British English, which does have some differences from American English.  Although, admittedly, this is not as common as it used to be.  Even if you don’t have a native speaker of a second language on the team it will still make a huge difference to the effectiveness of your communications if you have a team composed of many cultures and world views as these people will be used to thinking in different ways than would a monocultural team.   

Lastly let’s talk about culture. And by culture, I mean the engineering culture of the team and the national culture of the team.  Let’s start with the engineering culture.  There are many influences that will contribute to the culture of an individual engineering team ranging from the way they are educated as engineers in university to what the team dynamic may be.  Some teams will be proficient at solving many small tasks quickly and some may be better as solving complex technical problems or may be better at long-term, large-scale systems thinking.  The opportunity for you as the manger is identifying what that team is best at and then letting them do that one thing that they are best at.  Do not, under any circumstances, try to force every team to be the same cookie cutter thing. You will not be successful and you will frustrate the team.  Teams and individuals, especially engineers, are not interchangeable cogs. You, as the manager of those teams, need to understand what each of them is best at and let them focus on those areas. Yes, needs must, and at times we just need to “get things done”, but this should not be all of the time and you must expend the effort to at least let people do some of what they are best at and love most.  A satisfied, happy, and fulfilled team is a productive, stable team.

Understanding national culture is just as important as any of the above in ensuring the success of your offshore teams.  We, as Americans, can be very direct, some would say confrontational.  But that is not the same in many other parts of the world.   You must understand that it will be difficult for some teams to disagree with you; or push back on an unreasonable deadline or request; or decline work on a task that is given by a person of authority.  You must ensure that the team knows that it is not only acceptable, but it is required and expected, to ask for clarification or try to negotiate a deadline or even to decline work if it means that we are achieving the larger goals for the company and achieve roadmap success.  Understand that to get to this level of trust and communication is a journey and that trust and respect must be earned by you as the manager or person of authority.   

Thank you for hanging in there with me through this rather lengthy series, but I felt that it was an important part of my experience to share.  I can probably write another three or four pages on the on the topic of time management across teams but if I do this is going to get way too long.  As I’ve mentioned before the point of these articles is to hopefully get you thinking about things that you may not have previously thought much about, not to tackle the subject in depth.  Although at this point, I am seriously thinking of turning these articles into a book as I feel that each one that I’ve so far published has so much more to say.   I will probably revisit this topic sometime next year as there is still much to be said here, but for now I’m going to move onto language and culture. 

This will be my last post for this year as the holidays are coming up and I will be focusing on spending time with my family.  I wish you, your families and your teams a very merry holidays, prosperous new year, and may next year be better than the last.

See you next year!

Marcelo