Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company.
But after selling the deal, their workers have to solve a difficult engineering and organizational management problem simultaneously (the project).
They use contractors (devs) which proves they are not an engineering but sales culture. So, you need to bridge the two worlds. That's the PMs.
These are the most incompetent members of the team. The devs very often are very smart.
Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things.
Reasons for failure:
1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem.
2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed.
These kinds of projects fall under what used to be called IBM Global Services https://en.wikipedia.org/wiki/IBM_Global_Services. It could be compared somewhat to EDS (HP), Accenture, Perot Systems (Dell) etc. I've never heard of over-delivery from any of these kinds of outsourcing arrangements, they always seem so obviously destined for boondoggle.
IBM proper, the one that makes mainframes and POWER and DB2 and a ton of operating systems and storage etc is very much a technology company. Some of their best products have the worst sales and marketing efforts. I'm working directly with the senior leadership of the POWER group right now and there are no salesmen in sight.. the technology will either sell itself or not. When we met in person the first time the GM told me "we can build any kind of computer you want" - meaning microarchitecture changes, SERDES configuration, new board layout, sheet metal, OS, application tweaks. Not a lot of companies can do that. There is hubris, less technology, and lack of technical value at FANG or most startups or whatever your benchmark is in comparison.
I’m surprised the Stratix FPGA platform isn’t getting more marketing. Half a TiB/s memory bandwidth [0] (white paper) when GPU’s memory transfer is the bulk of the overhead could help Intel make up for lost gains in SIMD application marketshare.
There isn't more buzz around the Stratix 10 MX because it's a phantom chip. Intel's December press release clearly states that the chips are available but you can not buy one of these chips today. A blogger did some research and came to the conclusion that the press release claims were simply not true:
HP has GenZ, IBM is going to move from DDR or DDR buffers to CAPI attached RAM -- expect to see HBM2 attached to CPUs in 2019. I'd be happy to discuss that kind of thing in email.
Certainly misplaced! It was late, and somehow I scrambled IBM Research and Intel. I was thinking about how Intel's marketing is generally quite bad, whether it's unfair benchmarks or not knowing which products to actually push.
Early in my career I had a brief stint as an engineer at a consulting company in the ERP industry. Our projects always had at least one functional consultant whose expertise was _using_ the ERP systems and understanding how they integrated with other systems and procedures. This was a different position than PM, who was often an employee of the client company who drew the short straw.
The functional consultants had varying degrees of technical experience (some were highly technical, including having CS degrees), but in general they were people who in a previous life became really good at managing and hacking their company's ERP system, became the goto person to deal with crap, and figured out they their domain knowledge was highly valuable.
The competence of our technical consultants was questionable. On my first project the senior tech consultant told me that I was the first person he worked with (himself included) who structured his code into modules. He was like, "it makes it so easy to use your stuff!" :) But the functional expertise was excellent and the reason the company had an excellent project success rate.
The company basically imploded after some senior technical engineers and managers bought into the Java and XML fad. Their plans failed horribly because the technology was too complex for the technical consultants (not to mention too immature), and it left little room for leveraging the expertise of the functional consultants as pivoting to Java and XML effectively required reinventing everything. Chaos ensued and, after being bought by a major ERP systems vendor (ironically for their strong project success rate), effectively disbanded.
A functional consultant on our team who is great. Connected to their functional consultant who was wildly differing in skill level, from expert to can barely use a computer.
Technical Consultants, which involved 1 Senior who knew everything about one segment of topics. Another Senior who knew everything about a different segment of topics. A junior to learn things. And the PM which was also the sales lead looking for more work.
1 of those Seniors needed to be able to have social skills and diplomacy, the other didn't. You could hide the 2nd through preplanning.
The junior just needed to know to keep his mouth shut.
Then you'd have a variety of other seniors who you could call in on a particular topic, but you'd try not to use, as they are on projects.
And in our case, we had a GM who was more functional than all of us, almost as technical as all of us, and the best in front of customers. He could be brought in to deal with any special scenarios, and to gut check our plans.
So we were really, ridiculously successful with that model.
Basically, really well paid, SMEs, no cruft except a younger guy to learn on the job. Such a good structure.
Amusing to me that people consider a ton of modules to be a sign of high code quality.
What was your role in the project? Did you swoop in and do a copy and paste refactor into a bunch of tiny files and declare your victory?
I’m going out on a limb here but I’m going to say you’re a little bitter at the value of the consultant vs. your own textbook, indignant idea of value.
You obviously never used Allaire ColdFusion, before it got fancy features like functions.
IIRC, a "tag" was the closest equivalent to a function, but it was basically a parameterized textual include. A "module" was a "tag" that didn't need to be installed into a special directory. During development the only easy way to not have the source code for your entire application in a single logical source file (split across unparameterized includes) was to use modules. Using tags was a PITA because of the need to install them in a special location, but for [reasons] people never bothered using modules at the time.
So to better understand the context, s/modules/functions/.
The fact that I uniquely used modules says less about my competency (or the competency of any particular consultant) and more about the general technical competency of the organization. As I said, some of the technical consultants had CS degrees so they fully understood the concept of functions, as well as more difficult concepts. The senior consultant I mentioned had a CS degree. I didn't mean to imply that I thought I was more competent than he was; quite the opposite. I remember what he said to me precisely because he did have a CS degree (which I lacked), was one of the most experienced consultants at the company who had worked with most every other technical consultant, and was someone I generally looked up to.
And you conveniently skipped my larger point which was that the organization was successful without strong technical competency. All things being equal you want strong technical competency, but especially in the world of ERP systems where everything is highly customized and a tremendous amount of code is ad hoc business logic, functional competency is incomparably more important for achieving project success.
I have been on the bad side of IBM Global Services both times I’ve encountered them and was warned off by someone with existing beef.
They will build the most complicated thing that could possibly solve the problem. And then you can’t get rid of them because holy shit nobody else wants to deal with their code.
If Rube Goldberg and H P Lovecraft had a child it would weep in despair knowing that in all its life it would never create something as sinister and complex as the stuff IGS makes before breakfast.
They were trying to charge $80k a year for a proxy server to handle XML RPC. For a system that was basically ftp with code signing. Our team took care of the code signing, soup to nuts. To this day I don’t know what they were doing with all that money for a tiny part of the system. Except try to take over. They didn’t expect the wall of competence they encountered.
> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal.
I do understand what you meant here, and it's mostly right. But there are also obvious exceptions.
You can often make a sale by promising more than your competitors. If your competitors' bids are calibrated by what's actually possible, and yours isn't, then you'll win the bid... and then, years later, be unable to deliver what was specified, and have to renegotiate. But hey, you won the bid!
I guess that, if the market doesn't keep track of these renegotiations and failures-to-deliver, this is the optimum strategy over the short- and even medium-term. But it gets your company known to devs as a company that chews up and spits out talent. Devs that get stuck on projects trying to do the (literally) impossible, slogging forward each day with the knowledge that all of this is going to be ripped out when the deadlines pass and the renegotiation hits, don't tend to recommend to their friends the companies where they had to do that. So, over the long-term, this is a recipe for a talent shortage.
But, like you said, there's always contractors: fresh pools of devs who never signed up to work for something like IBM, headed by either unscrupulous or just plain naive management willing to take on such jobs with literally-impossible specs.
The project sizes are fine. The team sizes are too large.
There's too much empire building and career-minded politicking going on in companies of this size, which gets in the way of actually working on the product. Managers increase scope to increase their budget, then do busy make-work to justify the budget so they can get more next round. The engineers need to look busy even though things aren't defined, and optimize to internal-facing metrics as opposed to product-oriented productivity. Anybody who steps back and mentions that progress isn't being made towards actually getting the customer a working product is reprimanded as undermining the unquestionably accepted established processes (which usually aren't working anyway).
The actual deliverable gets lost in the shuffle, as the lumbering hulk of the company and career paths within it overshadow the customer.
This is the correct answer. I saw it first hand how PM and engineers don't care about the product, they just care about their careers and company internal metrics.
A friend of mine has had an illustrious career in I.T. with many successes in the last decade. Right before he struck out on his own to build his brand he was unhappy with his then job and decided to work with a recruiter to find a new role.
The recruiter got him a job with a large bank going through a transition from a major platform from a third party that had been long neglected. The platform was on what we will call version 5 of the software while everyone else was running what we will call version 9 of the software.
My friend was hired as a technical project manager. He worked there for less than a month before he struck out on his own and got to realize his full potential.
In that brief period of time he learned the following:
* The bank had not started to put together the requirements for the new software to be integrated.
* The software vendor had no upgrade path from the very old version to the new version.
* The bank needed the migration done in under ninety days or they would start getting fined millions of dollars by regulators.
* The project had already committed to spending $3M / month on a five year commitment with a hosting partner but they didn't have any developers working with them yet.
What I took away is that when big companies do stupid things they are big stupid things. I'm not surprised that government being as big as it is would also do stupid things on a larger scale.
I agree with some of your points but I don't think that deconstructioning the pieces of the project is a panacea. What frequently occurs when that happens is that you get distributed work along with distributed responsibility. Then whenever anything goes wrong or needs to change, there is no one who can make it happen.
You get team A who needs team B to make a new api, but they won't do it till they get a new device because their kpis don't improve for any work they do for team A, so HR needs to be involved the do hiring but they need to talk to accounting to approve the budget and on and on and on.
If you've ever seen Rick and Morty, the episode where aliens have accidentally pulled another character in and the leader is trying to find out why, when every department blames another and he says "oh, so it's nobodies fault" is a perfect example of most large projects
Not a panacea, but if you imagine - every effort is begun with a built in base probability of failure (battle won or lost before it's fought kind of thing) - that a smaller effort reduces likelihood of failure cause you have less unknown variables.
Breaking things up, not necessarily with the teams, but with time. Milestones, separate the projects over time. Also, the shorter deadlines I've found help keep focused. Longer than a couple months - things can languish.
> Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company.
An EDS executive's alleged overpromising, in landing a big contract to build a CRM system for British Sky Broadcasting, ended up costing EDS big bucks: USD $460 million, or more than four times the value of the original contract [0].
"After the decision was handed down, Sky announced that it expected the damage award to be at least £200 million. Had it not been for the misrepresentation claims, the pure-contract damages presumably would have been capped at £30 million. The difference works out to about US$270 million."
> Sales and Engineering - very different competencies. Companies like IBM are NOT technology companies. They are sales-culture oriented, and their product HAPPENS TO BE technology. In fact you could argue, the only way to win big enterprise contracts in the first place, is to be a sales-culture company.
Companies as large as IBM don't have a single unified culture. The sales groups are sales oriented, and the engineering groups are engineering/ tech oriented. Most of the time the two aren't in the same building, and often not even the same city.
> Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things.
> Reasons for failure:
> 1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem. 2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed.
It seems like you're stretching to blame PMs, and I don't think it's deserved.
The sales guy's job isn't just to sell the biggest deal - it's to sell the biggest deal that the company can actually execute and deliver.
And it's no secret that there at least as many incompetent devs as there are smart, amazing devs. There's a reason "fizzbuzz" is a weed out question.
Likewise, there are good and bad PMs.
Without all of the information it's impossible to place blame on a single group of employees.
> The sales guys are at the top. They are generally competent. Proof = they sold a massive deal.
Seems very flawed logic. Anyone can make a sale if you promise everything, charge a low price (that can't sustain your organisation/solution), and have no responsibility for actually being able to deliver within the timeframe they promised.
I fail to see how that shows the sales person is competent.
Still, I can confirm from personal experience this is how the world works for many people.
Been in multiple companies that went bankrupt because the sales people showed this behavior.
Pretend you're a customer. Would you buy from someone who promises everything at a price that cannot sustain his organisation and accepts no responsibility?
If only people knew how often employees of companies like this scrambled to build something in a mad panic because some exec made a promise to a client about software that wasn’t even designed yet.
That seems a little over-analyzed. Sales is seen as a profit center, engineering is seen as a cost center.
This is no different than a good salesman selling some shipping contracts and then the company failing to deliver because some penny pinching nit-wit "saved" some money by skipping oil changes and tire maintenance causing the trucks to break down before the job was done.
I wholly disagree with your criticism of the middle. The original article points to the cause of failure which was dismissal of SMEs prior to deployment. Almost all projects of this size are doomed to complexity overload but that is surmountable, but loss of Product Owners and SMEs is not.
It wasn't sales who decided not to have a SME on the project. They already got paid; why would they worry about personnel? That is a classic middle management decision.
But after selling the deal, their workers have to solve a difficult engineering and organizational management problem simultaneously (the project).
They use contractors (devs) which proves they are not an engineering but sales culture. So, you need to bridge the two worlds. That's the PMs. These are the most incompetent members of the team. The devs very often are very smart.
Draw horizontal lines on the org chart. The sales guys are at the top. They are generally competent. Proof = they sold a massive deal. The devs are at the bottom. They are often competent. They have to be or they wouldn't get hired or find work. You can PROVE someone doesn't know dev work. But, they don't have enough POWER to change things or fix things.
Reasons for failure:
1. The middle. This is the breakdown. Many PMs often have no real skills. ORGANIZING for success, given a complex technical and organizational problem. 2. The projects are too big. Any huge project is from the get-go at an unacceptable level of risk. Decentralization, Deconstruction is powerful. The projects must be broken into smaller pieces to be managed.