Sharing information among coworkers? Bad idea?
willanderson1111
Member Posts: 43 ■■□□□□□□□□
I work in desktop support and whenever I run into a complicated problem which I solved, I usually share that with my other coworkers. I would email our office email with the problem and the solution. However, I feel like is not being reciprocated. It seems like the rest of my coworkers are not willing to do the same. I am not sure if they're lazy or is a job security thing. Whatever the case may be I am tiring of sharing my knowledge all the time.
Is even worse at our sys admin shop. There are a couple of really good sys admin but there are more terribly bad ones. The bad thing is that the not so good admin are not willing to ask for help. They would let a ticket sit for days then to go and ask another sys admin for help. Is it a pride thing or what? Anyone else experience this in their work environment?
Is even worse at our sys admin shop. There are a couple of really good sys admin but there are more terribly bad ones. The bad thing is that the not so good admin are not willing to ask for help. They would let a ticket sit for days then to go and ask another sys admin for help. Is it a pride thing or what? Anyone else experience this in their work environment?
Comments
-
lordy Member Posts: 632 ■■■■□□□□□□Perfectly normal.
I have seen the same over and over. People seem to think that if they keep knowledge to themselves it will make them irreplaceable. That, of course, is wrong but most people haven't learned that lesson yet.
Keep sharing your knowledge. Make sure that the higher-ups occasionally take note that you do. It will not get you any reward immediately but you might be considered for a raise or promotion some day.Working on CCNP: [X] SWITCH --- [ ] ROUTE --- [ ] TSHOOT
Goal for 2014: RHCA
Goal for 2015: CCDP -
blargoe Member Posts: 4,174 ■■■■■■■■■□No, you are doing the right thing. Your co-workers have already noticed it. One of some of them may have already communicated your willingness to share information to your manager or someone who, one day, will remember things like this when it comes time to extend opportunities. Since you are doing these types of things already, you are also probably doing other little things that a good team mate would do... Everyone doesn't appreciate that sort of thing, but many people do whether they ever say it or not.IT guy since 12/00
Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands... -
Ryan82 Member Posts: 428Relatively common. Of course these don't apply across the board, but here are a few strange things I have noticed some people do:
1) People don't like asking questions because of the fear that people will realize they don't know something and they think that makes them look stupid
2) People don't like to share information because they love being the only one who knows something. Maybe they think it's good job security
3) Some people don't even like for you to share things with them because they feel that you are/or think that you are smarter than them.
Don't let these people bother you. Keep doing what you are doing. As long as you are working hard and contributing to the success of the team, you are never in the wrong. -
jamesleecoleman Member Posts: 1,899 ■■■■■□□□□□I think it's good that you're sharing the information. It shows that you're a team player, willing to help your department be good at what they need to do. I'm sure some important people will realize what you're doing and what everyone else isn't doing.Booya!!
WIP : | CISSP [2018] | CISA [2018] | CAPM [2018] | eCPPT [2018] | CRISC [2019] | TORFL (TRKI) B1 | Learning: | Russian | Farsi |
*****You can fail a test a bunch of times but what matters is that if you fail to give up or not***** -
SteveO86 Member Posts: 1,423Sharing information is always best practice.
You will always find co-workers that keep to themselves, in the end it will only hurt them in some form or another. Eventually you will find a group that will acknowledge your desire learn/troubleshoot/share info and you will move forward with them.My Networking blog
Latest blog post: Let's review EIGRP Named Mode
Currently Studying: CCNP: Wireless - IUWMS -
powerfool Member Posts: 1,666 ■■■■■■■■□□As others have mention, fairly common.
If you want it to change, talk with your boss, or your boss's boss. Here is what has worked in the past.
- Create a mail-enabled public folder in Exchange
- Create a distribution list and add the public folder and your team as members
- When ever you have something to share, just email that distribution list
It will be a good way of A) notifying everyone that you have info to share, and provide a simple repository to search later. Also, you can sort the public folder by the sender and date/time; this can be used as a metric. Have your boss make it a policy to use it.2024 Renew: [ ] AZ-204 [ ] AZ-305 [ ] AZ-400 [ ] AZ-500 [ ] Vault Assoc.
2024 New: [X] AWS SAP [ ] CKA [ ] Terraform Auth/Ops Pro -
pham0329 Member Posts: 556It's never bad to share information, as long as you do it in moderation. I used to work with someone who would literally send out an email about how he fixed something everytime he closes a ticket...it drove me insane.
Also, only email those who may find the information helpful. For example, if I find a problem with our network which require changes to our switches/routers config, I'll email that to our admins, not the helpdesk. -
higherho Member Posts: 882You are doing the right thing and management will notice. I always document how I solve a problem and put it up on our documentation share for everyone on the team / management to use / notice.
The people who act arrogant or go tell you "go read this guide, its in there" even though they know how to solve it are the type of people that never really amount to anything other than the position they are at. Funny thing is some of those same exact people come back to you and ask for help -
Forsaken_GA Member Posts: 4,024The people who act arrogant or go tell you "go read this guide, its in there" even though they know how to solve it are the type of people that never really amount to anything other than the position they are at. Funny thing is some of those same exact people come back to you and ask for help
Disagree with this. The entire reason I documented the problem and the fix for it is so I wouldn't have to answer it personally every time the issue crops up. If I take the time to WTFM, you can be damn sure I'm going to direct you to RTFM if it's covered. If someone is so lazy that they cannot perform their job without my holding their hand, they aren't going to amount to much. -
mikedisd2 Member Posts: 1,096 ■■■■■□□□□□Forsaken_GA wrote: »Disagree with this. The entire reason I documented the problem and the fix for it is so I wouldn't have to answer it personally every time the issue crops up. If I take the time to WTFM, you can be damn sure I'm going to direct you to RTFM if it's covered. If someone is so lazy that they cannot perform their job without my holding their hand, they aren't going to amount to much.
Agreed, I hate asking people how to do things because it's a nuisance for all involved. That's why documentation is so important. But it's not there, more people have to be utilised to figure out something. -
higherho Member Posts: 882Forsaken_GA wrote: »Disagree with this. The entire reason I documented the problem and the fix for it is so I wouldn't have to answer it personally every time the issue crops up. If I take the time to WTFM, you can be damn sure I'm going to direct you to RTFM if it's covered. If someone is so lazy that they cannot perform their job without my holding their hand, they aren't going to amount to much.
I guess I should have been more detailed. Here is an example:
User is asking the help desk a question. The help desk does not typically remember to well but the answer is in a guide that is 430 pages long. Instead of reading that long guide to find that answer (mark you the help desk person read this whole guide when he was hired) because the user is being very impaitient he (help desk) goes to the Information assurance officer who deals with this all the time so that he/she can get a quick answer. Instead the IAO tells him / her "its in the guide go read it".
Obviously people should research the issue first before asking the question but if someone is right there with you and knows the answer right away then why not ask that person instead of wasting all the time researching it? I mean in the example I pointed above its quite hard to remember 400 pages of documentation.
So I have a cluserting question and I understand the basics and the concepts but want to know some more fine detail. So I ask the person who worked for many organizations and is an expert windows engineer my question that I'm stuck on. After it is answered I have a better understanding now because he used his experience / expertise on the issue.
There is a major difference between holding someones "hand" vs a simple question of information. Holding someones hand is doing there job were they know nothing. I see many senior personal that have arrogant personalities use this excuse and in due time that person who asked for help surpasses them and all of a sudden that arrogant person is now asking the other person questions. Ironic eh?
EDIT
This also applies if the person cannot understand the documentation you wrote. This happens often because typically the techie that writes it forgets that other people will read his work and not quite understand his thought patterns.
Team vs group vs single person. Always be a team player no matter what the situation because it will make you look better in the long run and will even show up on your yearly reviews (at least they do on mine). -
Forsaken_GA Member Posts: 4,024User is asking the help desk a question. The help desk does not typically remember to well but the answer is in a guide that is 430 pages long. Instead of reading that long guide to find that answer (mark you the help desk person read this whole guide when he was hired) because the user is being very impaitient he (help desk) goes to the Information assurance officer who deals with this all the time so that he/she can get a quick answer. Instead the IAO tells him / her "its in the guide go read it".
There is a difference between holding someone's hand and answering a quick question. Obviously people should research the issue first before asking the question but if someone is right there with you and knows the answer right away then why not ask that person instead of wasting all the time researching it?
I think you took my post the wrong way.
No, I didn't. I just come from a different viewpoint. Whether I aim to or not, I somehow always end up being one of the go-to guys when problems develop, so I get interrupted on a fairly regular basis for simple crap. It is not incumbent upon me to remedy someone else's educational deficiencies, especially if the issue is well known and is documented. That is the point of documentation. If someone knows the answer is in the guide, and decides to interrupt someone else anyway, then that person is not being a good employee. It's an entirely different matter if the information is not available, or not easily accessible, but those 'quick questions' add up, and can be a real productivity killer.
Now, if the information is outdated, or blatantly incorrect, then that's an appropriate issue to broach, as policies and procedures frequently change, but documentation tends to lag. I also tend to be a little more tolerant if it's a comprehension issue. Approaching me with a question like 'Hey, I'm seeing this problem, and I was wondering how to fix it' when it's clearly documented is going to get you redirected. Asking 'I'm seeing this problem, and the documentation says to do this, but I don't quite understand what it means', and I'll take a little bit of time to provide clarification.
Once.
If you have to ask the same thing over and over again after I've explained it, I'm going to have a chat with your manager about your suitability in your current job role.So I have a cluserting question and I understand the basics and the concepts but want to know some more fine detail. So I ask the person who worked for many organizations and is an expert windows engineer my question that I'm stuck on. After it is answered I have a better understanding now because he used his experience / expertise on the issue.
That's a little bit different. I don't mind talking shop, as long as it's not interrupting something else. There's a time and a place for that, and if you exercise a little bit of courtesy and consideration for the value of my time, I'm likely to accommodate you. For example, asking if we can schedule some time to sit down and go over something, I'm perfectly ok with. Dropping by my desk when I'm fighting a project deadline to chat about the intricacies of BGP policy manipulation is not going to be well met.There is a major difference between holding someones "hand" vs a simple question of information. Holding someones hand is doing there job were they know nothing. I see many senior personal that have arrogant personalities use this excuse and in due time that person who asked for help surpasses them and all of a sudden that arrogant person is now asking the other person questions. Ironic eh?
I guarantee you that i would qualify as one of those arrogant seniors. And it's not because I hate people, or don't like sharing knowledge, it's simply that it happens so often that my patience is eroded. I hate documentation, but I hate being interrupted even more, which is why I take the time to document issues and their resolutions, or provide references to something else that is equivalent or better than what I would myself write.
The point I'm trying to get at is that juniors have the annoying habit of expecting seniors to basically provide on-demand training. I am not a knowledge vending machine. I'm perfectly willing to share my knowledge, and lend someone a hand, but I'll be damned if I'm going to put up with someone bitching about the manner in which I provide it. If I tell you to go read something, there's a reason for it, and that reason is because I believe it will help you, not because I hate you. -
higherho Member Posts: 882Forsaken_GA wrote: »No, I didn't. I just come from a different viewpoint. Whether I aim to or not, I somehow always end up being one of the go-to guys when problems develop, so I get interrupted on a fairly regular basis for simple crap. It is not incumbent upon me to remedy someone else's educational deficiencies, especially if the issue is well known and is documented. That is the point of documentation. If someone knows the answer is in the guide, and decides to interrupt someone else anyway, then that person is not being a good employee. It's an entirely different matter if the information is not available, or not easily accessible, but those 'quick questions' add up, and can be a real productivity killer.
The reason why I thought you took my post a different way was the fact I did not clarify the differences. I'm Sorry.
I agree with you and I would also be annoyed if I got interrupted a lot with quick questions. In my posts I was mainly talking about the person who might ask you a question here and their not all the time and depending on the situation (like user emergency, etc).
We had a new guy come in and I pointed him to all the documentation I created and said most of your typical issues are here. Instead of having one large document I created folders and sub folders of typical issues so its easier to find and easy to understand. Because of this, I hardly get asked any questions unless it is so random and the individual tried everything he can do (troubleshooting wise, etc) then I would see that person again asking me another alternative. Sometimes when he sees I'm really busy he will ask me later or at a better time.
Now I have seen people just every day ask me stuff (even after their typical 3 week training) and were they do not even know what an ethernet cable is nor has any troubleshooting skills. Thats were I go to management.Now, if the information is outdated, or blatantly incorrect, then that's an appropriate issue to broach, as policies and procedures frequently change, but documentation tends to lag. I also tend to be a little more tolerant if it's a comprehension issue. Approaching me with a question like 'Hey, I'm seeing this problem, and I was wondering how to fix it' when it's clearly documented is going to get you redirected. Asking 'I'm seeing this problem, and the documentation says to do this, but I don't quite understand what it means', and I'll take a little bit of time to provide clarification.
I agree with you here too. The example I gave though was in a 400 page document and a situation were it needed to be handled right away and its an issue that typically is IAO related vs IT. Now a help desk is supposed to have a good idea of all things within his department (were to point people too, answer typical questions, etc) would it be smarter to go directly to the IAO or have the user who is management wait there until you research a 400 page document (this is one reason why I document things the way I do instead of having one big old word document) wait?Once.
If you have to ask the same thing over and over again after I've explained it, I'm going to have a chat with your manager about your suitability in your current job role.
I agree with you on this too. Which is why I pointed out the difference between someone not knowing anything vs someone asking a question on an issue that rarely comes up.That's a little bit different. I don't mind talking shop, as long as it's not interrupting something else. There's a time and a place for that, and if you exercise a little bit of courtesy and consideration for the value of my time, I'm likely to accommodate you. For example, asking if we can schedule some time to sit down and go over something, I'm perfectly ok with. Dropping by my desk when I'm fighting a project deadline to chat about the intricacies of BGP policy manipulation is not going to be well met.
Very true and most of the team I work with have the common sense not to bother people when they are stacked with work.I guarantee you that i would qualify as one of those arrogant seniors. And it's not because I hate people, or don't like sharing knowledge, it's simply that it happens so often that my patience is eroded. I hate documentation, but I hate being interrupted even more, which is why I take the time to document issues and their resolutions, or provide references to something else that is equivalent or better than what I would myself write.
I honestly dont' think you would be one of those arrogant people. I get the vibe that you do like to help people but not get abused by those people all the time and during busy times. I also think you would write your documentation very well for others to understand too which in that case I doubt you would get many "Good" workers bothering you.The point I'm trying to get at is that juniors have the annoying habit of expecting seniors to basically provide on-demand training. I am not a knowledge vending machine. I'm perfectly willing to share my knowledge, and lend someone a hand, but I'll be damned if I'm going to put up with someone bitching about the manner in which I provide it. If I tell you to go read something, there's a reason for it, and that reason is because I believe it will help you, not because I hate you.
I agree with you 100% I just wanted to point out that not everyone is going to remember everything in a huge one long document. I felt bad for one of our help desk members because he got told off by the IAO to go read the "SA GUIDE" which is this HUGE document instead of aiding the team in a crisis (and when it was more of an IAO question to begin with). Because that help desk member is a great worker, good troubleshooting skills and very organize. -
Forsaken_GA Member Posts: 4,024The reason why I thought you took my post a different way was the fact I did not clarify the differences. I'm Sorry.
It's all good. I'm just disagreeing with you, not yelling at youI agree with you and I would also be annoyed if I got interrupted a lot with quick questions. In my posts I was mainly talking about the person who might ask you a question here and their not all the time and depending on the situation (like user emergency, etc).
Here's part of the core problem though - every user considers themselves 'every once in awhile, here and there' when it comes to the interrupts. They're only looking at it from their point of view. They don't take the time to consider that others may be doing the exact same thing as them, and that ends up taking it's toll on the bright and shiny disposition of the person being interrupted. With our society trending more and more towards the expectation of instant gratification, things like basic manners and courtesy are becoming archaic notions of a simpler time.
Now, with all that being said, I'll certainly stipulate that there are folks out there who act like douchebags simply for the sake of acting like douchebags. My opinions are my own, and I speak only for myself, though I suspect there might be a few folks out there who can empathize with me. -
higherho Member Posts: 882It's all good. I'm just disagreeing with you, not yelling at you
I did not take it like you were yelling at me. Just didn't want you to think I disagreed with your points / ideals. I just really love documenting / sharing my experiences with my colleagues / co workers. I just don't like getting taken advantage of which I think you and I both agree on.Forsaken_GA wrote: »
Here's part of the core problem though - every user considers themselves 'every once in awhile, here and there' when it comes to the interrupts. They're only looking at it from their point of view. They don't take the time to consider that others may be doing the exact same thing as them, and that ends up taking it's toll on the bright and shiny disposition of the person being interrupted. With our society trending more and more towards the expectation of instant gratification, things like basic manners and courtesy are becoming archaic notions of a simpler time.
Yea one of the things that was greatly appreciated in any type of consumer support is manners and how you deal with such things.Now, with all that being said, I'll certainly stipulate that there are folks out there who act like douchebags simply for the sake of acting like douchebags. My opinions are my own, and I speak only for myself, though I suspect there might be a few folks out there who can empathize with me.
Every techie should have the ambition to try and solve things by themselves without aid and that should be expected after the training period is over / once you get the handle of your new responsibilities.
I would never go and ask someone a question about clustering if I had no clue what it was. That would show the other person that you are just looking for answers without doing any research at all (aka the lazy person). This type of behavior should not be tolerated.
If you feel that you are aiding someone to much (like 5 questions a week on simplistic tasks) then thats a problem. -
N2IT Inactive Imported Users Posts: 7,483 ■■■■■■■■■■willanderson1111 wrote: »I work in desktop support and whenever I run into a complicated problem which I solved, I usually share that with my other coworkers. I would email our office email with the problem and the solution. However, I feel like is not being reciprocated. It seems like the rest of my coworkers are not willing to do the same. I am not sure if they're lazy or is a job security thing. Whatever the case may be I am tiring of sharing my knowledge all the time.
Is even worse at our sys admin shop. There are a couple of really good sys admin but there are more terribly bad ones. The bad thing is that the not so good admin are not willing to ask for help. They would let a ticket sit for days then to go and ask another sys admin for help. Is it a pride thing or what? Anyone else experience this in their work environment?
This is not your responsibility, this is for management to manage. Knowledge silos are common and without a proper framework and initative in place it will remain the same. You can do your part which is what you are doing, but you won't change anything. Change must come from the top down and if your management doesn't see value in this nothing will change. -
Anonymouse Member Posts: 509 ■■■■□□□□□□I noticed a few older techs do this where I work. One guy I work with though is pretty good about sharing his resolutions through really detailed ticket descriptions and resolutions. I've searched our ticketing system to problems that absolutely stumped me and I always find the same guys closed tickets with practically a tutorial walking me through the whole process of fixing LOL. Since then I've started trying to follow his lead so other techs can come across my old work and hopefully learn a thing or two also.