Help The Client Help You

Another way to maximize your effectiveness is helping the client help you. The first step is to understand the client’s needs. Throughout this book, the client is addressed as though he or she is a single individual, and to some extent that is true. The person who signs your check is your client, and at the end of the day, you want to deliver what that person hired you for. Employees in the trenches will probably have different ideas about what needs to happen than the hiring manager. Acknowledge these ideas and navigate these needs carefully, because of the political and technical knowledge of the employees. However, keep your eye on what you were explicitly contracted to do.

Remember, it is in the client’s interest to maximize your productivity. However, the client will not take initiative in helping you; they’re pretty busy, otherwise they wouldn’t have hired you. You can be a standout consultant if you look beyond ‘getting the work done’ and really think about the larger picture and the client’s business, including competitors, new technology and the cost of hiring you. Once you let them know about anything that affects your productivity, clients are almost always willing to help. Make sure you alert the client to anything that may be hindering you. This includes lack of access to people or systems, as well as lack of understanding of the business, project or systems.

In certain organizations, contractors may be brought in not to do work, but to empire build. Dan was in a certain large company who hired him via a consulting company, but didn’t really give him anything to do. If you’re a developer who likes building software, this is going to be a frustrating position, since your skills and motivation will be wasting away. Make your concerns known, politely but repeatedly, to both the client and other employees. If you are going through a consulting company, let them know too. Make every effort to fulfill the contract, but if things don’t seem to be getting better, leave.

Beyond keeping your eye on what you were hired for, another valuable thing is to watch for needs that a client doesn’t even know they have. For example, using an open source database to cut costs, or using version control. This is secondary to getting your job done, but you can plant seeds for more work and build trust. It also might save the client money, and save you from doing scutwork, like writing yet another O/R mapping layer.

Techniques To Help The Client Help You

Some specific actions you can take to help the client help you include asking questions, figuring things out yourself, enabling the best communication possible, and approaching problems from a non technical viewpoint.

It’s fine to ask questions throughout a contract, especially at the beginning. Though you were hired for your technical competency, no one expects you to come into an entirely new situation and immediately understand how all the pieces fit together. However, there are techniques that make it more likely your questions will be answered. As you explore the system, begin to jot down questions. Then, find out how the client would prefer to answer your questions, be it email, phone, instant messenger or face to face discussions. Also, find out who should answer or dispatch your questions–the right person may be different for each question, but a technical person as initial contact works best. When you have a significant batch of questions, or you’ve run into a show stopper, use the client’s preferred method to ask the questions. Also, make sure you are polite, patient and persistent. Very often, the person with the knowledge to answer your question is the busiest person. Be polite, and ask them when you can expect an answer. Note that time and if it comes and your question has not been answered, ping that person again. Exploring the system and figuring out things for yourself can be useful as well. Before you embark on this, discuss how long you should spend with the client–it can be a poor use of time for you to figure out something that someone else knows by heard. Exploration can and should be used concurrently with asking questions; when you’ve sent off that batch of questions, see if you can figure some of them out yourself (given the consent of the client).

Additionally, make sure that information is communicated well. Written documentation is best. If you are having trouble getting written requirements, offer to write them yourself. Here's a good article on how to write requirements; he calls them ‘functional specifications’. These documents don’t need to be formal; wikis have worked well for two of the authors. Point out the benefits for the clients: you will be able to head off and work more independently, rather than asking clarifying questions all the time. If you can’t get the client to agree to write requirements, you should still avoid verbal requirements, which lead to misunderstandings. Rather, rephrase what you think you heard the client say, and then write the requirements yourself. Share them with the client if appropriate. Again, no need for formality, a simple email or text note can be enough. Beyond requirements, writing down other information, or getting the client to do so, is a great way to ensure that you have it in the future. Whether you send emails to yourself, keep a developers notebook, or have a personal wiki, having information in a written form will save you grief when you forget it.

Developers have a tendency to approach issues from a technical standpoint, often focusing on how to solve problems via software. You’ll be more valuable if you can ask questions and think about problems from different points of view. Some other viewpoints to consider: user, management, deployment, designer and DBA. Doing this will put you in the client’s position, and lets you know what questions to ask to help the client help you. Using these points of view, try to diplomatically point out solutions. Sometimes a fresh set of eyes can see new or existing problems, but, other times, everyone at the company knows about those issues – there may be political, historical, technical or business reasons for not addressing them. Be diplomatic; the new guy who rails about how crappy everything is has often not given much thought to how things came to be that way. His opinion may be discounted in the future, even when he has valid points. An example of a diplomatic way to approach changing the build process would be: “I notice that our deployment process has a lot of manual steps. I’m sure there are good reasons we’re doing it that way, and I wonder if you can help me understand why.” Do your best to understand the situation first, then if there’s room for improvement or education after you’ve found out all you can, propose it.

