Tag Archives: Team

How do you manage intercultural issues in your teams?

I recently had the good fortune to fly in from Doha to Dubai in a Dreamliner, and later again from Bangalore to Delhi – before they got grounded following a safety advisory. No doubt, it is a marvel of engineering excellence, and I am sure they will figure out battery problems sooner than later.

However, while reading this article “From the Start, Dreamliner jet program was doomed”, I could not help express surprise over some of the issues discussed. While some of the issues reflect a very high-end of engineering being tried out for the first time, and hence some teething troubles could be expected that could be solved by engineering, some other relate to the human aspects, surely not happening for the first time, which perhaps trumped several other issues:

It seemed like the Italians only worked three days a week. They were always on vacation. And the Japanese, they worked six days a week,” said Jack Al-Kahwati, a former Boeing structural weight engineer.

Even simple conversations between Boeing employees and those from the suppliers working in-house in Everett weren’t so simple. Because of government regulations controlling the export of defense-related technology, any talks with international suppliers had to take place in designated conference rooms. Each country had its own, separate space for conversations.

There were also deep fears, especially among veteran Boeing workers, that “we were giving up all of our trade secrets to the Japanese and that they would be our competition in 10 years,” Al-Kahwati said.

None of these are new issues to any student of inter-cultural issues, especially in project management, but what is surprising is that for a program of that strategic importance and such magnitude, these issues were ignored and they eventually came back to bite.

Distributed and virtual teams are a reality of today’s world. It is not just limited to well-heeled MNCs – we see countless everyday examples of such teams with NGOs, startups, voluntary efforts, college project and so on. There is more to working with people from different time zones and cultural contexts than we realize. Problem is, most of us haven’t been exposed to, or adequately trained to handle such diverse teams – not just as a manager but even as a team member. As a result, when there is a need to work with distributed teams, we tend to curl up in our cocoons and shun working with them. It could be due to excessive paranoia due to job insecurity, or it could be due to prejudiced mindset about folks who are ‘out of sight’, especially at a low-cost destination. Sometimes, it might simply be due to sheer laziness. I have once been in a situation where a VP based out of company headquarters wanted to only work with people within his ‘line of sight’ – he hated getting on emails, hardly ever responded to them, and his preferred style was chatting in hallways or at cubicles. Sounds familiar? However effective this strategy might be for his immediate team within a shouting distance, this would lead to his remote teams feeling disenchanted. You might be a great leader, but remember – managing remote teams is also part of your success!

Panel discussion on "Intercultural Issues in Project Management" at Grace Hopper Conference, India, 2012In Dec, I had the opportunity to participate in an interesting discussion at the Grace Hopper Conference, India on “Cultural Intelligence in Project Management”. We discussed some of the personal experiences of a very diverse and highly experienced panel. Some of these experiences ranged from Bangladesh to China, Japan to Israel, and US to Europe and so on.

