Posted in Uncategorized

Are technical communicators the “fall guys”?

Sometimes, I think being a stunt person would be easier than being a technical communicator.
Sometimes, I think being a stunt person would be easier than being a technical communicator.

While plugging away at the big project I’m doing for work, a problem arose from how some features worked, and developers cluttered up the CMS architecture of the site I’m working on. When I tried to clean it up, the developers rolled out more content that either created duplicates, triplicates, and overwrote pages without my knowledge. This mucked up the whole thing even more, making it worse.

I ended up having a call with my manager explaining the situation, and showed him what happened. He was aware of some of it, and he knew I was trying to fix things, but he was unaware that the latest roll-out complicated the situation. After a good discussion, he came to the same conclusion that I did–it’d be easier to start from scratch with this section of the website than to try to clean it up. I took responsibility for my part of the mess, and was more than willing to put the time in that’s needed to get it right again.

In order to do this, we’ve had to work with the people in the global corporate office to help us wipe the slate clean on that section and resend the new information. Well, this turns out to be easier said than done, due to system issues and communication issues (we’re not sure, even with images demonstrating the issue, if we are explaining what we need correctly to non-native English speaking people, and we are having some trouble understanding their replys). It’s turning into a sordid mess that I didn’t mean to happen. Some of this is my fault, doing some things unknowingly, but it’s also Corporate’s fault for not staying organized with the information rolled out on the various servers and not informing me of these changes in a timely manner, as that’s what is complicating matters. My hands have not touched that section of the website for 2 days because I’m afraid of mucking up things even worse, and so I’m patiently waiting for the correct content to be rolled out so I can move forward.

In this type of instance, my experience has been that no matter what part I played, even a minor one, I needed to take the blame for the whole thing. I needed to fall on the knife for what’s happened, even if I’m actually the victim in this instance. I’m fortunate that my manager hasn’t viewed this as something that I needed to take the fall for, and he’s been incredibly supportive through this small ordeal. I am grateful to have him as a manager and it provides me with some relief. But in past positions, even if I was correct in the midst of something that had gone wrong, I’d have to take full responsibility even if full responsibility was not mine. I’m willing to take responsibility if it is truly and completely my fault. Yet, I’ve had many instances where it wasn’t my fault at all, or I played a minor role, and I’d still be blamed entirely. And it would be one thing if I was a manager taking the blame for someone under me, but I’m always the gal at the bottom of the totem pole! If I stood up for myself in the past, I’d be severely reprimanded, even though I was justified in standing up for myself. So, you can understand why I’ve developed a bit of a complex and learned to take the role of the scapegoat in these instances unwillingly yet necessarily.

It got me to thinking about technical communication and where technical communicators will be given the blame for something that’s gone wrong.  Sometimes the blame is justified, and sometimes it isn’t.  If a manual has incorrect information, is it the fault of the tech writer, or the SME who didn’t provide accurate information, or the editor? In my case, the developers were being sloppy. I was the one being responsible enough to realize there was a problem and clean it up, initially following their directions for the fix, and they made it more difficult adding a fix to my fix without communicating that they were going to make a fix on their part. So why am I feeling like I need to take responsibility for the problem I didn’t cause instead of taking responsibility for realizing the solution? Is that just me and the conditioning I’ve been put through over the years, or is that a common problem?

In my current situation, like I said, my manager has fully supported me, and he’s about to leave on vacation confident that everything will be fine, leaving it up to me to take care of things. This is a reversal of most experiences I’ve had, and it definitely bolsters my confidence that I do know what I’m doing, and I appreciate that I’m recognized for that.

Technical communications is not for the weak or faint of heart, for sure. There is no question about that. However, technical communicators are being encouraged, as a field, to assert themselves more to show that we do have the solutions and know what we are doing, and to play a greater role in communications. I’m sure you’ve heard the “Break down the silos!” battle cry by now. If that’s the case, how do we do that if we have introverts like me who have been pounded down enough times that they are fearful of losing their jobs for asserting themselves? Is that just me, or do others feel this, too?

Let me know what you think in the comments.


Danielle M. Villegas is a technical communicator who currently employed at Cox Automotive, Inc., and freelances as her own technical communications consultancy, Dair Communications. She has worked at the International Refugee Committee, MetLife, Novo Nordisk, BASF North America, Merck, and Deloitte, with a background in content strategy, web content management, social media, project management, e-learning, and client services. Danielle is best known in the technical communications world for her blog,, which has continued to flourish since it was launched during her graduate studies at NJIT in 2012. She has presented webinars and seminars for Adobe, the Society for Technical Communication (STC), the IEEE ProComm, TCUK (ISTC) and at Drexel University’s eLearning Conference. She has written articles for the STC Intercom, STC Notebook, the Content Rules blog, and The Content Wrangler as well. She is very active in the STC, as a former chapter president for the STC-Philadelphia Metro Chapter, and is currently serving on three STC Board committees. You can learn more about Danielle on LinkedIn at, on Twitter @techcommgeekmom, or through her blog. All content is the owner's opinions, and does not reflect those of her employers past or present.

