Contractor is not an employee

Everybody knows that contractors are cheeper, hard worker and more flexible than the average employee. Is not a rare case that they are working with a 3-6 months contract for 8-10 years on the same customer. It is great for the contractor’s mood being extended so long but is not a good sign then the maximum foreseen contract is 6 months. A the end is this a good management strategy? Probably the problem needs to be found beyond the pure fact of having short contracts, however If you need somebody for such a long time, it means his role goes beyond the 3-6 months contracts.

Of course is never easy to predict what the demand is going to be but after certain time, is clear what the vision and the strategy are. Moreover what are you going to do after your 10 year’s contractor is leaving? During these years he gathered a deep knowledge on the business, on the people and on the environment that is going to be hard to replace. I would recommend to keep as maximum 5 years time after that you consider to inglobate the contractor (in Europe, after 3 years of short term contracts the employer is obligated to hire the person with a permanent contract).

In software management, is normally best practice, well used, to use contractors for development, to train new employees or to make innovation analysis on new technologies. You should not use contractors for maintenance jobs.

If you are a good manager, you should find budget to bring through your good ideas and make your contractors happy to play with new cool stuff.

Never buy from the same Vendor. Competition is the key to keep control

Contract management. Enterprise companies and organizations are normally purchasing services and competences from a set of limited selected vendors that have won a tender and are fulfilling certain requirements. Outsourcing: well known and widely used approach to cut costs maintaining or gain flexibility. Sometimes is outsourced only certain part of the company, sometimes most services. Budget apparently is smiling, but there are some important risks.

Especially with big vendors, there is a risk of loosing control and quality over contract. A well know practice is to request an extension to “finish once for all the product” when the budget is already finished, the deadlines are missed and you, manager, start sinking in the shit. In these moments, is always cheaper (and easier to justify) to keep the same bad quality vendor and try to really finish the project before the budget, hopefully. There are never guarantees.

Market and Competition are the key. Buy from different vendor and make them compete to deliver better quality. If you successfully make it, you will gain control and you will simplify the replacement of people, if needed. This is indeed not an easy achievement, especially because in this system, vendors always make team among themselves in order to maximize the common benefits and try not to compete.

A good manager is going to give to any company the same possibility and opportunities to get visibility and to struggle to delivery in time and with quality. After one year is possible to judge and evaluate the performances of any vendor and make a priority list in order to give more to whom gives you more.

Don’t ask or impose people to decommission themselves

Every software developer is proud of what have written. No matter what they say, this is the reality. This attitude is present in any of us, but is more accentuate on junior programmers.

If you have the mandate to rebuild or replace some legacy project or application, you should never ask to do that to people that have worked there for more than 2 years. There isn’t only the fact that we are “touching their stuff“, but we are also threatening the position they have right now. The obvious consequence is a lot of resistance and contrast on your way to get your mission through.

Asking them is therefore neither a good nor an efficient solution. Is more likely not going to work.

What is more problematic here is definitively your position: on one side you have your boss, asking you to get rid of these legacy applications and on the other side a bunch of angry people blaming you for what is happening to them.

If you want to do it right, and in time, you have to invest some money (migration are expensive, not a news). I personally would create a team (not bigger than 5 people, but depends) with basically three different roles: 1 business expert (or Product Owner), 1 technical lead and developers (50 % of them can be an offshore team after the first 4/6 months). The legacy team would be in charge of the legacy documentation, and to support the new team on the implementation. They  would communicate only with the business expert.

Bear in mind that this idea is just a rough set of thoughts, is mostly based on my experience and should not taken letter by letter, depends case by case. The message I want to bring is to never ask people to decommission themselves.