One of the points I shared was about how to manage inter-cultural teams. This is a big topic and we can spend a day on it and still don’t get it right! In my experience, there is a process that I have developed and refined that works well. Here is how it goes:

  1. Be aware of the intercultural differences – don’t paint everyone with the same broad brush. This is especially important for ‘foreigners’ in your team lest they start considering them as ‘aliens’ in the team! To me, recognition of such differences means respect and that itself is such a motivation for everyone to feel welcomed in a diverse group. In a Chinese company I once worked for, it was common for everyone to be in office till 9pm everyday, 6 days a week, even if there was no work that demanded people to stay back. Meetings would be setup at 5pm and go on until 9pm and beyond. While this was ok for many of the Chinese folks as they were ‘foreigners’ to Bangalore and had nothing better to do in evenings than work at office, this was not so ok for many Indian engineers who had a family. While no one minds occasionally staying staying for work exigencies but everyday was a drain. In that high-performing culture, leaving early for home would be seen as a sign of lesser commitment and effort. While things did eventually get better (at least in my team because I summarily rejected such outrageous ways of ‘measuring’ performance of an individual), it took some time and great efforts to make people realise their intercultural differences that we have grown so subconsciously used to.
  2. Creating common norms – Instead of forcing one set of people to change to another set of people’s preferred way of working, it is much better to arrive at a common way of working, even if that is not the most efficient way of working. Ideally, let the team evolve such norms so that there is a higher buy-in for those common standards of mutual behavior. This will demonstrate tremendous respect for individuals and encourage them to participate in team proceedings that will go a long way in building their individual buy-in and a team camarederie that will set the team on a high-performance trajectory. More than once in my career, I have been involved with diverse teams where simple things like how fast an email should be responded to has been subject of intense debate. We all have different ways to answer them. Some would take the old analogy of a telephone call – just like someone who is physically present is more important than the one calling on phone at their leisure, why should someone sending an email become a priority for me? On the other hand, there are folks who would want to respond to emails within a hour if not minutes! So, what is the best way? Clearly not making everyone answer the mails in one hour, I hope! Let the team discuss this issue and let them come out with common norms such as 24hrs or 48hrs based on what is important for the business. As manager, step in only when you think teams are setting the bar too low, and then also, step in not to dictate your preferred ‘norm’ but to clarify the objectives and provide supporting data and steer the conversation towards why it is important to meet those objectives – teams are smart, they will figure out the rest. For example, if time tracking is a project requirement (either for tracking project effort or for billing the client, or for any other reason), and given people’s propensity to either avoid it completely or do very meticulous time tracking, then it might be a good idea to also identify a common tool, such as a time and attendance software, that makes sure everyone is on the same page. 
  3. Exploit intercultural strengths based on individual strengths – the idea is not to make a rabbit fly or to make a bird swim, but find out who is naturally adept at certain strengths and match their tasks to their strengths. As managers, we don’t want to be parents to the team members, and there is no point ‘forcing’ them to change them to do thing that they don’t relate to (unless of course, that is jeopardizing project objectives). Instead of doing a command and control style management of allocating tasks, managers should walk a few extra steps and undertand what motivates their team members, and if possible, assign them that work. In most cases, that might be a strength they already posses, and in some cases, it might a skill they aspire to possess and might not be the best candidate for it. However, if they can demonstrate that they have taken steps to match their desire to improve their capability in that subject, then as managers, we owe it to them to give them a fair chance. Assigning a mentor as they take up a new task might also be helpful. I once had a great team member who was majorly motivated by helping everyone on the team. Almost each evening as people were winding up their work, he would go to them and chat up with them on their problems and offer voluntary help to stay late and fix it. He would do it in such unintimidating and affable manner that other team members loved it (and I can’t recollect anyone misusing that gesture of benevolence, in case you are wondering). As his manager, the only thing I was supposed to do was just to stay out of the way and cheer him up! He was clearly driven by his own deep passion for the product that we were working on.
  4. Broadbase core strengths – finally, once the team has come to the point where people don’t feel intimated or vulnerable due to their shortcomings but rather feel appreciated for their strengths, it will be much easier to cross-pollinate those strengths among the team members. Since everyone is a mentor and everyone is a ‘mentee’ to someone else at this point, chances are that this won’t create adversarial relations among the team members, but actually stimulate a culture of mutual respect and learning. For example, someone might be an expert with a technology and another team member is great at planning. Once there is a feeling of mutual respect, it will be much easier to make them seek each other’s expertize in furthering their own knowledge.

This four-step process has served me well in multiple scenarios. There is nothing rocket science about it, rather it is based on simple laws of respect to everyone, and that’s why it works. And to me, intercultural is just that – a matter of respecting people for what they are rather than ignoring or ridiculing them for what they are not. After all, we are all perfectly imperfect and similarly different!

How do you manage intercultural issues in your teams?

How does manager’s proximity to team affects team dynamics and decision-making?

Congratulations! You’ve got the long-cherished promotion that will make you manager – of your own buddies! You don’t quite know what it means for your relations with the team – are you better-off as their manager or as their buddy?

