Dia daoibh, a chairde. Conas atá tú?
For the last nine months or so, I have been learning Irish. My mind is being stretched in so many ways, just trying to wrap my head around the orthography, pronunciation rules, and grammar. One of the greatest joys I have experienced recently was being able to read and understand a book that was written for parents to read to their children. That's right, folks: in Irish, I've reached the verbal equivalence of a six-year old!
Learning a new language requires changing your worldview, biases, and priorities. What works for you in your native tongue may have to be changed before you can understand — or be understood in — another language. For example, English has a Subject-Verb-Object order: The cat drinks milk. On the other hand, Irish has a Verb-Subject-Object order: Ólann an cat bainne (drinks - the cat - milk).
The change in sentence order and structure requires a fundamental shift in the way you think, speak, and read. It is similar to using a postfix notation calculator like those from Hewlett-Packard: Push the Verb onto the stack, read along to get to the end of the Subject clause and push it onto the stack, read along to get to the end of the Object clause and push it onto the stack, then pop off the whole phrase.
Another major difference between languages is in the way prepositions are used. Simple little words like "In", "Through", "Over", "Under", "With", "About", "For", and "To" make up a huge portion of any language, and learning the new words is fundamental for effective communication. But, it isn't just about learning the new words; you have to learn the correct usage for each preposition.
Consider an English sentence like "We listen to the radio". In Irish, though, the sentence becomes "We listen with the radio". Even though it may not make sense to your mind, you have to change your way of thinking, your verbal processing, to speak the language properly.
It is this change in mindset that makes learning a different language so important. You can read all you want about a country and its people, but until
you try to learn its language, you won't be able to touch its soul. In fact, I believe learning a new language is one of the highest forms of respect
you can pay to another culture. You have to be willing to accept that their way and their culture trumps your background.
Can you picture what would happen if I — with my vast experience of nine whole months and six-year old equivalency — decided that the Irish were wrong about their prepositions and that thousands of years of spoken culture was incorrect? Imagine the laughter and derision that would accompany such arrogance!
But yet, those of us who provide technology services and support are often guilty of the same type of behavior with our clients.
I was on a conference call the other day with one of my support clients. My client is a large, multinational corporation, and client representatives from France, Italy, and the United States were on the call. Also on the call was a third party who had been brought in to build a catalog of my client's products.
(Sorry to go into the weeds a bit, but on this client's website, they have their product lines split
into a hierarchy of "Product Lines" and "Segments". A "Product Line" contains multiple
"Segments". An example of a Product Line might be "Ceramic Coffee Mugs", and it
might have four Segments: "#1601 - 16 Ounce, White", "#1602 - 16
Ounce, Black", "#2401 - 24 Ounce, White", and "#2402 - 24 Ounce, Black". You get the idea.)
During the call, the representative from the outside vendor briefly mentioned "Product Lines", and then went into a lot of detail about "Segments" and "Types", and the format of the data for each.
What followed was a long period of silence as people in different countries tried to parse the English words into their own languages, and from there, tried to correlate the words with their own corporate culture. Then, the questions started flying back and forth.
For nearly 15 minutes, the actual business of the meeting was put on hold as the participants tried to understand what the vendor's representative was trying to convey. He kept insisting that the "Types" were simply "Segments without size or color".
Eventually, it became obvious that what he was calling a "Type" was actually what the client calls a "Product Line". Once the client corrected the vendor — and he accepted the client's terminology — the meeting got back on track.
As I left the conference call, I was struck by how similar supporting a client — and particularly taking on a new client — is to learning a new language.
Providing Winning Support means that we have to be willing to learn our client's corporate culture, corporate paradigms, and corporate language. We have to accept that our corporate culture, worldview, mindsets, and language may need to be modified when supporting that client.
Developing a deep and lasting relationship with a client should be a primary goal for anyone in a support role. We've all heard that it costs "ten times more to find a new client than it does to keep an existing one".
I don't know if it is really a 10:1 ratio, but I do know that keeping an existing client happy generally means your company gets to keep that client. And one of the best ways of keeping a client happy is to provide Winning Support.
To deliver Winning Support consistently, you have to respect your client's unique culture, and to do that, you have to learn the language. The great thing is that many of you already have the tools to do this, for the secret to learning your client's language is that you have to LISTEN!
It's actually pretty simple. I know you can do it. Let's get out there and start Winning Support!
Feicfidh mé ar ball thú!
Friday, June 19, 2015
Sunday, February 1, 2015
Effective Pairing
Several months ago, one of our development teams was trying to bring a project in for a landing and a call went out for developers to come in and do some “pair programming”. I’m sure we’ve all been at the end of a project that is running hot, had numerous change requests, and been subject to the mounting pressure to deliver the desired functionality by the promised date. I’ve been there, and wanting to build up some good karma, volunteered for a few sessions to help where I could.
It was a great experience, and after the project was over, several of us got together to exchange thoughts about effective pairing. Seven important elements for effective pairing came out of those discussions. Interestingly enough, these elements are also key to providing Winning Support.
Learn
Learning all you can from your partner establishes the framework for effective pairing. Your partner knows the code, the project history, and the overall picture, so assume the role of a student. Let your partner teach you and explain what is happening; your job is to listen attentively. More than likely, your partner already has the right information to solve the issue, but the problem is that he or she may have too much information. Allowing your partner to be the teacher will help to crystallize his or her thoughts, which will then narrow your partner’s focus to what is really important.
Inquire
Intelligent queries can help your partner sift through the pile of information. As your partner shares with you, listen carefully. Don’t ask general questions such as, “What’s that?” Instead, ask direct, specific questions:
Supporting your partner can take many forms. Offer to fetch a cup of coffee, a Mountain Dew, a cold cup of water, or a snack. Maybe he or she needs a break; if so, the two of you can take a quick walk around the building. While you are walking, let your partner talk to clear the cobwebs. This isn’t just an idle waste of time; your partner’s subconscious will continue working on the problem at hand, and you’ll both return refreshed and able to take a fresh look at the problem.
Don’t overlook the benefit of just being there with your partner. At the tail-end of a project that is under schedule, resource, and budgetary pressures, nothing is more demoralizing than working on a critical issue alone. Just having someone there who is willing to give of themselves to help you fight through the issues will keep the dark and depressing thoughts at bay.
Track
Tracking your partner’s moves through the code and through manual test cases takes keen observation skills. If your partner is exercising a particular test case, take notes. Keep track of the screens and the data entered to help ensure the test is repeatable.
Pay attention to how your partner is entering the data. If she types it in one time, but selects it from a list or copies it from a file another time, it’s worth a question. Usually, it won’t matter, but the test may not be exercising the same pathways in both cases.
In other situations, you may want to track process durations. Just noticing that an activity took one second during one test but 15 seconds during a subsequent test might help your partner uncover a potential problem.
Serve your partner by taking care of the periphery. Track the things that your partner isn’t focusing on, but bring them to attention if you see something that doesn’t fit with the patterns your partner has established.
Engage
Engaging your mind with the task at hand takes discipline. You are there to engage with your partner; therefore, your mind needs to be on your partner’s issues and not your own.
You are there to help your partner, not be a hindrance. You need to be actively involved in helping your partner concentrate on getting the work done. Being deep in the throes of a pair programming situation is probably not the best time to bring up that long story about that time you were working on a problem that is only tangentially related to your partner’s situation.
If you find your mind wandering and disengaging, you may need to return to the Inquire and Track aspects of a pairing exercise.
Nurture
Nurturing your partner takes grace and diplomacy. To nurture someone means you are caring for and encouraging his or her development and growth. In most pairing exercises, you are there to Learn, Inquire, Support, Track, and Engage, but there will be times when your experience needs to gently and gracefully come to the fore.
Knowing when to nurture your partner and on what subjects requires diplomacy. You have to know what is important enough to be a teaching moment, and what can slide, especially if the pairing exercise is being performed under tight schedules and project pressures. Under those situations, making a big deal out of your partner’s coding style is probably not going to be well-received. However, if your partner is using the wrong design pattern or a resource-expensive algorithm, then that may be the time to gently and gracefully offer wisdom.
During a recent pairing exercise, I observed a junior developer whose partner was a very senior, respected leader. The senior leader was trying to lead the developer down the right path, but it was clear the young developer was out of his depth. Although the senior leader was frustrated and wanted to just grab the keyboard, he stopped and took the time to explain not only what was wrong with the existing approach, but why it would be a problem down the road.
Instead of just pointing out the problem and saying, “Fix it!”, the senior leader showed the developer the rationale behind the better approach, and then gave detailed instructions on how to implement the changes. This is one reason why this senior executive is so well-respected in our company and in the industry: he knows when someone needs a nurturing mentor.
So far, we have six important tasks for effective pairing:
Some of you have already seen the seventh — and probably the most important — task in any pairing exercise, and that is to LISTEN.
I asked him, “How can I best support you in this effort?”
He replied with, “Just listen to me mutter.”
Throughout the evening, he gave his internal monologue a voice and I listened. Together, we discovered a problem with one of the data-retrieval web services. It was a long and arduous evening at the end of an already-long day, but solving that particular problem helped to make the entire project a success.
When you stop to think about it, listening to someone mutter might just be the essence of providing Winning Support. We always respond when our clients are yelling, because we tend to jump at the loudest voices. But, sometimes the small, quiet mutterings of our clients can indicate a bigger problem, and learning to hear those soft voices can help to identify problems you don't know you have. When one client happens to mention some seemingly inconsequential thing, and then, another client raises the same issue a day later, it may indicate a deeper problem that needs to be addressed, and quickly.
We need to tune our ears to listen to those mutterings, to learn from them, to inquire intelligently about the issues being raised, to support those who are voicing concerns, to track what is happening, to engage our minds fully with those who are muttering, and to nurture those who need guidance.
Whether you are in a pair-programming exercise or you are supporting a large number of users, the key to providing Winning Support to your partner — and to your clients — is to LISTEN.
We can do this.
Let’s start Winning Support.
It was a great experience, and after the project was over, several of us got together to exchange thoughts about effective pairing. Seven important elements for effective pairing came out of those discussions. Interestingly enough, these elements are also key to providing Winning Support.
Learn
Learning all you can from your partner establishes the framework for effective pairing. Your partner knows the code, the project history, and the overall picture, so assume the role of a student. Let your partner teach you and explain what is happening; your job is to listen attentively. More than likely, your partner already has the right information to solve the issue, but the problem is that he or she may have too much information. Allowing your partner to be the teacher will help to crystallize his or her thoughts, which will then narrow your partner’s focus to what is really important.
Inquire
Intelligent queries can help your partner sift through the pile of information. As your partner shares with you, listen carefully. Don’t ask general questions such as, “What’s that?” Instead, ask direct, specific questions:
- “Why are you forcing the string to lowercase every time through the loop? Wouldn’t it be faster to force it to lowercase once before the loop?”
- “You keep saying that we don’t need to look at this code. Why is that?”
Supporting your partner can take many forms. Offer to fetch a cup of coffee, a Mountain Dew, a cold cup of water, or a snack. Maybe he or she needs a break; if so, the two of you can take a quick walk around the building. While you are walking, let your partner talk to clear the cobwebs. This isn’t just an idle waste of time; your partner’s subconscious will continue working on the problem at hand, and you’ll both return refreshed and able to take a fresh look at the problem.
Don’t overlook the benefit of just being there with your partner. At the tail-end of a project that is under schedule, resource, and budgetary pressures, nothing is more demoralizing than working on a critical issue alone. Just having someone there who is willing to give of themselves to help you fight through the issues will keep the dark and depressing thoughts at bay.
Track
Tracking your partner’s moves through the code and through manual test cases takes keen observation skills. If your partner is exercising a particular test case, take notes. Keep track of the screens and the data entered to help ensure the test is repeatable.
Pay attention to how your partner is entering the data. If she types it in one time, but selects it from a list or copies it from a file another time, it’s worth a question. Usually, it won’t matter, but the test may not be exercising the same pathways in both cases.
In other situations, you may want to track process durations. Just noticing that an activity took one second during one test but 15 seconds during a subsequent test might help your partner uncover a potential problem.
Serve your partner by taking care of the periphery. Track the things that your partner isn’t focusing on, but bring them to attention if you see something that doesn’t fit with the patterns your partner has established.
Engage
Engaging your mind with the task at hand takes discipline. You are there to engage with your partner; therefore, your mind needs to be on your partner’s issues and not your own.
You are there to help your partner, not be a hindrance. You need to be actively involved in helping your partner concentrate on getting the work done. Being deep in the throes of a pair programming situation is probably not the best time to bring up that long story about that time you were working on a problem that is only tangentially related to your partner’s situation.
If you find your mind wandering and disengaging, you may need to return to the Inquire and Track aspects of a pairing exercise.
Nurture
Nurturing your partner takes grace and diplomacy. To nurture someone means you are caring for and encouraging his or her development and growth. In most pairing exercises, you are there to Learn, Inquire, Support, Track, and Engage, but there will be times when your experience needs to gently and gracefully come to the fore.
Knowing when to nurture your partner and on what subjects requires diplomacy. You have to know what is important enough to be a teaching moment, and what can slide, especially if the pairing exercise is being performed under tight schedules and project pressures. Under those situations, making a big deal out of your partner’s coding style is probably not going to be well-received. However, if your partner is using the wrong design pattern or a resource-expensive algorithm, then that may be the time to gently and gracefully offer wisdom.
During a recent pairing exercise, I observed a junior developer whose partner was a very senior, respected leader. The senior leader was trying to lead the developer down the right path, but it was clear the young developer was out of his depth. Although the senior leader was frustrated and wanted to just grab the keyboard, he stopped and took the time to explain not only what was wrong with the existing approach, but why it would be a problem down the road.
Instead of just pointing out the problem and saying, “Fix it!”, the senior leader showed the developer the rationale behind the better approach, and then gave detailed instructions on how to implement the changes. This is one reason why this senior executive is so well-respected in our company and in the industry: he knows when someone needs a nurturing mentor.
So far, we have six important tasks for effective pairing:
- Learn;
- Inquire;
- Support;
- Track;
- Engage; and,
- Nurture.
Some of you have already seen the seventh — and probably the most important — task in any pairing exercise, and that is to LISTEN.
- When you listen to your partner, you will be able to learn what you can about the problems he or she is facing.
- When you listen to your partner, your inquiries will be direct and pointed, and will help your partner focus on what is truly important.
- When you listen to your partner’s frustrated sighs and the heavy pounding on the keyboard, you will know it is time to support your partner with a cold soda, a snack, and a mental break.
- When you listen to your partner, you can be better at tracking the pathways through the code and through the test scenarios.
- When you listen to your partner, your mind will be engaged, and will not be wandering. If your mind is wandering, then you cannot be the effective resource your partner needs.
- When you listen to your partner, you will be able to know when to nurture your partner’s mind and craft.
I asked him, “How can I best support you in this effort?”
He replied with, “Just listen to me mutter.”
Throughout the evening, he gave his internal monologue a voice and I listened. Together, we discovered a problem with one of the data-retrieval web services. It was a long and arduous evening at the end of an already-long day, but solving that particular problem helped to make the entire project a success.
When you stop to think about it, listening to someone mutter might just be the essence of providing Winning Support. We always respond when our clients are yelling, because we tend to jump at the loudest voices. But, sometimes the small, quiet mutterings of our clients can indicate a bigger problem, and learning to hear those soft voices can help to identify problems you don't know you have. When one client happens to mention some seemingly inconsequential thing, and then, another client raises the same issue a day later, it may indicate a deeper problem that needs to be addressed, and quickly.
We need to tune our ears to listen to those mutterings, to learn from them, to inquire intelligently about the issues being raised, to support those who are voicing concerns, to track what is happening, to engage our minds fully with those who are muttering, and to nurture those who need guidance.
Whether you are in a pair-programming exercise or you are supporting a large number of users, the key to providing Winning Support to your partner — and to your clients — is to LISTEN.
We can do this.
Let’s start Winning Support.
Subscribe to:
Posts (Atom)