Feel the pain…

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 (7)

  1. moz says:

    I too have worked in both (several) types of work, and there’s definitely a balance to be struck. I’ve worked in a (large) room with 8 developers who all had to answer client phone calls – we were first level tech support. At the same time much of the UI and process we implemented were outside our control, so we felt the users pain but could do very little about it. Combine that with the company being into "code on the plane on the way to install the new release" and it’s amazing I lasted 14 months. Summary: too much exposure, not enough control.

    But I’ve also worked in companies where I never heard from users directly, and often only indirectly from their managers. I was very vulnerable to bad BAs and miscommunications, which sucks a lot. But currently I have a good BA and the test/support team is about 10m away, so it’s possible to get that setup right.

    The best for me was working a few floors below the customer with direct access and a receptionist answering the phone. Problems got filtered a little through the phone or email, and I could talk directly to users who had problems or wanted help if I needed to. The users liked the software, at least partly because it was structured around what they actually did with it. And it worked, which probably helped.

    Pain is only good if it comes from a problem you can solve.

  2. AlfredTh says:

    "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.

  3. Mark W says:

    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… 🙂

  4. Brady Kelly says:

    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.

Skip to main content