One key challenge with first-line managers, especially those fairly new in their roles, is how to strike right balance between formal reporting relationship and informal personal relations with the team. Considering that most people “leave managers and not companies”, this seems to be a critical issue, but seldom discussed. In my career, I have also seen similar issues when people became a second-line manager or a group manager for the first-time – so, this is not a one-time issue.

I have often seen managers who have been promoted from within going all too out to please the team that “nothing has really changed” and they are still the good old buddy that they have known him all along. In their earnest to earn brownie points from their once-colleagues-but-now-team, they behave and act like one of the guys. Nothing could be wrong with it, except when personal proximity limits or blurs their professional judgment, especially when pulling up low performers. At times, I have seen this was the ‘bribe’ such managers were willing to pay to buy their team’s ‘respect’. The team definitely loves such managers (“I drank till 3am last weekend with my manager”, or “We plan to watch movie with our manager this evening”), and the manager also has surely found a way to make peace with his team, some of whom might be secretly jealous of his growth. Sometimes, they also overdelegate, or recommend promotions too-soon for their teams – which could be an indication of the secret guilt or discomfort they carry inside them. Surely, this is not an easy seat to occupy, and with little preparation or onboarding support given to rookie managers, it is not surprising that people find what appeals to them best. Surely, these managers are extremely popular with their teams! I call them Santa Claus – they come to office with a goodie bag, and fulfill their team member’s wishes every day.

On the other extreme end are managers who think it will dilute their no-nonsense macho image to deliver results if they start mingling with the team. They maintain a two-mile distance from the team, and as a result, are not generally very popular, sometimes feared and often ignored from the social circuit of the team. They start moving with the ‘upper crust’. Even if such behavior might help those managers in maintaining a healthy professional-personal balance, sometimes they might lose their ability to influence their teams and motivate them to do that extra bit just to make sure the job is not just done, but is done well. At times, they might not even understand the team’s motivation levels, or their collective decision-making process, or their unappointed power centres, etc. I once had an expat manager who had never written code in his life and was clearly unfit to be a software manager. He regularly ‘bought’ respect and support by ‘delegating’ most of his work to the team. Actually, abdicating his responsibilities was more like it. While he sat in (literally) a corner cabin, the team toiled in a meeting room next door, which was ok – the team members got a lot of additional responsibilities in the bargain. What became a problem was when we ran into some some design bugs during system testing – he came and started getting angry at the team. What he clearly didn’t realize that by ‘delegating’ his responsibilities, he didn’t stop owning the consequences of the decisions the team was making without him! Within next few months, most of us left him and that company. Then I had another boss who was promoted from within as a group manager. While he was some sort of a poster-boy success as a first-line manager, he was all too-new as a second-line manager and without much mentoring on how to effectively lead first-line managers, he started behaving in an autocratic manner. When he wanted us for a quick conversation, he would simply shout names of us lesser mortals from inside his cabin! Goes without saying that none of those managers exist in my LinkedIn network :).

What’s a better approach – sitting with the troops in the trenches and drinking beer till neighbors call the cops, or working from that corner office (or whatever that is called nowadays) and keep a safe distance from the ‘guys’? I guess there is no single universal answer – they come in all hues. Excess on either sides seems like something to be avoided. Also, this doesn’t seem to be a unique behavior associated with someone promoted internally or someone brought-in from outside the company. Newcomers also tend to be equally tentative in their first few weeks – they are not sure of their property rights, the holy cows in the organization, the informal power centrers, and so on. So, while they test new waters, there might be tendency to soft-pedal issues in the beginning. If they act too swiftly and aggressively, they might already make ‘enemies’. If they start weeding out the garden too early, they might not have enough ‘context’ and hence might lack the finesse to do the job well. On the other hand, if they start befriending people and build the right network, they need to invest time – something that they might not have. 

Striking the right balance

What are some of the best practices and strategies you have seen around? Are there some ideas with timeless appeal and culture-agnostic applicability? I am sure we can sensitize new managers on the nature of the beast, but one must read the terrain and decide what is the right approach at a given point in time.

