Dare wrote a post talking about the advisability of making developers do operations.
Which is really part of a philosophical question…
When you're setting up a software organization, how much specialization should you have, and where you should you draw the lines around the responsibilities of the various groups?
Some orgs take a very generalized view of what people own, and others take a very specialized view. I've worked in both sorts of environments.
I've worked for a startup where, as a developer, I wrote the code, tested the code, built the code, made tapes to ship out to customers, and answered customer support calls.
And I've worked in other organizations where the job of developer was to implement what was written down in the spec and pass it off to the QA org. Those orgs typically had structures and policies designed to insulate the developers, so they wouldn't be distracted.
That eliminated a bunch of the outside noise that they would otherwise have to deal with, and make them more efficient at getting their development work done.
And how did those efficient organizations fare in their products?
Not very well.
They were reasonably good at shipping software, but their software didn't turn out to be very good for users. New updates didn't address issues that users had been hitting. New features were hard to use and/or didn't hit the sweet spot. They answered questions that users didn't ask.
All of this was because the developers were out of touch with people who had to deal with their software. They didn't feel the pain that the users were experiencing setting up their software. They didn't feel the pain when a bug in the software meant that the user's business was loosing money. And they didn't understand why users were having trouble using features that seemed obvious to them.
All that happened in DevDiv, and the issues showed up in our customer satisfaction numbers. So, it was decided to let developers (and the testers, and PMs…) talk directly with customers.
There was a fair amount of angst around this decision. It would take up too much dev time. Developers would insult customers. Customers didn't know enough to give good feedback.
But it turned out that all of those things were wrong. The developers liked to solve problems, and they also liked to help people. They remotely debugged customer issues on other continents. And they listened very closely to the detailed feedback customers gave about how the current software didn't meet business needs and what was good and bad about future plans.
And the organization adapted what they were planning, so that it addressed the areas that needed addressing.
Distraction is not the enemy. Pain is not the enemy. Pain is to be embraced, because only through feeling pain are you motivated to make it go away. [Eric Gunnerson's C# Compendium]