A Working Multicultural Model: Necessary and Sufficient Conditions

Happy new-ish year. After five iterations, hopefully Analytics and OR folks are moving along a steep and positive gradient toward achieving their 2012 resolutions! If not, apply corrections to get back on track (taking into account the leap year factor).

A 2012 goal for this tab is to explore the human element in OR/Analytics practice. The OR and (applied) applied math workplace is an increasingly multicultural one. There is an increasing exchange of skilled people between countries due to globalization. Even today, many new immigrants and foreign workers continue to be flummoxed by the myriad of seemingly strange local customs, unwritten laws, etc. that confront them upon arriving at the host workplace. These differences result in a special kind of anxiety for the entrant, and to a certain extent, to his/her host, as the two parties seek a working equilibrium to get the job done on time.The challenge for people in such a workplace is to be conscious of and recognize the prevailing cultural differences (including those that we personally judge as 'unpleasant') in an impartial manner, while also embracing the mutually beneficial and useful commonality across cultures. Blindly resolving these differences in favor of either the host's belief system or the entrant's only increases this 'anxiety' and leads to increased stress in the workplace, which can then result in a drop in productivity and morale. Clearly, there has to be a better way to make this work for everybody (and not just a vocal majority).

What are some of the necessary and sufficient conditions that must be satisfied by a healthy, working multicultural model (MCM)? A key-phrase in the corporate and university workplace-playbook is 'zero-tolerance' for discrimination based on a variety of factors such as gender, race, etc. However, this only represents a bare minimum requirement. In the pan-math community, we find pure-math types who can barely tolerate applied math types, or the other way around. In the ORMS world, we will find a few academicians who tolerate what practitioners do, and vice-versa. In the tech work-place, we can spot some science PhDs tolerating engineers who in turn tolerate off-shore developers, and managers who are trying hard to tolerate these PhD scientists, and so on. Putting these people to work together on an high-profile project can be disastrous. 'Tolerance' is merely a necessary condition for a working MCM, but is nowhere close to being sufficient.

The ideas in this post are motivated by the writings of Rajiv Malhotra, a successful (now retired) Indian-American tech entrepreneur based in New Jersey, USA. A fundamental point raised by Rajiv (in the context of inter-faith dialog) is that mere tolerance is insufficient. A key component of the ‘sufficiency conditions’ is mutual respect. Let’s see how this works.

Mutual respect in the workplace already implies the necessary condition of zero-tolerance for discrimination. It then says something stronger: equality does not mean “being the same” or being “western” in thought, dress sense, and food habits. It is not a vector comparison. Two people can be equal and yet very different, like woman and man. If people behaved and responded in a homogenous fashion, there would be little need for revenue management or indeed, analytics. Anyone who believes that it is sufficient to tolerate a colleague who is 'different' should try saying it to that person and stick around for the reaction.

Mutual respect says: I don’t patronize you by tolerating you, I genuinely respect your right to your cultural and religious beliefs, some of which I clearly recognize as being very different from mine, and at the same time, I expect the same level of respect from you for my beliefs; you may well feel your way is “better for you”, and that’s cool with me as long as you don’t bug me to join your 'better' cause since I’m quite happy where I am. In OR lingo, a workplace characterized by mutual respect functions like a ‘KKT point’; expecting something more than mutual respect also creates conflict. Stress due to the invisible and unspoken 'peer pressure to conform' is sometimes an effect of working in an atmosphere (be it a high school classroom or office space) where mere tolerance prevails at the expense of mutual respect.

All this may seem obvious, but 'implementing mutual respect' is not always easy. In the original instance, Rajiv Malhotra tried to replace the much-venerated but ultimately trite phrase “religious tolerance” with "mutual respect for others religious beliefs" within the text of grand inter-faith declarations. The results were quite interesting. To merely tolerate our co-worker's religious beliefs, gender, race, and sexual orientation is to feed a hypocritical feeling of superiority that is likely to manifest itself in our professional relationship with that person at some point in time. A tolerance-based approach works well for finding practical solutions to numerical math problems, but for human relationships, mutual respect is vital. Nothing more, nothing less.



This first post of 2012 is humbly dedicated to Sri Rajiv Malhotra. Thanks, Rajiv ji.

American Airlines Chapter 11: An OR Opportunity within a crisis

The news of American Airlines' Chapter11 may sadden some members of the OR community given their pioneering work in revenue management apart from their amazing impact on the overall ORMS practice in the airline industry. However, this crisis is also an opportunity for O.R. The company will be taking a close look at their business model as well as their more tactical operations and ring in a chain of meaningful improvements. Speaking from a similar 'chapter 11' experience during the last decade, this filing represents an opportunity for OR practitioners that must be grabbed. This situation highlights what this tab has talked about before: having a well trained ORMS team with domain expertise is invaluable and i'm sure AA has retained a lot of their experts.