Addressing the issue of “social loafing” in large teams

 Large teams might be inevitable in certain large endeavors, but there are several benefits of small teams. A small team can build and maintain a strong culture and a character that gets better with time. Small teams quickly learn the invaluable skills in teamwork and interdependence that lead to higher efficiencies while ensuring that individual team members don’t end up competing against each other but rather collaborate on the common objectives. Small teams also mean small egos 🙂

One of the biggest motivations of making smaller teams is to provide higher levels of transparency and task accountability to individual team members. A large team tends to hide inefficiencies, both of its structure and of its people. One particular problem in a large team is the problem of “social loafing” – something that is perhaps best described in this poem by Charles Osgood:

There was a most important job that needed to be done,
And no reason not to do it, there was absolutely none.
But in vital matters such as this, the thing you have to ask
Is who exactly will it be who’ll carry out the task?

Anybody could have told you that Everybody knew
That this was something Somebody would surely have to do.
Nobody was unwilling; Anybody had the ability.
But Nobody believed that it was their responsibility.

It seemed to be a job that Anybody could have done,
If Anybody thought he was supposed to be the one.
But since Everybody recognized that Anybody could,
Everybody took for granted that Somebody would.

But Nobody told anybody that we are aware of,
That he would be in charge of seeing it was taken care of.
And Nobody took it on himself to follow through,
And do what Everybody thought that Somebody would do.

When what Everybody needed so did not get done at all,
Everybody was complaining that somebody dropped the ball.
Anybody then could see it was an awful crying shame,
And Everybody looked around for Somebody to blame.

Somebody should have done the job
And Everybody should have,
But in the end Nobody did
What Anybody could have.

This is a great description of how so many ‘obvious’ things don’t get done – either due to miscommunication, or misunderstanding, wrong assumptions, or sometimes just shirking away from the responsibility. One of my best personal examples is working for a community team as a volunteer. I believe working for a community as a volunteer is the greatest way to hone one’s teamwork – if you can get people who are not motivated by money or power or promotions to work together for a job, you can do anything! So, I was part of this team of a really nice bunch of 15-odd people who was required to serve this 400+ families. This so-called executive committee was required to plan social events for the community. What I found was that 80% of the people on this team were there just for the meaningless social prestige. Over 90% of the work was done by just one individual (and I was doing another 5% and rest of the entire team doing the remaining 5%). Those 80% of the people were otherwise regular nice people, but when part of this large team, they could not be counted upon to deliver the goods. We organized some wonderful events, but it was mostly the two or three of us who did maximum running around and the rest of the team just travelling First Class. After a few months, I was ready to quit (I eventually quit that team at the next team election. What I find is that the new executive committee team has very similar effort distribution – so it was clearly not me who was an aberration :)).

In my professional experience, I have been involved in some really large software teams, up to 190+ people on a single product. While these efforts were large and simply required those many number of people, we used small teams, not more than 7-9 people each, to divide and manage the work. Each of these programs was divided into such a number of small project teams, each a self-contained and autonomous unit that could deliver its functionality with minimum external dependency. Small teams have smaller number of communication paths, and allow fostering of meaningful teamwork rather than poisionous politics. It also is a great way to groom technical leadership and managerial expertise in the teams. A large team is no fun for people to volunteer and train for roles and tasks that require building special skills. But a small team must often replicate several skills in each team, and hence is a great way to groom future leadership apart from also acting as a derisking strategy to counter impact of attrition. Agile practices advocate small teams for achieving high team throughput, and the issue of social loafing is indirectly addressed by things like daily scrum meetings where social shame and the feeling of letting down the team ‘forces’ team members to get their act together. An excellent discussion of social loafing can be found here.


Social Loafing is a real team dysfunction not restricted to a given country, culture, society, industry or team size. It has been observed in all types of societies and all kinds of groups. Making the team size small is one of the ways to address social loafing. In the context of software teams, everything depends on how individuals make commitments and live up to them. And hence, it becomes extremely important for a manager to be aware of this team dysfunction and evolve strategies to deal with it. Having a small team with clear roles and responsibilities, and setting common standards for work evaluation are some of the ways that can reduce the extent of social loafing in teams and improve morale and team productivity.

