Whose English is it Anyway? [Kimberly Wiefling]

My work takes me from my home in the San Francisco Bay Area, where more than 50% of the people living here don’t speak English at home, to Japan and elsewhere around the world nearly every month. I have the distinct honor and pleasure of working with people from all over the world, and recently had an incredible adventure with 37 people from 12 different countries who all came together as a global team to propose the future direction of their company. It’s an incredible experience to work with such a diverse group, and a heck of a challenge due to the most basic of reasons – we all speak different languages.

Even though all members usually speak some version of “English”, it might as well be Klingon. There’s the traditional British English, and many more, including Australian English, New Zealand English, South African English, Canadian English, English of “the islands”, African English, Singapore English, East Indian English, as well as heavily accented versions of Spanish English, German English, French English, and the worst of the worst – American. Without modifications, or an interpreter, no sustained meaningful communication is possible among these disparate groups.

If you’re a native English speaker, working in a global team, you need to stop speaking English. Stop speaking YOUR English, that is – if you want to understand, and be understood by your colleagues. Delving a bit more deeply into the various versions of the so-called “shared language” called English based on my own personal experience:

Americans – Strictly speaking you don’t speak “English”. You speak “American”. It’s different. Just listen to someone from New Zealand speaking English and you’ll know exactly what I mean. Or catch a couple of idiom-laden blurbs of British English from a person from the UK. You won’t understand what they’re saying, and they’ll be horrified when you start talking about your“fanny pack”.

UK People – For people who didn’t grow up with British English as their native language, no one will have a clue what you mean when you start complaining about the “tallback” that delayed your arrival at work.

East Indian Colleagues – As an American Native English speaker, I reluctantly admit that I can’t understand more than 70% of “Hinglish” because the emPHAsis is on a difFERent sylLAble than I am accustomed to.

Singapore – “Singlish” is musical and beautiful, but – unless I watch your lips every moment, and assure that my attention doesn’t drift in the least – I can only understand about 50% of what you are saying.

Australians – It’s not as bad as listening to someone from Texas or Georgia, but it’s pretty tough to understand you, mates!

New Zealand Colleagues – Really, I get such a headache focusing on what you are saying that it makes the Australian accent seem almost easy to understand. As I mentioned previously, listening to you is not quite as challenging as understanding people from my own country who hail from Texas or Georgia, but it’s pretty darn demanding.

There are other examples, but you get the idea. I don’t want to beat a dead horse (sorry, I couldn’t resist).

The former CEO of ABB, Percy Barnevik, stated that the official language of the company was “bad English”. I almost agree, but I reject the negative connotations of “bad English” in favor of “Global English”. And a CEO of a Korean company advised his people that it’s more important to speak badEnglish than good Korean.

Although I’m sure that most people assume that they are perfectly understandable to others when they speak English (especially my American colleagues!) in my experience they all might as well be speaking entirely different languages. The solution is not to speak English. The solution is for ALL of us to STOP speaking English and START speaking GLOBAL English.

I’m not a linguist, but here’s a few things I’ve learned about effective communications among global teams:

- Do your L.A.P.S.s.s.s!

• Loud – Speak loudly so people can at least receive the soundwaves.


• Attention – Make sure you visually make contact with the person you’re talking with before starting to speak to them. Eye contact varies greatly across cultures, and can be uncomfortable, but is critical to beginning a conversation.


• Pause – Many non-native English speakers are “translating in their head”. Although not ideal, it’s a reality that they will need a few seconds to grock (sorry!) what you said.


• Slow – Speak slowly . . . painfully slowly. Imagine you are speaking in molasses, then slow down even more.


• Simple – Use simple words. Native English speakers use over 5000 different works, but non-native speakers use something like 500 – 1500. Don’t go showing off your vocabulary if you want to be understood.


• Short – Short sentences. No long-winded phraseology, with obscure references to previous clauses.


• Smile – If they can’t understand you, at least they’ll like you!

- No idioms, slang, obscure references.

- Don’t never use no double negatives!

In my experience, it’s not just European, Asian, South American or African people who need to change how they communicate. EVERYONE needs to adopt Global English in order to assure that 21^st century global company teams can understand each other.

STOP speaking English. If you are a so-called “native” English speaker, DEFINITELY stop speaking English! START speaking GLOBAL ENGLISH. It’s better for you, it’s better for your colleagues, it’s better for your company, and it’s better for your business profitability.

If we truly are going to realize the dream of a global economy where we collaborate across time zones and cultural boundaries for mutual benefit, we ALL need to change the way we communicate. Let’s not wait for “other people” to change so that it’s easier for us to communicate. Let’s all share the responsibility for improving communication and moving toward a truly global economy.

