Bow, Sniff, Shake: Your Foolproof Guide to Greetings Abroad

My most recent article (“Use With Caution: Hand Gestures Mean Very Different Things Outside the U.S.“) was the top-read article last week on Avaya Connected. There’s only one possible reason, right?


Yes, fear. We’re all scared of making a cultural faux pas, of unintentionally offending a business partner, of burning bridges and, you guessed it, embarrassing ourselves.

Navigating international business cultures can be difficult–almost as difficult as walking in heels for an entire day (stay with me here).

Speaking of heels, flashback to one of my first days on the job at Avaya. After a wonderful, albeit tiring, day of work, I kicked my stilettos off and put my feet up on a nearby chair, preparing to switch into sandals before walking home. I looked over at my colleague nearby and saw… his face aghast, jaw scraping the ground.

My face turned hot, cheeks cherry-red. My feet, I thought, they must smell. As I was debating whether I should go fetch some air freshener, my colleague informed me that showing the bottom of your feet is offensive in Indian culture.

Just as easily as you can alienate someone with a gesture, an improper greeting is the worst way to make a first impression.

Not scared yet? There’s someplace where you should sniff, instead of shake, and another where you should applaud before saying hello. Check out this international greeting guide, for when a handshake just won’t do!

International Greeting Guide

If you’re still looking to improve your international etiquette, check out these five fun facts:

  1. In Japan, a thumb held up alone means five.
  2. The A-OK sign (thumb and forefinger connected) is obscene in Brazil or Turkey.
  3. The deeper you bow in Japan, the more reverent the gesture.
  4. In Germany and Austria, a forefinger held up means two, not one.
  5. In Asian culture, when you cross your chopsticks over your bowl, it usually indicates you’re done feasting.

Related Articles:

How to Explain Cloud Projects to a CFO

As tensions continue to increase in cloud-related discussions at the executive level, so has the importance of effective communication. Much of the debate on cloud investments revolves around one topic: OpEx. It’s understandable why many financial experts seek to avoid OpEx, but the value of investing in cloud services lies beyond this range.

An effective method to bridge this gap is to build a strategic plan, so that you are prepared to let the facts speak for themselves. This method allows for pure business value to be presented, while also giving equal consideration to the weaknesses and challenges faced. Common ground may also be easier to establish when both parties enter the discussion with a clear understanding of the advantages and disadvantages. It’s too easy to let tensions and emotions direct the conversation, so instead present a case grounded in research and thoughtful consideration. The following five tips will assist you in establishing a tested, well-developed plan for cloud implementation.

  1. Gather Research and Data (Know Your Numbers)

    Start by researching case studies that contain TCO (total cost of ownership) and the cost of production for comparable applications. Also consider watching demonstrations to learn how functionality works and how workflows can be implemented—this is pure empirical evidence that companies can try to replicate or expand upon.

    To further pique the interest of your CFO, share data that enumerates how your company will gain a high ROI—this will have the greatest impact on the direction of your conversation.

  2. Consider Feasibility

    Gauge the necessity of the cloud products/services under consideration by analyzing the scale of the project. Develop your own internal criteria based on the particular delivery timeframes, budget, global accessibility, etc. Then compare how your research matches specific project requirements and identify any challenges upfront. Standard guidelines also help to objectively compare applications and ultimately identify the greatest potential benefits. An additional area of consideration is security. There are a number of controls in the area of access, encryption and legal compliance issues, both global and domestic that must be addressed. Although this may seem like a no-brainer, it is often forgotten in the complicated world of cloud considerations.

    In everyday life it’s easier to see the folly in taking on a big endeavor without a coordinated plan. Imagine preparing for a dinner party without knowing how many guests will attend, when they are coming, if they have any dietary restrictions or allergies, and then attempting to cook this meal without a recipe—failure and chaos are expected, if not unavoidable. Luckily, through careful preparation all these mistakes can be easily avoided and the same is true for cloud implementation.

  3. Adopt Standards
    Creating standards is an absolute prerequisite for implementing cloud services, especially when using an agile process. You won’t get the full benefit of cloud if you don’t have standards. Self-service capabilities can be dramatically expanded through the use of standards at all tiers of the infrastructure and application development landscape.

    Examples of these standards include operating systems, middleware, communication protocols, storage access, development tools, development processes, development coding standards, monitoring, alert plans, scaling practices, and even server hardening practices. Additionally, security controls and individual corporate business models are also standards that should be considered. If you are planning a private cloud, ideally you would already have standards in place for the server infrastructure, storage, and networking—in addition to the items listed above. The goal of standardization across an environment is to create simplicity and consistency, which drives automation—the foundation of cloud in an SP-based or private cloud environment.

  4. Create a Prototype Environment
    This experimental approach provides the opportunity to try before you buy and is certain to impress your CFO. A prototype environment serves as proof of concept, which tests if the service is technically and operationally feasible. There are two main considerations within this.

    First is your ability to create and leverage the basic infrastructure as a service, IaaS, offered in your own cloud or that of a service provider. It’s the best way to obtain computing infrastructure without the capital investment. You will be paying for usage on a monthly basis, but ensure it is properly managed so budgets are not exceeded. Again, preparation is key! Get ready to tackle this concern head on and create a plan for how you will manage any issues. IaaS can be a great way to start a development process or even set up a production application deployment.

    Next, determine how it will impact your development process. Two important metrics to track include increased development speed and improvement in the overall cycle of development and testing. This can be achieved by leveraging the standards you have adopted and deployed in your cloud environment, which can be further enhanced by adoption of a DevOps model within your development teams and process.

  5. Think Scalable
    Managing cloud operations is different from rolling out a large capital-intensive project. Cloud services and features can be added and removed dynamically. With proper configuration and standards this can be truly elastic. However, you need to manage within an allocation to ensure you do not overconsume resources and create a negative budget impact. The benefit of it is to spend at the level you need to consume. But you would need to monitor the usage on an on-going basis to ensure that growing the allocation is a premeditated decision with proper budget consideration. Cloud itself cannot be a set-and-forget environment.

    Over time, the benefits of cloud investments compound as infrastructure and labor cost savings are realized through automation, workflow, self-service, etc. So, it’s important to fully seize the opportunity to communicate this tremendous value by directing the conversation to the facts. If you have given thoughtful consideration to the strengths and weakness of these topics, then you are in a better position to objectively analyze the full potential of cloud implementation. This knowledge will let you minimize the emotion of the conversation and develop a strong, well-informed position. With these tips in mind, you are fully prepared to put nebulous cloud conversations in the past.