How Agile Practices address the Five Dysfunctions of a Team ?

Since times immemorial, ideas, objects and experiences of grand stature and lasting economic, social and emotional value have been created by men and women working together in teams. Granted that some extraordinary work in the fields of arts, philosophy and sciences was done by truly exceptional individuals, apparently working alone, I suspect that they too were ably supported by other selfless and unsung individuals (in the backoffice, perhaps) who all worked together as a team. Right from the great wars, social upheavals, political resistance, empire building, freedom struggles and forming of nations and protecting its borders to the creation of majestic wonders such as Pyramids, Taj Mahal, Eiffel Tower, Statue of Liberty, Sydney Harbor Bridge or the London Eye and many more, each one of them owes its creation and existence to teamwork. Of course, the scope of teamwork doesn’t exclude simple, mundane and everyday things that are extremely important even though they never make a headline: an activity as routine as tilling the fields, or planning a picnic or even a family function, all involve a team. 

With such profound impact teamwork having on our everyday lives, it is only natural to expect that output of a team is directly impacted by the quality of its teamwork. Unfortunately, this doesn’t happen by having right intentions alone, or by leaving it to chance. Quite often, it doesn’t even happen ! Quality of teamwork is impacted by various factors such as motivation levels of individual team members, levels of trust among team members, clarity of purpose, uniform understanding of the goals, lack of resources, poor communication among the team members, and so on. Thus, it comes as no surprise that appropriate investments must be made to make the team click. However, most often, team dysfunctions affect a team’s performance seriously jeopardizing its ability to perform effectively, any state of art processes or tools notwithstanding. Most software managers lack the ability to detect such deeper sociological smells, thus are unable to deal with its impact. Any superficial response to such problem only makes the task harder to deal with. 

In this article, I have analyzed the team dysfunction model proposed by Patrick Lencioni in his wonderful book, written in the form of a fable in a business setting, The Five Dysfunctions of a Team – A Leadership Fable. In his model, called The Model in the book, he has identified five dysfunctions of a team that affect team performance. These five dysfunctions are not really independent, but interrelated to each other, and build on top of one another…

Read the full article here.

What kind of “Managers stick with poor performers rather than hire new faces” ?

I am sure you have heard it in all versions, subversions and perversions, but one simple universal workplace truth seems to be don’t tolerate poor performance, and if not outrightly eliminate poor performers, do ease them out over a reasonable but fast period of time. The yawning gap between a bottom performer and the top performer is perhaps nowhere more so prominent as in a human-skill based knowledge industry like software. Over the years, various productivity studies still continue to point a gap of anywhere between 1:10 to 1:20 or even more between the top programmer and the bottom one. The exact number doesn’t really matter.

What is important is to understand that success of a software endeavor howsomuch is dependent on very smart people, it finally needs a great team to deliver goods – no task is trivial enough to be single-handled performed by the star performer on a sustainable basis, nor is anyone smart enough to effectively comprehend every bit of information created by mankind. This doesn’t trivialize individual human talent, nor is meant to belittle those huge efforts that make a star performer a star performer. It only highlights the nature of the beast – to deliver a non-trivial piece of software with reasonable complexity and business criticality, one must have a team comprising of team members that complement each other’s skills.

We all know a great team that works like Swiss clockwork doesn’t happen by accident. Throwing a bunch of people together, howsoever individually competent, in a blender doesn’t ensure that the result is sweet juices of creativity, teamwork and performance. Instead, all one might get is a bloody mix of team dysfunctions, bruised egos, competing team members constantly on the prowl to backstab others…and so on.

