How Hudson Software became the preferred choice for Technical Support and QA services
In 1987 I found myself unemployed in the New York area, with a house, a wife, a baby, a dog, and a mortgage. With a master’s degree in Computer Science, I had been happily and fully employed for years working at various aspects of educational computing. I had written software, consulted with educators, consulted with publishers, and done marketing and sales campaigns to put Apple II computers into schools. But right then it didn’t seem like anybody in NY had a job for me.
There were a lot of large traditional print publishers in New York, and they were all interested in putting out software to go with personal computers. But there was no job at a publishing house for a “software person.” In those days, the software was “sizzle” to help sell the steak, which was the books. Whatever editor showed a slight inclination or interest in software got the job of producing it to go with their textbooks.
So instead of going on job interviews, I starting interviewing the publishers to find out what they needed. I offered myself up as a freelancer to help them with producing software.
Traditional print publishers weren’t prepared for the ups and downs of software development, especially in those early days.
All of the traditional print publishers needed help with software, even if they didn’t know it. They had all hired developers to create software for them (or were considering it). None of them had the skills to write a clear software specification for a developer to work from. None of them understood just how different creating a piece of software was from producing up a print product. If a software developer told the publisher that the software was finished, and they saw the developer demo it, they were likely to just send the floppy disk to the duplicator, and insert it in the back of the book. There was no thought given to testing.
Traditional print publishers weren’t prepared for the ups and downs of software development, especially in those early days. Even a well-intentioned, highly skilled software developer was likely to run into problems during development. Hardware wasn’t always standard, tools were relatively primitive, and operating systems (Windows, especially prior to Version 3.1) was very buggy.
Part of the problem was that the publishers and the developers didn’t really speak the same language. The developers couldn’t explain the kinds of problems they had, and what was important to them, while the publishers weren’t always clear either before or after the contract about what the priority items were. A developer might get hung up for a long time on some particular graphic, throwing the schedule off, while they tried to perfect the look of something. The developer might not realize that the publisher cared more about the schedule than a particular graphic or animation. Or the developer might have a real technical problem, perhaps not even their problem, but a bug in Windows or the development tools. They needed to work around this to keep on schedule, or possibly to change the spec slightly. But explaining it to the publisher proved difficult.
With a written QA report in hand, discussions with developers became more productive.
So Hudson started with me acting as the go-between, or the translator if you will, between the two groups. I would orient the developers as to what to fix first, and what kind of compromises were easy for me to sell to the publishers. And I would orient the publishers as to what real problems the developers had, and help them make decisions and compromises that would serve everyone and get the products un-stuck and on schedule, or at least close to schedule. Helping the two groups work out these problems became some of my earliest freelance jobs.
Not every developer was thrilled with this arrangement. Some of them persisted in denying reports of bugs, and ignoring parts of the program that didn’t meet the specs. So the first Hudson “product” became the testing report. When we couldn’t resolve the problem with conversation, we would do an extensive QA test of the product, finding all the bugs, and documenting them with screen shots and sequences of actions which would trigger the bugs. This became an easily understood service that publishers found helpful. With a written QA report in their hand, discussions became more productive.
Even when the software is free, customers expect to be treated well on the phone.
The second service Hudson provides, technical support, came about for similar reasons. The publishers had little or no idea what to do with user’s phone calls. One of my two earliest clients published the phone number of an associate (an entry level job) as the technical support number. She was supposed to collect the information or pick it up off voicemail, and send it on to the developers. Then the developers told her what to tell the customer. As you can imagine, that arrangement pleased no one, but had the virtue of not costing much money.
My other traditional publishing client published the software developer’s number as the tech support number. Their assumption was that the programmers knew the software better than anybody and would be the best people to solve user’s problems. Well, complaints started to come in. Even when the software is free, customers expect to be treated well on the phone. It turns out that programmers aren’t great communicators with non-technical people, and they don’t like to have their work interrupted by phone calls. It also turns out that they often don’t have very good empathy skills. They didn’t sound appropriately helpful or sorry. When they offered users a solution, the users got the feeling they were being shunted away, or that if they asked any questions, the programmer would be angry if they had to explain anything they had just said. And having written the program, they had a habit of denying that there were bugs, and assumed everything bad that happened was user error.
Technical problem solvers are what was needed.
In this I sensed an opportunity. At that time, almost all technical support was done in house at software companies. But traditional print publishers had no pool of employees they could assign to be technical problem solvers. Thus I decided that I would provide exactly the kind of service that the publishers needed.
It took a while to convince my largest client that it was a good idea, and that I would be perfectly happy sitting in my home office and taking their phone calls. After six months, I had figured out the pieces of running a call center: procedures for handling calls, a method keeping records and billing, and a knowledge base summarizing the important things you needed to know to take a phone call, and what the common problems and solutions were. So I hired an employee to take the phone calls, and shortly thereafter Hudson started tech support with other publishing clients, and the business grew from there, forcing me to leave my house and get a real office.
