In a recent software development project, for example, I worked with a team of very talented Vietnamese colleagues. At the start of the project, two of them joined me at my client’s site in the US, in order to get immersed in the project.
Part of any project is bringing staff up to speed on the product they’ll be working on, and on the business the product is intended to support. In this case, my client’s product supported collection agencies – whose businesses are complex in ways that can be hard to comprehend for an outsider. So one of our first tasks was going to be giving my foreign friends a briefing on the collection agency business.
That sounded simple, but it proved to be a challenge, because language got in the way. The problem was that the client manager we asked to give the business and product overviews was teaching way too fast for my colleagues to understand. As a result, the briefing turned out to be one-sided. The manager spoke as if every nuance was being understood, and my colleagues struggled to keep up with even the most basic concepts he was describing.
People being people, neither party said anything. The manager didn’t seem to notice that he wasn’t being understood. And my foreign friends, though they asked responsive questions, weren’t willing to say flatly that they needed help. Sounds like people everywhere, doesn’t it?
Talking later with my Vietnamese colleagues, I confirmed that they had grasped very little in the briefing. Since another more detailed briefing was planned, I could see that something had to change. But the options seemed limited, because:
- Detailed knowledge was a requirement of the job
- Only client staff (and not me!) knew enough to teach it
- The client manager did not have the instincts or experience to handle this cross-cultural situation.
I remembered that my Vietnamese friends were astute programmers, and so was the client manager. In other words they had skills and subject matter in common, so it was likely they also had a common language. After a little more reflection, I realized that their common language was that of diagrams and code, the tools of the software developer.
So I coached the client’s manager before his next training session to:
- Keep it simple
- Use only diagrams to convey the key concepts
- Keep spoken language to a minimum
- Confirm understanding frequently, using the diagrams as a reference
During his second briefing I saw few signs of disconnection on my co-workers’ faces. The pace seemed to match their rate of comprehension. And my subsequent discussions with them confirmed that they had fully understood what was presented, and grasped its fundamental relationship to mastering their tasks.
What I want to convey to you is this: though we accomplished much less than the manager originally set out to accomplish in his briefings, it turns out that he was overly ambitious. Much of what he set out to accomplish was unnecessary.
His problem – unknowingly unnecessary ambition – is a common problem in business these days. Among engineers it is humorously pathological – “what’s the problem” is usually followed quickly by “sure, I can fix it”. But in one way or another, we’re all pushing ourselves, our colleagues, and our staffs to overachieve without taking the time to remember our real objectives.
I hope my little story will remind you that there is an alternative. Ambition, while it certainly has its place, doesn’t fit everywhere, and discretion is often the more effective path to success.
Discretion that appreciates our differences and our common ground – well that is golden!
