Hacker News new | past | comments | ask | show | jobs | submit login

Most of my experience with IBM has been pretty reliable:

1. They bring the A players to the sales process 2. They bring the B players to manage the account (technically and commercially) 3. They bring the C/D players to do the actual work.

Wondering if I'm an outlier or if this is a standard mode of operation for them? I wonder how this plays in with their OSS strategy? Who works on things like OpenShift?




Pretty much the same experience. Maybe just add:

They bring the A++ lawyers to tell you that not having database corrupted / application crash / buttons click fail wasn't specified in the contract and that in their opinion the software works as agreed.

Seeing the IBM letters still leaves a bad taste in my mouth.


Whenever I meet with any of the big(ish) players to to assess a product I spesifically ask them to send engineers instead of sellers.

If they send sellers after that we usually just ask them to leave and send the engineers. I've seen quite a few pouts but it's impossible to get accurate product information out a seller, they just tell you what you want to hear.

I've never been in contact with IBM before but I'm not surprised about your experience.


What's the difference between a car salesman and a software salesman? The car salesman knows he's lying to you.


Think you'll get a kick out of this scene from Halt and Catch Fire:

https://youtu.be/XOR8mk0tLpc?t=54 [0]

[0] Sales call scene with Joe and Gordon in Halt and Catch Fire: Season 1 Episode 1

