Month: March 2013

I’ve been waiting on a delivery of books for about a week now. When I got my first notice from UPS about a failed delivery (they needed a signature), I deliberately worked from home the next day so I could sign for the package.

Imagine my surprise when I went out to get the mail that afternoon and found another “failed delivery” notice on my door! I checked the UPS tracking site, and sure enough, it said the driver had “tried to deliver” the package 15 minutes earlier.

Here begins a bizarre experience in customer service.

I used UPS live chat to contact their customer service department, asking if they could have the driver swing back by, since I was home and he obviously didn’t try to deliver the package. They said they couldn’t do that, but they’d report my problem to the local branch, who would contact me by the end of the day.

The local branch called – at 7:30 at night, well after close of business. They left a rambling voicemail that insisted the driver had tried to get a signature, but would try to re-deliver the next day. Alternatively, I could have them hold it, and pick it up between 8:00-8:30 am. They repeatedly mentioned I should call “the 800 number” to tell them what I wanted, but failed to tell me what the actual 800 number was.

So, second question: if complaints are handled locally, why was the local branch redirecting me to (I assume) the national office’s number?

The next day, I tweeted about my bad experience, and got a reply from the UPS twitter bot asking for more info. I emailed them my tracking number, hoping for some actual customer service. Boy, was I wrong. They sent back the same “complaints are handled locally,” response, even saying “I see the local office has contacted you already,” as if the fact that they left a voicemail made everything better.

Again, why the hell would the national office bother to find out more, if there’s nothing they can do?

So, instead of getting my package delivered – the service I paid for – I’m heading out to the UPS package center in the morning to pick up my books.

Let’s review all the mistakes here:

1) When confronted with a customer that didn’t get the service they paid for, UPS never admitted wrongdoing.

This is an amateur customer service mistake.

2) Rather than try to compensate the customer for the mistake, UPS bounced the customer between different departments.

This is like watching the federal and state governments argue over who’s responsible for bad schools – they’re both involved, so why don’t they work together to fix it instead of passing blame?

3) UPS is requiring the customer to complete the service on their own.

This is like a waiter telling you to go fetch your re-fired steak from the kitchen yourself. You’d never go back to that restaurant.

I’m amazed a company like UPS could fall on its face over something as simple as delivering a package to a house with a person inside. You’d think they’d treat their core mission a little more seriously.

If you don’t allow your software developers to work from home, you’re not just withholding a nice perk from your employees, you’re hurting your business.

Here’s five reasons letting developers work remotely should be the default:

1. Widen your talent pool

Good software engineers are already hard to find. On top of that, you’ve got to hire someone skilled in your chosen tech stack, which narrows the pool even further. Why restrict yourself to those engineers within driving distance to your office? Can you really afford to wait for talent to move close to you?

The CTO for my current gig lives an hour away from the office, and can’t move because of his wife’s job. We wouldn’t have been able to hire him if we didn’t let him work from home. Who are you missing out on because you won’t look at remote devs.

2. Reclaim commute time

The average commute time in the US is 30 minutes. That’s an hour a day your in-office developers aren’t working. If you let them work from home, they can start earlier and finish later.

Don’t think they will? The evidence shows they do: people working from home work longer hours than people in the office.

An extra hour of work a day is five more hours a week, or almost three more work days in the month. Why throw that time away?

3. Reduce sick leave

When I’ve got a cold or flu, I stay home. I usually spend the first day or two resting, but by the third day I’m usually able to work for a little, even though I’m too sick to go into the office.

If my boss didn’t let me work from home, he wouldn’t get those “sick hours” from me. I’d be forced into taking more time off, getting less done.

And when my wife’s sick, I don’t have to choose between taking care of her and getting my work done. By working from home, I can do both.

4. Increase employee retention

The only thing worse than not hiring a good dev is losing an engineer you’ve already got. When they leave, you’re not only losing a resource, you’re losing all the historical knowledge they have about the system: weird bugs that only show up once a quarter, why the team chose X db instead of another, etc.

Since the competition for talent is fierce, you don’t want to lose out to another company. Letting developers work from home sends a clear signal to your employees that they’re valued and that you appreciate work-life balance. And with many companies sticking to the old “gotta be in the office” way of thinking, you’re ensuring that any offer your employees get from another company won’t be as attractive.

5. Stay focused on work done

Finally, letting developers work from home forces the entire team to focus on what’s really important: getting work done. It doesn’t matter how many hours a developer spends in the office; if that time isn’t productive, it’s wasted.

What does matter is how much work a dev gets done: how many bugs squashed, how many new features completed, how many times they jump in to help another engineer. What you need from your developers is software for your business, not time spent in a cubicle. If they’re not producing, they should be let go. If they *are* producing, does it matter if they’re at a coffee shop downtown?

And if you don’t have a way of measuring developer productivity beyond hours spent at their desk, get one. You can’t improve something you don’t measure, and team productivity should be high on your list of things to always be improving.