Mobility: It's More Than Just Apps!

Avaya’s mobility solutions are intended to increase the availability and responsiveness of employees, by allowing them to communicate and collaborate from anywhere independent of location, network, device, or device ownership–while reducing communication expense.

When planning for mobility, consider a strategy that addresses a broad range of use cases:

  • Teleworker: A knowledge worker, task worker or contact center agent who works from home either on a regular or casual basis.
  • Road Warrior: An employee who needs to communicate while in transit, work from a public place or hotel, or operate from a customer or partner location.
  • Enterprise Roamer: An individual working in and around an enterprise facility while not at an assigned desk. This may include individuals moving from a desk to a conference room, a nurse, doctor, hotel- or retail associate that does not use a desk, or a knowledge worker who uses “hoteling” to occupy a temporary office, workspace, or cubicle.
  • Desk Worker: Workers who are not mobile per se, but who benefit from mobility capabilities that allow them to remain in contact with associates who are remote and mobile, and to complement their work with mobile devices while at their desk.
  • Customers: Customers who wish to interact with the contact center through their mobile devices.

Avaya’s strength comes from the ability to support a multitude of use cases.

While some people may fit only one of the personas above, Avaya anticipates that many mobile workers operate across multiple personas. It is critical that the user can shift easily between devices and networks, and that services are available in a consistent manner and contextually-relevant to the device, network and location.

Further, the user experience should be simple, so the technology or communications task flow does not detract from the real workflow at hand.

Stay tuned to this blog for solution ideas to address each of these use cases.

Vishing – Another Form of Social Engineering

Recently, a customer reached out to me and asked me to comment on the current state of Vishing, or Voice Phishing, as it applies to today’s communications environments. Since it is one of my pet peeves, I gladly provided them with a brief write-up on the topic of Caller ID spoofing and the net effect on overall network security. Writing about such things is like walking a very thin line. While you don’t want to educate potential “bad actors” with information on how to perpetrate an event, you need to increase awareness so that others can easily recognize potential threats that fit, or do not fit, a specific pattern or profile.

As communications technology migrates away from traditional carrier network architectures, confidence in Caller ID is dwindling. In a legacy network, Caller ID is typically associated with a specific pair of wires connected to the telephone company end office. The subscriber information for each call is associated with the call event by the central office, and the originating endpoint, in most cases, has no ability to generate or modify this information. Based on this, the information received at the terminating side (Caller ID) was trusted and assumed to be verified.

While this is true for analog endpoints, or POTS lines, the same is not true for VoIP. This new technology brings a twist to the trust factor of Caller ID, as now the origination endpoint (being IP-based) has the ability to define and transmit the Caller ID and name of each individual call session.

VoIP carriers rarely provide any validation of this information, letting it proceed into the PSTN unfettered. This enables the creation of several new scenarios that, before now, were not even possible without complex equipment or access at a deep level in the telephone network. If sent by the originating endpoint, Caller Name (CNAM) information can be transported to the receiving endpoint. Typically it is applied at the terminating Central Office which does a CNAM lookup based on the ANI or Caller ID received. Unfortunately, this can enable a spoofed Caller ID at the terminating endpoint.

Telephone hackers, or “phone phreakers,” can use this loophole to add a level of credibility to their efforts. Using a number of methods, they can easily control whatever Caller ID and CNAM appear, ultimately masking their true identity and adding an incredible amount of credibility to their phishing schemes.

It is a well-known fact that hackers look for and exploit tiny, seemingly irrelevant bits of information and then use that information to build credibility.

Imagine receiving a simple call from a representative of your company’s IT support team that displays a valid, recognizable caller ID.

This new technology makes that hack possible. It creates a veil of confidence that allows the phreaker to extract sensitive information such as usernames or passwords.

Scared? Good, you should be.

What’s even scarier is the fact that there is currently no way to authenticate or expose this tactic, so we must remain alert and diligent. We need to train our employees to immediately recognize and then report social engineering attacks.

There is a lesson in this story. While the hack is simple caller ID spoofing, it in itself is not the sole threat. This is an enabler of an even graver threat: social engineering… and that is difficult or impossible to prevent.