31–40 of 50 posts
It means you hire folks who can do customer support. That's definitely not an introverted engineer. Sounds like the benefits might even be worth the extra hiring filter.
I worked at a SaaS startup that did this, and found pretty similar benefit: quicker fixes, and a better understanding of real customer needs. Eventually we made it optional though, because we found that a minority of our developers really disliked it. Which I can understand- not everyone enjoys interacting with customers and answering dumb questions like "can you reset my password?" I personally found it really valua…
I think #1 is a feature, though. One of the ways a growing company can go bad is to make it hard for most people to solve customer problems.
The megacorp customer support model is basically just to put all the disempowered support people in Nowheresville, so that nobody "important" knows how much the customer experience sucks. Which is part of what allows startups to come in and savage their business.
But there's another path: you can also avoid the customer and staff frustration by empowering them to fix problems, and working hard to keep it that way as the company grows.
This is in pretty stark contrast to yesterday's article about devops: > Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once. > What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (whil…
My experience says that if you're responsible for building a product, it's way cheaper to be directly in touch with the end customer so you can fix what you're building. It's better than having a legion of product managers, sales people, business owners in between you and the user. If you're a developer who is oriented around building products that sell and are loved by customers, it's pretty addictive to talk to cus…
The problem with this is geeks are generally not business people and do not know if the client is up-to-date on their billing or if they are notorious for trying to get free work and need to be kept in check. When I do take personal interest in solving a clients issue I risk promising things I should not be promising them or putting way more time and effort into a client who is already behind on billing than I should be.
I also have a very hard time quoting a client an appropriate amount. I work for a interactive and design agency and when you work with us you have a team of individuals working for you including but not limited to an account manager, producer, designers, art directors, user experience, strategy, front end developers, back end developers, system administration in some cases. Having a team of 5-10 specialists working for you is expensive. Just having a 1hr meeting with everybody is probably going to get billed at around $1000. I feel really weird giving clients numbers like this and responding to the sticker shock.
National Instruments does something interesting with their customer support. NI is one of those companies that hires mostly college grads then tries to keep people around forever. If you are a college grad hired into NI, will will spend 6-12 months in their customer support division. This applies to almost everyone regardless of degree. They do this for a few reasons from what I understand. It helps indoctrinate newh…
I worked at a SaaS startup that did this, and found pretty similar benefit: quicker fixes, and a better understanding of real customer needs. Eventually we made it optional though, because we found that a minority of our developers really disliked it. Which I can understand- not everyone enjoys interacting with customers and answering dumb questions like "can you reset my password?" I personally found it really valua…
Here's where we see "culture fit" is arbitrary.
Some customers are just incredibly stupid. That's who Tier 1 support is precisely for: the kind of people who would suffocate in a wet paper bag. I walked into my manager's office one day and said enough. I developed 10 products used by over 250k users and I was the only developer at the company. Never again was I going to reset another password. I followed best practices and made it as easy as possible. Any further difficulty on the part of a user was not my problem.
This is in pretty stark contrast to yesterday's article about devops: > Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once. > What began as an experiment aimed at increasing software quality has become a farce, where the most talented employees are overworked (whil…
I find you get a different perspective on what customers find easy and hard and this helps me develop my projects in a way that our customers will understand.