Hacker News Reader

Comment by gordonguthrie | Hacker News Reader

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?

View on HN

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.

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.

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.

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.

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.

"having the developers take customer calls and help requests"

wat.

DO you want your developers taking simple tech support calls?

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.

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.

What would you do if the developers weren't budging after you told them that "this is what the client wants".

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.

...and the cost impact of a software developer who doesn't understand the customer and real-world scenarios is enormous. They just sit there are crank our new support calls, new support costs, worse customer experiences, slower growth rates, deteriorating customer experiences.

You need to take action to stop them folk coding as quick as...

Getting the customer to do it is as good a way as any.

Yup. How do you get to zero defect if you don't? The point is to eliminate support calls by root cause analysis:

* is the software borked?

* are the doco's borked?

* is the user community too poor/uninformed/unsupported to generate the answers without developer involvement

The devs are a key part of determining which of these things is the root cause. If they don't talk to the people who matter (the customers) how can they help solve the problems?

Reply on news.ycombinator.com