As a software developer, my primary responsibility is to ship working code. I do this by writing code all day long. This is the job I was hired for. I work for a small company that struggles with identity. I feel that lately, they are struggling to find new clients and therefore are targeting alternative markets. The result of this is that they are now having me travel for a week a month or less to various clients onsite. I understand that doing this once is reasonable. However, I feel that if my company continues to put me in a position where I'm traveling and meeting clients, rather than writing code in a comfortable working environment, that this would be counter-productive.

How can I convince my boss that having me travel for extending amount of time to visit clients or prospects is not the most productive use of my time.

I don't see how travel is necessary when there are lots of telecommuting tools available to making communicating over long distances possible.

  • 3
    Why does your boss believe it is a good idea for you to travel? Are you helping the client troubleshoot issues? Serving as a technical resource to help a client understand how they could use your product? Something else? Is there someone else in the organization that could do these things? Is there some reason to believe that these things are unnecessary? Is the company losing more money because of the features you're not able to add than they're making by having you travel? Commented Oct 6, 2013 at 5:48
  • 4
    Working for a small company almost always entails more generalist work than working for a large company. In my experience senior developers at small software companies are always needed to do pre-sales and post-sales work like you seem to be describing. If you want to just write code all day long you'd be more likely to get that opportunity at a large company. Commented Oct 7, 2013 at 3:43
  • 5
    "Non-productive" is in the eye of the beholder. Most tech jobs, especially at small companies, involve a mix of tasks. Just because you're a programmer doesn't mean you'll never do tech support, discuss products with customers, help out with testing, and so on. Commented Oct 7, 2013 at 15:40

5 Answers 5


Everyone wears different hats at different times, sometimes it's "dad", sometimes it's "son", sometimes it's "employee" and sometimes it's "developer".

From the company's perspective, you mainly wear the "employee" hat, under which your primary responsibility is to help the company achieve its goals, typically, that is to be profitable. That may be done via wearing the developer hat or the "client smoother" hat or whatever they think of your customer interactions, and it is your supervisor's job to determine which best suits the company.

If you don't like what they are asking you to do (which is what it sounds like), then you should reconsider working there (and possibly the compensation you are receiving).

If on the other hand you simply think that your supervisor is making the wrong choice, and that your activities are not serving the companies goals, that's a different matter.

Either way you should be having a conversation with your supervisor, but you should be aware of which conversation you are having going in. Do you want to determine if your current activities are achieving the companies goal, or do you wish to let your supervisor know that your current activities are not satisfying and you wish to change them?

  • 4
    +1 - your primary responsibility is to help the company achieve its goals Commented Oct 7, 2013 at 14:14

Business is complicated. Sometimes "we care enough about your problems to take the developer off his coding tasks and send him to you" is a powerful gift to a customer that can bring a tremendous amount of revenue to the company. In that case your theories about telecommuting and whatnot are worse than irrelevant. Other times, your boss is an idiot. I know you think that's what's happening here, but it might not be, and you haven't given us enough information to know.

The way I see it you have three choices:

  1. Trust your boss. Ask some questions, but only so you can learn or so you can more fully support whatever it is this small company is trying to do. (That is, not along the lines of "Why should I do this?" or "why shouldn't I do X instead?") Pitch in, roll up your sleeves, be a team player, do what needs to be done to keep the company afloat. Optionally, ask for a raise to compensate you for work you like less than coding.

  2. Stick to your guns. "I was hired to code and dammit I demand you give me coding to do and pay me to do it." This may work for a while, because they need code or because they want to keep you, but if they get a chance to replace you with someone more rounded, they will.

  3. Look for another job and choose a larger firm this time where roles are less likely to change over time, and you can focus on your best thing.

