Integrating Into the Client's Environment

Integrating into the work environment of your client is often a crucial part of maximizing your effectiveness. (For remote workers, this is important as well. Please see the ‘remote working’ section.) Being able and willing to integrate means that you’ll have less friction with employees, be able to pick up undocumented but important norms, and move more adeptly around the political structure of the client. This section presupposes you’ll be working with a team of some kind–if you are independently delivering software, integration is much less of a concern.
Before the first day

Before you even start a contract, but after you and the client have agreed that you will do the work, ask these questions:

1. Is there an expected level of dress?
2. Is there an intellectual property agreement you’ll need to sign? Can you get a copy of it before work starts, so you can have it reviewed by a lawyer if need be?
3. How would the client prefer to be invoiced? If you have a preferred timeframe, let the client know that too.
4. Should the project work be viewed in light of any larger goals?
5. When should you arrive on the first day?
6. Should you bring your own computer, or will they provide one?
7. What tools does the team use? How can you get them?

On the first day

Getting the above questions out of the way before you start working lets you arrive on the first day ready to work. Coming in 5-10 minutes early can help kick start the day and shows that you are enthusastic about the work. The client may need a little extra time on the first day; be aware that, depending on their experience with contractors, they may not be ready for you. Be patient, but never forget that you’re being paid to produce. Coming in with these questions can help you move the process forward:

1. How do I get the code I’ll be modifying and environment that I’ll be building in?
2. How do I make changes available to others?
3. Where do you get the tools others use? If you haven’t gotten them beforehand.
4. Who is on the team? What are their roles? Make sure to ask for formal introductions, at the least, to the other developers and QA.

After the first day

Getting to know the team you’ll be working with can help you integrate. You want to do this both formally, on the first day or as soon as possible, and informally, which generally takes more time. Informal connections can be quite useful and informative; the best way to cultivate those can be attending lunch. Additionally, clients sometime have company events and may invite you to them. Be open to attending, though always be professional. When you attend such events, be friendly and ask each person you interact with what they do for the company; be interested in their answers.

As you get to know the team through formal and informal channels, begin to note each individual’s strengths and weaknesses. Never share this opinion, but use it to determine your course of action. For example, if Megan has a strong grasp of the data model and its history, but a poor grasp of the UI requirements, go to her with data model questions, but don’t ask her about button placement. You can also gain knowledge of who the decision makers are, which can be useful whne conflict or uncertainty occurs. However, try to never offend anyone, since, as a contractor, you have less knowledge of the inner politics in the client than most employees.

On a more technical level, try to use the same tools as the team. This will help you, because you’ll be able to use the same terminology as the team, as well as leverage their experience and knowledge. It also makes it clearer that you’re interested in integrating with their setup, rather than the other way around. When setting up a development environment, using a virtualization tool like VMWare helps you keep different client environments separate, and your machine clean from unneeded software installs. If the company uses expensive tools, finding out beforehand can help you prepare. You may be able to get by with evaluation copies, if the client will not provide you the tools. In an extreme case, you may discuss buying the tool and billing the client for it.

Integrating into the team doesn’t mean blindly following their suggestions, however. Just as when you’re a ‘hired hand’, your experience with other environments can be a source of real value for your client. Make suggestions from a technical or business standpoint when you feel you have knowledge that could be useful, whether it enhances the technical environment or helps the client avoid a mistake. However, be careful not to appear a ‘know it all’. One easy way to do that is to frame your knowledge in terms of making the current project succeed. For example, ‘You know, I think if we used a build tool, deploying the application would take less time.’ If your suggestions are turned down, you need to decide, based on the severity of the issue, how hard you should push your agenda. At the end of the day, it’s the client and the employees who have to live with the issues inherent in any piece of software, so be gentle when suggesting change.

Conclusion

This section outlined ways that any contractor can integrate themselves into an existing technical team. This may force you out of your comfort zone, but the benefits can be great, as the team will tend to resent you less and may be more able and willing to share knowledge about the project.