A True Detective: an InfoDev in a Project Team

The skill of being a good detective lies at the very heart of the InfoDev profession. My personal impression is that among many other roles, such as being a writer, a linguist, and a “user prototype”, an InfoDev on a project is also a detective, an investigator – especially, at the early stages of involvement.

Imagine that you have just been assigned and welcomed to your new project. Congrats! Now, consider this scenario: “When you arrive at the scene, the crime has been committed, and the evidence is partially corrupt or hidden. The potential witnesses are reluctant to talk about what they saw, what they did, and where they were on that distant day. The culprit is on the run. You realize that what you deal with is a cold case”. Does that ring the bell? After a couple of days of work, does this detective story sound strangely familiar?

Apart from the biggest passion in my life – Information Development – I am truly passionate about watching television dramas, especially detectives and police procedurals.

Once I was watching one of the most anticipated detective seasons of the year. Suddenly, it dawned on me that my everyday working experience is similar to the one I am getting when watching a story about investigating a crime or solving a mystery. That insight led me to thinking about my job routines more in terms of an investigation than just documenting.

Furthermore, my colleagues have recently discussed the 10 indispensable traits of an InfoDev, and having an investigative and analytical mind was high on the list. That, too, has inspired me to speak about the investigative talent of an InfoDev – an ability of being a good detective.

In my opinion, an InfoDev, similarly to a good detective, must have the following skills and traits:

  • Digging for clues
    As a detective starts the investigation by searching for clues, an InfoDev starts the documentation project by gathering information. It is equally true if you are getting to know the application or when a new feature has just been developed. Here comes the investigation itself: click through an application, study all possible workflows, and notice all the changes on UI and in the logic. You may even find some bugs in the process. Needless to say, during the investigation you need to use both logic – to establish the right connections and workflow – and vivid imagination that will help you see the whole picture through the eyes of a user.
  • People skills
    To get information, you need to master communication and people skills. As O’Keefe and Pringle put it in their must-read book Technical Writing 101, “The information you need resides in someone’s head, so you must be able to work with that person to (gently?) extract the information”. That perfectly sums it up. Learn what works best for different members of your team. Some communicate best in writing, some like to talk. Some prefer to start the day with their hardest tasks, and you should know that they must not be bothered at that time. Some like cracking jokes, some are dead serious. Some explain the whole picture, some need to be asked the right questions. Study these habits and peculiarities and make them work for you – use various interrogation (interviewing) techniques. Besides, who else but not your team will help you learn your own ABC’s – from where to download the recent builds to who is an expert in specific subject areas?
  • Preparation
    Do your homework. Come prepared. A good detective knows laws and regulations and learns lots of specific information. This knowledge allows making correct assumptions and asking the right questions. What about InfoDevs? We usually have little time to learn how the whole application works and what the business logic is. Nonetheless, do it. Get as much information as possible about your application and subject area from the existing documentation, specifications, prototypes, or emails. When you appoint an interview with your SME, come prepared. Show that you respect their time by not asking questions that you could easily investigate yourself.
  • Going undercover and assimilating
    The experience of starting work in a project team – among developers, QA engineers, architects, business analysts, and managers – reminded me of an agent who works undercover. At the very beginning, integrating into a well-formed team of old pals might seem an uneasy task. It is useful to watch and study carefully the ways and habits of your team, and then adopt some (or many) of them. Even small things matter: if no one else in the room talks loudly on the phone, you should not do it either. Be friendly to your teammates, but no hypocrisy! Be honest and open, be yourself (or your better self). You will not only find it much easier to work and communicate, but also discover that you are having a good time with awesome people.
  • Showing initiative and being proactive
    A lazy and indifferent detective will bury the whole investigation. Similarly, an InfoDev has to be involved in all project discussions, even – and most importantly – informal ones that happen at a water cooler or during a coffee break. Besides great socializing, you will get tons of valuable information as to who is doing what and what difficulties your team is experiencing. Most importantly, ask questions if something is not clear. Speak up if you think that you as an InfoDev professional can contribute to making a product better. If you hear that someone in your team discusses the feature you are about to document, do not hesitate to join the conversation. Well, at the very least, pay attention.
  • Listening (establishing surveillance)
    A tip: wearing a set of headphones while conducting a surveillance (working) is not the best idea. The largest part of valuable information is being spoken. Do not expect that someone will inform you of all the latest developing decisions and changes via email or will appoint a meeting to keep you on the same page with the whole team.
  • Being patient
    Working on a difficult slow-moving case or a project requires patience. Sometimes it is counterproductive to rush and document a recently developed feature. After the code is reviewed and the feature is tested, many changes may follow, and you may end up rewriting the whole topic.
  • Critical thinking
    Critical thinking helps a detective avoid the wrong clues and not be fooled by the lying witnesses. Similarly, an InfoDev should critically evaluate the received information. No matter what your SME says, the users do not need the long intro about the code specifics that enables the new feature. On the other hand, we should be critical to our own writing: to make it clear and minimalistic, many long wordy sentences just need to go.

To conclude, those InfoDevs who feel excited when digging deeper into the subject and collecting the fragments of information to get the broader picture, in my opinion, are true detectives. They are heroes of open spaces and cubicles, having both introvert and extrovert traits. Their skills may be natural, but they also might be acquired with experience. And, as long as the project (just like a TV show) lasts, the progress can be measured not only by the volumes of paperwork that we, InfoDevs, produce, but mostly by the whole picture that we have managed to establish and communicate to the users.

One more thing: the list above is by no means full or exhaustive. I am eager to hear your suggestions and specific cases from your own experience.

Advertisements

5 thoughts on “A True Detective: an InfoDev in a Project Team

  1. Yes, yes, and yes! This is fantastic, and so true. For years I’ve told my students that Lieutenant Columbo — dogged, underestimated, and smarter than everyone in the room — is the patron saint of technical communicators. Now I’ll just point them to this article.

    One minor point (since no InfoDev can resist editing another writer’s work): the co-author of Technical Writing 101 is Sarah O’Keefe, not Keefe. It is, as you said, a must-read book.

    Liked by 1 person

    • Hi Larry,

      Thank you for your feedback!

      I loved the idea of Lieutenant Columbo being a patron saint of technical communicators. When it comes to communicating with team members (suspects!), indeed, Columbo is the best role model. I always liked his seemingly simple and matter-of-fact tone and sharp mind. And I guess I have just found inspiration for a new post))

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s