Information Technology Dark Side

A few days ago I blogged about five ways we intuitively evaluate each other’s competency. Fluency, the ability to use the vocabulary of the project comfortably, is one of the most important. Without fluency, it’s hard to move on to comprehension, expression, and nuance. If you can’t speak the language of the project, you won’t be able to understand the consequences of changes to the project easily.

Even if you manage to develop comprehension without fluency, it won’t benefit you much. After a brief grace period, people will begin to treat you as incompetent even if you are not, simply because you don’t grasp the terminology of the situation. As an example, I can overlook a new hire saying something really stupid like “Java Real-time Engine” instead of “Java Run-time Engine”, but I wouldn’t overlook that in a job interview with an allegedly “experienced” developer, manager, tester, or analyst.

Fluency can be broken up into several different areas, and it’s important that you come up to speed on the right ones rapidly, depending on your role. Here are some common areas I focus on, in no particular order:

This isn’t an exhaustive list but it’s a good place to start. You should be able to summarize each of these, even if you don’t understand them perfectly, within a week or two of engaging in a new project. If you can’t you risk others thinking of you as incompetent or disengaged.

It’s not that difficult to come up to speed on these things quickly, if you do it consciously. Carry a moleskine with you, and make notes in it as you talk to people. The act of writing stuff down cements it in your brain. If you’re in a meeting and someone is describing features to you, get a marker and draw it on the whiteboard, to make sure you understand. If someone asks you about the project, try to answer them from memory. If you can’t, tell them you will find the information and get back to them. DON’T SEND THEM CHASING THE ANSWER IN DOCUMENTS IF YOU CAN’T ANSWER THE QUESTION. This simply postpones learning for you, and you don’t want to do that. It’s okay to send someone after documents when you do understand, if you have a reason to do so (like lack of time, etc), but only when you are already fluent.

Developing fluency is critical, not only in appearing competent, but actually being competent. I know it’s a bit squirmy feeling to think of oneself as incompetent, but if you or I can’t easily and accurately describe the six aspects of a project mentioned above without referencing notes, documents, or “experts”, we should consider the possibility that we are in fact incompetent to some degree. And others can see it.

Stumble it!