Specific example
The renegotiation of the existing collective bargaining agreements (CBAs) with various unions is a great application example that can generate significant 'true dollar' returns. OR can be gainfully used to analyze rule changes that significantly improve efficiency while also improving the quality of work life of stakeholders to produce win-win deals. During 2003-2006, OR folks at a similar legacy US carrier were able to quantify and successfully redefine a set of highly complex work rules that ensured better utilization and compensation without sacrificing quality of work life. What's more, such feedback can help prevent CBA negotiations from stalling and win some trust from both sides of the table. In such situations, the management is likely to be more flexible in 'opening up' old rules, allowing the full use of powerful solvers and large-scale optimization models to determine the maximum level of improvement possible by replacing such legacy constraints with more sensible ones. Every  (deterministic) dollar saved during such stressful times is precious and is highly appreciated. In short, Chapter-11 is a time when OR folks on the ground can make their presence felt and directly contribute to the bottom-line. A friend in need is OR indeed.

update: some typos fixed

The Dangerfield Syndrome - To Patent, Publish or Present?

Before we start, as always, this tab entry is purely a product of personal opinion, watching much comedy central, and is solidly based on the wild conspiracy theory (if this isn't dual noise, what is?) It is completely unrelated to any real-world company or university, including the ones I worked for in the past or present. On the other hand, it is well and truly dedicated to every Rodney Dangerfield in O.R. practice (you belong to this club only if you already knew that).

In academia, a professor would be happy to get their work published in a leading peer-reviewed O.R journal and often, this acceptance defines the degree of success or failure of a research project. Almost all new ideas in a university make it to some journal or conference, but very few practical innovations in the industry gain visibility. They are either patented, or remain hidden as a company's intellectual property. At the end of the day, the Edelmans, like the Oscars, are as much (and probably more) a tribute to an organization's upper management for being O.R. friendly, as it is to the guys in the trenches who actually pull off the O.R. innovations.

So how does the common O.R. guy in the company gain peer-recognition? (suggestions most welcome here :-)
After prototyping is done, what does the practitioner do? Sit around tooling, while waiting for analytical support calls ? There are a few choices (or few choices if you have a bad boss), depending on when your next project starts. You can try to patent the most practical approach. After all, in practice, the proof is in the pudding. Or you can publish a non-proprietary version of your findings. A cynic may say that what this really means is that you released an 'unpractical' version, but this not the case - at least not always. Patenting is common place in the IT world, but a relatively less popular option in the O.R. world. A patent in your resume can make you look more 'result-oriented'. A future employer may be worried if he/she observes way too many publications during your past job ("so did u do any real work this millennium?").

On the other hand, if you plan to move on to academia after a while, publishing is not such a bad idea. And it's not bad for a future industry job as well, since it serves as a solid, peer-reviewed reference for your scientific skills. It's also a good marketing and recruiting tool, since your company gains recognition in the scientific community as a place that promotes cutting edge R&D. A good manager would recognize these benefits. A common fear that is unfounded is that publishing = giving away your intellectual property. As long as you keep your engineering ideas out of scope, my own experience is that it can be counter-productive for a competitor to try and directly reproduce a product from a journal paper that appears in print 2-4 years after the idea was implemented in a product (or not). Add to that a couple of years that it takes to go from idea to finished product, and you get the picture. Then you realize that you would have been better off building something for today's customer on your own, rather than relying on recycled ideas.

Patenting versus publishing is a personal choice. Acads are shocked to see frivolous patents. But for every seemingly hideous patent, there exists a new publication for yet another factor-of-2 approximation algorithm for an NP-Hard problem that can be readily 'solved' in milliseconds for real data instances. The answer to the original question is not clear cut. And what about presenting at conferences?

Nowadays, companies count the number of patent applications filed by their R&D group. If such a metric is employed, perhaps patenting should be the first option. This scenario is more likely if you work in a non-traditional O.R. industry, and in such a situation, presenting at a conference can provide visibility and is a nice trade-off. Conference presentations takes up much less time than publishing, and you can get your ideas out there quickly. On the other hand, conference proceedings seem to be valued less in our field. Perhaps practitioners can present more of their work at a dedicated conference. These should be a conference of practitioners, and organized by, and for the benefit of practitioners. That would be wicked. Why the Gettysburg clause you ask? When profs meet, its an conference, but when practitioners and engineers meet, its labeled a workshop. As we all know, when the rocket stays up, it's hailed a scientific success, and if not, its an engineering failure. There's still no respect for 'R&D'.