You have little control over how your email is perceived. For example, in my last job, I occasionally wrote up documentation on certain things. One of the people in a similar position on my distro was hired about a month after me and had a very defensive attitude. In one email I discussed how to access a certain application password repository; he sent a flaming response that he knew about the repository on his second day on the job. He saw the email as implying that he was incompetent. The reason I had included him on the distro was because I had asked him to fix a certain file transfer issue, which required knowledge of a certain schema password (stored in the repository); also if there were any manual changes to a relevant password, the repository needed to be updated. My colleague had called me up specifically to get the schema password (several weeks after he "knew" about the password repository). I had already memorized some of the passwords for various common tasks but was assigned certain tasks which required checking the repository. There was no local relevant document.
Documentation is something I had focused on since my early days as a programmer/analyst; I had to patch buggy, cryptic APL code; now I happened to be very good (better than anyone I knew) at reading other people's code, but I never wanted to be typecast as a maintenance programmer. Other APL gurus (APL is an interpretive computer language developed by IBM to facilitate things like rapid application prototyping) prided themselves in writing code as concisely as possible (and comments added to the overhead/size of a program without adding any functionality). I remember in one case a manager proudly gifted me with application documentation literally yellowed with age; the old system had been transformed beyond recognition since then. I felt the only way I could advance in my career is to provide a better context for new maintenance programmers. This is one of the key reasons I was motivated to research documentation for my dissertation and post-graduate research.
It's very possible that the one-on-one training my work colleague had received was different than I got; I certainly did not deal with the password repository on a daily basis. So I wanted to write up the process to avoid reinventing the wheel weeks from now. I did recall having to tell the guy a password over the phone, so I did include him on the distro, but I had included other newbies and my boss on the distro. What I did not expect was a hostile reaction; this guy exploded, interpreting my email as a judgment of his performance, that I was somehow calling him incompetent by sending the email; if he had wanted my documentation, he would have asked for it. I pointed out that if he didn't want my email, he could simply delete it. He was indignant that he should have to delete unsolicited emails, and he certainly didn't need my advice on deleting emails. (No others on the distro responded in a similar fashion.)
I'm not saying that I don't have room for improvement in my own emails; I've had several complaints over the years for long vs. succinct emails. In many cases, length is an artifact of discussing complex issues. In other cases, I didn't know what the target audience knew/didn't know, so I wanted to provide a comprehensive context. But if you use cellphones to read my email messages, it's easy to see how recipients get frustrated. Just to give a sample: one of my frequent tasks was to transfer certain files to other (distant) computer servers. Quite often, colleagues at other locations would complain the files never got there, but I usually could prove the other site got the file through an application notification from the target server. So normally I waited for the notification from the target server before sending a fulfillment confirmation to the original requester, copying the notification in the body. (That still didn't stop the requester from disputing receipt, and in one case, I remember a local colleague being confused and mistaken over the direction of the transfer from the notification.) But I soon started seeing others emulate my file transfer emails. Technically I didn't have to quote from the notification, but to provide some context, application functionality did not flag if you tried to transfer a nonexistent file. I knew people who reported back they had transferred requested files they didn't originally have. Was the additional notification extract necessary? Perhaps not. There were some nuances where they may have received the file but didn't know it. The notification gave them a specific GMT time stamp as to when the file was received.
But in response to the lengthy email issue, I've learned to focus more on attachments to less detailed emails.
I'm going to give one horror story from my past where an email led to my termination. It wasn't that the email was "wrong", but a prime contractor supervisor of system administrators took exception to it and filed a grievance with her management. I was affiliates with the subcontract. My company provided resources, like database administrators and Unix system administrators, to the prime contractor of the government client (in this case, NASA-GSFC). I and the Unix administrator in question reported to different prime contractor points of contact/supervisors.
Here is the context: one of the databases dealt with base security. If and when we did (typically Thursday evening) maintenance on related servers, we had to plan for it in advance, including making hard copies available to security personnel at base entrances. We usually discussed maintenance tasks at Monday afternoon sessions with application specialists along with us infrastructure specialists.
The security database was a special case because it deployed a "Data Guard" format of server redundancy (Oracle provides the technology "free" under the standard enterprise license; this is different than RAC, a technical solution which allows multiple servers to access a common database. DG basically duplicates the server and its attached database. In either case, if the or one of the servers goes down, you have the technology to switch users to another functioning server/database/clone.) It never made sense for me how NASA had implemented DG because the failover server was literally deployed in the same rack as the primary server; usually you want to mitigate geographic risk, e.g., flooding in the server room.
I had fixed a number of DG configuration and failover script issues. But one of the things you want to ensure is that the primary and failover server have the same version/patch base, including the operating system; differences would violate Oracle Technical Support guidelines. I'm fairly sure that my Unix admin counterpart knew this issue. (He was not the sharpest guy on staff; I overheard him call his wife for technical advice on his work tasks.) I'm not sure that the system admin supervisor he reported to was all that technical herself; she never discussed the database servers with me. The story was one of the leads on the prime account had worked with her in the past and recruited her into the position. She had not made a good impression on me fairly early, calling one of our application colleagues a "bitch". I never heard her discuss technology per se; she seemed to be more focused on office politics (which should have been a warning to me).
So one Monday staff meeting, she announced that we needed to do Unix security patching on the DG servers, tentatively a week from Thursday. Again, you might think she would have discussed my database servers with me first, but she didn't. So the next Monday she wasn't there. Think that my Unix admin colleague would bring up working on my servers? No. So I bring it up. Keep in mind that we need to describe the length of the maintenance period, and my Unix colleague doesn't say anything over, say, a typical 3- or 4-hour period. And I'm literally doing the supervisor's work over the next couple of days, getting the sign offs from the relevant servers, arranging for hard copies with the security guards, etc. I write up what needs to happen on my servers for Thursday.
I'm not sure if she returned Tuesday or Wednesday. But I think Wednesday the Unix admin started saying that he only had time to do one of the servers; now at the risk of oversimplification, it was like a McDonald's worker claiming he couldn't start grilling a second hamburger until the first hamburger was assembled and delivered to the customer. It was preposterous; he had walked me through the process, and there were periods you had to wait several minutes for the process was complete; he could easily start the next server's patch while waiting for the first server to finish. But he wasn't "comfortable" with working on the 2 servers concurrently, which was a personal preference, not a logical or physical one. I immediately launch complaints with his and my supervisors. No response.
The system administrator manager sends out an email at 2 PM on Thursday, literally 2 hours before the maintenance period, canceling the maintenance period, citing that her Unix admin needed more than the allocated time period to complete the patching. My prime supervisor told me to stand down, let it go. But I was not happy; first of all, there was no legitimate concern because the patching could be done concurrently. Plus all the work I had done getting everything set up for maintenance had gone down the drain.
So I wrote a tough but fair email pointing out:
- why didn't you know that my servers needed to be patched concurrently when you brought patching up a week ago Monday?
- why didn't you discuss patching on my database servers first with me?
- if you needed more time to patch both servers, why didn't you request more time from the get-go? Why didn't your Unix admin, who was at the meeting, raise the issue this past Monday?
- how is it you waited until 2 hours before the maintenance period to announce your decision? (There was a nuance because I had to book a later start to accommodate the maintenance period, and this meant that I could only book 5 vs. 8 hours for the day, which caused an issue with my subcontractor boss.)
No doubt this supervisor took exception to the implied notion of her incompetence in handling the situation and filed a grievance against me. The prime contractor manager contacted the sub-prime, said that they would no longer approve my time sheets, and demanded my immediate replacement. I was told by my company if they couldn't place me on another project (they had no open DBA slots), I would be administratively discharged.
Do I regret it? Yes and no. As a subcontractor on the account, I was in a vulnerable position. I should have realized that she would escalate the situation politically, and my project supervisor wasn't in a position to defend me (and had warned me to stand down). Besides, her own last-minute cancellation caused her a credibility issue, and I was not to blame for the fiasco. Finding another job is always a hassle. On the other side, I had run out of things to fix, the job was boring and lacked challenge, and other Oracle work was under different NASA contractors.
Obviously the email got to her. Was it worth it? No. She probably had already realized the points I was making. I would have been better served by quietly finding another job and leaving under my own terms.
