On Consulting and Consultants

In today's job market talented software developers are in absurd demand, far exceeding the supply. Everybody is looking for them. When they become available the competition for their services is fierce. This leaves companies in a difficult position. There are a few options available: greater investment in hiring, lowering the bar for qualified candidates, choosing not to fill the position, or hiring a third party firm.

I spent several years as a senior consultant at ThoughtWorks. Now, as an employee of Braintree I have experienced life having consultants join our team. I will attempt to remain as objective as possible, but hey, it's a blog post.

Situations where consultants are valuable

Hiring a third-party firm is not cheap. At ThoughtWorks, I regularly billed over $150 an hour, occasionally upwards of $200 an hour as a developer. With some quick math, assuming 40 hour weeks and 50 working weeks a year, that consultant you are paying $150 an hour is costing you $300k a year. At that rate, there are several places that consultants can prove their worth.

Providing expertise

There are many companies out there that are experts in very specialized skills. Microsoft is a very good example of this. Microsoft Consulting Services and their partners are experts at very specific Microsoft products. Many open source tools offer similar consulting and support models. If, for example, you would like to set up an instance of Microsoft Dynamics CRM, Microsoft is happy to provide you with consultants that know that product inside and out. Bringing one or two of these folks in to train and educate your team can be a very successful partnership. As a short-term investment, they can get you pointed in the right direction.

Specialized consultants are not without caveats. Often people with very deep, specialized skills are very weak in other areas. So while this person may be an expert in Dynamics, its likely they are lacking in knowledge of testing or automation, or anything else that is necessary to successfully ship software. They most assuredly do not have a deep understanding of your domain. Also, any context that they have built about your particular solution will be gone when they leave. Therefore, I like to think of specialized consultants as bay leaves, they can add wonderful flavor to your dish, but you want to take them out before you serve it to your guests.

Independent Delivery

A much more difficult proposition, but another that can be successful is to have the consultancy provide you a team and build a project independently. This can be quite valuable when the opportunity cost greatly exceeds the cost of the consultants and you simply don't have the development capacity to build it yourself. A discrete project also opens up the opportunity for fixed-bid contracts that may help keep costs under control.

The war in Iraq has taught us, when starting a large expensive venture, its best to have an exit strategy. The vast majority of the cost of software is maintenance and having consultants doing maintenance is prohibitively expensive. At some point the maintenance of the application needs to be turned over to another team. There are probably more, but I have seen three exit strategies have some modicum of success:

  • Seed the consultant team with the future maintenance developers. It can be a subset of the team that will eventually take over development, but you need someone to gain the context that the consultants will be taking with them when they leave. They will also aid in providing context to the consultants about your development environment, existing APIs, deployment requirements, etc. Adding an employee later in the development process is better than nothing, but there will be some historical context that will be forever lost.
  • Allow the consultants to hire their replacements. This can be must more risky as hiring is what defines the culture of your team, but it can be useful when you have built a foreign artifact, for example a Ruby on Rails application in an enterprise Java organization, and simply don't have anyone on staff with the knowledge to properly vet candidates. You should be warned that this can take quite a long time. I did this with a client for ThoughtWorks and it extended the engagement 6-9 months longer than necessary.
  • Throw it away. Not all software lives forever. Some is built for a specific event like a presidential election. When the election is over, the software is useless. The consultants leave, servers are turned off, its like it never happened. This is by far the easiest of tactics, but obviously the least common.

Things to watch out for

Consulting is a business. They are out to make money just like you are. It pays to understand how their business works and how firms game things to turn a profit. There are some things that will happen during your relationship that you need to be aware of.

Frequent Rotation

One of the alluring aspects of being a consultant is to have constant exposure of new and exciting projects. Working for a consultancy generally does not pay as well as working for a product company, so changing projects is one of the primary ways that the developers are kept happy. While this is the number one reason I recommend people coming directly out of college to join a consultancy, it can be damaging to a client. When that consultant walks out the door, all the context that they have built about your company and software is gone too. Constant churn and training can be damaging to the team morale and productivity.

Makeup of the Blended Rate

Often, the statement of work for a relationship will include a blended rate. This means that you pay the same rate for each consultant regardless of experience level and skill. If you are paying one amount for a team of two senior people and two junior people, and a senior person is replaced with a junior person, that rate looks a lot worse. This is understandable from the point-of-view of a consultancy because they maximize profits by staffing a blended rate project with as junior of a team as possible.

Incompetence

Hiring is very difficult. When you bring in a group of consultants, you are basically outsourcing your hiring to them. You need to make sure that the developers joining your team are competent. Relying on the reputation of the firm in insufficient. You need to hold the consultants that join your team to the same standards that you hold developers you would hire. This is important not only for the quality of the work that is done, but also for the morale of the team. A very toxic atmosphere can be created when part of the team is perceived to not be pulling their weight.

Situations to avoid

Staff Augmentation

One of the silliest arguments I hear in favor of working with consultants is that they become your "developer cloud". They are capacity that can be easily added and removed to respond to business demand. If you believe this is true, I suggest you stop reading now and immediately buy this book. There is no faster way to slow a team down than to introduce churn into the makeup of the team. Not only are software projects usually large complex beasts, their development is an incredibly social activity. Learning a domain and gelling with a team are not things that are done easily and without effort from the team itself.

Intermingling of consultants and your development team generates an incredible amount of waste. As I said before, you typically will have a mix of senior and junior people. Both groups need to gain understanding of your domain. That knowledge takes time to disseminate. The junior people also need investment in their skills to become competent senior developers. That investment takes time. It takes time away from building great products. It takes time away from building up your own junior people.

Meddling in your Core Domain

Every software project has that core part that is its essence. Its what differentiates you from your competitors. I strongly believe that you should never give any sort of control of your core to any third-party. Does that mean that every line of code in your core needs to be written by an employee? No, not at all. But I do believe that every decision should be vetted and every line of code should be reviewed. Its simply too precious to give up control of.

Wrapping up

Hopefully I've given you some food for thought when it comes to working with a consulting firm. Used tactically, consultants can help deliver really great value. They are not a magic bullet. Use them wisely.

blog comments powered by Disqus