"I'd love to have ten of you. Would you like to be cloned?"
Dan Quigley, manager of the Premier Developer Support Team, was sitting with me for my August 1991 performance review. As I have already described, helping other programmers gave me a deep inner satisfaction and a special joy that inspired me to an extraordinary level of productivity. Dan thoroughly agreed and said so on my review. The subsequent raises and bonuses I received were nothing short of extraordinary themselves.
At the same time, I wasn't particularly happy with the outward circumstances of my job, so much so that my response to Dan's idea of corporeal duplication was that "ten of me would not work here." Though my comment saddened Dan a bit, he was not insensitive to my struggles and did his best to brighten my spirits.
Both of us were trying to understand what had changed. A short twelve months earlier I was a bright-eyed, enthusiastic young new hire who rapidly became one of the best engineers in our entire department. But now I was becoming more and more cynical by the week—not with the ideal of helping other programmers, mind you, but rather with the organization, Developer Support, through which I was trying to manifest that ideal. I loved my work but came to despise my workplace.
The situation here was not unlike many a Dilbert cartoon. Friends who have not experienced the corporate life sometimes ask whether the stuff they see in that comic strip has any basis in reality. "Well," I reply with a chuckle, "just about all of it's true—only slightly exaggerated!" Indeed, Dilbert is often inspired by real-life stories about the outrageous quirks of the modern corporate scene, especially those involving the all-too-common failure of employees and managers to see eye-to-eye on just about anything.
Perhaps Nature intended it this way; if nothing else, it at least adds to the richness and diversity of life. Managers often have tens if not hundreds of employees under their wings, not to mention endless worries about budgets and such, making it practically impractical to really understand the perspective of any individual worker. Workers, for their part, are notoriously small-minded and/or selfish, concerned mostly with themselves and their particular jobs in the here-and-now. So when management decides to invest in brand-new office furniture, for example, to "make everyone more comfortable," those who are already content say, "Well, if you really want to make me more comfortable, how about giving me a pay raise instead?" And so it goes on.
Being all of 22 years old at the time and still full of youthful immaturity, I was not only unable to relate to what Developer Support's upper managers had to contend with, but was pretty much unwilling to even try. In my mind, what I wanted and what I felt was right were all that mattered. I wasn't open to other points of view.
I had started my Developer Support job with the correct understanding that customer service in our line of work meant solving the multifarious problems that those customers sent to us every day. Therefore, we answered questions over the phone, answered service requests (as we called those questions that came in electronically), and disseminated our growing expertise through Knowledge Base articles. In this latter way, especially, we hoped to create a resource through which programmers could find many answers on their own. So far, so good.
In my mind, however, this was only the beginning. I tried to write articles that would guide people through complex tasks from start to finish rather than addressing only specific troubles. In my sample programs, too, I did my best to show how something was done and to offer self-contained code that other programmers could just drop into their own projects as-is. In time, I thought Developer Support might even make its own business out of small, reusable software components that addressed our customers' most common difficulties. I figured that if Developer Support could take on the task of writing and testing such components, it would save other programmers the trouble and, in turn, greatly reduce the overall volume of support questions. In time, we might make it so simple to write Windows applications that the need for developer support as we understood it could be wholly eliminated. And by so making our present jobs obsolete, we'dhave the freedom to pursue even greater things.
These thoughts infused my assigned duties with a passionate sense of purpose and direction. For such goals I was willing to make personal sacrifices that I would not have made for other projects (like Windows NT, see Chapter Five). Still, I recognized that my ideas were somewhat revolutionary and best kept to myself. It wasn't my responsibility, after all, to set a direction for our department! I could only nurture the hope that those in charge would, in time, take notice of what I was doing and become interested themselves.
Unfortunately, I was also rather attached to this particular outcome; so attached, in fact, that I was utterly blinded to the special recognition I did receive for my work. Attachment is, indeed, blinding, and in my case it also caused me to place the worst possible construction on a variety of wholly benign circumstances. As a consequence, I felt increasingly thwarted in my aspirations and thus increasingly angry.
It started small, literally, with a somewhat minor award that I didn't get yet felt I deserved. Around the end of 1990 upper management began to recognize individual excellence at our monthly departmental meetings with these precious little six-inch faux-marble pyramids embossed with an appropriate motivational maxim. For the first few months I cheerfully applauded the recipients of the award. It was obvious that they had gone above and beyond the call of duty. Naturally, then, I felt it wouldn't be long before I was also honored—I handled far above the average number of calls and service requests each day. I wrote more Knowledge Base articles than most everyone else combined. And Microsoft Systems Journal had recently accepted a more extensive article of mine for publication. This alone was a significant achievement for any engineer within Microsoft, let alone a support engineer.
Yet month after month I was passed over, even after the list of other notable individuals was wholly exhausted. The awards were now going to people whose performance, from even the most unbiased perspective of raw statistics, couldn't shake a stick at my own! I just couldn't understand it. I seemed to be the only one whose special efforts went unnoticed, and it hurt.
Had I bothered to ask anyone about this, I would have easily discovered my being selected to help found the elite Premier Support Group was a much greater reward than some plastic pyramid! But I never did ask. Cursed, you might say, with an annoying tendency to stew over baseless assumptions about the intentions of my superiors, I have, on occasion, allowed myself to become frustrated without cause. Today, at least, I'm aware enough of this tendency to catch myself before some minor frustration snowballs into outright anger. Back when I was 22, however….
◊ ◊ ◊
Enter Snowball #1
Within Microsoft's unique corporate counter–culture, classical Dilbert-inspiring office policies were rarely to be found. The dress code was lax. There was little opposition to setting up a popcorn machine and charging supplies to the departmental budget. And with private offices with solid doors, no one could complain about your personal environmental preferences, save that of noise.
In Developer Support, we naturally followed suit (or the lack thereof). We rarely had any face-to-face contact with our customers and even then we impressed them so much with our enthusiasm and the quality of our work that outward appearances were somewhat unimportant (as told in the story at the end of Chapter Six). Having our own popcorn machine provided a quick snack and the ability to keep on working even if the cafeteria was closed or if we lacked pocket change for the vending machines. And it was a long-standing tradition within the cubicle farm of Developer Support that we generally kept the fluorescent overhead lights turned off. In the days before flat-panel LCD and LED screens, programmers typically liked to work in moderately- to dimly-lit rooms because it's much easier to stare at a screen for twelve hours straight if there isn't any glare on the monitor. And without individual offices, we had agreed en masse to turn the overhead lights off and let everyone illuminate their own space with desk lamps. (For this reason our area was known as the Bat Cave.)
At the same time, upper management rightly wanted to encourage a certain degree of professionalism within our ranks because although we didn't see our customers that often, we talked to them all the time. The principle here is that one's demeanor is subtly influenced by one's environment in surprisingly powerful ways. As Malcolm Gladwell illustrates in The Tipping Point, if you are always surrounded by sloppiness, you will tend to express or favor sloppiness in other parts of your life; if you are surrounded by refinement, you will tend to express or favor refinement. This is true of how we hold our bodies, how we speak, how we write, and, indeed, how we even think. So be very careful in choosing your influences! Environment is generally stronger than will power.
In the professional context of Developer Support, a threadbare T-shirt motif with an optional theme of 1970s-era running shorts, for example, wasn't exactly appropriate. Likewise, the popcorn machines were rather aromatic if not messy—besides the obvious fact that answering a phone while chewing a mouthful was not a very good idea. And somewhere it had been shown that people (at least those on a manufacturing floor) were more productive under bright lights. Therefore, we were informed that thrift-store fashions could no longer be allowed, that the popcorn machines would have to go, and that the lights would remain on. Simple as that!
Now as far as most employees were concerned, these things weren't even issues to begin with. They already dressed well, they didn't care one way or the other about popcorn, and some actually preferred the overhead lights. A few of us, on the other hand, held the opinion—and voiced it fearlessly!—that these new rules were absurd. The slobs protested by dressing worse than ever. The popcorn junkies among us began to employ the microwave variety with reckless abandon. And the Anti-Fluorescent League turned almost militant.
My personal thorn was the lighting. "We've been perfectly happy without the lights," I cursed under my breath, "so why should we have to keep them on now?" Failing to see any good reason for the new policy, then, I took it upon myself to keep the lights turned off. Whenever someone from upper management came by and turned them on, I waited until they left and turned them off again. When they had special tamper-resistant switches installed, and turned the lights on, I found a way to tamper with a paper clip and turned them off again. Above my own desk, I also found it convenient to simply reach up and pop the bulbs out of their sockets. But this was apparently a violation the local fire code, so someone kept having the bulbs put back in. I pulled them out again anyway.
Obviously this sort of tussle didn't have the most uplifting effect on my attitude. It was, in fact, degenerating a little more every day. "Why," I fumed, "can't we just be left alone to do what we'resupposed to be doing? Why does the lighting have to become such an issue?"
I wasn't helped by the fact that at this time I was deep into William Shirer's comprehensive history of Nazi Germany, The Rise and Fall of the Third Reich What did I just say about choosing your influences? Reading that book heightened my sensitivity—and my stubborn resistance—to all forms of what I considered petty tyranny, whether real or imagined. I also read the classic team-management book called Peopleware by Tom DeMarco and Timothy Lister, a wonderful title that I highly recommend to anyone in a leadership position. If, on the other hand, you're an unempowered cube-jockey like I was, better give it a miss. For me, reading that book simple highlighted everything I felt our leaders weren't doing right, and that didn't help my attitude at all….
◊ ◊ ◊
Enter Snowball #2
During Microsoft's first fifteen years or so, it had pretty much been the case that once a development team sent a product to manufacturing[*] it became the responsibility of Product Support. If there were serious problems the development team could of course provide a patch or an update. But if end-users were having trouble installing it, running it, or simply understanding it? That's what Product Support was for.
As products became more complex, however, they were also becoming more and more difficult—and expensive—to support. At the behest of the development teams themselves (and over the protests of our own upper managers, I later learned), it was decided somewhere on high that Product Support should submit a quarterly operations cost to each product development team who would then reimburse the expense. This would give those teams a reasonable measure of how "supportable" their products were and make them directly accountable for it. They would then naturally want to create better products and thus reduce their financial liability. So went the theory.
In practice—to generate the cost figure—someone decided that all engineers within the Product Support Division would report, accurate to the quarter hour, how much time they spent each week supporting different products. A simple system was devised to categorize those numbers by product, add them up, and send the bill to the appropriate development team.
For most of Product Support this process was practically effortless: 95% or more of the engineers ever dealt with only a single product. All they needed to do was report the time they spent answering customer questions, save a bit here and there for the occasional excursion into foreign territory or the time they spent in research and ongoing education.
In the Premier team where I worked, however, it wasn't nearly so simple. We (all four of us) personally and individually handled each and every question from our specific clients no matter what those questions involved. Solutions often crossed the boundaries of two or more products, sometimes as many as five or six. I could just imagine:
Me: "Thank you for calling Microsoft Developer Support. How can I help you?"
Caller: "I'm trying to connect to a SQL server from within our Windows application, and…."
Me: "OK, hold on a minute, let me record this. <mumbling> Five seconds for the Windows Software Development Kit, start clock for SQL Server…OK, please proceed."
Caller: "Uh, yes—this SQL server is running as a background process under OS/2…"
Me: "Got it—ten seconds for SQL. What's next?"
Caller: "Huh? Er—well—this OS/2 machine has LAN Manager 2.1 installed whereas the Windows client is running Novell NetWare 6.3 and…."
Me: "OK, OS/2, eight seconds, LAN Manager, five seconds, Windows, four seconds, Novell NetWare—wait a minute, we don't support Novell—how do I count my time for that?"
Caller: "W-what? Why are you counting seconds?"
Me: "It's my job, don't you know?
I'm exaggerating, of course, but you get the idea—it seemed ridiculous to expect that our numbers would mean anything unless we expended considerable energy just to record them. Even if we did, our supposedly accurate numbers would ultimately be collapsed with hundreds of others into a single figure on someone's budget spreadsheet for apparently no other purpose than shuffling some money around.
As a team, then, we decided it would be much easier if we just made some numbers up. To spare us even that trouble, my teammate Charlie Kindel whipped up a little random-number program to do all automatically!
Well, word got out about our little trick and someone was sent down to put things straight. Standing in my cubicle, the fellow who was second-in-command in Developer Support—a man I'll refer to as Arnold—did his best to give us, and myself in particular, a real pep talk. With admirable enthusiasm and a transparent belief in the goodness of the whole system, he patiently explained why our participation was important for our department, our customers, and Microsoft as a whole.
Now, had I been more in control of myself I could have just nodded along with Arnold while continuing to have Charlie run numbers for me. But noooo—already perturbed about those cursed fluorescent lights (which Arnold had just turned on again, if I remember correctly), I wasn't in the mood to play sandbag to what I saw as another outrageously cumbersome policy. Allowing my red-haired temper to get the better of me, I gave Arnold a piece of my mind. "The whole scheme is preposterous!" I snarled, "it's not worth the effort to track my time. So whether you like it or not, I'm just going to make my numbers up." In fact, I told him that he could save me a lot of trouble by just making them up for me. So there! Ha! Grrr!
I don't ever remember being quite so angry with any manager as I was then. Nor had I probably ever been so close to getting myself fired! But I just couldn't help it. From my point of view, I was doing everything possible to help our customers, while upper management seemed bent on obstruction. They seemed far more concerned about how long I spent answering questions rather than how well I answered them, not to mention whether I was answering them in a brightly-lit cubicle!
"Well," I consoled myself with a sigh, "at least they aren't rating our performance on the number of questions we answer. That would really be silly…."
◊ ◊ ◊
Enter Snowball #3
The 1990 introduction of Windows 3.0, along with a number of other stunning products like Word for Windows, created a dire crisis in Product Support. Sales were skyrocketing and millions of new users were suddenly calling in for help. Caught off guard by this unanticipated boom, end-user Product Support was utterly overwhelmed and desperately understaffed. Callers invariably had to wait in a queue, listening to Microsoft promos for as long as an hour before finally talking to an edgy support engineer who had already spent upwards to seven hours on the phone that day answering question after ceaseless question. Phew!
Under these intense conditions, the overriding concern was to answer, in some way, as many calls as possible and to minimize the wait time lest callers became disgruntled and dissatisfied. It was perfectly reasonable to then rate the performance of each engineer according to the number of calls answered in a day. Such a measure would more or less reflect one's ability to hone in on the customer's core question, get it answered, and quickly move on to the next call. Although this emphasis did tend to undermine quality a bit, it was simply preferable to give some kind of answer than no answer at all.
Goals were therefore set to increase the number of calls answered, keep the wait time under two minutes, keep the average call duration under four minutes, and prevent customers from hanging up while waiting in the queue. To monitor the ongoing battle, automatic tracking systems were installed that produced copious real-time statistics. Team managers could then rally the troops whenever an extra burst of energy was necessary on the battle front.
It wasn't long before all this proved marvelously effective. Calls were getting answered, fewer customers were dropping out, and the whole situation became manageable. What's more, the support engineers responded well—meeting and in many cases exceeding their numerical goals, and feeling happier too.
In Developer Support we also felt the surge as many new software companies were now jumping on the Windows 3.0 bandwagon. But whereas the sale of a million copies of Windows created a million potential callers to end-user support, it meant only another couple of hundred or so in our neck of the woods. Spread around three or four dozen support engineers, the actual increase wasn't all that significant, which was good! Unlike many end-user questions that could be answered in a few minutes, programmer questions could take several hours; the ones we dealt with in the Premier team often took days, even weeks. What mattered for us was that we got the questions answered thoroughly and accurately, and that we helped programmers understand the system more deeply. The number of questions we actually answered each day was quite irrelevant as long as we weren't falling behind the incoming requests.
Nevertheless, word came down from on high that we too would now be rated, like everyone else in Product Support, by the daily number of phone calls and service requests we answered. No more, no less.
"My God," I exclaimed, (embellished with my now customary under-the-breath profanity), "doesn't upper management understand what we actually do?" Here we were, especially in the Premier team, trying to help some very large companies move onto the Windows platform. Here we were, trying to understand the most intricate parts of a complex operating system. And here we were, trying to share information that would reduce the need for programmers to call us in the first place! "How on earth," we asked ourselves, "can they rate our performance on volume alone? Why, wouldn't we then be better off spreading mis-information?!"
In truth, our upper managers actually balked at subjecting us to this sort of thing; they really weren't given much choice themselves. And, as it turned out, such measures never became very important in our department—despite anything we heard to the contrary, our performance continued to be measured in terms of quality as well as creativity. One more incident, however, prevented me from really understanding any of this, an incident that made me feel that everything I was working for was being sacrificed on the altar of mindless statistics.
In early August 1991 my whole team took two days off to attend the Windows 3.1 Developer's Conference in downtown Seattle. We got a jump-start on the yet-to-be-released operating system and were able, for a change, to meet many of our clients face-to-face (we did dress decently). In our absence, though, we accumulated a sizeable backlog of service requests and phone messages. What's more, those of our customers who attended the conference were bursting with new questions themselves, and called in as soon as they returned to work.
That next day we were thus faced with both the backlog and a call volume at least five times the norm. If there is a special place in the 666 layers of Hades reserved for support engineers, this was it. A normal day for me meant answering maybe five calls and maybe three electronic service requests. This day—throwing precision, as necessary, to the wind—I answered a combined total of over sixty. After eight-plus non-stop hours, I was completely fried. Serious ultra-crispy.
It was at this exact point that chummy ol' Arnold stopped by my cubicle. Was it to talk about the lights? Thank God, no. Was it to talk about time-tracking numbers (which Charlie's program was still generating for us)? Nope. Was it to console me? Not. He actually came by to congratulate me. Yes, congratulate me. Having seen a big spike by my name in the call-tracking statistics, he enthused over how wonderful a day it must have been for me. "Wonderful?" I thought, "this one most miserable day of my entire career?" I really don't know what he was thinking. As for myself, I wanted to slug him. But exhausted as I was, I could only keep myself from weeping….
Thus it was a week or so later, in my performance review with Dan Quigley, that I stated with unequivocal certainty, "ten of me would not work here." I was thoroughly disgusted with the whole mess. All I wanted was the freedom to help programmers in every way I could imagine. Why couldn't I do this in Developer Support, of all places? Why? Why? WHY? I felt crushed on all sides and didn't know how much longer I could stand it. Something had to change or I would just explode.
Of course, I felt that the whole problem was with Developer Support's upper management. "they're the ones," I fumed, "who are the problem!" From the more unbiased perspective of over a decade, however, I see the error in that judgment. All the rules, all the policies, and all the tracking systems were perfectly acceptable and even desirable to the vast majority of support engineers. Many of my co-workers were happy then and continued to work happily in the group for years to come.
At the same time, my own feelings were somewhat justified by the fact that I was not alone in them—a fair number of others felt the same way, even if their experiences were not quite as intense. What's more, I couldn't believe for a second that my compassionate desire to help other programmers in every way imaginable was at fault. Sincere kindness and love is never a mistake.
But attachment is. It prevents us from seeing what's really trying to happen in any given situation. It prevents us from considering other possibilities, or other environments, through which we might better exercise our natural impulse toward growth and realize a greater degree of self-expansion. Being out of tune with this greater harmony, we experience pain.
My sympathies were expanding beyond the boundaries of Developer Support's limited though wholly valid mission. However, I clung to the mistaken belief that Developer Support was the one and only place where I could express those sympathies. Consequently, I kept painfully smashing into walls no matter which direction I tried to go, and in my frustration I could blame only the walls themselves and the people who had put them there.
To put it more gently, helping other programmers succeed was my special passion. From the beginning of my full-time career, Developer Support had been the soil in which that love, like a plant, could flourish. Eventually, however, the roots of that plant became bound, constrained, and even starved for nutrients to the point where better soil—or different lighting!—could no longer help. In short, what that plant needed to grow further and ultimately flower was simply a bigger pot!
Why, then, did I have to experience so much frustration in the process? You might remember from Chapter Three that young computer engineers like myself were generally not all that interested in making careers in the relatively inglorious fields of product support or marketing. No, we all wanted to be on the front-lines of high-tech innovation! For me, having failed at becoming a hot-shot software engineer, the opportunities I had in Developer Support seemed the next best thing. And had I not been so discontent with my circumstances, I would have stayed in that group for a long time, comfortable and complacent.
Complacency is perhaps the greatest obstacle to growth of any kind, especially spiritual growth, and it was exactly this complacency that God was now helping me avoid. Being open and expansive is the real solution for difficult situations like this. By allowing me—even inspiring me!—to become so upset with Developer Support, God gave me the openness and the courage to accept just about any other opportunity he might place before me, especially one that I would certainly have rejected outright under less intense conditions.
And what was that opportunity? You got it: marketing!
Shortly after my review with Dan Quigley, I got a call from my old friend and former manager, Bob Taniguchi. "Hey Kraig," he asked, "how would you like to work for me again?"
How would I!
Bob was then working in the recently formed Developer Relations Group (DRG), a kind of technical marketing team that sold faith rather than products. In particular, they promoted the newest technologies in Microsoft's yet-to-be-released operating systems—the Gospel of Windows, as we called it—to other software development companies. Bob was recruiting me to give DRG a more solid technical grounding and a better rap-port with outside programmers. They needed someone who could pro-actively remove whatever technical barriers might prevent the adoption of our latest innovations (poor documentation, lack of sample code, and so on). DRG also wanted an internal advocate for the developer community at large.
How could I turn it down? The job was virtually tailor-made for me. It meant working with the cutting edge of new technology as well as serving other programmers more directly, more creatively, and more effectively than Developer Support could possibly accommodate. It was perfect.
Still, I had to wonder just a little bit. Would I again run into boundaries? Could I truly give it my all and not wind up with ulcers? Would Developer Relations really give me the freedom I had been seeking in Developer Support?
That question was put to rest forever when I visited the man—whom I will call Friedrich—who would become my direct manager if I accepted the position. "The purpose of this job," he said, summing up the deal, "is to make yourself obsolete." The only measure of this goal would be my willingness and effort to give away absolutely everything I knew and learned. Music to my ears!
As a token of my acceptance into his group, he handed me a 40-ounce Louisville Slugger, the biggest and heaviest baseball bat you can find (the significance of which is explained in Chapter 8.) For the next two months or so, as I finished up my work in Developer Support, I often carried this bat around on my shoulders. It was way better than having one of those little plastic pyramids on my desk. For rather than merely symbolizing past accomplishments, it symbolized the strength of my convictions, the height of my ideals, and the future fulfillment of my aspirations.
And it also seemed to prevent anyone from confronting me when, as I continued to do until the day I left for DRG, I once again walked over to the switches, and turned off the lights.