On 9 Jun 00, at 16:05, Jeffrey Rua wrote:
> Why don't you just fire the guy or tell him that the IT department and it's
> policies do not provide a friendly environment for engineers? Maybe he will
> get good and pissed on his own and quit. End of problem.
There has to be a lot more in the situation than what he is telling
us. Up to a point, my basic instinct is to side with the developer,
but I draw the line when he starts trying to break into systems. If I
was working anywhere and someone wiped out my system and
reinstalled things like that, I'd start looking for another job. There
wouldn't be any use in trying to break in to the systems.
> Realize that if he has been hired as your database priest, ERP God, CRM
> Guru......whatever his title is, he needs full access to do his job. If you
> piss him off, he will go and write code for someone else. If your HR people
> don't wanna mess with him, it should make perfect sense to you that they are
> probably paying him a LOT of money to do his craft at your company. Put him
> on his own network with his own servers for testing. He won't need to
> install software on your production server boxes anymore. Give him full keys
> to his kingdom and standard domain user permissions to yours. Realistic end
> of problem.
The development system should be completely separate from the
production system. That way, a minor error during testing doesn't
crash the production side, too. What's really nice is to have a
testing person assigned to you to do more extensive testing for you.
On the other hand, I've worked in environments that couldn't afford
two separate systems. So you just have to do what you can to
make it work.
Eric Johnson
--------------------
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
