5 ms·

This discussion starts from the premise that developer time is the most critical thing for which you must optimize your organisation. The most critical thing i

This discussion starts from the premise that developer time is the most critical thing for which you must optimize your organisation. The most critical thing is usually the customer and optimizing for the customer means doing things differently: * having the developers take customer calls and help requests * increasing the amount of time the developers spend understanding the users - in order to reduce the amount of irrelevelant work being done * cultivating a culture of 'code not written' Do you really think that cranking code is the most important thing your organisation does?

jim_h 15y ago
In my experience, the developers should NOT be taking customer calls. Once a client knows that a developer will take calls, they will take advantage of it and try to get in new features and changes. There should be a layer between developers and clients. This helps the developers not get distracted or waste their time by explaining things that someone could do also (or better). Yes, the developers should be aware of what the clients are having issues with or what features they want, but there should be a 'firewall' between developers and clients. Not all the time, but most of the time. The firewall can be imaginary, but the client needs to believe it exists.
- jrs235 15y ago
  I tend to agree with this point. There should be a firewall or layer between customer -> developer communications. The firewall intercepts/takes/handles incoming requests from the customer and forwards them on to the dev team or a developer who, if needed, can/will contact the customer. The customers should never have a direct line to developers unless you only want developers to work on "urgent" (regardless of important or unimportant) issues and "small/easy" features.
  - gordonguthrie 15y ago
    I am not saying that all developers should always be on customer support. But all developers should sometimes be on customer support - maybe 1 day a week, maybe more.
- gordonguthrie 15y ago
  We call that 'moving' and not 'working'. Working is something that generates customer satisfaction. Moving is just anything else. Adding bodies just to run distraction for developers is adding pure waste onto payroll.
scottshea 15y ago
DO you want your developers taking simple tech support calls?
- edwinnathaniel 15y ago
  Depends on the type of software you write. Developers tend to have the biggest ego and opinion in the room yet from time to time, they are also the ones who are clueless about the users or real-world scenarios.
  - marshray 15y ago
    I'm a developer. I like to interact with customers some of the time and wouldn't even mind taking some support calls once in a while. I feel like it keeps me in touch with reality, like you're saying, and I like knowing that people are out there using my stuff. But most developers don't feel this way. Forcing them to take support calls just to satisfy the boss' idea of how their ego should be adjusted just doesn't sound to me like something that's likely to be productive.
    - edwinnathaniel 15y ago
      What would you do if the developers weren't budging after you told them that "this is what the client wants".
      - marshray 15y ago
        I don't know anything about the business structure you have in mind, but usually customers don't get to talk to the developers so they don't expect to be able to do it unless its part of the contract. In my experience usually they don't even ask unless someone has put them up to it. E.g., they may be working on a complex issue with a Support guy in over his head who has been reduced to relaying messages to "the developers". I'm happy to jump on such a call directly because it feels like it saves everyone time and running around. But all companies with lots of users eventually develop layers of Support in place to shield their developers from potentially constant interrupts.
qdog 15y ago
Yes. If you define my 'organization' as the component that builds the products we sell. As a company, customer interaction is very high, but that is very dependent on the quality of our product. Almost overwhelmingly, our #1 customer request is new features closely followed by bug fixes. I enjoy talking to customers to help them with problems, but even when I had free reign to contact customers directly, I usually wrapped up conversation pretty quickly and cranked a new build for whatever the issue was. I have spent plenty of time in customer calls with 4 or 5 other employees twiddling my thumbs, and I don't think the customer benefited much from my presence. Developer time with a customer really needs to be targeted to be valuable. At least 80% of the time I spend is working on stuff that doesn't need a distraction.
georgemcbay 15y ago
"having the developers take customer calls and help requests" wat.

jim_h 15y ago

In my experience, the developers should NOT be taking customer calls. Once a client knows that a developer will take calls, they will take advantage of it and try to get in new features and changes. There should be a layer between developers and clients. This helps the developers not get distracted or waste their time by explaining things that someone could do also (or better). Yes, the developers should be aware of what the clients are having issues with or what features they want, but there should be a 'firewall' between developers and clients. Not all the time, but most of the time. The firewall can be imaginary, but the client needs to believe it exists.

jrs235 15y ago
I tend to agree with this point. There should be a firewall or layer between customer -> developer communications. The firewall intercepts/takes/handles incoming requests from the customer and forwards them on to the dev team or a developer who, if needed, can/will contact the customer. The customers should never have a direct line to developers unless you only want developers to work on "urgent" (regardless of important or unimportant) issues and "small/easy" features.
- gordonguthrie 15y ago
  I am not saying that all developers should always be on customer support. But all developers should sometimes be on customer support - maybe 1 day a week, maybe more.
gordonguthrie 15y ago
We call that 'moving' and not 'working'. Working is something that generates customer satisfaction. Moving is just anything else. Adding bodies just to run distraction for developers is adding pure waste onto payroll.

scottshea 15y ago

DO you want your developers taking simple tech support calls?

edwinnathaniel 15y ago
Depends on the type of software you write. Developers tend to have the biggest ego and opinion in the room yet from time to time, they are also the ones who are clueless about the users or real-world scenarios.
- marshray 15y ago
  I'm a developer. I like to interact with customers some of the time and wouldn't even mind taking some support calls once in a while. I feel like it keeps me in touch with reality, like you're saying, and I like knowing that people are out there using my stuff. But most developers don't feel this way. Forcing them to take support calls just to satisfy the boss' idea of how their ego should be adjusted just doesn't sound to me like something that's likely to be productive.
  - edwinnathaniel 15y ago
    What would you do if the developers weren't budging after you told them that "this is what the client wants".
    - marshray 15y ago
      I don't know anything about the business structure you have in mind, but usually customers don't get to talk to the developers so they don't expect to be able to do it unless its part of the contract. In my experience usually they don't even ask unless someone has put them up to it. E.g., they may be working on a complex issue with a Support guy in over his head who has been reduced to relaying messages to "the developers". I'm happy to jump on such a call directly because it feels like it saves everyone time and running around. But all companies with lots of users eventually develop layers of Support in place to shield their developers from potentially constant interrupts.

qdog 15y ago

Yes. If you define my 'organization' as the component that builds the products we sell. As a company, customer interaction is very high, but that is very dependent on the quality of our product. Almost overwhelmingly, our #1 customer request is new features closely followed by bug fixes. I enjoy talking to customers to help them with problems, but even when I had free reign to contact customers directly, I usually wrapped up conversation pretty quickly and cranked a new build for whatever the issue was. I have spent plenty of time in customer calls with 4 or 5 other employees twiddling my thumbs, and I don't think the customer benefited much from my presence. Developer time with a customer really needs to be targeted to be valuable. At least 80% of the time I spend is working on stuff that doesn't need a distraction.

georgemcbay 15y ago

"having the developers take customer calls and help requests" wat.