|employment job skills bleed over into development|
employee, independent contrator
| 10:54 pm on Jun 11, 2010 (gmt 0)|
I have been a freelance developer for a long while now. As the economy slumped, I desperately got a menial job doing network administration and tech support for a small company.
I was hired only to keep their computers running basically. But they were also launching a second php website and I started helping them here and there with some things.
Problem now is they expect me to do all the projects for the site and any other development they need, but they are only paying me to to tech support. It's really stressing and agitating me now when I work on the site because I'm getting paid crap for it.
I want to tell them that they hired me as tech support, so I'm simply going to just sit there all day unless a computer breaks or whatnot. I asked them to be paid as a developer but they said the company isn't doing well enough at the moment. Thing is, if it's important and something with their first asp site, they're willing to pay for an independent contractor who's a friend of mine at a significantly higher wage.
There are a number of projects they were talking about asking him to do, that I am much more capable of completing, but unwilling since they won't pay me for it. I need to keep my employment status with them for insurance purposes. I could just feign inability.
I'd like to do projects for them on the side as a independent contractor while maintaining my tech support position. I also don't want to be their in house developer because they'd become very inconcise since I was there and could just reprogram whatever over again at their whim. As an independent contractor they would need to give me specifics beforehand, and once it was done, it would be done. If they wanted it completely changed, they could pay for a new project.
Any suggestions on my best course of action?
| 5:11 pm on Jun 12, 2010 (gmt 0)|
As one who's been in this situation **many times,** there's no good answer outside of quitting. Which doesn't appear to be an option. :-) I call these "corporate shenanigans" even if it's a small company. A few items to look at:
Policy: Do you have an "official" job description, as in, on paper, something quantifiable? It doesn't sound like you do, but if you do, this is really your only leverage.
Pliability: "He who has the gold makes the rules." Not really true, but in the context of an employer, this is how they see it. What is your relationship with the employer, can they listen to reason, or is it "put up or shut up?" If they are inflexible, by bringing it up repeatedly or bucking their wishes you're going to be seen as a troublemaker, and they will figure out a way to let you go. And hire someone for less money to replace you. You're expendable, this is how it's seen, so tread carefully.
Job value: So you're doing tasks you feel you should be paid more for, and are probably right. But you have a job, in a time when many people are living on the streets, you have insurance, and even though you're not appreciated, like it or not, every thing you do in web development expands your experience. Sometimes it's mind numbing, but every time you adjust another script, it's likely you'll learn something new, or at the very least, get better and faster at what you do. In this respect, you have access to a venue of experience that others don't, even if it feels like hell. So are you seeing this aspect of it, or is it all about "more money?"
Add these three up, I've been in these situations and when the employer won't move, your hands are tied, you really have two choices. See the best in it or heave ho matie.
A small anecdote, and listen carefully to this one:
|but they are only paying me to to tech support |
I was "Senior Web Developer" (tongue in cheek, this company offered titles, not raises) at a Northwest ISP with the same sort of corporate shenanigans going on. In the next room was tech support, and one day they hired this guy at minimum wage. I got to know him, and the guy is a freakin' genius. Almost every day he helped me solve things I couldn't, and I always asked what the heck he was doing here. He was biding his time, gathering his forces. One day he'd saved enough from his minimum wage to float for a couple months, and quit.
He had built this web site that was gaining momentum, based on a very simple concept, something that a lot of people need. Two years later . . . the man is a millionaire (and my hero.) :-)
So advice? It's up to you, but it's all in your hands. This job is temporary, like most things. Focus on what you want out of life, and keep the job until you find it.
| 10:13 pm on Jun 12, 2010 (gmt 0)|
I was in a similar situation in the slump of the early 90s. It worked out to my advantage as it let me build up my CV to get a decently paid job elsewhere.
| 3:13 am on Jun 13, 2010 (gmt 0)|
There are really two ways you can approach this and I think you could pitch them both even though one is more favorable than the other. First, go to the key decision maker (who is going to be hiring the outside developer) and cut out the middle, if there is any.
Let him know that the project they want developed is well within your abilities, and that there are two possibilities that could save them money. Option one would be to pay you as a developer (I know they shot this idea down before, but if they're willing to pay a third party then the money is there) and let them know that you'll still handle the internal support and all of your current duties until they're at the point where they can afford to hire someone else to do that. This is key, because right now they see you as the low-level support and want to bring in a developer. Switch their thinking - let them know you ARE the developer, and you're just doing this because it needs to be done.
The second option (remember, present both) is that instead of paying Joe Blow to develop the app, that you could develop the app instead for $(some amount lower than Joe Blow would charge) initially, and because you're already here and on the payroll there wouldn't be any ongoing support costs. Just be clear that there has to be a separation between DEVELOPING the platform and SUPPORTING it (if they go with this option, you will need to have a contract that is very specific).
I can tell you right now that the first option is probably going to be better for you, even though you aren't thinking that right now. What's going to happen with the second option is that they will pay you separately for the initial build as agreed, then every time they get an idea for a "quick new feature" since you're already on the payroll they will ask you to just add it in. It's not because they're trying to exploit you or anything, and really there is nothing "wrong" with their mentality, it's just the natural progression of how these things always go. You're already there, you're not doing anything else and we're paying you, therefore you can work on this. It's difficult to separate it, and it will be difficult for YOU to separate it as well because you'll see something that you know will only take an hour and you'll just do it.
The reality is that you're better off convincing them to bump you to developer pay, with the pitch that "Yes you'll be committing to a higher salary, but it's only $X per year more than you're paying me now and with all of the ideas we come up with around here it will ultimately cost less than paying Joe Blow $Y every time we want to pursue something."
As far as the constant changes, you have the ability to set the tone on that early on. Non-developers don't understand this, and they aren't expected to - it's your job as a developer to educate them in the development process. I like to use the foundation analogy... if you're going to build a 2,000 square foot house and then after you pour the foundation and lay pipe you decide you'd rather build a 10,000 square foot house it's a lot more work than if you had just poured that foundation initially. That it's important to spec out the ENTIRE project, including things that you aren't going to develop right now but may include in the future, so you create the appropriate foundation that will allow you to add those new features.