[1] https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(TV_series...


Blocked on copyright grants in NL.


What do you do when the engineers turn up and know nothing about the prices, contracts, or anything else like that?


You can usually negotiate that after you've confirmed that the product will actually do what you need it to do.

When I took sales calls, I would usually sit through the intro pitch from the salesperson, and if it seemed in the ballpark, I would cut the call short and ask to be put in touch with product/engineering by email. And if I liked what I saw, I'd go back to the salesperson for pricing, etc.


First I want to know what the product actually does, then I can worry about prices and contracts. They are usually the least part of the problem.

The biggest issue I've had in the past is that I ask for a feature and the salesman say "no problem" and when it's time to implement what I asked for is a custom feature that they can build for €100k.


The observation about getting C players to do the work is part of the actual strategy for succeeding in their market. The idea is that there are C players who are supported by B players who are supported by A players at HQ so that when things aren't going well the problems are escalated in order to either make the account go well or fix it after something has gone wrong. It is a model that actually works - though it can be a rocky path sometimes.

If you hire an independent A player as a consultant instead, they have no big organization with the resources of IBM. I've competed with IBM, and the saying of "you don't get fired for choosing IBM" is still more true for them than for anyone else.

IBM can still bring a level of competency which far exceeds anything Red Hat alone can do. Several well-known and successful companies where I've worked considered their biggest competitor to be IBM - though they didn't say that publicly since they didn't want to further legitimize the competition. They were already losing too many sales to IBM.


I worked for an independent team of A players (that ended up being bought by a D player company), and it was pulling teeth to get deals. We were better, everyone knew we were better that ever spoke to any of us, and them.

But none of that mattered. All that ever mattered was the CIO, and what company he wanted. Then he would write up a rule system where X company had to meet Y requirements that only his preferred company could meet.

We still got more work than we could handle, but people always want A players on the ground, but even at the exact same cost, the upper level management are going to make decisions based on things that have nothing to do with success.


> The idea is that there are C players who are supported by B players who are supported by A players at HQ

I agree it's a strategy, just not a very good one IMHO. I'd prefer to see A players at all levels, just at different levels of their career. Junior level A players can still contribute.


Your assumption is that a company with 300,000 employees would be able to only hire A players. The larger the company, the more it will naturally HAVE to trend towards average. Most successful large companies are successful because they know how to organize their company so that average employees are productive.


I'd be surprised if you could find enough A players to staff the model at the present payscale. Sure, you can argue that a more successful entity can generate more profits, but there's diminishing returns to that effect. Furthermore, there's going to be a lot of egos in the room if all you have are A players, and that's not necessarily sustainable in the long term, either.


A more successful entirely does not generate more profit in consulting body shops. The only thing that generate more profit is more consultants billed for more hours.

Sell quantity, not quality.


You still hear the old adage “nobody ever got fired for choosing IBM” in many large enterprise software sales negotiations, even if the veracity of this statement is increasingly dubious in 2018.


And likely there are many counterexamples proving that people do get fired for choosing IBM but companies and governments typically do not go out of their way to advertise their failures.


"They bring the A players to the sales process 2"

Not in my experience - at my last job we had multiple meetings with them to try and sell us one of their products (CIO was ex IBM and was pushing us to use it) and everyone technical who was involved on our side was profoundly unimpressed.

Was also a bit bizarre that about 6 of them came along to a meeting with 4 of us - we never did find out what most of them did.


> everyone technical who was involved on our side was profoundly unimpressed

That's your "mistake" (from their part). They only know how to sell to top-level oxygen-deprived-brains that are impressed by technical fancy words but couldn't turn their notebooks wifi off and on again to save their lives


>Was also a bit bizarre that about 6 of them came along to a meeting with 4 of us

Ever seen that scene in Halt and Catch Fire where IBM comes to meet with the small company and a hundred IBMers flood into the office? That's the most accurate scene I've ever seen in any movie or TV show ever.


> Was also a bit bizarre that about 6 of them came along to a meeting with 4 of us

Sounds like that's a typical mode of operation, seen that several times, too. So maybe the quality of the sales team is the variable. So if your sales team is C players, do they bring the... E? ... players to project?


It was actually quite an uncomfortable demo as when they finished they genuinely expected us to be impressed - what they had demonstrated would have taken a few moments by someone competent in SQL to duplicate.

I think they might have been used to giving demos to not technical folks rather than people who were actually fairly competent and inclined to scepticism.


I'd been putting Dell/Netapp hyperconvergence appliances into accounts for 9+ months when I wound up at an IBM dog and pony show where they demoed an early version of their own box and acted like it was the first time anyone had ever conceived of such an idea.


Pretty standard for consultants in general. I worked for a contractor where we did proof of concept after proof of concept for Kubernetes deployments and the people working on the proposals were literally the only people at the company that understood Kubernetes. It was a pure bait and switch. We had nobody that could actually implement what we were selling.


Very rarely does sales get dinged if they make a big deal for something that doesn't exist yet, or even something which is completely impossible. They cash their bonus checks and move on to the next mark, tossing a big mess into the laps of the people that have to implement. In a lot of the bigger shops, people move around so often that they aren't anywhere near by the time the shoe finally drops.


Enterprise storage reps make used car salesmen look like angels.


Wow!!! This sums up the culture of IBM as confirmed many replies to the above comment.

> 1. They bring the A players to the sales process, .. C/D players to write code.

I was wondering why IBM failed to make great progress with WATSON project which was started years ahead of others in ML/DL filed.

Now I know the answer, internal IBM projects are developed with same A/B/C people of the hierarchy, where C players are people who write machine Learning/Deep Learning WATSON code.

Since Microsoft lost consumer space by losing windows phone, it's focus is ONLY Enterprise market which is confirmed by LinkedIn purchase.

Slowly but surely Microsoft will eat IBM's "Enterprise lunch" eventually. (sharing part of lunch with AWS & Google Cloud)


I don't think it's fair to characterize the Watson developers as C players. At the time, developing a natural language query interface to a web-scale unstructured database was a pretty cool technical achievement.

The problem was that Watson was a (largely successful) publicity stunt. In that sense, it falls in the category of sales and IMO is a top notch, A-player, demonstration of hype. It wasn't designed from the start to solve real problems, so it was always going to be hamstrung as a real product, regardless of how good the underlying engineering was.

* Edit to add a link to the papers they published -- https://researcher.watson.ibm.com/researcher/view_group_pubs.... -- which I remember skimming at the time and feeling like they were on par with any other typical ML paper. In general, research departments are run with an entirely different culture than engineering.


Watson represents the end game of IBM's retreat from selling solid (literally) products.

When I worked at IBM eons ago, products were very tangible, and often very physical in form, and there was no doubt whatsoever about what they did. Each came with beautiful bound folders for Africa describing functionality and usage. As a Systems Engineer, a part of one's job was being able to drive the configurator and other tools that controlled updates and upgrades and ensured products interoperated correctly.

Watson, it appears, is more the sort of snake oil that one would associate with a flakey, fast moving startup that can promise anything and then somehow make it sort of happen for the early adopters. Its hard to pin down exactly what is IS - which is kind of the point when using it as a sales tool.


Watson is a brand name, that's all. If you want to dig under the covers what most people think of as Watson, i.e. the sentient being kept locked in the basement it is just marketing. The actual "Watson" services are competent implementations of Speech to Text, Text to Speech, Natural Language Processing, Visual Recognition, and open ended classical statistics and neural network based model generation/execution. It's no more snake oil than Google AI or Microsoft AI.


That's how all the big players in this area work. And the C/D players usually are in a foreign country where it's even hard to get hold of them during the day.


This is the whole consulting business in a nutshell unless you are the rare client they don't believe they can risk.


>>They bring the C/D players to do the actual work.

That is probably true for any company ever. Unless of course you are full of cash, overflowing to a point, where you have ginormous amounts of time and money to waste interviewing people, reject them and offer whom ever you want top of the market salaries.

Any company can probably do this at their prime. Other people have to hire on average competence if they want to scale. And that works fine most of the time.


Turn it upside down you get Hewlett-Packard :-)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: