Sorry to have been away for so long. This thing called "Life" kept getting in the way, and I needed to stop and re-assess what was going on. By writing this post, I am refusing to accept the status quo from the past year.
I read a fascinating article today about something truly strange that has been observed and then studied in depth. Believe it or not, but your choice of browsers can say a lot about your personality, your work habits, your performance, and overall ability to cope with the stresses of your job. I was skeptical at first, but as I read the article and watched the TED talk that was behind the article, I became a believer. The more I read, the more I realized there was a definite tie-in with providing Winning Support.
First, the attributions and links. The TED speaker is Wharton psychology professor, Adam Grant, who has written a book entitled, "Originals: How Non-Conformists Move the World". The article that helped to break through the inertia of the past year is, "Adam Grant: What Your Web Browser Says About You". The TED talk in which Grant expounds on his findings is "The Surprising Habits of Original Thinkers". I encourage you to read the article and even watch the TED talk. The article will take you about 5 minutes to read, and the TED talk is about 15 minutes.
In a series of studies, an economist named Michael Housman was involved with a project to determine why some customer service representatives stayed in their jobs longer than others. His team studied the data from more than 30,000 employees who handled calls for banks, airlines, and cell-phone companies. His team's initial dive into the data sought to reveal a correlation between a history of job-hopping and commitment, but the data didn't support the original hypothesis.
Looking for other clues, he saw that the data his team had available included the internet browser that employees had used when applying for their jobs. He assumed that the browser one uses was just an individual preference, and didn't expect to see any correlation. What he found astounded him. Those who had used Firefox or Chrome to browse the web remained in their jobs 15 per cent longer than those who used Internet Explorer or Safari.
He then ran the same analysis for absences from work and found that Firefox and Chrome users were 19 per cent less likely to miss work than those who used Internet Explorer and Safari. (I know, I know ... I would be prone to miss work, too, if I had to use IE on a daily basis, but that wasn't the root cause.)
His team then looked at performance, and was able to analyze nearly three million data points on sales, customer satisfaction, and average call length. You guessed it: the Firefox and Chrome users outperformed those who used IE and Safari. Their call times were shorter, they had higher sales, and their customers were more satisfied with the service received.
The more the team studied, the more convinced they were that there was definitely a positive correlation between the browser a person uses and his or her job performance and job satisfaction, and it wasn't due to certain users having more technical skills than others. What they discovered was that the deciding factor was how the user had acquired the browser. Internet Explorer and Safari are the default browsers for Windows and Mac OS. Therefore, in general, the Firefox and Chrome users had had to make a conscious decision to load those browsers and to use them.
You don't have to be especially tech-savvy to download a different browser. However, you have to want to. Instead of accepting the default — in this case, a browser — you have to refuse to accept the status quo. You have to be willing to take the initiative.
And this is where it ties in to providing Winning Support.
When you take the initiative in your work, your customers (both internal and external) will benefit. When you say, "There just has to be a better way ...", you will start to explore new options, new ideas. When you refuse to accept "That's the way we've always done it" as a valid reason, you'll begin to look for ways to improve your life, your work environment, and even your browser.
When I look back over my career and review the programs I have written and the web sites I have helped design and support, I can see that the bright spots all have something in common: I didn't like what was happening or the way the software worked, so I did what I could to improve it. In some cases, that was in redesigning a subsystem to be simpler, more elegant. In some cases, it involved writing a program or utility, and then making it available for others to use. I've done it in the past, before I was involved in day-to-day support, and I've done it in my current position, trying to make a complex content management system implementation easier to use by non-technical users, most for whom English is a second or third language.
When I get brutally honest with myself, I think I have remained in software development and support precisely because I often find myself looking for better ways to do things. I cannot build things like models and bookshelves with my hands. (Well, I can, but they don't last long.) However, I can build useful software applications and simplify complex tasks through the proper application of a keyboard and a compiler.
Now, please don't misinterpret the concept that Adam Grant and Michael Housman discovered. Don't think that just by downloading Firefox and Chrome you are going to magically become the Greatest Support Superhero That Has Ever Lived! It isn't the downloading in itself ... it's the willingness to search for better/faster/easier ways to do things and then want to improve the lives of others by sharing the fruits of your explorations with them.
So, in what ways have you been accepting the status quo in your job, in your relationships, in your life? In what ways have you been "happy" with the default settings?
If you want to start improving your game, if you want to boost the amount of Winning Support you provide, start by looking at the defaults you have accepted and change what you can. Look for ways to make incremental improvements. Don't just accept the status quo; instead, take charge of your life, your environment, your job.
I know you can do it.
For many of you, all that is needed is the decision to start and the impetus to make that change. I applaud you and encourage you to do just that. Small changes, baby steps, tiny improvements. The big stuff can come later.
For others, though, you need to know where to start. Let me suggest you start with one of these links:
It is a small change in your life, but one that may open many doors for you in the future.
Let's do this. Let's start Winning Support.
Monday, June 6, 2016
Friday, June 19, 2015
Learning the Language
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ú!
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ú!
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.
Sunday, June 8, 2014
Are we Having Fun Yet?
Lately, I’ve been reading Reality is Broken by Jane McGonigal. This book is an exploration of the role games play in our lives, how they make us better, and how games might help us improve the world. She has a powerful thesis, and some of the things she says resonates deeply.
In the opening chapters of her book, she illustrates how games can provide more meaningful work, and then follows it up with a chapter called “Fun Failure and Better Odds of Success”.
In that chapter, McGonigal lays out the position that games offer us overwhelming opportunities to fail repeatedly, but in a fun way. Whether it is avoiding barrels tossed by a gorilla, shooting at alien spaceships, or killing orcs and goblins, we typically only succeed after failing multiple times. It is obviously fun to fail at these games, because most of us don’t walk away from the game after we have failed once or twice. Instead, we start the level over and try again. It is this fun failure that gives us an “urgent optimism” that we are almost ready to conquer the level.
Be honest: how many late nights have you put in on Halo, Call of Duty, WoW, Tetris, or Candy Crush Saga saying, “Just one more level!”?
Fun failure, indeed.
But while the concept of “fun failure” is fine in a game, it certainly doesn’t reflect reality for those of us in the Support trenches. Except for the failure part, because sometimes it seems like we’ve got failure down pat. This is especially true when we have an intractable issue that defies logic, or when an issue keeps cropping up in the field and we can’t duplicate it in our debugging environments.
That’s because real life is difficult, reality is tough.
Right now, I’m working on an issue that is a dark shade of ugly. It is like one of those old maps that shows the known world and seas, and then near the edge of the map is a coastline followed by the legend, “Here there be dragons.”
This code that I’m trying to fix is miles inland from that warning. I’m so far into the dragon-scape that I can’t even tell you in which direction the coastline lies.
It is a whole lot of failure and even less fun. I’ve tried to refactor this code at least twice, and failed to make headway. Here there be dragons, and the dragons be winning. I have to admit that being unable to slay this dragon made me pretty demoralized.
But then I read this nugget from McGonigal:
Just the simple change in my attitude has already given me hope. I know I can beat this level; it’s just a matter of time. I’ve taken a fresh look at the battlefield, reconnoitering the dragon’s landscape with a more critical eye. I’ve started mapping the dungeon, listing all the intertwined business rules that are driving the complexity of the code I have to fix.
Rather than driving me back and beating me down, my previous attempts — and failures — have become an integral weapon in my arsenal. I know what doesn’t work, and more importantly, I know where the dragon is likely to be lurking.
McGonigal is certainly right when she says that urgent optimism in the face of failure can be energizing.
A week ago, I was responsible for supporting 60 or so content editors in a content management system containing tens of thousands of content items, fixing bugs and adding features to a burgeoning legacy system with business rules that get more complex with every passing day.
But this past week? This past week I was playing an MMORPG with 60 or so other players. Within the game’s landscape there are tens of thousands creatures, mostly benign, but each of those creatures has the ability to become a problem overnight. Every passing day, new challenges arise as the game’s owners — my client —toss new business rules into the mix.
Last Friday was a pretty good day in my new game and I was able to complete two major quests. The first was “The Case of the Untranslated Zombie Documents”, and the second quest was “Why Does this Functionality Break in Internet Explorer 10?”.
The root cause in the second quest turned out to be caused by the change to the User Agent string reported by Internet Explorer. It turns out that the CMS we use is looking for “MSIE” in the navigator.userAgent string. However, with IE 10 and later, the User Agent string no longer contains “MSIE”; instead, it reports “Trident” (among other strings).
In that particular quest, I found the reason why the functionality broke, but I don’t have a fix for it yet. But, now that I know the root cause, fixing it is just a matter of time before I finish the quest and can move on to new challenges. No matter what happens, I can’t wait to get back to my game tomorrow.
I’m having fun at my job once again. Are you?
What support battles are you facing? Can you change your thinking and make it a game?
Support and Maintenance can seem like an epic battle, but it is a battle we can win.
Let’s start Winning Support!
_____________
1 Jane McGonigal, Reality is Broken (New York: The Penguin Press, 2011), 69.
In the opening chapters of her book, she illustrates how games can provide more meaningful work, and then follows it up with a chapter called “Fun Failure and Better Odds of Success”.
In that chapter, McGonigal lays out the position that games offer us overwhelming opportunities to fail repeatedly, but in a fun way. Whether it is avoiding barrels tossed by a gorilla, shooting at alien spaceships, or killing orcs and goblins, we typically only succeed after failing multiple times. It is obviously fun to fail at these games, because most of us don’t walk away from the game after we have failed once or twice. Instead, we start the level over and try again. It is this fun failure that gives us an “urgent optimism” that we are almost ready to conquer the level.
Be honest: how many late nights have you put in on Halo, Call of Duty, WoW, Tetris, or Candy Crush Saga saying, “Just one more level!”?
Fun failure, indeed.
But while the concept of “fun failure” is fine in a game, it certainly doesn’t reflect reality for those of us in the Support trenches. Except for the failure part, because sometimes it seems like we’ve got failure down pat. This is especially true when we have an intractable issue that defies logic, or when an issue keeps cropping up in the field and we can’t duplicate it in our debugging environments.
That’s because real life is difficult, reality is tough.
Right now, I’m working on an issue that is a dark shade of ugly. It is like one of those old maps that shows the known world and seas, and then near the edge of the map is a coastline followed by the legend, “Here there be dragons.”
This code that I’m trying to fix is miles inland from that warning. I’m so far into the dragon-scape that I can’t even tell you in which direction the coastline lies.
It is a whole lot of failure and even less fun. I’ve tried to refactor this code at least twice, and failed to make headway. Here there be dragons, and the dragons be winning. I have to admit that being unable to slay this dragon made me pretty demoralized.
But then I read this nugget from McGonigal:
Learning to stay urgently optimistic in the face of failure is an important emotional strength that we can learn in games and apply in our real lives. When we’re energized by failure, we develop emotional stamina. And emotional stamina makes it possible for us to hang in longer, to do much harder work, and to tackle more complex challenges. We need this kind of optimism in order to thrive as human beings.1Getting energized by failure is a difficult concept to grasp, and as I reflected on how I might get energized by my current dragon-battle, I wondered what would happen if I adopted McGonigal at face value. That is, if games are fun and teach us how to have fun while failing, then what would happen if I turned my support efforts into a game? Instead of being demoralized by a seemingly invincible dragon, what if I was just facing a super-difficult Boss Level?
Just the simple change in my attitude has already given me hope. I know I can beat this level; it’s just a matter of time. I’ve taken a fresh look at the battlefield, reconnoitering the dragon’s landscape with a more critical eye. I’ve started mapping the dungeon, listing all the intertwined business rules that are driving the complexity of the code I have to fix.
Rather than driving me back and beating me down, my previous attempts — and failures — have become an integral weapon in my arsenal. I know what doesn’t work, and more importantly, I know where the dragon is likely to be lurking.
McGonigal is certainly right when she says that urgent optimism in the face of failure can be energizing.
A week ago, I was responsible for supporting 60 or so content editors in a content management system containing tens of thousands of content items, fixing bugs and adding features to a burgeoning legacy system with business rules that get more complex with every passing day.
But this past week? This past week I was playing an MMORPG with 60 or so other players. Within the game’s landscape there are tens of thousands creatures, mostly benign, but each of those creatures has the ability to become a problem overnight. Every passing day, new challenges arise as the game’s owners — my client —toss new business rules into the mix.
Last Friday was a pretty good day in my new game and I was able to complete two major quests. The first was “The Case of the Untranslated Zombie Documents”, and the second quest was “Why Does this Functionality Break in Internet Explorer 10?”.
The root cause in the second quest turned out to be caused by the change to the User Agent string reported by Internet Explorer. It turns out that the CMS we use is looking for “MSIE” in the navigator.userAgent string. However, with IE 10 and later, the User Agent string no longer contains “MSIE”; instead, it reports “Trident” (among other strings).
In that particular quest, I found the reason why the functionality broke, but I don’t have a fix for it yet. But, now that I know the root cause, fixing it is just a matter of time before I finish the quest and can move on to new challenges. No matter what happens, I can’t wait to get back to my game tomorrow.
I’m having fun at my job once again. Are you?
What support battles are you facing? Can you change your thinking and make it a game?
Support and Maintenance can seem like an epic battle, but it is a battle we can win.
Let’s start Winning Support!
_____________
1 Jane McGonigal, Reality is Broken (New York: The Penguin Press, 2011), 69.
Friday, May 9, 2014
Putting the Most Important Things First
Twenty years ago today, on May 9, 1994, I had one of my greatest personal work-related triumphs. It was a Monday, the day after Mother's Day.
For the past six months I had been leading a development team creating a completely new version of our company's software. This particular application was my baby; I had designed it and had convinced the company that it was best way to handle a growing customer base and getting our clients off the old, buggy, single line-of-business software.
Not only had I designed it, but the company had even let me name this new product. I was intimately familiar with all of its files, all of the code. I had a great team working with me, and we clicked like a well-oiled machine.
On that day, we had installed the software at a major client's headquarters, as a Beta Test site. We spent the day hand-holding the users, going from desk to desk, answering questions and giving pointers. Sure, we had a few glitches, not the least of which was the discovery that the memory manager that I had designed was not up to the rigors of the abuse the clients were giving it.
But, all in all, it was a banner day, a day which I count among one of my greatest career achievements.
Around 7:30 that evening, we were exhausted. The team was gathered in the server room, analyzing dumps and traces, trying to figure out how we were going to replace the memory manager. We were laying out the schedule for the next day and handing out debugging, code-fixing, and hand-holding assignments.
Suddenly, the group leader's pager went off. He looked at the number, expecting it to be a client, and he said, "BobR, I think your wife is trying to get in touch with you." This was before cell phones were commonplace, and I wasn't at my desk, so she had paged my boss.
I called her and got the news I was expecting to hear.
Twenty years ago today, on May 9, 1994, my Dad ran his last race, fought his last fight, and drew his last breath. He had finally lost a very short battle with a fast-spreading cancer.
For the previous six or so weeks, he had been in the hospital in Los Angeles, his life ebbing away. I had had to make the painful decision not to fly out there from Kansas City until the end, knowing that when I had seen him just nine weeks earlier, it was going to be for the last time.
At that moment, the problems with the memory manager were flushed from my mind. My boss told the team that we were done for the night, and we headed home. The problems with the software would have to wait.
It is difficult to provide Winning Support when you are faced with a personal tragedy. It is difficult to serve others when our own lives are in turmoil.
I learned a couple of important lessons that day.
First and foremost, your family comes first. Period.
Yes, I truly believe that we are to serve our clients to our utmost, but we also have to consider our family as our most important client.
If your clients are more important to you than your family, I would suggest that you need to take a long, hard, serious look at your life. Clients are important, jobs are vital, and work needs to go on, but clients and jobs will not be around forever. Your family, on the other hand, should be your refuge, your place of respite, your primary responsibility. Cherish those around you.
If you have a husband, wife, partner, brother, sister, son, daughter, father, mother, or any other close loved one, then put down the mouse, step back from the keyboard, and give them a call. Better yet, go see them and give them a hug.
The second thing I learned is how important it is to have a good team around you. Over the next day, I had to develop a work plan for the team, reassign all my work, bring a team member up to speed on the memory manager, get ready to fly across the country, design a headstone, and prepare a eulogy. I had an awesome team and they all stepped in and supported me in my time of grief. And the work got done without me.
If you are a one-person shop — if you are all alone in your position — do yourself a favor and find a friend. Buddy up. Cross train someone. Do some pair programming. Find someone who can help shoulder the burden when you need help.
Providing Winning Support is an endurance race, not a sprint. Take care of yourself, take care of your family, and then take care of your clients.
You cannot serve others well — you cannot provide the type of Winning Support of which I know you are capable — if you aren't putting the most important things first.
Others stepped up to help me when I needed it, and I want to pay back that favor.
If you need some help, I'm here for you and will help in any way I can. Feel free to leave comments below. I would love to hear from you. How may I serve you?
Let's start Winning Support.
For the past six months I had been leading a development team creating a completely new version of our company's software. This particular application was my baby; I had designed it and had convinced the company that it was best way to handle a growing customer base and getting our clients off the old, buggy, single line-of-business software.
Not only had I designed it, but the company had even let me name this new product. I was intimately familiar with all of its files, all of the code. I had a great team working with me, and we clicked like a well-oiled machine.
On that day, we had installed the software at a major client's headquarters, as a Beta Test site. We spent the day hand-holding the users, going from desk to desk, answering questions and giving pointers. Sure, we had a few glitches, not the least of which was the discovery that the memory manager that I had designed was not up to the rigors of the abuse the clients were giving it.
But, all in all, it was a banner day, a day which I count among one of my greatest career achievements.
Around 7:30 that evening, we were exhausted. The team was gathered in the server room, analyzing dumps and traces, trying to figure out how we were going to replace the memory manager. We were laying out the schedule for the next day and handing out debugging, code-fixing, and hand-holding assignments.
Suddenly, the group leader's pager went off. He looked at the number, expecting it to be a client, and he said, "BobR, I think your wife is trying to get in touch with you." This was before cell phones were commonplace, and I wasn't at my desk, so she had paged my boss.
I called her and got the news I was expecting to hear.
Twenty years ago today, on May 9, 1994, my Dad ran his last race, fought his last fight, and drew his last breath. He had finally lost a very short battle with a fast-spreading cancer.
For the previous six or so weeks, he had been in the hospital in Los Angeles, his life ebbing away. I had had to make the painful decision not to fly out there from Kansas City until the end, knowing that when I had seen him just nine weeks earlier, it was going to be for the last time.
At that moment, the problems with the memory manager were flushed from my mind. My boss told the team that we were done for the night, and we headed home. The problems with the software would have to wait.
It is difficult to provide Winning Support when you are faced with a personal tragedy. It is difficult to serve others when our own lives are in turmoil.
I learned a couple of important lessons that day.
First and foremost, your family comes first. Period.
Yes, I truly believe that we are to serve our clients to our utmost, but we also have to consider our family as our most important client.
If your clients are more important to you than your family, I would suggest that you need to take a long, hard, serious look at your life. Clients are important, jobs are vital, and work needs to go on, but clients and jobs will not be around forever. Your family, on the other hand, should be your refuge, your place of respite, your primary responsibility. Cherish those around you.
If you have a husband, wife, partner, brother, sister, son, daughter, father, mother, or any other close loved one, then put down the mouse, step back from the keyboard, and give them a call. Better yet, go see them and give them a hug.
The second thing I learned is how important it is to have a good team around you. Over the next day, I had to develop a work plan for the team, reassign all my work, bring a team member up to speed on the memory manager, get ready to fly across the country, design a headstone, and prepare a eulogy. I had an awesome team and they all stepped in and supported me in my time of grief. And the work got done without me.
If you are a one-person shop — if you are all alone in your position — do yourself a favor and find a friend. Buddy up. Cross train someone. Do some pair programming. Find someone who can help shoulder the burden when you need help.
Providing Winning Support is an endurance race, not a sprint. Take care of yourself, take care of your family, and then take care of your clients.
You cannot serve others well — you cannot provide the type of Winning Support of which I know you are capable — if you aren't putting the most important things first.
Others stepped up to help me when I needed it, and I want to pay back that favor.
If you need some help, I'm here for you and will help in any way I can. Feel free to leave comments below. I would love to hear from you. How may I serve you?
Let's start Winning Support.
Sunday, May 4, 2014
Winning Support Through Selflessness
On April 11, 1970, the Apollo 13 mission was launched with
the goal of becoming the third time that humans were going to step onto the
surface of the moon. Two days later, an
oxygen tank exploded, which then caused the other oxygen tank to release its contents
into outer space. This crippled the Service Module.
One of the primary functions of the Service Module was to supply power to the Command Module, which housed the astronauts. With only fifteen minutes of power left, the astronauts were forced to move into the Lunar Module — which had limited, self-contained supplies of oxygen, water, and power — and use it as a lifeboat.
One of the primary functions of the Service Module was to supply power to the Command Module, which housed the astronauts. With only fifteen minutes of power left, the astronauts were forced to move into the Lunar Module — which had limited, self-contained supplies of oxygen, water, and power — and use it as a lifeboat.
Instead of trying to land the crew on the moon, the mission
became focused solely on bringing them back safely to earth.
For the next four days, extraordinary measures were
undertaken by the NASA support staff. Flight technicians stayed at their consoles around the clock, working on
every conceivable aspect of the rescue mission. Calculations for consumables such as oxygen, battery power, and water were fed into the computers.
Engineers had to write completely new
procedures and test them thoroughly, in just a matter of days. Simulations were run, checked,
double-checked, rerun, and then re-verified.
Their selfless devotion was successful, and on April 17,
1970, astronauts Jim Lovell, Jack Swigert, and Fred Haise landed in the South
Pacific Ocean. The story of the rescue
became the stuff of legend, spawning books and a blockbuster movie.
The survival of the crew and their safe return stands as an
incredible example of Winning Support.
Mission Control staff supported the astronauts by designing
new solutions and in giving detailed instructions by which to carry out those
solutions. They didn’t have email
in those days, so Communications staff supported the Mission Control technicians
by relaying messages between consoles using a pneumatic tube messaging
system. In fact, they even delivered
sandwiches to the Mission Control room using that same system.
One of my former managers was a computer programmer for a
NASA sub-contractor. She supported the
engineers who were performing the calculations and running the
simulations. She spent the entire rescue
mission in the basement of the Johnson Space Center hand-checking printouts of
diagnostic calculations made by the computers to make sure the computers
themselves weren’t malfunctioning. She slept only while waiting for the printers to finish churning out the next report to be checked.
There are many lessons to be learned from studying the
Apollo 13 rescue mission even though most of us are not rocket scientists or
hold others’ lives in our hands. Whether
we provide support for nuclear plants, hospitals, office software, video games,
or content-driven web sites, there are lessons that can help us provide Winning
Support to our own clients.
One of the most critical elements of the Apollo 13 mission was
the attitude of all involved: Failure is not an option. Each person involved with the mission had to be
selflessly devoted to the astronauts, putting the needs of the crew and
of the mission ahead of his or her own needs. In effect, the mission support staff had to adopt an attitude of servanthood
toward the crew whose very lives depended upon it. The consequences of not following through on
their tasks did not have to be explained.
In my own quest to provide Winning Support, I have had to
ask myself some tough questions:
- How much of a servant’s attitude do I bring to my job in supporting my client and in maintaining our software?
- Do I put the needs of my end-users above my own?
- Am I putting others first?
- Am I here to serve my clients or am I just collecting a paycheck?
I have found that how I answer these questions has a direct
bearing on my own job satisfaction, and I am absolutely positive that this is especially
true in a Support or Maintenance role. The
ongoing, day-to-day grind of facing never-ending problems from the field has
the potential of eroding a person’s soul. The Internet is full of stories of Support technicians who have erupted towards
their clients, walked off their jobs, and ended their careers in frustration.
I don’t want to be one of those stories, and I’m pretty sure
you don’t want to be, either.
From painful introspection, I know that when I have not had
a servant’s attitude toward my clients, my job has seemed frustrating. When I have put my needs first, I felt like I
ended up in last place.
But yet, that same introspection reveals that when I have
been most fulfilled in my career — when my job satisfaction has been the
highest — the needs of the users have been first and foremost in my mind. My best work — my most creative solutions — have
come when I have tried to solve their
problems, and not my own.
Napoleon Hill was a man who studied the movers-and-shakers
of the early 20th Century and tried to encapsulate the secrets of
their success. He became successful in
his own right, becoming an advisor to two Presidents of the United States. He commented on this very subject, saying, "Great achievement is usually born of great sacrifice, and
is never the result of selfishness."
The support staff at Mission Control whose efforts brought back Apollo 13 exhibited that sacrifice and unselfish
behavior.
Compared to Apollo 13, our jobs might
be considered mundane, and lives may not hang in the balance. However, I believe that if we put our clients
first, we will achieve great things; and if not great things, then great satisfaction.
The best way to serve our clients is
to follow good, solid principles in our code.
We can make life easier for them by making our software easier to use. We can provide clean and efficient solutions. We can clean our code so that future changes in
requirements have a minimal impact.
Winning Support starts with an attitude; only time will tell where that attitude will take us.
Let’s start Winning Support.
Sunday, April 27, 2014
Winning Support
Hi. My name is Bob
Rench, and I've been involved in all aspects of software development since the
early 1980s. I started programming in
high school on an Apple IIe, and in college, wrote my first commercial program
in dBase II, running on an Osborne 1 luggable.
Since then, I have worked for huge, medium-sized, and tiny companies. I've worked for multinational corporations,
as well as for companies so small that we held all-hands meetings over lunch at
Olive Garden.
I have designed and implemented enterprise-level software,
both pre- and post-Internet; from old-school fat-client software applications
to web sites and web applications. I'm a
survivor of the OS battles of the 90s (hint: OS/2 lost, but shouldn't have),
the browser battles of the early 2000s (go Netscape … er … Mozilla ... er ...
Chrome), and the managed-code skirmishes between Java and C#.
I've seen a lot of things come and go in the last 30 years,
but, no matter what new technology comes along, somebody still has to support
the clients and maintain the software.
Support and Maintenance.
Ugh. (I heard you.)
It’s a necessary job, and isn’t glamorous. Sometimes, it can be extremely frustrating dealing
with all kinds of headaches, from systems that just stop running, to data that
gets corrupted, to users who don’t know how to run such well-crafted,
thoughtfully-designed, well-engineered software. If you are lucky, you only have to work on
one issue at a time, but typically, it’s more like playing Whack-a-Mole. On a machine that doesn’t register the hits. While drunk.
Some days, things can be so quiet, you might say to a
friend, “You know, things are really going great! My queue is empty, so I’m going home early to
relax.”
And when you come in the next day, you wish you had not
tempted the software gremlins; before you know it, three weeks have gone by
with no end in sight.
Even if you love solving problems (admit it: finding a
solution when everybody else has failed can be such a rush!) Support and
Maintenance roles can often feel like a soul-sucking swamp, and you can’t wait
to find another job — any job!
If that is how you feel, then I think you’ve come to the
right place.
Maybe you’ve been slogging through the swamp for a while,
wondering if you’ll ever get through it to firmer ground.
Maybe you’ve just started your career, and somebody had the
brilliant idea of putting you on the Support or Maintenance teams to learn the
software, but dealing with legacy spaghetti code is driving you crazy.
Maybe you have a tough support issue and need some lateral
thinking.
I know how you feel, because I have been there many times in
the past.
Recently, I was asked to take on support for a large, legacy
website. Maybe I had forgotten how much
I disliked support in the past, so I said, “Sure, why not?”
Perhaps I’ve matured, or maybe it’s because I love being
challenged by multidimensional puzzles, but I can tell you that I don’t feel
like I’m stuck in a swamp like I did on my last Support gig. Instead, I have found that a Support and
Maintenance role can be satisfying.
I currently work at the world’s largest digital-marketing
company; a company whose clients include some of the biggest names in the
airline, fast-food, beer, sports, and financial industries. I am privileged to be providing support and
maintenance for a Fortune 100 company, managing an international website, and supporting
content editors who are working in nine languages, including French, Germany,
and Chinese.
Like any living, breathing system, our website has evolved
over the past few years. That evolution
and growth has required providing creative solutions to meet new business needs,
while at the same time, making sure the old business needs are being met, and
all the business rules are followed.
But, no matter how well-planned the changes, no matter how
creative the solution, no matter how disciplined the developers, no matter how
thorough the testing, things happen; things break.
When things break, my job is to fix them. But I don’t want to just fix them; I want to
take the steps to make sure they don’t happen again.
After thirty years, I’ve grown weary of stumbling across the
same problems project after project. And
no, I didn’t create all those problems. Most
problems I encounter were created by a combination of poor design, changing
requirements, creeping scope, and shrinking budgets.
But, we all know there are better ways of doing things. Lately, the development landscape has been
shaped by powerful forces, such as:
- The Pragmatic Programmer by Andrew Hunt and David Thomas;
- Clean Code by Robert C. Martin (“Uncle Bob”); and
- Development philosophies such as Agile, using Scrum, eXtreme Programming, Kanban, or Test-driven Development.
These are great tools to have at our disposal. But, there is a lot of legacy code around that
was not developed cleanly. Or, how many
times have we known that there was a right way to do something, but were forced
by budgetary or time constraints to just get it working, and then fix it later?
Usually, “later” never comes. And, once again, we’ve made the same mistake our predecessors did.
It’s like playing a video game where we have to kill the monsters in a particular room. We enter the room, turn left, and get pounded by the monsters. We re-spawn, re-enter the room, turn left, and die once again. We keep losing the game because we keep making the same mistakes.
Let’s start doing things the right way.
I want to become better at my craft. I want to become more disciplined as a developer and more creative in my problem-solving. I want to improve.
I want to provide outstanding service to my clients; after all, they allow me to have two things that I really enjoy: sleeping indoors and eating.
We can do this.
Let’s start Winning Support.
Subscribe to:
Posts (Atom)