So, how does one go about building a great team. Having the right intent, high bar (higher than what people believe that are capable of achieving) and zero-tolerance for poor performance is a good start. Often, it is easier said then done. There are also fair arguments that when you build a team six people, you can find the smartest people, but when your team needs sixty people, try doing the same. I have managed three fairly large teams: two of them were over 110+ people and one of them had some 190+ engineers working on really complex softwares such as core routers and SoftSwitch, and I can tell you the mindset one needs to manage such large endeavors of human creativity are radically different from what I would need when working on a six-people teams. For one, there is no way you are ever going to get all smart people with top talent – it is just impossible to hire people of equally hire calibre in such numbers on any team, any place on earth. People often don’t admit it, but I am going to hold on to my arguments. There is always a performance curve (“Bell Curve”) in any random distribution. My favorite quote here is from Mali, our HR Manager at Philips, “There is a Bell Curve even at Bell Labs”. Wider the bell curve, bigger is the gap between the top and a bottom performer that I talked about earlier. In a six-people team, it is possible to cherry-pick team members that leads to a very narrow bell curve. In a larger team, the curve starts to flatten out and widen at the ends. This is not by intent, but because of a combination of various factors:

  • difficulty in finding large number of experienced people with required skills in the given domain
  • you can’t always start with a flat staffing (meaning, achieve 100% staffing in the initial stages of the project) – there is not enough work in the beginning, and during the peak, everyone is stressed out and later in the project, there is overstaffing. A Rayleigh’s curve works reasonably well
  • the bad economics of having an all-star team – even Manchester United can’t get all the best players in the world to play for it – they might go bankcrupt before the kick-off itself !
  • inevitable dilution in hiring standards over time as hiring responsibilities get delegated, often to new managers who might not have the same level of organizational understanding as the original team
  • many smart people might not want to join a large team for the fear of becoming just another face in the crowd !
  • a large project is more like a marathon than a hunderd meter dash, and is often late, forcing people to forgo weekends and vacations for a prolonged period of time. Many people, irrespective of their talent, might not want to get stuck in such situations – so this already limits the gene pool to work on and work with

There are many more reasons, and even if you don’t agree with all of these reasons, it is incredibly difficult to build a large team. Coming to smaller teams, it is similar challenge, and many of the reasons mentioned above might very well apply there. However, when it comes to absolute numbers, I look at it this way: what is easier – raising a loan of $50,000 or $3million ? The fact is, everything else equal, you can almost always go a far better job of building a smaller team than a larger team. But even that doesn’t guarantee scintillating performance by our small team. The fundamentals don’t really change. If any, the stakes are even higher for there no safety nets – the team can’t handle inefficiencies, and probably everyone in the team is a multi-skilled multitasker (as opposed to an individual in a larger team where there is a higher level of ‘vertical differentiation’ and ‘horizontal differentiation’). If one person leaves the team, the impact is far bigger than a similar percentage attrition in a larger team that no HR metric on attrition can capture. And the same goes for low performance – poor performance is far more lethal in a smaller team than a comparable percentage of poor performers in a large team. You would expect a lower tolerance for poor performers in any team, more so in a small team.

And it is for this very reason, that I was surprised to read Managers stick with poor performers rather than hire new faces. It is unbelievable and very shocking that a good 70% among us would rather put up with an existing poor performer than risk a new hire ! I think most reasons there don’t make sense, and I think ‘denial’ as a reason is probably a bigger contributor than is generally credited for. Irrespective, I hope like hell this data is an anomaly. For if it is not, I see more serious challenges ahead. By not getting rid of the poor performers even in these tough economic situations, a clear message is being sent that not just condones, even promotes, that level of performance. The teams are as it is not performing to their potential. Everyone in the team knows who those poor performers are, but the fact that a lower performance is being tolerated clearly send mixed signals and confuses people, especially the committed, hard-working performers. Some among them might feel insulted and likely to leave, thus leaving the team in an even bigger mess. I think managers of those teams are doing the biggest disservice to their organizations: one one hand they are tolerating poor performance and on the other hand, their condoning behavior could be disenchanting higher performers.

With this attitude, I think it surely is going to be one long slowdown. For those companies, surely.