5 ms·

AFAIK, they introduced SAP elsewhere in the company, and it became difficult/too expensive to manage the communication between the old system and the SAP system

by lqet 4y ago

AFAIK, they introduced SAP elsewhere in the company, and it became difficult/too expensive to manage the communication between the old system and the SAP system. I can imagine too well how the conversation between the SAP people and the company went because I also took part in similar conversations with clients in a previous job a long time ago: client asks you if software X can do thing Y. Both you and the person representing the client have only superficial domain expertise on Y. "Oh, you mean enter data into a form? Of course software X can do that, it was designed exactly for that purpose!" The complexity of the task is eventually discovered in production.

ornornor 4y ago
> The complexity of the task is eventually discovered in production. I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome. A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.
- lotsofpulp 4y ago
  On an individual decision making scale, there are no repercussions for the bad outcome. The people who decide on plowing ahead get another bullet point on resume for “accomplishing” something, since the outcome is impossible for an outside entity to verify, but doing “something” is verifiable.
- magicalhippo 4y ago
  > I’m amazed that this is what happens every. Single. Time. The details about the day-to-day operations disappear quickly as you move up the hierarchy. My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down: My boss: "Well, what about when you do orders of type X?" Manager: "Oh we don't do those" My boss: "Really?" My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC Manager: "Oh... so that's what she does" So that information was lost in just one level. This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten. On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.
  - ornornor 4y ago
    At least we’re paid decent amounts of money to crash the bus into the wall…
  - q-big 4y ago
    Isn't this story rather a strong sign that many managers are simply incompetent? I mean: how can you seriously manage things if you don't even know what kind of tasks you actually manage?
    - greedo 4y ago
      At a certain level, managers have to delegate broadly. I think this is best illustrated by the US Army. In an ideal situation, the commander general guidance about his intent. Then his subordinates plan how to accomplish it. I wouldn't expect a Colonel to remember how to fire a mortar properly, and it's the same in IT. My manager expects a well run, secure and efficient datacenter. He expects his SMEs to take care of the details and bring issues to his attention if they exceed the ability of the SMEs to resolve.
      - marcosdumay 4y ago
        If you are delegating broadly, you don't get to mandate the important decisions. Trying to do those two is a clear signal of incompetence.
        greedo 4y ago
        Eisenhower was in charge of D-Day, arguably one of the most complex human endeavors. He made the majority of the decisions surrounding it, of course influenced by outside factors (De Gaulle, Churchill). He chose Normandy, he decided which units would go where, who would lead the campaign on the ground. Incredibly important decisions, yet he left the tactical decisions to those on the ground. Delegating broadly, as a good commander should. General Marshall, Eisenhower's superior also delegated broadly, while making key decisions as to the timing of the invasion, which units would be involved, and making sure all the disparate organizations involved were used to the best effect. Again, delegating broadly, as a good commander should. This goes on and on up to Roosevelt himself, the Commander in Chief at the time. Does he know jack about the tide tables on Omaha beach? The range of a German 105mm howitzer? Of course not. Yet he clearly mandated the important decisions. All three of these leaders were clearly EXTREMELY competent.
- sph 4y ago
  The guy making a deal with SAP and their revolutionary solution is a few steps removed from the poor technician/engineer that is aware of how many corner cases the business runs on. This is why every company with at least 2 levels of hierarchy is doomed to repeat this costly mistake. This is what big corp suppliers like IBM, Oracle or SAP thrive on. CEOs and executives not actually knowing the intricacies of their company, and underestimating the risk of creating a very expensive second system effect.
  - calvinmorrison 4y ago
    I guarantee the CTO has a much more realistic view of these projects and understands how hard it is to deliver these things successfully than the average engineer. There's a metric ton of complexity and their jobs depends much more on their ability to deliver the project at a whole without knowing all the details. The fact is the higher you go the concerns separate. I think the army motto was "go 2 levels up". You're a grunt, you need to know what your platoon and your company are up too and what the goals are so that if you can't follow the plan directly, you can still hit the objective. This is good because no plan army or business, survives reality without changing. In the same way, you can only go so many levels down.

by lqet 4y ago

ornornor 4y ago

