Now, I know what you're thinking: "Well, if they fired you, they must have had a pretty good reason, right? I mean... you can sometimes be an arrogant prick, and you're definitely a slacker. Plus, when was the last time you showered???"
First of all... ouch! Why are you so judgmental? Second... irrelevant. You see, they had a very specific reason for firing me: Failure to demonstrate the necessary skills to exhibit basic core competencies. I will repeat that. No, I will repeat verbatim what they said in my termination letter (on very nice stationery, I might add):
Our new IT Director has had serious concerns about your performance and has communicated these to you over the past several weeks. Finally, he provided you with a very specific assignment designed precisely to determine whether or not you were capable of producing a work product that exhibited basic core competencies outlined in your job description. Your submission failed to demonstrate the necessary skill level and the new Director recommended your termination.Go ahead. Stare blankly at the screen. I'll wait..... OK, blink now.
I know, I know... you are dying to know what this core competency is that I so obviously failed, that it required firing me. Aren't you? Well... come on, allow me a little dramatic pause...
First of all, most of you know me as a computer programmer, software engineer, or just plain "computer geek." I pride myself on doing my job well. Many of you also know that I am a writer, and that I was fortunate enough to be in the right place at the right time, and co-wrote a book on PHP. So, yes. I am a tremendous computer geek who knows how to write.
So, dramatic pause over. What did I get fired for? What is it that I failed so miserably at? Documentation.
D O C U M E N T A T I O N !
Do you want to know the story? I'll be happy to tell you. Those who were only here for the Reader's Digest version, thanks for coming, and don't forget to buy a T-shirt on your way out. The rest of you, feel free to grab something to drink, and I believe there are donuts and bagels in the back.
So... here is the Ballad of B.S.:
I was hired to work at DAV in 2008. The IT Director at the time was (and still is) a great leader. I have always believed that a leader should not be judged on his accomplishments, but on the accomplishments of the people he leads, as well as their willingness to follow him. By that measuring stick, he is one of the greatest leaders I have known, and probably ever will. This is why I will continue to follow him -- but that's another story for another time.
When I was hired, my job title was Systems Analyst. After a while, the job titles in our department were revamped, and I was given the title Software Engineer II. That is the title I had until the day I was “let go.” Some time AFTER that title was given to me, a new job skill was added to it: documentation. I don't currently have a copy in front of me, so I don't know the exact verbiage, but essentially, a Software Engineer must have the skills necessary to document the applications we are working on.
I have documented many, many applications. I used to be the Release Manager at Fifth Third Bank, and that required a ton of documentation. It's not that I don't have the skills. I do. Enough said about my core competency.
Late in 2009, our IT Director was fired. I don't know the details, but essentially upper management was not pleased with his management style. Some stuff happened, and they decided to get rid of him. He was gone, and our IT department was shocked. We managed to rally our spirits, however. He told many of us to “soldier on,” and to always remember the mission: our disabled vets. So we did.
Fast forward to January of this year (for those of you reading this in the future, or watching the movie version, I mean January 2010. Two years before the end of the world). Our new IT Director, Bill Saunders (hence, the Ballad of B.S. Clever, no?), was hired. The beginning of the end. His message to us: “Don't worry, I'm not here to fire anyone, and I'm not here to make drastic changes. I'm just going to observe for a while.” Days later, our Development Team was split up into smaller groups (isolating and “protecting” the web and Epicor dev teams). The new Dev Team consisted of 3 people responsible for development of our internal applications, in addition to a couple of other team members.
Bill made it clear that he did not like these applications, and wanted to “fix” them. If he had his way (and he wanted to get his way), they would be completely rewritten or we would find a third-party product to do the job (I won't even go into the research that had already been done before on this very thing). I had a bad feeling at this time. He had isolated the group responsible for the very applications he wanted to replace and was already bad-mouthing the products we were responsible for. NOT good.
At this time, we had a manager and a lead developer. They were given the task by Bill to provide him with documentation of our current systems, and to complete all of the current high priority defects. I was told by the manager that he was going to take care of documentation, and that he may be coming to me for information. For now, I was to concentrate on new development and defects. I did just that.
A few weeks later, both of them were demoted. We no longer had a development lead or a manager. Bill was now our manager, so we were to report directly to him. He called a meeting to explain what he had done. He also said that he was forming a new team: the Business Analysts. He explained to us that their job was going to be to gather requirements for new development, and to do documentation. This would be good for the developers, because we would be free to do what we were hired to do: code.
We were all very pleased; programmers HATE documentation – a VERY well-known fact in this industry. Of course, Bill knew this well. So at this point, we were quite happy that he seemed to be looking out for us.
Also at this time, Bill told us, the developers, that our number one responsibility was to work on priority 1 and 2 defects. As professionals, we wanted clarification on our other responsibilities... “what about new development? What about the priority 3 and 4 defects? What about documentation?” Bill responded, with more and more agitation as we asked these things, that our number one concern was defects.
“What is your number 1 concern???”
“Defects.”
“Right. So why are we having this discussion?”
Uh. OK. No need for condescension. Message received. We worked on defects.
I spoke to Bill about the defects at one point. He wanted to make sure that we would be able to complete the defects in a timely manner. He believed that they would take us to the end of April. I assured him that as soon as some of us were done with our assigned defects, we would help out with the other ones until they were all handled.
The other thing he said was “if you're not working on defects, you're working on documentation.” At this point, we had been told that we needed to document our applications. OK, so I guess we didn't get completely away from documentation. Oh well.
I was told to stop working on my last defect – it was a problem that was very difficult to solve, and was affecting our QA environment. I said OK, and asked if I should help with the other unfinished defects, since that was my last one. No, I was to start working on my documentation. Specifically, I was to work on a Functional Requirements Specification document. This was March 23. Up until now, I did my job, quite well and on time.
I won't go into details, but essentially a FRS document is very involved, and is usually something you write for a new project, NOT for an existing application. It involves a ton of research, including interviews with all of the key players involved. It typically takes months to write such a document. he wanted it ASAP. I enlisted the help of the person put in charge of our documentation efforts, the lead Business Analyst. We searched high and low for an existing FRS we could build upon. Nothing existed.
The following Monday, we had our daily defect status meeting (the meeting where we were micro-managed asked to provide daily updates on the defects we were working on). This meeting did not go well at all. One of our developers got into a heated argument with Bill, telling him that he kept changing what he wanted us to deliver, asking us for documentation that doesn't make sense for an existing application, and that he was being unreasonable asking us for all of it in such a short period of time.
Without belaboring the entire argument, Bill threatened this developer's job, adding “you better be very careful what you say next.” When the rest of us were asked, I backed this developer up, telling Bill that his claim that he has been “asking for this documentation for 9 weeks now” was inaccurate. I personally had only been working on documentation for 3 days at this point.
Four days later, on the following Friday, the developer who argued with Bill and I both had our compressed work schedules revoked. By email. On the day we had off, starting the following Monday! We were also sent (along with two others) a very condescending email outlining exactly what Bill wanted for our documentation: a project charter, and a fully complete functional requirements specification document. Project Charter??? This was the first we heard of this. Not only that, but we were to have each section reviewed and approved before moving on to the next. Micro-management at its finest.
It was at this time that I decided that we had had enough. I composed a letter to HR outlining the issues that I had concerns about. Most of it centered around Bill's constant changing demands, and the overall horrible morale problem at DAV. I finally met with the HR Director to discuss my concerns, and he expressed surprise at some things, but told me that he was already aware of most of the things in my letter. Danger, Will Robinson, Danger! The final warning to me should have been when he said “clearly, you are not asking for us to do anything here, right?”
Three days later, I was fired. And so was the developer who argued with Bill in that meeting. Not by Bill – he was nowhere to be found. Not only did he never talk to me about his issues with me, he couldn't even face me himself to fire me!
My termination letter says that Bill had serious concerns about my performance. He NEVER expressed those concerns to me. With the exception of a couple of very condescending and contemptuous emails addressed to everyone on the team, he never ONCE called me into his office to tell me he had a problem with my work, that I was under any sort of probation, or that my job was at risk. Honestly, had I known this, I would have worked 24/7 to deliver that FRS. I loved my job.
I was fired April 14. I never spoke to Bill, since that volatile March 29 meeting. He made himself my direct supervisor when he demoted my manager, and never spoke to me. How can you fire someone you never even talk to, unless... hmm.
It is my contention that the day he segregated our development team, he decided that he was going to target us, and fire someone. He clearly believes in management by fear: fire a couple of likable people, and everyone else will do their job with their heads down, afraid of being fired themselves. His tactic was to find something in our job description that is the most difficult or hated requirement, give us a moving target that will be impossible to hit, then fire us based on not meeting “core competencies.”
I am a software developer and author with over 15 years of experience and a proven track record. And I got fired over documentation. To all my friends who are still working for this man: I sincerely hope that you are able to endure. This cannot go on forever, but if it does, I hope that you are able to find a way to keep moving forward.
Good Luck to you all.