The first time, I thought about the low-hanging fruit. Immediately, the story was relevant to my days at Quintrex, the company I worked at from 10/1/1998 to 10/15/2010. The article tells a story about a grieving developer as his beloved system's user interface was being redesigned by the author. At Quintrex, there was a point during those 12 years when our systems had been developed in multiple programming languages and by multiple teams. There was not a single "Quintrex" look and feel. There were rules for using the systems and those rules were dictated by the programming language / team, not by Quintrex, the company. At some point, the decision was made that all of our systems would be converted to (yet another) programming language. It was kind of a running joke. There was always an effort to rewrite the systems in a single programming language and the list of the "chosen" or "standard" programming language was changed several times over the years.
At one point, there was a meeting I attended. The reason I remember this specific meeting is because it was very tense. None of the teams wanted to concede anything about their workflow because, and I get this, their workflow made sense to them and the thought of re-learning the way they did their job was scary. The meeting was riddled with a lot of subtle (and sometimes not subtle) statements, such as these:
Your system in your programming language looks bad.
My system in my programming language looks awesome.
As a company, we should adopt the way my team do things.
The way my team does things should be the new standard.
All you other teams should have changed your standards to match mine years ago
No, of course I don't have my team's standards in a document that you can read - we know how to do our job!
Of course, no, no one actually said those exact words, but there would have been a higher degree of honesty in the room if someone had actually just said those words.
Recalling that meeting in my brain was intriguing so I reread the article. This time, though, I extracted the Developer reaction text from the article into this blog post. Originally, my idea was to use them as a springboard for writing this post. I thought this post would be summarizing the meeting above only. But then something made me think about something else. But before I get to that, here are the stages from the article:
Stage I: Denial
Upon seeing the new sketches, the developer’s first reaction was to deny the reality of the situation.
Developer: “I’m sorry, I don’t think you can even do that in HTML. Errr, no, no…. Technically, this just can’t be done. Sorry.”
Stage II: Anger
Developer: “This is wrong—all wrong. You don’t understand this product. I do. Our users won’t like this. Stop sketching and listen to me! Have you worked on this type of application before? These designs are ridiculous! Why aren’t you listening to me?”
Stage III: Bargaining
Developer: “Um, your colors…. Your colors are good. Let’s just take your colors and put them on the existing user interface. Then, can’t we just leave everything else alone?”
Stage IV: Depression
Developer: “You know, I never really cared about what the user interface looked like anyway.”
Stage V: Acceptance
Developer: “Do all of the new product designs have to be implemented in this release?”
As I mentioned, the article is presented in the context of a Developer grieving over the changes to a product he brought to life. As I reread the article, I applied my 20+ years of working perspective, I can apply the Developer's grief to my own work as a technical writer when there is a transition. Over the course of my career as a technical writer, I have gone through many transitions. I will name only one at each employer, but, especially at Quintrex, I went through many transitions:
- NDP: converting from using OfficeVision to write training documentation to using MS Word
- JSI: transitioning from being a 'stand-alone' silo-type operation to consolidating each person's information / knowledge into a central repository.
- QDS: transitioning from documentation being a 'stand-alone' silo-type operation where each Quality Assurance tester wrote or updated documentation to developing a workflow where I was to review the changes to the system and figure out what documentation needed to be changed.
- Unnamed Hellhole in southern Iowa: honestly, bringing me into the department and having me question the tools we used (InDesign) was a big transition. Also, since I was to focus on creating online Help, that was a very different mindset.
- Pearson: converting from using MS Word and distributing user guides as PDFs to using Confluence
- Where I am now: transitioning from being a 'stand-alone' silo-type operation to consolidating each person's information / knowledge into a central repository so that I can publish consolidated disaster recovery documentation
No comments:
Post a Comment