If you were my friend or brother, I would urge you to go with #1. It's a chance to grow and learn new skills, a chance to be vitally important to a small company and make a huge difference, and probably a path that brings you more money than just coding. But if you're going to go #2 or #3 (and over a year or so time frame we both know they're the same) then do so with your eyes open knowing there was something else you could have done, but chose not to. Knowing your strengths is very important and if you self-identify strongly as only writing code then you need to embrace that aspect of yourself and live it.


There is more to selling software than simply having a developer write code. Especially if you want to sell to the customers again.

This includes writing documentation, talking to customers, teaching customers to use the software, and on and on and on.

In a large company there are many hands to do all these tasks. In a small company you may simply be the person best suited for doing this task and therefore you are chosen to do it.

As a team player you should have been given enough insight to understand this. You may need to have your boss give you the grand perspective of things, to allow you to understand why this is necessary and why it is necessary for you to do it. The reason may be as simple as "we don't need you to write any more code right now, but we have this thing that needs to be done."

  1. First of all, is your manager expecting your productivity to change or remain the same with all this travel? If the latter, you've got to slam the brakes and sit down with him and discuss expectations of your role, the one you seem to be silently transitioning to and what is the actual incentive for you both growth-wise and career-wise. With really small companies (I've worked in one for nearly 6 years), this "doing anything it takes" attitude is adorable but comes with costs that your CEO often chooses to ignore. You don't want to come to work feeling bitter ... that does more damage to your productivity than the travel! So have this talk, get your answer and at the very least you'll have a clear idea if this job is still worth sticking on to, even if you feel you are not being used as efficiently by your company as you could be.

  2. If that approach doesn't fly, a simple yet effective way of convincing anyone up the ladder is a side-by-side comparison of the costs (dollar estimations!) of you coding AND commuting vs. you coding all day. Most people cannot (and often choose to NOT) see things at altitudes below 50,000 feet and unless you spell it out to them in dollars-and-sense, they are going to shrug their shoulders when you deal with intangibles such as simply hearing "need a comfortable work environment to code" and "travelling is distracting". (some managers might perceive this as whining!)

  3. A more guerilla approach to this would be to only schedule travel during 8-5 work days and this will automatically take away from your coding time. After a few weeks, you can use this as a data point to further drive home point #2 above. If your manager actually suggests that you fly/drive early mornings or in the evenings, go back to point #1 and really figure out if this is a promotion that has incentives you like OR if you should be looking someplace else for a job.


Your company is in the business of selling software. Selling the existing product will alawys take higher priority over adding new features. From the company's perspective, having a developer on site with the customer is a huge selling point and may be the difference between them making enough money to pay your salary and them not. Small companies can't always afford to have strict job definitions and roles, so your role is not just software developer. This is one of the best things about working for a small company, the chance to learn how to do a lot of things.

From the perspective of your personal career, one of the biggest weak points most developers have is that they don't userstand the users' needs. This is a priceless opportunity to get client-contact and start to understand what is truly needed. This kind of experience can only make you a better developer when you are no longer inthis this role.

You say all this could be done through other means, but there is no substitute for direct personal contact. Emails, IMs, teleconferences are just not the same and the client won't feel the same level of company commitment to them without the personal meetings.

All that said, if you don't understand why they need you specifically to travel, you need to have a private conversation with your boss about it. But don;t go in defensively, with an "I hate this and don't want to do it" attitude. Go in and ask exactly what you are expected to accomplish with the visit and then make suggestions from there for alternatives ways to meet the objectives of the visit or alternative people to do the work. But remember, the company's priorities and yours are not the same, they most likely view this as the productive use of your time. It would be up to you to find a convincing argument otherwise and you can't do that until you know exactly why you were chosen to do this and exactly what they expect you to accomplish that can't be accomplished with you staying home.

  • +1 And this is how developers transition into UX professionals. There is no substitute for direct personal contact! And having that direct personal contact can actually make your career so much more rewarding if you let it. Commented Oct 7, 2013 at 15:56

Not the answer you're looking for? Browse other questions tagged .