The contractually obligatory beeper, and the customers who demand them
One of the fun parts of meeting with other developers, either at conferences or on my self-funded book tour, is exchanging war stories. Here’s one of the stories I’ve collected, from somebody describing a former company. As is customary, I’ve removed identifying information. One day, the engineering team were instructed that the team was being issued a beeper, and that a member of the engineering team had to be on call at all times. This new requirement was the handiwork of the sales team, who landed a big contract with a customer, but the customer insisted on a support contract which included the ability to talk to a member of the engineering team at any time, day or night, to be used when they encountered an absolutely critical problem that the support team could not resolve to their satisfaction. The engineering team grumbled but knew this was something they had to accept because the customer placed a huge order and the company needed the money. To secure the engineering staff’s agreement, management contributed $10 to a pool each week, and whoever was saddled with the beeper when it went off got the pool money as a consolation prize. The engineering team drew up a schedule, and responsibility for the beeper rotated among the team members. A week went by. The beeper didn’t go off. Another week. Still quiet. Months passed. Still nothing. It was over a year before the customer asked to talk to a member of the engineering team. The engineer who received the windfall understood that the prize was a team effort, and as I recall, he spent it by buying beer and snacks for everyone.
The engineering team figured that the customer had the engineer on call clause on their list of bullet point must-have features, even though they didn’t really plan on using it much at all.
Light
Dark
0 comments