With a well-documented project, anyone possessing the bare minimum of competence can set it up and have it running in no time. You don’t want that in your workplace. That means that some eager, overachieving newcomer can use it as a shortcut to build up his reputation much faster than you could. Your goal is not to level the playing field, but to tilt the scale in your favour. Remember, information is power, and that power is the documentation in our merciless IT world.

While you should always take the advantage of the existing documentation written before you joined the org, you shouldn’t add to that pile - ever. Moreover, you should fight with every fiber of your being that the pile in question never comes into existence.

Of course, bits and pieces of valuable information in a written form will, and should, exist. The key point is to keep them to yourself. This is how you’ll do it…

When you find yourself in a need of some precious recipes or how-to’s that will propel your career to the next level, ask your colleagues to document what you need, but make sure that you, and only you, receive it via email.

You will build your private knowledge base comprising the documentation pieces you’ve gained through private communication channels, and you’ll do it cleverly.

Always be careful about the way you extract the documentation from the others, because if you ask someone outright for the whole recipe to a certain solution, they will most likely post it to a company’s document management system. Even worse, they may alert everyone in the company’s main IM channel they produced a document, as low self-esteem, attention seeking grunts usually do.

If that happens, the harm can’t be reversed, so tread carefully.

The clever way to do it is to involve a colleague (the sucker you’re asking for the documentation) in a chain of emails, extracting the valuable information bit by bit, which you’ll then compile into a final document for your eyes only.

It’s always good, even necessary, to add random, unnecessary fluff to the email chain that will only make sense to you. That will make it hard for anyone else to parse the chain and compile the final documentation from it.

The phrase that you should think of when thinking about the documentation is “Tribal Knowledge”. Tribal knowledge is any unwritten information that is not commonly known by others within a company. You’ll want to keep all the knowledge in your organization tribal. Your goal is to become the leader of the tribe soon, so you’re the one that’s going to control all of it in the end.

What to do when you’re the one being asked to produce and share documentation? Well, avoiding it may prove difficult. Your annoying colleagues and product/project managers will approach you often, saying that writing documentation should be a part of your process. They will even allocate time for documentation writing sometimes, those self-important do-gooders.

They will say it helps the team grow, or it helps the company grow. It might be so, but it won’t affect your life, financially or otherwise.

To successfully get yourself out of that situation, never attempt to write any documentation while you’re working on a project. Always leave it for the end, making the excuse that you can’t properly document something that will change multiple times until the end. Don’t give in, and defend that stance. You can always say that people like you accept nothing than perfection, and risking having a messy and tangled documentation is unacceptable.

Deadlines will come, as they always do, and you’ll already have spent all of your time working on the “more important” stuff. Nobody ever prolongs deadlines because of the missing documentation! It’s as sure as death and taxes.