Wikipedia defines the word ‘geek’ as
‘…a slang term, noting individuals as “a peculiar or otherwise odd person, especially one who is perceived to be overly obsessed with one or more things including those of intellectuality, electronics, etc.’
But wait, it gets better…
‘…Formerly, the term referred to a carnival performer often billed as a wild man whose act usually includes biting the head off a live chicken, bat, snake or bugs.’
Mercifully, I do not remember ever biting off or wanting to bite off ‘the head of a live chicken, bat, snake or bugs’. However, I do remember many incidents that would make me eligible for the more contemporary definition of geek.
For instance, approximately a few gazillion years ago, I remember sitting in front of a fat cathode ray tube with green characters, pulling out my hair at ‘null pointer exceptions’. I was debugging my first linked list program in my high school computer lab. In Pascal.
I also remember the exhilaration when the program finally worked! The excitement when a piece of code works exactly as it is supposed to do. When every possible input is handled gracefully and the list magically creates, inserts, deletes and displays as expected. For those who cannot relate to this exhilaration, I will refer you to the aforementioned definition of geek as a possible explanation. (You probably may not be one. And I probably am.) I think that was when I decided I would code for a living. Especially if the code I wrote also helped customers save time and money.
Many moons later, the exhilaration I experienced in my school lab was a faint memory. Every now and then, I would get back in touch with the fundamental reason I got into technology, but more often than not, the dominant experience was stress. And one of the chief causes was workplace conflict. Quite often, I would find myself driving back from work, fuming about some meeting, mail thread or conversation – dissatisfied with the cause, course and outcome of a conflict.
There were times when I felt I was not assertive enough, and that my team or I were taken advantage of. There were other times when I thought I was too assertive and though I may have gotten the outcome I wanted, the collateral damage was high. Often, I paid a heavy price in terms of damaged relationships and burned bridges. There were times when I was able to steer conflicts in a way that generated the desirable outcome for all stakeholders, but I was not able to replicate this experience at will and at a high enough rate of success.
So I kept wondering if this was just the way things had to be in the fast paced, high pressure world of Technology R&D or if there was a better. I began to think that surely someone somewhere had figured out simple, repeatable techniques on handling workplace conflict constructively. It was just a matter of asking the right questions and zeroing in on the answer. The quote that kept popping up in my mind was…
“The quality of your life is determined by the quality of questions you ask.”
-Dr. John Demartini
We have a glut of easily accessible information in the world today. The right questions can help us hone in on relevant information and separate the wheat from the chaff. A series of questions kept popping up in my mind on the topic of workplace conflict.
My journey took me on a convoluted path – from the pages of Patrick Lencioni’s ‘Death By Meeting’ and ‘The Five Dysfunctions of a Team to the Thomas-Kilmann Conflict Mode Instrument or the TKI, the world’s best-selling assessment for understanding how different conflict-handling styles affect interpersonal and group dynamics. I made quite a few interesting discoveries as I started reading the literature on this topic. For instance, a study on the cost of work-place conflict in 9 countries states that the average US employee spends 2.8 hours per week on conflict management, adding up to $ 3.9 Billion in paid hours! Can you imagine the gains in productivity if we could use training to reduce this cost by just 5%? And this would be in addition to the reduction in stress, fatigue and damaged relationships.
As I discovered how the TKI could be applied to constructively harness conflicts in the workplace, I had two thoughts-
Engineers like to learn from the past. As a community, most of us probably live the quote…
“Those who cannot remember the past are condemned to repeat it.”
-George Santayana
We hate repeating the same mistakes. Before we start to solve a problem, we look back at our experience to see if we have solved the same or similar problem in the past and apply the lessons we learned. When faced with a new problem, we reach out to our community to see if someone else has solved a similar one in the past, and how we can mine their experience. Whenever possible, we try not to re-invent the wheel, we just find the one that fits best and roll with it.
So what lessons can your organization learn from past conflicts? What powerful questions can you ask about conflicts to improve the direction and quality of your organization’s life? Are any of these questions relevant for you-
If you are curious about any of these questions or if you have similar questions , the Org Whisperers Online Workshop on Conflict Resolution may be worth your consideration. This workshop is a guided enquiry that helps attendees reflect on key questions like-
Contact me if you would like to share your thoughts on these topics or learn more about how Org Whisperers can help you constructively harness the power of conflicts in your organization. Life is short and if there is a journey we can take to get back in touch with the exhilaration that made us choose our professions, it will be well worth our time.