One time Dan was at lunch with a possible client, who had a crufty old user training system that was humming along. It was getting harder to maintain, but there was limited business value in rewriting the entire system. One of the employees of the client almost fell off his seat when Dan stated that as long as the system still had business value, it should not be rewritten: ‘I’ve never heard a developer say that!’ Dan was offered the contract.

Conclusion

In general, contractors need to be aware that they have the onus for being productive. The client will benefit and appriciate their productivity, but the contractor needs to be proactive in pursuing whatever information and access he or she needs. Think about the work you’ve been hired to do in terms of the larger picture and from different points of view, as that will help you do so.

Know What an Employer is Looking For

Being effective at your tasks increases the chances that you’ll be retained or referred, and makes the job more enjoyable, because you’ll be getting things done. Contractors are hired by clients for a number of reasons, but there are three broad categories. Knowing why you were hired lets you focus on what the client wants, and can let you know if the contract is going to be a good fit for both of you. The three broad categories are: hired hand, hired gun, or country doctor.

When an organization is understaffed, ofttimes hired hands are brought in. Hiring contractors allows for temporary staff-up without long-term payroll liability. You just do what you’re told with a minimum of fuss. In a well organized company, you’ll be handed a requirements or design document when you start. In other organizations, you might have to do some hunting to find the work for which you were hired. Either way, you are not going to have a long term effect on the corporation–you’re being hired for the hours of work you can provide. For that reason, these types of contracts tend to want you full time.

Hired guns, on the other hand, are contracted solely for specialized knowledge. For example, an Oracle expert might be hired to tune a database for performance. These jobs will typically not be forty plus hour a week positions. The client will expect you to transfer skills to employees; be sure to provide plenty of documentation and be a willing resource.

Back in the day, country doctors were the only medical resource for miles around; they had to do everything, including communicate effectively with people who had no medical background. Small companies and startups often hire people in such roles. The organization typically has little or no technical experience and is looking for help with minimal payroll liability. They’ll expect some attributes of employees, such as loyalty, even though both parties still have the understanding that you could be gone tomorrow. In this situation, try to view problems through the lense of the company, especially in terms of money. The clients are typically small and have less money, so do what you can to save money. This includes documenting possible corners that could be cut during requirements gathering. Communicate loudly about both present and future costs. It is far better to have this type of client know about the costs and choose not to spend the money than for you to spend the time without their buy in. (See the money section for more about getting paid.)

How do you know in which role you are being placed? Be aware of clues: ask about other technical resources; if they don’t have any, you’re probably a country doctor. If the client drops written requirements documents on your desk on your first day, you’re probably a hired hand. Knowing when you’re a hired gun is easy: did they have certain, drop dead, esoteric requirements for the job; “talk to us about an instance when you troubleshot Weblogic 8.1 while using SSL and Weblogic Portal Server.”

On the other hand, always be willing to offer advice. Even in the ‘hired hand’ role, you are still being paid for your ability to deliver software, and that means you’re still being paid to think. Offer advice humbly and know that some things may not make sense from your limited viewpoint. Some technology decisions may have political, legacy or technical justifications that you’ll not understand, and that the employer may not want to take the time to explain to you.

In general, larger organizations are more capable of handling contractors. They tend to be more used to contractors, have more team members to get you up to speed, and desire longer contracts. They also are slower to engage with you, and typically have large amounts of existing infrastructure that your code will have to leverage and fit into. Typically, you’ll be in the ‘hired hand’ or ‘hired gun’ role.

Small organizations, on the other hand, tend to be looking for individual contributors. There is little support infrastructure, and you might be the first contractor they have ever used; ‘country doctor’ is a typical role. There may be software already present, but it’s likely to be less extensive.

Either one of these situations can lead to a nightmare contract or a great experience. When you’re headed into a contract, the most important thing is to get to know the client’s expectations, which are shaped but in no way completely determined by the size of the company.