Is this really true? I'm very sceptical.
Does anyone have any evidence to back this up?
For instance, if you have a clever solution to sales funnel optimization, chances are that even your savviest software customers aren't in a good position to deploy strong engineers on that problem; they're too busy making the things your customer wants to sell.
This is true of a lot of business functions: marketing, sales, recruiting, integration testing, devops, project management, bug tracking, log management, reporting, email. Basically take every product anyone ever sold successfully to tech companies and there's a list of things tech companies aren't good at effectively deploying in-house talent on.
For example, have you ever seen someone statically allocate a million element array to hold ~1-2000 6-digit numbers? Did I mention the program had significant memory usage problems? Then again, after looking at that particular mass of 30-year-old goto-loving, copypasta C, maybe I should have been grateful they never once used malloc.
Plus, a lot of custom work in software is not sophisticated. Customer mainly have basic needs (from the POV of software development) but many of them, in disorder.
Working for them, is more about have patience ("pls move this 1cm to the left, not right, can you also do X?, no we decide after all don't do that" etc) than the kind of "raw skills" of a uber-developer.
And what's fantastic about funded startups from the perspective of a software muggle is that not only might they have a product already in existence that you can check out and find reviews from other customers but they've also been given the stamp of approval by investors, investors who are likely far more knowledgeable than the average software consultancy customer. Just look at the Obamacare website debacle as a case in point of how incredibly difficult it is to a: find a quality development shop who can actually deliver what you want, and b: do so within reasonable budget and time constraints. And the difference between finding a good development shop and a poor one isn't merely a better quality product, it's a factor of maybe 2x or more in development time (which is, of course, tremendously valuable) and a factor of 10-100x in cost.
It may also be based on the premise that if you're doing consultingish work, you're probably not doing it for one of the top tech companies, but more likely for a smaller company that doesn't have dedicated developers.
From prior experience working at a consulting startup, this tended to be the case more often than not. Obviously, YMMV.
This also assumes your customers are the kind that pay for custom code and have coders, which obviously only applies to a subset of startups.
There are good programmers in the enterprise (meaning, say, investment banks or large corporations or governments) but they generally fall, ambition-wise, into one of three categories:
(1) those who want to become managers or software architects (or, in finance, quants and traders) and will define and oversee work but delegate the dirty bits. This would be fixable (they could oversee a team of mediocrities, who'd be grateful just to be employed) but they generally don't have the patience for that.
(2) those who want to do highly-theoretical R&D work that doesn't necessarily solve any immediate problems of the business.
(3) those who have a specialty (say, deep neural networks) and want to be in the umbrella of a large organization that can protect it. Pull them out of their specialties and they'll try to leave.
In other words, these supposedly stodgy non-technology companies do, contrary to stereotype, have good programmers (I've worked in a few) but the ones who are at all decent have career strategies that they expect to be able to implement in their full-time work. They won't work on "just anything" and if you stick them with the random muck that comes from the line of business or zealous "product people", they'll either leave or slack in order to learn new skills on the clock, and the project will be done poorly or even abandoned mid-flight.
The appeal of the $3000-per-day consultant is that he'll work on what he's told to do and he doesn't expect you to consider his career needs. He's not going to do a shitty job and leave after 6 months because the people allocating the work don't care about his career; that's what the money (4-6x typical salary) is for. He gets his education and career advancement on his own time and dime (but earns a premium to account for his unpaid work). And while he might not be a great (2.0+) programmer, he's better than anyone in-house who could actually be assigned a bad project without political friction or high departure risk.
The average Bay Area startup programmer, like the average software consultant, isn't great; but he's far better than the corporate serfs who get sloshed around on the worst projects. He might be 1.4-1.5; so Goldman's R&D engineers and it top quant-coders will be better, but he's a relative colossus compared to the in-house peons (0.7-1.2) in back-office IT who'd get assigned to grody projects based on internal processes.
(Of course, not all the work that consultants do is undesirable. You also have the specialists and those with elite levels of skill. My point is that a "mercenary" consultant will power through the ugly projects for the pot of gold, whereas in-house people expect investment in their careers.)
In other words: yes, Goldman can hire great people. But if you want to hire someone great to do a project where 99% of the work is mediocre (and the 1% is extremely careful and requires an expert) you want the $3000/day consultant because Goldman can't get anyone good who's in-house (and not getting a consulting salary) to do the work. One might ask: why don't they pay an internal person $3000 per day, as they would a consultant? The answer is that it'd have him out-earning his boss and they'd often end up promoting someone not on traditional definitions of readiness (increasing scope, leadership) but because he took on an icky project.
And, while I do buy that all three of these developer archetypes exist in the real world, I do not buy that they are the reason that companies don't deploy talent aggressively to upgrade "support services". Rather, companies make straightforward buy-vs-build decisions based on whether projects are part of the focus of the business or not.
It does. That's not the sole reason why consultants make more, but that's a factor.
If you're a full-time employee, you expect your health insurance, HR, work supplies, 401k, office space, finding of work, and your career growth and promotion planning to be taken care of, and you're likely to leave if you're not getting it. If you're a consultant, you're taking on those responsibilities for yourself. That's a big part of why you charge a higher hourly rate. It's to include buying your own health insurance and having to manage your own career with no expectation that the people giving you work give a damn about your vector.
That's not to say that typical middle managers or companies actually care about the careers of most people under them, but they at least pretend to, and some actually do. It's part of the social contract that exists for an employee and not for a consultant. Of course, after being an employee for a while and seeing that part of the social contract ignored, many people decide that the job is too important not to do themselves and start managing their own careers... and some become consultants.
A well managed internal team could do the work at 1/3rd the cost but the work is rarely a core part of the business and no executive wants to deal with the internal headaches and risk associated with the work when it won't get them anywhere politically.
The "contracting" world is much more like what michaelochurch described. And to be fair there are a large number of individual contractors working at large firms for great daily rates (think $1000/day on the lower end) for which what he is saying is true.
http://michaelochurch.wordpress.com/2012/01/26/the-trajector...
I've never seen it used by anyone other than him either.
This is more up to date than nostrademons's link:http://michaelochurch.wordpress.com/2013/04/22/gervais-macle...
Also, from Quora: http://www.quora.com/What-do-the-top-1-of-software-engineers...
The last sentence is a very important point in enterprise IT shops: Lack of self-confidence in line managers is a big disincentive to hiring smarter developers. They worry that the smart developer (who often shows up with a bit of an attitude) will overshadow the manager and our point out their weaknesses.
lol...well you just described my last contract.
(4) Good but insecure (at least in a financial dimension) who seek the safety and anonymity of large corps and
(5) Favor 9-5, low stress, and a steady paycheck
Contrary to what is often said about middle management being hell on earth, it's not worse (on average) than being on a team, just different. You don't have to be unambitious to want a job where you primarily evaluate others' work instead of doing the work.