You may bring to your new company ideas that would prove quite valuable especially to a small or rapidly growing shop. A small or fast-growing company, with its shortage of experience and talent, may have no consistently applied standards and procedures; management allows the programmers and managers individual experience to prevail. Even the members of a programming team may use different standards. To you, an IT department like this may seem to be operating in semi-chaos.
In these situations, you can nudge the performance of your colleagues upward by using the standards and procedures you were trained to employ in your old job. If youre lucky, someone in authority will notice.
When I was a consulting programmer for a large software company, we used a set of detailed, handwritten program turnover documents when we went out to our clients offices. (Not all of those client companies had a software change management system. Thats why we couldnt simply employ a standard change management software package.)
At my new company, there were no consistent or particularly effective manual change management procedures. That led to mistakes in the programming projects turned over to production. So, on my new job, I started using manual program turnover documents similar to my previous companys (uncopyrighted) documents.
To my surprise, the systems analyst that I worked with adopted them and asked all the programmers on the team to use them. The project turnover procedure went much more smoothly than it had before, and now the disaster recovery and rollback procedures were written down, so theyd be available immediately if some problem occurred. I still find it satisfying , when I consult at that company years later, to see quite a few of the programmer productivity procedures I brought to the company still in use in this rapidly growing company. I didnt invent them; I just passed them onsimply by using them from my prior work experience to others who were not aware of those effective procedures.
If you come to a company with really effective tools and techniques, be bold enough to try them on your first project and see how your manager reacts. If he likes them, he may propagate them throughout the department. If not, then you can adapt to the companys procedures, even if theyre not as efficient as the ones youre used to.