4 ms·

Years ago I worked for IBM, and have dealt with them in various contexts since. The thing I've found that best captures the essence of IBM is how they love bri

by jghn 3y ago

Years ago I worked for IBM, and have dealt with them in various contexts since. The thing I've found that best captures the essence of IBM is how they love bringing *everyone* to every meeting, and then insist on full introductions. Every time. I've been on a few different projects where we would routinely chew up 20 minutes of a 30 minute call hearing every last one of them announce their name and role. Thanks folks, I already know who you are. Can we talk about the project now?

hinkley 3y ago
On the clock of course. My last interaction with them, I remember they kept claiming the sky was falling (aka schedule slip) if we didn’t rework the library to do exactly the API they worked out before any line of code was written and with no input from the four other teams that needed to consume it. This culminated in 2 of our leads sitting in a room with a giant table, in a meeting of what had to be ten people at least, for three hours one afternoon while we dictated pseudocode and sequence diagrams for their next three months’ of work (if you can describe a month of work in an hour, it’s really not as complex as people are making it out to be) So we paid six or seven of them to listen while we did half of their job for them, with our two most expensive employees.
pram 3y ago
This made me laugh hard. When I worked at Oracle they’d do this in internal meetings if it was outside your immediate team! A dozen people saying “I am a System Analyst II for Managed Services” like goddamn who fucking cares
- hinkley 3y ago
  I had a boss who was making giving me a lead position into a bigger deal than it needed to be. Like he wanted me and one of my peers to be secret leads before he announced it formally. The entire situation was odd. I told him I didn't care what he called me, what mattered is whether people would listen to me when I asked them to do stuff, like use a better solution to a problem. If you want to be a lead, you have to do a lot of that yourself. But I was young (1st lead position) and his lack of backing that up were making it all more complicated than it needed to be. Made all the weirder by the fact that he was good at selling people on ideas, to a fault (it took me 3 tries to quit that job, he was such a smooth talker)
hinkley 3y ago
Another story for that same project: this was a program where being two weeks behind schedule resulted in theatrics. Think English Parliament in period pieces, but toned down and with more ties. That same other lead and I had figured out that IBM was perpetually 5 weeks behind, and always fishing for problems on other teams they could use to invoke day-for-day schedule slippage. And the reason we knew it was five weeks is this: they would not take patches or hot fixes from us. Because doing so would indicate that we hadn’t fulfilled out contract to deliver on X date. So I’d give them version 1.0.4 (had to be exactly 1.0.4, if the CI/CD pipeline glitched and I gave them 1.0.5 they would demand an explanation, fuckers). And then I’d go off working on catching up with automating functional testing that we were still figuring out, trying to get it to run faster on one particular underpowered destination system, or get feedback from other teams about how some feature in the release was fundamentally broken, and I’d fix those problems and issue 1.0.5-7. I’d tell them they needed the patch and they would say no. Then eight weeks after we gave it to them they’d complain it was broken, they are blocked, and the schedule will slip “day for day” until we fix the bugs - often bugs they should have seen week one if they were actually using the deliverables we gave them. In one case it took me about 14 clock hours to fix their problem, but in all other cases I had already fixed that bug almost exactly six weeks before they found it. I just informed them that 1.0.7 already fixes that, upgrade. They were hoping for a week and every time they got less than a day, and only then if the meeting schedule aligned so the could stall for half a day. That was honestly one of the more satisfying aspects of that job. Ten times they came at us with that schtick, and it worked once. Barely. Near as I can tell they were spending a month at the beginning of each milestone cleaning up tech debt from stapling together the feature set for the previous milestone, and not getting around to our stuff until much later than they wanted the company to know.
- senderista 3y ago
  https://en.wikipedia.org/wiki/Schedule_chicken https://en.wikipedia.org/wiki/Schedule_chicken
  - Aloha 3y ago
    I am amazed there is an wiki article for this.
latchkey 3y ago
This really hits home. It was absurd. 12 people on a zoom call, 1-2, at most, speak beyond the introductions.
- johnvanommen 3y ago
  > This really hits home. It was absurd. 12 people on a zoom call, 1-2, at most, speak beyond the introductions. For a while there, I had a weekly meeting at a former employer that had 63 people on it. The goal of the project was to change the IP address on an Oracle server. Nobody wanted to take responsibility for the change, because if it broke, they might be unemployed. So it just dragged on, week after week after week.
  - glitchcrab 3y ago
    I honestly don't know how you can work in an environment like that, it sounds like my idea of hell.
  - icedchai 3y ago
    I once had a contracting job where nobody wanted to update-and-reboot a server because they were afraid of getting fired. As a contractor who already had another job anyway, I had no such fears. The server had been running for several years with no patches or updates. You'd think someone would've been fired for that? Anyway, the "job" involved more meetings than actual, real work. I'd guess 4 hours of meetings and status updates for every 1 hour of work. I don't know how some places even function.

