Hacker News Reader

Comment by nthj | Hacker News Reader

A large piece of delivering value to a business as a developer is, in the words of PG, "knowing what to build, not just how to build." Day-to-day, an on-site developer might be expected to sift through customers' feedback, join in on customer meetings, visit a customer to watch their product being used, and have the opportunity to overhear what issues the customer service team seems to be dealing with over and over again. He or she may well end up writing fewer lines of code than a remote developer because of these interruptions, but when those fewer lines of code have a greater financial impact on the business, the business is happy to continue to pay 10x salaries.

Also, many startups strive for amazing customer service, which usually means fixing issues on the spot when a customer calls in, American business hours. (I realize many remote developers are in similar time zones, but it is worth noting.)

View on HN

Seems like the optimal mix of skills and location is; find someone local that is good at doing what you're talking about and teach/force them to get good at #4 on patio11's list.

This one person (or small local team) can then 1) drive the product 2) act as a project manager with a big workforce and 3) stop coding, start reviewing code written by the minions and 4) get them where they need to be on new tech stack etc.

Timezone issues should be minor. Even people in the US should only be in the office 1/3 of the day. You need to rethink your whole management style, prioritization-wise if you run into problems like commonly needing stuff during off peak times. (Or, just hire a rotating shift so you have a 24 hr staff in Asia).

> Even people in the US should only be in the office 1/3 of the day.

A Silicon Valley startup /generally/ has most of their customers in the US. Both US businesses and US consumers have a cultural expectation that issues be resolved quickly within business hours, but are usually more forgiving at 9 PM at night. (For example, if I call my bank at 3 PM, I expect a resolution darn near immediately; if I called at 11 PM I would expect to leave a voicemail. In both scenarios I am equally satisfied, even though in the first I received an immediate solution and in the second I did not.)

It's not a matter of having developers on call 24/7, but in having the 8 hours they are online overlap the 8 hours that the customer base expects prompt service.

I'd argue that you're talking about customer service, not software development. That's a different topic, I agree customer service should be responsive and local to customers.

If you notified your bank of some technical issue. They would probably respond thanking you and telling you that they would look into it. I would be very surprised if they followed up with you to tell you when it was fixed (although, that would be great service)

Edit: just to add, the software dev on site can review customer services logs asynchronously, he shouldn't need to be the one actually working the customer service queue

This. Is what I do, exactly!

most of the times, I work _with_ the client's in house dev teams so that they can take over when we are done. I _love_ this model as everybody wins.

Key is to staff with the right people offshore.

Someobe local with the talent to drive product, mentor technical teams and manage a remote client is probably going to be either very expensive or a hoy commodity or interested in founding their own company. The combination of these skill sets isn't exactly common.

So, if you finding someone like that, how are you going to convince them to work on your problem?

Reply on news.ycombinator.com