I have yet to find the first multibillion outsourcing company that was any good.
All the great people are immediately hired by the company they’re actually working for, so they’re always left with the mediocre and terrible.
Most confusing was when things were straight horrible ... there was nothing anyone can do. I don't know if the contracts say "you give us your money and just deal with whatever we give you" but that's how people would act. The outsourced company could do all sorts of absurd things that would have serious consequences had it occurred with domestic support / new procedures and etc. But when the outsource company did it and it was as plain as day "nothing we can do about it".
Those late-joiners had absolutely no clue on what was going on, and also didn't have the competency at all to hold the helm. Result? A much mediocre rewrite of the whole platform which never fulfilled the requirements.
Your above average talent gets trusted with high stakes, client-visible scenarios like new business development, RFP pitches, and high-visibility fire fighting. The roles tend to be a combination of subject matter expertise, solutions architect, client management, and sales.
Once you have a contract in hand, theoretically the engagement is structured at that point. It no longer needs the independent competence of members of your A Team, but rather competent project/program management, client/engagement management, and execution resources.
That's the stage where a lot of problems get introduced, and it's not always a result of cost cutting or profitability measures. A lot of it comes down to operational competency (both for the agency and the client), as well as the structure of the contract itself.
The biggest thing I've learned in my time consulting is what to do (and not do) when structuring a contract for a consulting/outsourcing engagement. Everything else cascades from there.
At enterprise scale it comes down to how well the consulting team can understand and worm their way into the business processes. They need an inside ally who can enable the consultants to navigate the silos, and not just some internal PHB barking orders.
Every enterprise org chart has a different flavor of dysfunction.
I run a marketing consultancy. I can't really offload my work to cheaper talent because my deliverables can be easily evaluated. Good writing and good design, after all, are universally accessible.
But unless you're a programmer, you can't really make out good code from bad code.
Outsourcing companies will aim for the lowest common denominator, which the contract allows and with which they can get away with.
Case in point? I can exactly tell you what the specs for the first time reporting system I worked with at MajorCorp said, without ever having seen those specs:
Must be able to enter hours
That's exactly what we could do. Enter hours. Not minutes, not ten minute intervals, not quarter - or half hours, no; hours.
When I get such a spec I hit back with questions. Send that to an outsourcer and they won't see any need to provide a yota more than what the spec says.
In other words: You entering a world of pain, which looks good on spreadsheet but really only that.
That's not always true. We recently dropped a small consulting company (~20 people, US based) that was awarded a small (but not necessarily trivial) project and really bungled things up. The end product was delayed numerous times, noticeably sluggish and riddled with bugs. It would have been an easy win for this company and would have led to more recurring work, but for whatever reason, they decided to assign the project to a single junior programmer without any oversight.
The consulting agency was prospecting for enterprise clients who would not pay attention close enough to such details.
Principal consultants, who actually really know their shit, are called in for the contract negotiations. Those are of course not the folks, which you get to work on the project.
The actual contractors are usually rather junior, often fresh of a plane and range in quality from quite good to absolutely abyssimal. With big name consulting companies they can still be billed at a daily rate of 2K +.
In other words, and less politely put, the consulting business is pretty much a bait and switch.
eg I used to do contract work with Fujitsu some years ago, as one of the implementation people in their projects team. We'd get things set up and working well, document the heck out of it for the ops team, and then hard it over to said ops team for daily running.
It's done this way so the more experienced / creative solution finding types ;) (eg expensive) can be engaged to solve the initial problem + implement the solution. Once that's working it just needs people to run the daily playbook and look after minor issues that crop up.
Basically any industry where manpower cost is the biggest cost and you have a fixed-ish price B2B contract, the only way to squeeze out a higher margin is to lower manpower cost.
Any company over size x is, by definition, staffed by average people. That’s the very definition of average. What, then, would lead anyone to believe that a sufficiently large company could possibly be full of geniuses? It just can’t happen.
(FWIW this is why I find the companies that do seem to break the mould – Apple, for example – so interesting.)
Average for that company, not average across profession.
> What, then, would lead anyone to believe that a sufficiently large company could possibly be full of geniuses? It just can’t happen.
It absolutely can and should (though it's another question why it rarely does). It requires expending continuous effort though - effort to bring in above-average people, to raise the level of people on-board so they stay above average, and to get rid of people that are below average.
This is actually what life itself does. The default, lowest-energy state of matter is a mixed and utterly uninteresting soup of everything. Living things continuously expend energy to maintain an organized, higher-energy state against the threat of average. They continuously pump entropy out.
If orgs outsourcing projects start optimising on quality of deliverables or security, or speed of delivery, we will see drastic change in behaviour of these IT companies.
IT companies will be better incentivised to hire smart graduates, invest in trainings etc.
Why do companies pay this premium? For one, it may be because they have a budget for a "6 month project" (wink, wink, nudge, nudge) but not for a full time hire. Sometimes it's because they think that they'll be able to pick and choose the best developers from inside a large organisation (and sometimes it works out that way... almost never, but sometimes...) But really it's just a matter of being naive, I think.
The company I used to work for (as an independent contractor... ahem...) went through a phase where the CEO was absolutely convinced that it didn't pay to hire developers -- they were a PITA (always demanding weird things, never showing up before 10:30 am, never dressing properly for work, etc, etc). They always wanted raises and you have to track progress and negotiate with them on price every year. You have to pay benefits and if a person is on disability on maternity, you've got to do something about it. You constantly need to be reviewing CVs, interviewing and hiring. If you get someone really bad, you can't actually reasonably fire them for a long time. Etc, etc, etc. So he tried a few experiments with hiring from outsourcing companies (all of which were charging considerably more than any of us were getting paid, I will add)... and it wasn't a disaster, but it wasn't really any better. But the cherry on the cake was, as soon as the project was done, they fled and no amount of pleading could get those developers back again (as you can imagine). So the CEO realised that having a crack development team was definitely worth the effort and the company really transformed as a result.
However, a lot of companies are still stuck in the mindset where it's best to have as few full time developers as possible.
Maybe I'm saying this from the perspective of a programmer and not a business owner, IDK. Cloud stuff seems promising: a nice way to deliver turnkey solutions instead of custom crap that needs an outsourced body shop to maintain.
I think from that perspective it makes total sense. Unfortunately, software is an embodiment of your business requirements and that you business requirements will probably be changing from day to day. Once you realise that, you can see that you need a team to be constantly changing the software.
In bonsai (trees in pots) there is a saying that a bonsai is only "finished" when it is dead -- because it keeps growing and changing. You can never say, "I'm done" because tomorrow the tree is different. I think this is also true of software: it's only "done" when nobody is using it any more (or, I suppose, when it's so unimportant that nobody cares that it isn't correct).
I think until we get the singularity, we will always need "programmers" -- people who translate the business requirements into something that the computer can act on. In fact, it's mostly thinking about the requirements that is important. The actual encoding of the computer instructions is (hopefully!) not that difficult.
Jesus please don't draw conclusions about things you have no idea about. Would you say that designing and developing machines that replace humans bit by bit is not difficult (hopefully!).
That's a curious choice of wording. I have considerable experience encoding requirements as computer programs. According to the latest Stack Overflow survey, I seem to be in the 99th percentile in terms of coding experience ;-) I find that getting the requirements right is dramatically more difficult than encoding the instructions for the computer (even if you happen to write a big ball of hairy code).
Consider that we have 3 types of errors that can occur in software: errors in requirements, errors in translating those requirements to code, and errors in expressing that code. In other words, we can build the wrong system because we got the requirements wrong, we can build the wrong system because our code doesn't implement the requirements that we gathered, and we can have errors where the implementation has effects that we didn't consider.
There is a reasonable chance that we can build systems that given requirements will encode them into working code. This can take care of the second 2 classes of errors. However, if you look at where most of your time as a developer goes to: it is rewriting the code where the requirements were insufficient or incorrect. Until we have an AI system that can replicate human levels of thinking we won't be able to go from "I need a sales report" to code because there is no way for the system to reason about what should be in a sales report -- and especially no way to ask relevant questions about the business to write a sales report that is good for that business.
No matter how good we get at automatically translating requirements to code, you are still going to need a person to gather the requirements and think in excruciating detail about exactly what you need. You may have noticed that normal people can't do that job. They will say, "I need a sales report" and you say "What should it contain?" -- the answer will be "The sales information". Keeping track of all the mind-boggling little details and exactly how it will affect the rest of the system is still going to be a job for a human -- until we can build a system that is capable as a human (and not just any human -- a human that is able to think very hard about requirements). This will not happen in my lifetime. It might not even happen in your lifetime (which by the very nature of statistics is likely to be longer than mine ;-) ).
The "hopefully!" part was meant to be a nod to the occasional situation where people build systems that are far more complicated than the problem they are solving. Hopefully you are not building such a system ;-)
I hope that cleared up what I was trying to say. I have to admit that I am not very clear on what you were trying to say.
> All the great people are immediately hired by the company they’re actually working for, so they’re always left with the mediocre and terrible.
By "great people" I assume you mean the best talent. I assume you also mean that corporate politics (bootlicking, backstabbing, parasitic behaviour...) has no role to play in these hirings.