> The complexity of the task is eventually discovered in production. I’m amazed that this is what happens every. Single. Time. And yet we plow ahead with this kind of projects like we have no idea it’s the usual outcome. A couple years and millions over budget later, we rediscover this axiom. I really don’t get it. And try to warn about this, you’re labeled as not a team player or whatever and paint crosshairs on your back for the next round of layoffs. It’s just soul sucking.

lotsofpulp 4y ago
On an individual decision making scale, there are no repercussions for the bad outcome. The people who decide on plowing ahead get another bullet point on resume for “accomplishing” something, since the outcome is impossible for an outside entity to verify, but doing “something” is verifiable.
magicalhippo 4y ago
> I’m amazed that this is what happens every. Single. Time. The details about the day-to-day operations disappear quickly as you move up the hierarchy. My boss recently had a meeting with a large customer of us, we deliver a product used heavily by one of their departments. Here's roughly how that went down: My boss: "Well, what about when you do orders of type X?" Manager: "Oh we don't do those" My boss: "Really?" My boss brings up the order list and filters on type X, finds at least one entered each day by user ABC Manager: "Oh... so that's what she does" So that information was lost in just one level. This is why we try our best to get the actual users involved when discussing requirements with a customer. I don't think I've ever experienced a project where at least one of the users haven't brought up some edge case the manager wasn't aware of or had completely forgotten. On the flip side, the projects where the users are left out of it until it goes live never goes well. We'll get it fixed eventually, but there's always pain for far longer than necessary.
- ornornor 4y ago
  At least we’re paid decent amounts of money to crash the bus into the wall…
- q-big 4y ago
  Isn't this story rather a strong sign that many managers are simply incompetent? I mean: how can you seriously manage things if you don't even know what kind of tasks you actually manage?
  - greedo 4y ago
    At a certain level, managers have to delegate broadly. I think this is best illustrated by the US Army. In an ideal situation, the commander general guidance about his intent. Then his subordinates plan how to accomplish it. I wouldn't expect a Colonel to remember how to fire a mortar properly, and it's the same in IT. My manager expects a well run, secure and efficient datacenter. He expects his SMEs to take care of the details and bring issues to his attention if they exceed the ability of the SMEs to resolve.
    - marcosdumay 4y ago
      If you are delegating broadly, you don't get to mandate the important decisions. Trying to do those two is a clear signal of incompetence.
      - greedo 4y ago
        Eisenhower was in charge of D-Day, arguably one of the most complex human endeavors. He made the majority of the decisions surrounding it, of course influenced by outside factors (De Gaulle, Churchill). He chose Normandy, he decided which units would go where, who would lead the campaign on the ground. Incredibly important decisions, yet he left the tactical decisions to those on the ground. Delegating broadly, as a good commander should. General Marshall, Eisenhower's superior also delegated broadly, while making key decisions as to the timing of the invasion, which units would be involved, and making sure all the disparate organizations involved were used to the best effect. Again, delegating broadly, as a good commander should. This goes on and on up to Roosevelt himself, the Commander in Chief at the time. Does he know jack about the tide tables on Omaha beach? The range of a German 105mm howitzer? Of course not. Yet he clearly mandated the important decisions. All three of these leaders were clearly EXTREMELY competent.
sph 4y ago
The guy making a deal with SAP and their revolutionary solution is a few steps removed from the poor technician/engineer that is aware of how many corner cases the business runs on. This is why every company with at least 2 levels of hierarchy is doomed to repeat this costly mistake. This is what big corp suppliers like IBM, Oracle or SAP thrive on. CEOs and executives not actually knowing the intricacies of their company, and underestimating the risk of creating a very expensive second system effect.
- calvinmorrison 4y ago
  I guarantee the CTO has a much more realistic view of these projects and understands how hard it is to deliver these things successfully than the average engineer. There's a metric ton of complexity and their jobs depends much more on their ability to deliver the project at a whole without knowing all the details. The fact is the higher you go the concerns separate. I think the army motto was "go 2 levels up". You're a grunt, you need to know what your platoon and your company are up too and what the goals are so that if you can't follow the plan directly, you can still hit the objective. This is good because no plan army or business, survives reality without changing. In the same way, you can only go so many levels down.