by jghn 3y ago

hinkley 3y ago

On the clock of course. My last interaction with them, I remember they kept claiming the sky was falling (aka schedule slip) if we didn’t rework the library to do exactly the API they worked out before any line of code was written and with no input from the four other teams that needed to consume it. This culminated in 2 of our leads sitting in a room with a giant table, in a meeting of what had to be ten people at least, for three hours one afternoon while we dictated pseudocode and sequence diagrams for their next three months’ of work (if you can describe a month of work in an hour, it’s really not as complex as people are making it out to be) So we paid six or seven of them to listen while we did half of their job for them, with our two most expensive employees.

pram 3y ago

This made me laugh hard. When I worked at Oracle they’d do this in internal meetings if it was outside your immediate team! A dozen people saying “I am a System Analyst II for Managed Services” like goddamn who fucking cares

hinkley 3y ago
I had a boss who was making giving me a lead position into a bigger deal than it needed to be. Like he wanted me and one of my peers to be secret leads before he announced it formally. The entire situation was odd. I told him I didn't care what he called me, what mattered is whether people would listen to me when I asked them to do stuff, like use a better solution to a problem. If you want to be a lead, you have to do a lot of that yourself. But I was young (1st lead position) and his lack of backing that up were making it all more complicated than it needed to be. Made all the weirder by the fact that he was good at selling people on ideas, to a fault (it took me 3 tries to quit that job, he was such a smooth talker)

hinkley 3y ago

Another story for that same project: this was a program where being two weeks behind schedule resulted in theatrics. Think English Parliament in period pieces, but toned down and with more ties. That same other lead and I had figured out that IBM was perpetually 5 weeks behind, and always fishing for problems on other teams they could use to invoke day-for-day schedule slippage. And the reason we knew it was five weeks is this: they would not take patches or hot fixes from us. Because doing so would indicate that we hadn’t fulfilled out contract to deliver on X date. So I’d give them version 1.0.4 (had to be exactly 1.0.4, if the CI/CD pipeline glitched and I gave them 1.0.5 they would demand an explanation, fuckers). And then I’d go off working on catching up with automating functional testing that we were still figuring out, trying to get it to run faster on one particular underpowered destination system, or get feedback from other teams about how some feature in the release was fundamentally broken, and I’d fix those problems and issue 1.0.5-7. I’d tell them they needed the patch and they would say no. Then eight weeks after we gave it to them they’d complain it was broken, they are blocked, and the schedule will slip “day for day” until we fix the bugs - often bugs they should have seen week one if they were actually using the deliverables we gave them. In one case it took me about 14 clock hours to fix their problem, but in all other cases I had already fixed that bug almost exactly six weeks before they found it. I just informed them that 1.0.7 already fixes that, upgrade. They were hoping for a week and every time they got less than a day, and only then if the meeting schedule aligned so the could stall for half a day. That was honestly one of the more satisfying aspects of that job. Ten times they came at us with that schtick, and it worked once. Barely. Near as I can tell they were spending a month at the beginning of each milestone cleaning up tech debt from stapling together the feature set for the previous milestone, and not getting around to our stuff until much later than they wanted the company to know.

senderista 3y ago
https://en.wikipedia.org/wiki/Schedule_chicken https://en.wikipedia.org/wiki/Schedule_chicken
- Aloha 3y ago
  I am amazed there is an wiki article for this.

latchkey 3y ago

This really hits home. It was absurd. 12 people on a zoom call, 1-2, at most, speak beyond the introductions.

johnvanommen 3y ago
> This really hits home. It was absurd. 12 people on a zoom call, 1-2, at most, speak beyond the introductions. For a while there, I had a weekly meeting at a former employer that had 63 people on it. The goal of the project was to change the IP address on an Oracle server. Nobody wanted to take responsibility for the change, because if it broke, they might be unemployed. So it just dragged on, week after week after week.
- glitchcrab 3y ago
  I honestly don't know how you can work in an environment like that, it sounds like my idea of hell.
- icedchai 3y ago
  I once had a contracting job where nobody wanted to update-and-reboot a server because they were afraid of getting fired. As a contractor who already had another job anyway, I had no such fears. The server had been running for several years with no patches or updates. You'd think someone would've been fired for that? Anyway, the "job" involved more meetings than actual, real work. I'd guess 4 hours of meetings and status updates for every 1 hour of work. I don't know how some places even function.