Free Newsletters

   All InfoWorld Newsletters
IT Troubleshooter | Harper Mann » Tired Programmers

July 25, 2007 | Comments: (0)

Tired Programmers

I've picked up an interesting new book called The 4 Hour Work Week by Tim Ferriss. Aside from addressing the essential—yet rarely asked—question: what do you really want from life?, the book suggests that you can outsource parts of your life so you can be more efficient about delivering work results.

This has relevance to coders in a development group. I know some really good programmers who are tired. Really tired. They work at a start-up and service any and all requests from sales to fix customer problems. These requests arrive fast, furious, at random intervals and are basically one-off tasks that are customer specific.

While these tasks are great for staying "sticky" with the customers, scaling this kind of business is next to impossible. I'm sure this is always a trade-off in a product where the general cases are only so interesting to specific customers, but the custom work is just not scalable. It’s a staple for Open Source companies, because when the software is “free,” support services are often the most valuable product. So, how do you balance servicing customer requests directly but still capture general solutions that can be rolled into a product for general sale? Do you put your best programmers on the customer tasks or do you put them on the main product so you can evolve the foundation? How do you get the most bang?

Posted by Harper Mann on July 25, 2007 09:27 AM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




Used to work for a company with about 150 customers, and about 150 employees. The product was very customer oriented. Product was pricey enough to support the company, but cheaper than the competition.

The company had unique customer support. There was a customer support team of about a dozen individuals, who specialized in different areas of the product. When a customer called in, the support phone number was answered by one of these people, who would enter a ticket and either resolve the issue, or inform the customer that the support person who had expertise in that area would be calling back. Then the individual with expertise in that area of the product would research and resolve the issue, whether it was explaining how the software worked, or making programming changes if needed.

Patches that fixed bugs were immediatly available for distribution to any other customer who had the same problem, and were rolled into the next release of the product.

Meanwhile the development team would hold periodic meetings with a customer advisory panel who would identify areas of the software that needed improvement in general or new requirements that needed to be met.

After a new release went beta, a few volunteer customers would migrate to the new version, and for a period of time, calls from these customers were refered to the development team. Once major issues were resolved, the product was released, and further calls were handled by the customer support team.

I guess a partial answer to the tired programmer problem is to have a customer support team knowledgable enough to take some of the tasks off the developers shoulders.

I don't know how to address the issue of scalability.

Any product that requires in depth knowledge of the customer's unique business processes can not afford to be too big or too remote from the customers. If you try to make the product all things to all people in attempt to increase your market, you are bound to drop features that are needed by only a small percentage of your customer base. Your customer support will devolve into a number of individuals who do no more than answer the phone and document the problem or worse a voice response system that walks you through a script that in no ways addresses the issue the customer is calling about.

I found that working in customer support, you encounter a tremendous variety of individuals, none of whom are stupid. They are just trying to get their job done. Ninety percent of the time what they are calling about, is something that the developer of the software had no idea the customer would encounter. You can't script that.

Posted by: gostak at July 26, 2007 06:30 AM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links