support serf to writer: part II

this is part II of a story about software support and how I moved through various jobs...
part I - support serf to writer: a how-to

when I joined NCompass, the .com economy was at it's peak. it was the time when great things could happen for a technology company. but it was clear to some people that the glory days wouldn't last forever. one NCompass manager told me at a company hockey game that "being an internet-focused company right now is like being in a gold rush -- everyone is trying to get their before the gold runs out." it was this sort of thinking that led the NCompass board to tell its executives to spend like "drunken sailors".

<how-to section>
I started at NCompass labs as a trainer. this was a good example of getting my foot in the door so that I could work towards other things. I wanted to do something more technical, but it was a way to get some experience at a software company. I believe that getting your foot in the door is the key to making big strides. by working along side the right people, I was able to form relationships that lasted for years. some people call it networking but that almost implies that it's some form of deception. genuine relationships are far more valuable.
</how-to section>

that position didn't work out -- I simply wasn't a good fit for what they were after. my manager and I simultaneously came up with the idea that I should move to the support department. most people would view this as a demotion -- yet another example of the support department not getting enough credit for the crucial role that it plays.

when I moved to support, there were about a half dozen support reps. although, one was soon fired for using company time and resources to run his own support business. after he was canned, he tried to get a product key for Resolution; he actually called the help desk and pretended to be a customer. the support rep recognized his voice and told him that we would have to check his credentials. when we contacted the customer, they confirmed that the caller had used a fictitious name.

the most challenging aspect of supporting Resolution was that NCompass didn't track how many cases each customer logged. believe it or not, we were also responsible for free pre-sales support. during this period, there were about 350 open cases and six people to handle them. in contrast, Microsoft tries to keep their case allocation to less than 20 per support rep. hiring was extremely difficult during the bubble, but NCompass did eventually increase the support staff to around a dozen people. the days when one person had 100 cases (which actually happened) were over.

I enjoyed the experience of working on something that was innovative. at the time, it was unusual for anyone to use a database on their front-end web servers. Resolution was meant to run in this fashion -- although there was a 'staging' option for those who weren't ready for the leap into dynamically rendered data or online web-based authoring. Resolution also had a top quality Application Programming Interface (API). the API was my favourite feature and I enjoyed playing around with it. in fact, I saw the API as the perfect way for me to hone my technical skills.

I tried many times to get sample applications added as part of my job responsibilities. one of my managers hated the idea -- the company need to keep people in the support department and he probably saw my interest as an attempt to get out. eventually we made a deal that I could volunteer my time as long as it didn't interfere with my actual job. the irony is that there was a need for such applications. at one point, the company ran a contest for the best sample app. the prize was an old foosball table that had just been supplanted by a proper tornado brand foos table. I won the table with a dynamic image gallery app. although, for posterity, I feel that I must note that I was the only one who finished on time.

I was having a good time working on sample apps, and NCompass was a fantastic environment. I was truly fortunate to be part of such a great company, but I still had to deal with the tribulations of being part of the support department. I was working in support despite the overshadowing knowledge that those of us on the front line would not get all that much respect from the industry. this is something that most support people just deal with.

there were times at NCompass when I received a great deal of recognition. however, these were almost always related to some work that was outside of my job description. people who worked hard within their defined support role were generally below the radar.

after NCompass had been absorbed into Microsoft, I heard a story that amazed me. one team in the company was told that they could go on a rabid spending spree weekend. they actually spent more money than I made in a year. the party was a celebration for meeting an annual goal. did free pre-sales support play a role in meeting that goal?

I've written about a pervasive lack of respect so I had better cite some examples. working at NCompass I was once asked to take over a case with an angry caller. the original support rep was so offended that he could not deal with the person in a rational manner. he later said that he felt like he was treated like a dog. you assumed that I was talking about a customer didn't you? no, it was an NCompass employee who had called. fortunately, that guy didn't last long. but it just goes to show that even within the company fold, support was considered a lower caste.

what role does support play? at NCompass I figured that the experiences of being on the front line were not systemic. surely at Microsoft things would be different... but would they?

I'll get to that, but I want to first address the obvious counter argument that is bubbling up in the minds of some of the readers out there. it goes like this: support is paid less and given fewer perks because the people in support aren't as skilled as those in groups such as development group or consulting. after all, software companies make software. the people in support don't make software.

first of all, the astute will see that there's already a crack developing in this logic. a company is comprised of many different parts. in order for the company to be successful, all of these parts must be functional. the argument about developers being the only contributors to a software product is ridiculous. without the sales team, how would the company make any money? without the support team, who would put out the fire when a company's web site goes down?

and what about the first part? the idea that only developers have skills. have you heard of a software product that didn't have bugs? no, me neither. the reason for this is that devs make mistakes. more often than not, the support group takes the flack for those mistakes. yes, it's true that management sometimes encourages errors with unrealistic timelines, but no one is perfect. people need to remember that the support department is created by the developers' mistakes.

saying that support staff aren't skilled is a gross generalization. for the purposes of this post, 'support' is primarily used to refer to problems that arise from actual product bugs. I am most certainly not referring to cases where the customer has created the problem through their inability to use the software. I'm not talking about supporting people who are having issues while writing their grocery list in word.

at microsoft there is a group in support called SIE. I think it stands for something like 'solutions integration engineering.' if you saw the cases that those folks handled, you would have a different impression of the skills of the support team. they are given cases which involve the interaction of countless technologies and network configurations. resolving cases that complex is an ability completely outside the scope of most developer's experience. in other words, complex debugging requires smart people with considerable training.

coming soon...
support serf to writer: part III (working at microsoft)