The Development Abstraction Layer

Joel talks about what it takes to build a successful software company, not just cutting code and hoping to somehow "market" it:

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization... The abstraction exists solely to create the illusion that the daily activities of a programmer are all that it takes to create software products and bring them to market. Your first priority as the manager of a software team is building the development abstraction layer... If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.

Many of the same lessons apply to successful consulting engagements. If you are bringing in consultants to just cut code then you need to create an environment (manage) where they don't have to worry about getting accounts set up, finding the right person in a dependent team to talk to, having enough memory on the developer's PC, get a quick response for info when someone reports a production problem, etc. If you don't plan on creating such an abstraction then you better find someone else who will, otherwise the consultants will thrash between lots of tasks and the system stands a good chance of not getting delivered!