Demonstrate Competence by Developing Your Project Fluency

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:

Technology: J2EE? ROR? .NET? CICS/COBOL? Whatever technology is in play, there is a vocabulary to accompany it. The example in the previous paragraph is of Technology Fluency.

Context: What problems is the project attempting to solve? Who cares about these problems, and why are they important?

People: Who is on the project and what do they do? What are they good at? What are their limitations?

Trouble: What do people worry about? What keeps them awake at night? Sometimes you can find this stuff on issue/risk lists, but not usually.

Features/Scope: What is the project going to build? What business capabilities are in scope?

Design: What are the major software components of the project? How do they interact? What is the relative complexity of each of them?

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.