As an employer, and account holder, I am not a fan of this feature.
My team must feel free to use our internal communication tools to have private, perhaps critical, conversations between each other without worrying about me, or other members of management, from reviewing them.
If the tools cannot be trusted, employee will not use them. If they don’t use, they’ll revert to other methods of communication, which will consume their attention.
This should be an option, and one whose affect is in plain view of users.
Lacking such an option, or clear disclosure, I will be canceling our account, as well as reviewing my companies use of other Atlasssian tools.
Please reconsider this feature, or at least, reconsider its implementation.
I completely agree with you on this. I can't imagine continuing to use hipchat with this change in place.
This was pretty stunning at first, but after thinking about it my guess is simply organizations that use Jira are the kind of organizations that want/need to keep tabs on all employee communications.
Which hey, I get that for some companies they need that for one reason or another.
What it says to me more clearly than anything though, is that Hipchat's core customer isn't small teams any longer.
We run local e-mail and IM servers; the only thing that protects user communications on company owned infrastructure is our company policy. How is this any different?
What I find far more alarming -- and quite hypocritical from SaaS users seemingly suddenly concerned with privacy -- is that when I communicate with companies and individuals that use SaaS providers like Google Apps, the party with which I'm communicating implicitly shares my private correspondence with a SaaS company that engages in massive cross-internet data collection.
By comparison, employers having access to data that flows over employer-owned infrastructure is barely worth mentioning, has been the status quo for decades, and I'm absolutely stunned that anyone is shocked by this.
You honestly don't see the difference between the amount of interest a third-party software company would have in the private conversations of a team than the amount a person's immediate manager might have in them?
Second, simply because something is "status quo" does not mean it's OK.
As this is my company, I can chose to run it in a way that doesn't make me feel like an asshole.
You're being disingenuous; it's the status quo because having the ability to monitor user communications is the default and inherent legal and technical nature of conveying communications over company owned infrastructure.
If you don't want to "be an asshole", set a clear company policy and move on.
Having been in the position of needing to access historical e-mail records while investigating CFO malfeasance and fraud, I'd say its downright irresponsible to not have the ability and policy necessary to monitor and review communications in extenuating circumstances.
You're looking at it from the perspective of malfeasance/fraud. The other poster is looking at it from teamwork/management.
They're not being "disingenuous". Ironically, speaking of trust/management, criticizing people's personal motivations like that is precisely one thing I'm taught not to do, for effective, healthy teamwork. (Whereas, if I must investigate antagonistically, like if a boss is harassing employees, I must assume the possibility.)
No, I'm looking at it from the perspective of simple rationality: SaaS does not mystically change the technical and legal nature of administrative access to communications over company controlled infrastructure.
As for criticizing motivations, disingenuity was the more polite assumption compared to the alternative: that he is ignorant of the legal, technical, and historical context to the degree that he actually believes HipChat's changes are unique or novel or questionable in any way.
Entities in a technologically privileged position are limited only by policy. The fact that he accepts that truth simply by relying on SaaS demonstrates the significant incongruity of logic at question here.
It's hilarious that you're implying it's hard to understand that the guy with the server password has can read everything. I mean, really?
The entire point of my protest to this change is specifically to stop either myself, or any member of management team from having a "technologically privilege position".
Your arguments about SaaS are irrelevant and juvenile. Just cause Atlasssian, or any SaaS provider, has access doesn't mean I, or my management team, should.
Saying "well we run our email server in house so we just solve this problem with a policy" is fine.
Whereas you appear to be simply dense given your inability to see the hilarious hypocrisy of surrendering the privacy of yourself and others to SaaS vendor policies while calling them to task for giving you the equivalent privilege of policy choice.
Thanks for doing this, please keep us updated if you get a response that you can share.
Our team has just switched back to HipChat as we have more and more remote workers. I'm the current owner of the account, and I don't want the ability to be able to read private chats. I don't want anyone else taking over as owner being able to read my private chats.
By all means, allow it as an option for customers that feel the need to spy on their employees, but let us turn it off.
As an employer, and account holder, I am not a fan of this feature.
My team must feel free to use our internal communication tools to have private, perhaps critical, conversations between each other without worrying about me, or other members of management, from reviewing them.
If the tools cannot be trusted, employee will not use them. If they don’t use, they’ll revert to other methods of communication, which will consume their attention.
This should be an option, and one whose affect is in plain view of users.
Lacking such an option, or clear disclosure, I will be canceling our account, as well as reviewing my companies use of other Atlasssian tools.
Please reconsider this feature, or at least, reconsider its implementation.
Thank you.