It’s in ALL of our best interests to make the pie bigger instead of arguing over who gets the crumbs. That win-win scenario begins with speaking a common language, and it's not as easy as just saying "English". It's GLOBAL English. Give it a shot (sorry again!).

Originally published on CareerShorts.com where Kimberly has been invited to contribute blogs periodically on global leadership and project management.

More...

Project Manager Meets The Steering Committee [Glen Gage]

Situation: You, the project manager, have just been called to represent your project at the next IT Steering Committee meeting, a meeting that includes the CEO and is held once every three months.

It can be daunting to be called before a group of 'C' levels, VPs and other executives when you aren't used to it. When you are used to it it's even worse because any naive thoughts you may have had of a group making reasoned business decisions based on open dialog and fact have long since evaporated. Steering Committees are some percentage true to their charters and the other percentage a hot bed of corporate politics. The percentages vary from company to company and within companies, from month to month.

Your first thoughts upon receiving the invitation were mixed--pride and fear. Good. Appropriate. The devil on your left shoulder whispered in your ear "Don't worry, it's no big deal. You know what's going on in the project, just relax and go to the meeting. They just want to tell you what a good job you're doing." The angel on your right shoulder whispered "This is a big deal. Get prepared, thoroughly prepared."

The first thing you did right when your manager told you your presence was expected at the next IT Steering Committee meeting was to ask why. When the answer was vague (your manager isn't on the committee) you did the second right thing, you arranged a few minutes with the project's sponsor (who is on the committee) to find out why and ask a number of other questions.

The answer to 'why' might range from "Project Managers are invited randomly so that they get the experience of executive level dialog and exposure to the management team. It is all a part of our employee development program" (not likely) to "This is a critical project and not everyone feels they have a handle on it." (whoops, is your communication plan not working?) to any number of reasons. The important thing is to find out why they want you there so that once you are there you can satisfy them.

I'll tell you now that you performed well because you listened to the angel on your right shoulder and because you knew in advance not only why you were invited, but what senior executives want in general.

What do they (Executives) want in general? They want the project finished and the benefits on which it was sold accruing. You and others may want the project for the project itself, after all its your job for the moment. They don't, it's a means to an end, full stop. What they want from you: competence, in control, working to achieve the benefits for the company promised by the project (vs. the details of the project.) Be aware that they look at project managers as commodities. One PM isn't working swap another in. It can't be that hard to learn MS Project, right? I don't think this way but most of them do.

Let's look back on your performance and see why it went well...

The sponsor told you you were invited because Sales was questioning the importance of the project, especially in light of the recent three month delay. You also found out where you were in the agenda, who else would be there, what they thought of the project, how to dress, how early to show up, the fact that it would be a good idea to have a few slides to show and a hand-out, and that your sponsor was a good guy and would support you. Then you were on your own.

You prepared your message and you visualized the end result. You practiced over and over in your mind driving to work. You did a dry run with your spouse. You prepared simple materials to hand out--bullet points and pictures, the detailed information planned for verbal delivery, detailed documentation written in case you had to distribute something. You made sure your project binder was up-to-date and indexed and you brought it to the meeting.

During the meeting you kept your cool and always appeared attentive and interested, but never cock-sure. You watched the body language.

Here is what happened:

You were introduced by the chair, the CIO. You had barely started when the VP of Sales interrupted. "These damn IT projects are like the pork and barrel Congress. Full of fat and low on delivery. For example, look at functions 12.1.4.5 and 12.1.4.6, if I can navigate this requirements spec properly! Where the hell did they come from?" You wanted to say "Then why did you sign off on the requirements document, you monkey?" but you didn't. Instead, you went to your project binder, found the data, and were able to say "Those functions were proposed by Mr. Bell A. Whistle at the user workshop held in Atlanta last month. The full group approved them as items with significant business benefit but not essential for version one. The development cost was estimated as low so they were included in the User Requirements Document for version 1." Then you stopped talking. Good, you answered his question. Everyone knows the Sales VP signed off and everyone knows he was represented at the workshop.

You continued with your presentation. The delay in your project was due to a change request from Sales that took several weeks to clarify, and this was your next topic. Your sponsor had coached you on how to phrase this part of your presentation. After your brought up the delay and why, the room went nuts--finger pointing, accusations, red faces. You did your job, you stayed out of it. As project manager you need to navigate politics, but it is not your job to resolve it, certainly not at the level you saw being played out before your eyes. You soaked it all in and kept an expression that communicated interest and professional concern. In fact the argument had little to do with your project.

When the dust settled you had an action item to modify the functionality of the software slightly and the direction that if the supplier gave you a hard time you should refer them to the sponsor. You began to finish your presentation but it was clear from the expressions in the room that the reason you'd been invited had been taken care of. You asked if there were any questions. There weren't. You thanked everyone and went back to work.

End note:

This little tale had a happy ending. Sometimes it doesn't, and sometimes there isn't anything you can do about it. In my tale there is an assumption that your project was approved because the steering committee 'power field' leaned toward supporting it. Sometimes, very rarely, but in my experience, projects are approved to discredit the sponsor. If that had been the case in my tale above you would still have survived because everyone (who counts) would know why your project was crushed, and everyone would respect the fact that you kept your cool and professionalism.

-------------------------------------------------------------------

Mr. Gage is an independent consultant with extensive international and cross-industry consulting and line management experience. Getting the highly unlikely done is the hallmark of his career.

Mr. Gage teaches a variety of project management classes in partnership with Fog City Consulting. These classes count toward Personal Development Units (PDUs) with the Project Management Institute (PMI). Links to these classes can be found on his web site https://sites.google.com/site/gageinnovation

I would love to hear from you. If you found an article interesting or not, please comment. Thanks in advance!

Contact information for Mr. Gage can be found on http://www.linkedin.com/in/glengage

Article Source: http://EzineArticles.com/?expert=Glen_Gage


More...

A Journey of 1000 Miles is Still 1000 Miles Long [Rich Mironov]

It's easy to confuse actual progress with intentions to make progress.

Why point out the obvious? I've just come out of another agile conversation where prospective clients confused "we want to build better software faster" with "we hope that some new processes will instantly catch us up on years of slipped deadlines and missing features."

So paraphrasing Confucius, "A journey of a thousand miles begins with a single step, but is still a thousand miles long. Even at twice your normal walking speed, be prepared for a very long slog."

For context, nearly every software development team would like to be more productive, ship better product, and be innovative. Almost by definition, though, those with the biggest productivity issues are the furthest behind - with months (years) of unmet customer requirements and technical debt. Shovelfuls of postponed promises piled in a heap. Which means that calls for better development processes are usually in the context of big, ugly backlogs and long-suffering customers.

So the unstated question in these meetings is "how do we catch up to where we were already supposed to be? Can a better process (in the future) also erase our previous shortfalls?" Stated that baldly, it seems naive. Yet the emotional logic is very real. Everyone wants a fresh start, a reset, a mulligan. Surely an outside expert or shiny new process will catch us up. Or not.

So What Do We Do Now?

Consider a hypothetical software team that sporadically ships product, has run up a stack of technical debts, missed some customer commitments, and needs a series of process improvements. Business needs are pressing, so there's no option to halt development for a radical retooling.

You might try some combination of these:

Pick one small thing as a demonstration, and make it successful. For example, if we're having trouble planning and estimating, then identify one very small project for careful planning and estimation. Focus the team on completing just that - mostly on time and reasonably on spec. This becomes our existence proof for improvement: having done a better job once on something small, we can do it again. (After all, a journey of a thousand miles...)

Ruthlessly prioritize. There are years of backlogs to address, and our newly hopeful development team can still only handle a few items at a time. Make sure that the next handful of small improvements are truly the most important. For everything else, 'nice to have' translates to 'not this year.'

Don't confuse small with big. As soon as a few tiny things start arriving on schedule, internal stakeholders will be lobbying for massive overhauls. ("If the engineering team can rewrite a report in a week, can't they re-architect all of our business processes in a month?")

Be transparent. Explain your 'do one small thing right' strategy to all internal stakeholders. (To be fashionable, you can call it 'agile.') Remind everyone that we still have 998 miles to go, but we're picking up the pace.

Share small improvements with customers. They are likely to be hungry for any good news, and eager for you to succeed. Gather some applause for your team. Customers don't really expect you to fix everything at once, but need some sense of progress.

Do your math. If we have two years of backlogs to work through, and we double our development speed, then it may take a year to catch up. Avoid magical thinking.

Celebrate the positive. Regardless of the starting point, your teams need a sense of progress and optimism. Highlight small triumphs, applaud people who are doing the right things, divert attention from yourself.

And wear comfortable shoes. There's a lot of walking to do. Because Confucius also said that "no matter where you go, there you are.

SoundByte

Find some improvements that you can make now, and establish a trend. Most long-term issues are solved with incremental changes and successes, not through one big fix.

Crossposted at http://www.mironov.com/1000miles/

Rich Mironov is a serial entrepreneur, product management thought leader, and agile “product guy.” He’s the author of The Art of Product Management, and writes about software, startups, organizations and technology customers at www.mironov.com .


More...