Compartilhar via

Feel the pain...

  • Artigo

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.

Comments

  • Anonymous
    August 21, 2006
    The comment has been removed

  • Anonymous
    August 21, 2006
    "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. "

    I worked in the OS development group of a Fortune 100 company where I wrote the code, tested the code, buildt the code, made tapes to ship to customers and fixed bug reports. I didn't often take customer phone calles but I did call a few to better understand their bugs. Not all the devs in the group ran the build and made the tapes as I was the release engineer for the OS in my "spare time." It's been 20 years since then and I am still waiting to hear of any bugs being filed against my code by a customer.

  • Anonymous
    August 23, 2006
    It should be obvious that both extremes would not work.  As a small organization progresses and grows, the sensible thing to do is division of labour so each step can be scaled out as demand for a certain function increases and specialization can occur.  Customer support, quality assurance, productions all have developed and can be developed into its own specialty.  That makes hiring harder as well if every new hire requires a broad range of skill.

    So the challenge is to find the balance so that specialization can occur and yet the teams do not operate in different insulated silos.  It gets increasingly tougher as the organization size increases so I guess Eric can feel the pain way more than I do... :-)

  • Anonymous
    September 12, 2006
    While I think developers should communicate with customers, I am quite against developers actually taking support calls.  A model I have seen work quite well here is dedicating a new, junior developer to field support calls.  This person can answer some common questions, assist with common operations such as password resets etc. but forwards more involved issues to the relevant developer.  This way the new guy learns the system, and the developers are shielded from the 'noise' calls while still having the necessary involvment.

  • Anonymous
    June 08, 2009
    PingBack from http://toenailfungusite.info/story.php?id=6126

  • Anonymous
    June 12, 2009
    PingBack from http://jointpainreliefs.info/story.php?id=2344