8 thoughts on “Are technical communicators the “fall guys”?

  1. I’m not sure that we are the fall guys. Let’s look on the bright side here. In your case, perhaps the developers are counting on you to tie all their loose ends together into a nice neat bundle of documentation. They are using you as the “neatener” and “beautifier.”

    1. I see what you are saying, Craig. I don’t mind playing the part of being the “neatener” or “beautifier”.

      Part of the problem is with the way our WCMS is set up. Once you delete a file, there is no way to get it back. My team wasn’t aware of that. (New system that we’re still acclimating to right now.) Additionally, there were some issues related to inherited content. When you have duplicates and triplicates of content, and you don’t know what is what, the developers had to take some responsibility for what they were rolling out. Even my manager agreed with that. Fortunately, the solution was to start from scratch and rebuild the section again. Even the developers understood the problem once we pointed it out to them, and agreed that this solution was the better fix long term. It was the better solution short term as well–the entire website is due to launch in about 3 weeks, so having to redo an entire section is a setback, but it’s better to have your “house” in order before the launch than try to fix things after the launch.

  2. It’s a tough situation. My approach tends to be: “Such-and-such happened. Blame me if you want. I don’t care. But let’s focus on solving the problem: fixing what’s broken, and making sure it doesn’t happen again.” That last part usually involves changing processes and/or replacing tools. As someone who was burned by the faulty process and/or tool, I have every right to speak up — loudly — with recommendations for improvement.

    If anybody reads this article and takes away the idea that technical communicators should set themselves up to be martyrs, I would totally disagree. And I think you’d disagree too, Danielle.

    1. You’re right–on principal, I agree with you that we shouldn’t be martyrs. But I think there have been instances that we do end up becoming them involuntarily, and that’s why there’s the cultural push to assert ourselves more. I just know that when I have asserted myself, and offered solutions, I would be smacked down hard, and even in one instance got fired. In today’s economy, it’s not worth it sometimes. Sometimes it’s just easier to roll over, but I suppose you have to take it from a situation to situation basis. I’ve never been in a position where I wasn’t expendable–until now–to be able to push back and not have negative consequences.

  3. I’d agree with Larry, but I can appreciate where Danielle is coming from. A lot of what could happen elsewhere comes down to how highly “content” is considered by those involved. If a top down appreciation of what we offer is present, this sort of problem is less likely to happen. If it does, the chances of getting the problem solved along Larry’s lines are greatly increased. Things seem to be complicated further in Danielle’s case by parties based in a different continent. Maybe there are cultural issues at play here as well.

    I have had similar issues where I have been blamed for something that was not my fault. The problem was caused by someone else’s skills not being up to mine. I stated this but it didn’t wash. I took a pragmatic view that I’d take the rap, based on the fact that I was flogging a dead horse and that it was a very minor problem. It still annoys me that I had to, but I can live with it. The alternative was escalate things up and make problems further down the line.

    In summary, Danielle seems to have gone through a tough time. Thankfully she has good support. The problem is elsewhere in the organisation. Blames games are never an effective method of problem solving. Better to collaboratively solve the issue. Only then have a calm and collected look back at what could be improved.

    1. I think you hit an important point, Colum. Very often, if there’s support from the top down, like I have now, then it’s easier to make your point and make things happen. When the people at the top don’t know what’s really going on–or don’t care other than it gets done–then there tend to be problems. I’ve experienced more of the latter than the former in my career, and it’s stigmatized me as a result, as you can tell.

      In the end, everything was resolved peacefully in my current situation, although it took a little time to get it all straight, and once it was straightened out, it was REALLY straightened out correctly, which made me happy. This is one reason that I really want to stay where I am. There is much more of a conscious effort for those from the top to be involved and understand what’s going on, and those at the bottom (like me) are appreciated for what we can contribute. It’s good worker relations, in the end, and it motivates me to want to do more and stay with the company as long as I can (as a consultant–but I’d love to be an employee)! I can also say that I’ve seen much more of a teamwork effort and attitude where I am now than I’ve ever seen elsewhere in my career, so again–no complaints in that respect.

      Just the difficulties made me review what I’ve experienced in the past at critical times when there have been severe blunders, and how it all played out.

  4. I agree that there’s need for support from the top. That’s tied to management valuing what we do. I was just in a company-wide “town hall” meeting where a new feature was reported to have missed meeting all its goals because “the help” was incomplete. In actuality, “the help” is perfectly complete, reviewed, and ready for deployment; what was missing is that the user assistance content (also complete) was not embedded in the feature. UA was repeatedly communicated to me to be a “priority” for this project, but in practice it became the developers’ very last priority because management wanted to see everything else completed first.

What say you?

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.