Every company is unique. Every company has their own processes, their own documents and, of course, their own language. That language is part of the culture and if you don’t embrace the new language it’s likely that there will always be friction and, worse, misunderstanding in the future.

Take, for example, the process documents you work with. Regardless of industry there is usually some form of communication that contains the requirements of what you have been asked to build, and after that it is likely there will be a more detailed communication that outlines what it will take to meet those requirements.

Previous monikers for the former, that I’ve come across, include Market Requirement Document, Business Requirement Document, Request for Enhancement and so on. The latter I’ve seen referred to as Functional Specification, Software Requirement Specification and Build Plan.

Which means, culture/language wise, I’ve spent far too much time reading MRDs, RFEs, SRSs and so on.

But the key is that whilst most of these documents do, essentially, the same thing, I’ve happily switched my language to incorporate these new terms. It’s not a big switch but it’s a crucial one which helps me frame my work in the correct terms. These things are, by and large, considered a small deal by many, but getting the culture right and buying in to that culture is key to building a successful team.