Do it my way or leave it
-
Yesterday one of our IT project managers told me the following story:
Our corporate top management had done a strategically super-important and highly profitable deal with the provider of an internet selling platform, allowing us to distribute our products over their service.
For this purpose, we had to provide our new business partner with daily updated product descriptions and pricing data.
The operations manager of the business department in charge with the cooperation approached my colleague and his team and charged them with implementing the data exchange. She already had put together a technical concept.
As an IT person in our company, you have to be thankful if the business people have the slightest idea what they actually want before they request a new project, let alone have a concept.
The problem with this manager's concept, however, was that it went well into the technical details, despite the fact that she had no idea about technical things. She only knew MS Excel, and so the concept involved a bunch of Excel sheets that would have to be exchanged between us and the other company, and regularly merged and maintained on either side - altogether a very cumbersome and error-prone semi-manual process.
My colleague decided that there had to be a better way, and in fact the other company already had a powerful, well-tested web-service API.
The interface to that API was nearly finished when the manager got wind that the implementors hadn't stuck to her concept. She demanded that all that had been built so far be scrapped, and her Excel-based solution implemented instead. My colleague refused, pointing out that, as the IT project manager, the technical implementation was in his responsibility and not in hers.
She went furious and cancelled the whole project, not only throwing out all the effort that had already been made on either side, but also costing both companies several hundred thousands, if not millions, of Euros of potential revenue. Naturally, she blamed it all on my colleague, accusing him of having "sabotaged" the project.
It was his luck that top management had, in the meantime, put their attention on new, even more super-important projects, so the cancelled project was already out-of-sight, out-of-mind to them, and nobody really cared any more about who had screwed up.
-
@ronin said:
She went furious and cancelled the whole project, not only throwing out all the effort that had already been made on either side, but also costing both companies several hundred thousands, if not millions, of Euros of potential revenue. Naturally, she blamed it all on my colleague, accusing him of having "sabotaged" the project.
That reminds me of some former managers here.
-
any time you see excel sheets used for data is a WTF
TRWTF is that upper management didn't care
-
@ratchet freak said:
TRWTF is that upper management didn't care
Unfortunately, it's not uncommon. They can't be bothered with mundane details and a mere trifle of a million dollars. They've got to have the vision, lead by example, stay ahead of the mission and leverage the upcoming synergizing merger. I worked at a place where "upper management" would change their strategy every 6 months and come down with entirely different plans, almost canceling everything. Two years after I left, they're still doing that. The company just survives on customers paying yearly license fees. Amazing.
-
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
-
@Ronald said:
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
So I could just as well tell my mechanic exactly how I want him to fix my car, knowing nothing about cars other than how to drive them, and when he rightly refuses to follow my insane directions I can claim that he's trying to shove his dogma up my pass, interfering with the business of the repair shop?
-
@garrywong said:
@Ronald said:
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
So I could just as well tell my mechanic exactly how I want him to fix my car, knowing nothing about cars other than how to drive them, and when he rightly refuses to follow my insane directions I can claim that he's trying to shove his dogma up my pass, interfering with the business of the repair shop?
All you can come up with is this retarded example? Tell whatever the fuck you want to your mechanic, you are a moron anyways.
-
@Ronald said:
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
People who think like this don't understand the relationship between those who have ideas and those who implement them. It's just bad business to hire people with high falutin' degrees in software development (or whatever) when you're not going to let them do any software development. Those who subscribe to this style of management are usually insecure control freaks who need to justify their own existence within the company because they're so terrified that one day someone will see through the charade and fire them for gross incompetence.
There was supposed to be a quote from Ronald in there but I have no idea what happened to it.
-
@aapis said:
Those who subscribe to this style of management are usually insecure control freaks who need to justify their own existence within the company because they're so terrified that one day someone will see through the charade and fire them for gross incompetence.
Kind of like software developers?
-
Sure, developers aren't excused from being self absorbed pricks just because they can code.
-
@aapis said:
@Ronald said:
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
People who think like this don't understand the relationship between those who have ideas and those who implement them. It's just bad business to hire people with high falutin' degrees in software development (or whatever) when you're not going to let them do any software development. Those who subscribe to this style of management are usually insecure control freaks who need to justify their own existence within the company because they're so terrified that one day someone will see through the charade and fire them for gross incompetence.
There was supposed to be a quote from Ronald in there but I have no idea what happened to it.
It does not matter who has ideas and who is implementing them. What matters is that more money flows in than out (that's how business works). Maybe that is something they should teach to CS graduates so they stop getting their panties in a bunch when the Real World ends up not caring about their fucking REST api.
As for saying that other people are insecure control freaks: it's a bit rich coming from someone who wants to decide who should do what in a company.
-
@aapis said:
Sure, developers aren't excused from being self absorbed pricks just because they allegedly can code.
FTFY.
-
@Ronald said:
What matters is that more money flows in than out (that's how business works).
In the long run a proper solution will save money, rather than cost money. Most of the cost involved in almost any IT project is not in building; it's in maintenance over lifetime. Spending more on building to reduce the maintenance footprint is almost invariably a good thing. (Ofcourse, the usual provisions apply; i.e. don't overshoot your target and go off into architectural la-la land.) The problem is this requires up front investment and the cash flow in the average IT shop is not going to allow for a whole lot of that because most operate with ridiculously small financial buffers. This is a symptom of the rash and brazen cutthroat pricing sales will usually resort to in order to undersell and stifle the competition, rather than preparing a good offer and negotiating a good deal; i.e. , doing their job. In other words; the root of the problem is the usual incompetence on the business side, not the IT side. (However; woe on the poor developer that points out that elephant in the room…)
-
@Ronald said:
It does not matter who has ideas and who is implementing them. What matters is that more money flows in than out (that's how business works).
You cannot possibly be serious.
This kind of thinking is exactly the reason why so many big (government) IT projects fail: they were designed by someone with no understanding if the technology, who then forces her inappropriate solution onto whoever is in charge of implementation, and the resulting product is so costly to maintain that it never breaks even. And then usually more money is spend on outside contractors to "fix" things, which they cannot possibly do because the root cause of all the trouble is the design itself, but which nonetheless does not stop them from charging you through the nose for their services.
If the person with the idea is not intimately familiar with all the technical details, he or she should only tell the developers what the system must do, not how.
-
@Ronald said:
...seeing that the partner really wanted this Excel piece of shit...
You seem to think that the vendor / thirdparty wanted the spreadsheets. In fact, the partner already has a robust web-api. We can be sure that they do NOT want spreadsheets. (Sorry if you were just trolling... if that's the case, then let's talk about what kind of suit the manager was wearing!)
-
@FragFrog said:
@Ronald said:
You cannot possibly be serious.Really, that should go without saying. Well played, Ronald.
-
@ratchet freak said:
TRWTF is that upper management didn't care
I honestly don't think that upper management should get involved in the implementation details. The data needs to be passed between two parties - the format of the data stream could have been thrashed out and agreed between the implementers who could then just report back that it's technically capable and how long it would take.
@Ronald said:
How hard would it have been to implement the Excel solution; even if it needed some manual tweaking
In my IT youth I would have flamed such a comment with a spluttering protest. Perhaps I'm getting older and more jaded, but I agree with Ronald's comment; only because someone had designed the spec and we should run with it.
After it had been in situ for some time (a month, perhaps?) and teething issues had been ironed out, I would have subjected the process to a review that examined the effort involved and questioned if there was a better method of data exchange.
You're not going to get buy-in with a better solution if there's no frame of reference. It also means that the Excel method would become a fall-back system whilst the API was being developed.
-
@Ronald said:
It does not matter who has ideas and who is implementing them. What matters is that more money flows in than out (that's how business works). Maybe that is something they should teach to CS graduates so they stop getting their panties in a bunch when the Real World ends up not caring about their fucking REST api.
As for saying that other people are insecure control freaks: it's a bit rich coming from someone who wants to decide who should do what in a company.
If the service doesn't work because it was built wrong, who will buy it?
What do you think your managers do? I'm not saying they can't have input, my point is that cancelling the whole project because IT didn't implement it exactly their way is a clear sign they're afraid of something. Failing to show leadership means failure, failure means unemployment.
You're trolling, bro. If CS grads were the only people who cared about doing things properly we wouldn't have technology today. I doubt we would have made it out of the industrial age with that attitude. I guess it is kinda funny that you think your job is to build really, really awful products because "business". 7/10. Keep up the good work.
-
@Ragnax said:
@Ronald said:
What matters is that more money flows in than out (that's how business works).
In the long run a proper solution will save money, rather than cost money. Most of the cost involved in almost any IT project is not in building; it's in maintenance over lifetime. Spending more on building to reduce the maintenance footprint is almost invariably a good thing. (Ofcourse, the usual provisions apply; i.e. don't overshoot your target and go off into architectural la-la land.) The problem is this requires up front investment and the cash flow in the average IT shop is not going to allow for a whole lot of that because most operate with ridiculously small financial buffers. This is a symptom of the rash and brazen cutthroat pricing sales will usually resort to in order to undersell and stifle the competition, rather than preparing a good offer and negotiating a good deal; i.e. , doing their job. In other words; the root of the problem is the usual incompetence on the business side, not the IT side. (However; woe on the poor developer that points out that elephant in the room…)
You are not arguing about this situation, you are arguing about principle. Those are two different things, and this is the actual problem.
In a perfect world, if you are told: hey we need to exchange data with a possible partner, how should we do it? Of course you will not suggest a piece of shit. You will suggest an optimal architecture, and if you are worth anything you will already prepare a series of compromises for that ideal solution knowing that someone on either side may impose a shorter deadline than what is required to implement the ideal thing. So at least you will build something decent from start, and even if some bells and whistles are missing you know you can add them later if needed.
However in the real world things don't happen like that. In the real world, you have a business opportunity that is worth *millions* (as stated by the OP) that comes to you tied with a ribbon of shit. So you have this moron working for the business partner coming up with an Excel-based solution. You may suggest to use their own API instead, or whatever other solution you think will be easier to maintain in the long term. But the person handling the deal for the other parties insist that you should use her Excel solution. So you don't jeopardize the deal, what you do is say: sure let's make this thing happen. And you create a fucking VM so you don't have to install Excel on your usual web application server, and you write a lousy SSIS package or Powershell script to load the data to/from the fucking Excel files, and you assign either a FTE or a contractor to watch that piece of shit and support it and nurse it like the golden goose it is. And while it's up and running and the business partner is all happy, you can have meetings with them where you bring up sound principles like "we nailed it, now let's scale it!" or "thanks to Mrs XYZ and her Excel skills we were able to quickly build a POC and establish a successful partnership, now let's have the code monkeys make this thing rock-solid". You pull out a nice Powerpoint with an Integration Roadmap and go from there. IF NEEDED.
The OP was lucky. The partner came up with something that is at least somehow possible to implement. Sometimes you are handed down a solution so ridiculous (usually filled with security risks) that you need to snort two lines of brown-brown to figure out a way to make a solution that *looks* like it does what the business partner suggested and let them save face without putting anything at risk. I've been in that kind of situation often and I can tell you that when you have to figure out how to make a Winfax-driven solution or intercept OLAP queries to force a cube rebuild on a proprietary system you look at situations like the OP's with envy and lust.
So I'm not saying you have to blindly implement stupid things. I'm saying that this is like poker: there is a point where you have to stop raising the bet and you have to play your hand. In this case suggesting to use the API was the right thing, and even working on a prototype was possibly a good idea. But once the business partner got mad and required to drop all such work and implement the Excel architecture, it was a cue that time was not to argue on principle but to eat a shovel of shit and make the Excel solution work. Later when money was rolling in there would have been plenty of time to reassess and work up a business case.
-
@Ronald said:
Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority. It's one thing to follow along with a trainwreck when your purpose is just to cash out and leave the ungodly bugs and maintenance issues to some other poor fuck down the road. It's another thing entirely when you will be one getting blamed for the system being shit, and having to spend unpaid overtime to keep it limping along.
Not to mention the ongoing cost to the business of implementing a poorly designed system. As an employee (rather than a contractor) he's supposed to have some loyalty to the business and speak up when a clueless fuckwad designs something that will wind up biting the company in the ass a few years down the road.
-
-
@Ronald said:
It does not matter who has ideas and who is implementing them. What matters is that more money flows in than out (that's how business works).
I've seen this a couple times and thankfully I wasn't around long enough to see it crash and burn. Usually it's something where the bosses want to do something, ask my advice, I say "No, this is a horrible idea and will cause all kinds of problems 6 months from now." To which the bosses respond with "Well okay, but the client offered us $20,000 to do it so we'll do it anyway and deal with the consequences later." Never mind the fact that there was a fair chance it could cost more than $20k in time to clean up the issues.
-
@Ronald said:
However in the real world things don't happen like that. In the real world, you have a business opportunity that is worth *millions* (as stated by the OP) that comes to you tied with a ribbon of shit. So you have this moron working for the business partner coming up with an Excel-based solution. You may suggest to use their own API instead, or whatever other solution you think will be easier to maintain in the long term.
The moron wasn't at the business partner. Saying OK to something stupid to get the deal often makes sense, but it was the OP's company that was injecting the stupid into the deal so fighting it makes sense.
-
@Snooder said:
That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority.
Read the first post again after you are done getting a blowjob from the paperboy and come back to the thread when you are aware of the context. I won't give you the cliffsnotes because I hate people who get blowjobs from paperboys.
-
@mott555 said:
@Ronald said:
It does not matter who has ideas and who is implementing them. What matters is that more money flows in than out (that's how business works).
I've seen this a couple times and thankfully I wasn't around long enough to see it crash and burn. Usually it's something where the bosses want to do something, ask my advice, I say "No, this is a horrible idea and will cause all kinds of problems 6 months from now." To which the bosses respond with "Well okay, but the client offered us $20,000 to do it so we'll do it anyway and deal with the consequences later." Never mind the fact that there was a fair chance it could cost more than $20k in time to clean up the issues.
I agree. If it's a 20k opportunity. But the OP was talking about millions, and even if it was running on an Hebrew version of Excel using roman numerals the business partner solution would defnitely not have been more expensive than millions.
-
@Ronald said:
@Snooder said:
That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority.
Read the first post again after you are done getting a blowjob from the
paperboy and come back to the thread when you are aware of the context. I
won't give you the cliffsnotes because I hate people who get blowjobs
from paperboys.The Excel-Based Manager is in the same organization as the poster.
The partnering company has a robust api all ready to go... but the poster's manager insists on using spreadsheets.
If you're reading it differently, then that's clearly the source of the confusion. The OP's phrasing of "the business manager in charge of the cooperation..." is ambiguous, and requires the additional context that the partnering company already has a well-tested API to resolve the ambiguity.
-
@ronin said:
My colleague decided that there had to be a better way, and in fact the other company already had a powerful, well-tested web-service API.
The interface to that API was nearly finished when the manager got wind that the implementors hadn't stuck to her concept.Let me tell you what your colleague should have done:
- Before writing any code, get in contact with someone (preferably as senior as possible) from the other company, who is responsible for their web API.
- Explain to them the business manager's solution versus your solution, and get them to agree that your solution is better.
- Get the business manager (BM) to email his/her "solution" to the web API guy at the other company. If the BM won't do it because of reasons, make a fuss about him/her being an impediment to the project until s/he does. It's vital that the BM's "solution" comes directly from him/her and is not transcribed by you - that way the BM can't accuse you of distorting facts later. Also make sure as many senior people as possible in your company are CC'd on this email.
Web API guy at the other company rejects BM's "solution" because it doesn't use the web API. You send your solution to that person, s/he approves it and communicates back to your company (including all the higher-ups previously CC'd) that this is what they want to go with.
At this point, the BM no longer has a leg to stand on. The other company has flat-out rejected her solution and accepted your colleague's. The BM has to go along with the hive mind; if s/he protests, s/he's the problem. There's no-one else to blame - certainly not you, who suggested the solution that seems to work best for both parties, and prevented any friction with the other company.
- Implement your solution.
- ???
- Profit, hopefully.
Unfortunately, in a corporate world, you gotta play the politics. It's distasteful, it's time-wasting, and it's downright infantile, but if you know how to play it right, you can generally come up with a watertight defense against anyone trying to shoot your solution down. The only way to beat the system is to play it better than everyone else.
-
@Ronald said:
@Snooder said:
Once again you demonstrate the reading comprehension of a doorknob.@ronin said:That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority.
Read the first post again after you are done getting a blowjob from the paperboy and come back to the thread when you are aware of the context. I won't give you the cliffsnotes because I hate people who get blowjobs from paperboys.
The operations manager of the business department in
The "operations manager" works for the same company as the OP. The way the OP's post is written could seem a bit ambigous at first, and it might not be clear who works for who. But then he clears it up.@ronin said:
charge with the cooperation approached my colleague . . . She already had put together a technical concept.<font size="4">the other company <font size="3">already had a powerful, well-tested web-service API</font></font><font size="3">.</font>
The OTHER company. Not the OP's company, the OTHER company already had an API. But the operations manger, who is with the OP's company, not with the OTHER compnay, insisted on using Excel sheets, which is stupid no matter what the context, and then cancelled the project when she didn't get her way.This is not a case of developers "getting in the way of business". It's a case of clueless morons who don't know what they are doing and who never should have been in an "operations manager" position in the first place.
-
@Ronald said:
@Snooder said:
That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority.
Read the first post again after you are done getting a blowjob from the paperboy and come back to the thread when you are aware of the context. I won't give you the cliffsnotes because I hate people who get blowjobs from paperboys.
What do you have against paperboys?
-
@El_Heffe said:
@Ronald said:
@Snooder said:
Once again you demonstrate the reading comprehension of a doorknob.@ronin said:That would be an appropriate response if the business manager was a CLIENT. In this scenario she appears to be a fellow co-worker, albeit one with more supervisory authority.
Read the first post again after you are done getting a blowjob from the paperboy and come back to the thread when you are aware of the context. I won't give you the cliffsnotes because I hate people who get blowjobs from paperboys.
The operations manager of the business department in
The "operations manager" works for the same company as the OP. The way the OP's post is written could seem a bit ambigous at first, and it might not be clear who works for who. But then he clears it up.@ronin said:
charge with the cooperation approached my colleague . . . She already had put together a technical concept.<font size="4">the other company <font size="3">already had a powerful, well-tested web-service API</font></font><font size="3">.</font>
The OTHER company. Not the OP's company, the OTHER company already had an API. But the operations manger, who is with the OP's company, not with the OTHER compnay, insisted on using Excel sheets, which is stupid no matter what the context, and then cancelled the project when she didn't get her way.This is not a case of developers "getting in the way of business". It's a case of clueless morons who don't know what they are doing and who never should have been in an "operations manager" position in the first place.
No, it's a case of you "deciding" again that I misread because you jump to conclusions as usual. So here is one more for you:
-
@The_Assimilator said:
@ronin said:
My colleague decided that there had to be a better way, and in fact the other company already had a powerful, well-tested web-service API.
The interface to that API was nearly finished when the manager got wind that the implementors hadn't stuck to her concept.Let me tell you what your colleague should have done:
- Before writing any code, get in contact with someone (preferably as senior as possible) from the other company, who is responsible for their web API.
- Explain to them the business manager's solution versus your solution, and get them to agree that your solution is better.
- Get the business manager (BM) to email his/her "solution" to the web API guy at the other company. If the BM won't do it because of reasons, make a fuss about him/her being an impediment to the project until s/he does. It's vital that the BM's "solution" comes directly from him/her and is not transcribed by you - that way the BM can't accuse you of distorting facts later. Also make sure as many senior people as possible in your company are CC'd on this email.
Web API guy at the other company rejects BM's "solution" because it doesn't use the web API. You send your solution to that person, s/he approves it and communicates back to your company (including all the higher-ups previously CC'd) that this is what they want to go with.
At this point, the BM no longer has a leg to stand on. The other company has flat-out rejected her solution and accepted your colleague's. The BM has to go along with the hive mind; if s/he protests, s/he's the problem. There's no-one else to blame - certainly not you, who suggested the solution that seems to work best for both parties, and prevented any friction with the other company.
- Implement your solution.
- ???
- Profit, hopefully.
Unfortunately, in a corporate world, you gotta play the politics. It's distasteful, it's time-wasting, and it's downright infantile, but if you know how to play it right, you can generally come up with a watertight defense against anyone trying to shoot your solution down. The only way to beat the system is to play it better than everyone else.
The problem in this approach lies in #2. Just think of it from the other company's perspective: you get this dude from IT at ABC Corp calling to bitch about the solution that someone else at ABC Corp is pushing, and he is trying to get you on the record to win his internal fight. Not. Gonna. Happen.
If you play this game, first thing you know you're either on the bench or hitting the pavement for not being a team player.
-
My thoughts, in the order they were generated:
- ronin is the new snoofle!!!
- The manager is an ass for cancelling a multi-million dollar project over the format of the data exchange. Grow up.
- Coming around to agreeing with the other posters: If the manager and the the other company have already agreed that excel is the way to go, then the OP should have done it that way. There is always time later, when the money is flowing, to get it "right".
- The OP should document how much the excel format cost the company, and how much the web-service API would have saved; trot it out in 6 months and demonstrate that if it had been implemented that way, the company would have saved xxx dollars. Explain how the non-technical manager made a technical decision that cost the company xxx dollars. Use that to convince upper management to fire the manager.
Win for everyone then.
- ronin is the new snoofle!!!
-
-
@DrPepper said:
If the manager and the the other company have already agreed that excel is the way to go...
This is not the case. The 'other company' has a web api, and would prefer to use that instead of manual spreadsheet-based processes.
The Assimilator's plan is strategic and diplomatic, and allows you to gather more information as you go. You commit to nothing at first (by reaching out to a technical contact at the partner company), and getting people on your side before the meeting is just basic meeting-strategy.
On another note, where do you normally find your paperboys, Ronald? Perhaps I'm using that term to mean something unrelated.
-
@_leonardo_ said:
@DrPepper said:
If the manager and the the other company have already agreed that excel is the way to go...
This is not the case. The 'other company' has a web api, and would prefer to use that instead of manual spreadsheet-based processes.
Where does this come from? There is no mention by the OP of any position taken by the other company. There is only a mention that they have an API. Are you and ronin working together? Or is this another case of identity theft?
@_leonardo_ said:
The Assimilator's plan is strategic and diplomatic, and allows you to gather more information as you go.
No it's not. It's dangerous and politically suicidal. You cannot go around an account manager and talk directly to someone from the other company. That's like being a drunk driver that gets hit from behind by a non-drunk driver who was not paying attention: even if you are right, you are wrong and you're the one who's gonna foot the bill.
-
@Ronald said:
Where does this come from? There is no mention by the OP of any position taken by the other company. There is only a mention that they have an API. Are you and ronin working together? Or is this another case of identity theft?
It is a fairly save assumption. They have an existing API in place for transferring data, which is (almost certainly) known to work and work well (since it has been in use for at least a little while). Now they are given the choice: "do you want to not do any work and let the other company interface directly with your existing systems for no extra cost, or, do you want to implement some crazy data transfer scheme which will definitely cost a lot to implement, and which will possibly require human interaction and additional support for its entire existence?"
Put it like that, which do you think the other company would prefer? Add to that the fact that they were absolutely fine with OP's company using their API, even though it was not part of their initial agreement.
-
@FragFrog said:
@Ronald said:
Where does this come from? There is no mention by the OP of any position taken by the other company. There is only a mention that they have an API. Are you and ronin working together? Or is this another case of identity theft?
It is a fairly save assumption.Nononono. Ronald is right. We should approach this from a blakeyrat level of willful ignorance. Just because those guys publish something with the purpose of transferring the sort of information involved, only a shoulder alien could possibly suggest that course of action. It is certainly
equallymost likely that they would rather not have an automated process, because you just can't trust that sort of thing. The right course would have been for the OP to sense the genious of the Excel solution and one up the clever manager by including more faxes, emails and wooden tables.
-
@FragFrog said:
@Ronald said:
Where does this come from? There is no mention by the OP of any position taken by the other company. There is only a mention that they have an API. Are you and ronin working together? Or is this another case of identity theft?
It is a fairly save assumption. They have an existing API in place for transferring data, which is (almost certainly) known to work and work well (since it has been in use for at least a little while). Now they are given the choice: "do you want to not do any work and let the other company interface directly with your existing systems for no extra cost, or, do you want to implement some crazy data transfer scheme which will definitely cost a lot to implement, and which will possibly require human interaction and additional support for its entire existence?"
Put it like that, which do you think the other company would prefer? Add to that the fact that they were absolutely fine with OP's company using their API, even though it was not part of their initial agreement.
Again - where does that come from? There is no mention of ANY interaction with the other company in ronin's post. All we know is that ronin's colleague wanted to use the API. You are not even arguing about the story, you are arguing about a version of the story that you made up in your mind. I'm no doctor but I believe this is getting into schizophrenia territory.
The only person in this story whose job is to interact with the other company is the account manager, and that's the person who came up with the Excel solution. So if you want to make relevant assumptions, you can suspect that she had already shared her solution with her counterparty before discussing it with her team. That's how it goes - two business people chewing the rug and one of them is slightly more technical than the other, and before talking to their IT people they come up with a solution. That's suboptimal but this means that by coming back with a different approach her team is putting her in a tough spot - and from that moment that account manager has probably been looking for an exit. That's how it works.
While the account manager should obviously involve IT people before proposing technical solutions (or at least bring a business-friendly pre-sales engineer in meetings) it is quite obvious that there is an issue with communication in that company and I suspect that if she was to offer her side of the story we would learn a lot about problems she had with IT in the past.
That's the part that IT people often don't get. It does not matter if you are technically correct; politics play a big part in the game, and that's that. Annoy people and they will do their best to not involve you in their work - that explains why SaaS solutions are getting so popular, they take stubborn IT people out of the equation.
-
@Ronald said:
@_leonardo_ said:
@DrPepper said:
If the manager and the the other company have already agreed that excel is the way to go...
This is not the case. The 'other company' has a web api, and would prefer to use that instead of manual spreadsheet-based processes.
Where does this come from? There is no mention by the OP of any position taken by the other company. There is only a mention that they have an API. Are you and ronin working together? Or is this another case of identity theft?
On the one hand, we have Occam's Razor, and the phrase "the company has a web API." On the other hand, we have Ronald, who, if not trolling, acts as if he thinks the other company's position is "we have this web api, but if you want to roll your own thing, we're fine with that, even if it's a stupid idea that sucks balls."
-
@Ronald said:
That's the part that IT people often don't get. It does not matter if you are technically correct; politics play a big part in the game, and that's that. Annoy people and they will do their best to not involve you in their work - that explains why SaaS solutions are getting so popular, they take stubborn IT people out of the equation.
I assume most of us get that your position is "don't stand in the way of the money even though you'll be the one blamed when this runs like molasses" but apparently most people here have a little bit of a sense of self-preservation.
-
@Ronald said:
Again - where does that come from? There is no mention of ANY interaction with the other company in ronin's post.
Wait, building an API client does not count as interaction? So the documentation for that magically appeared, or what?
I guess congratulations are in order. You really did manage to get me to reply seriously to your posts! You really are a most marvelously subtle troll! *applauds*
-
@FrostCat said:
@Ronald said:
That's the part that IT people often don't get. It does not matter if you are technically correct; politics play a big part in the game, and that's that. Annoy people and they will do their best to not involve you in their work - that explains why SaaS solutions are getting so popular, they take stubborn IT people out of the equation.
I assume most of us get that your position is "don't stand in the way of the money even though you'll be the one blamed when this runs like molasses" but apparently most people here have a little bit of a sense of self-preservation.
How well did that self-preservation work for the OP's colleague? Moving forward that account manager will go around in meetings talking about yet another situation where IT got in the way of business. Who do you think people will believe? And do you think the business people have an increased confidence in IT? It's the worst possible outcome: no business, more bad blood inside the organization, and everyone pointing fingers at each other.
I'm not saying to go along with any stupid idea that comes up, I'm saying there is a time and a manner to address poor solutions. You have to pick your battles and keep an eye on the bottom line.
-
@Ronald said:
Most of how we help the business is automating stupid, redundant, and otherwise useless people out of a job, helping the business more than said stupid, redundant, and otherwise useless person ever would.Once again stubborn IT people got in the way of business. How hard would it have been to implement the Excel solution; even if it needed some manual tweaking, for a few millions it would have been a no-brainer, even a FTE would have been justified to handle this shit. It was ok to propose a different architecture at first but seeing that the partner really wanted this Excel piece of shit they should have done it that way.
For IT people who want to jerk off writing perfect software in a perfect architecture: open a fucking github account and play with your xml files on evenings and weekends. When you are at work, help the business, don't shove you dogma up the ass of potential business partners.
Yes some people are annoying and it's too bad when it's a client or partner, but that's life. Grow up.
Just saying.
-
@Ragnax said:
@Ronald said:
Yeah man, tell him. But remember: Ronald is a troll pur sang. Being dominated by a micromanaging PHB with no knowledge of software whatsoever, he channels his passive-aggressive energy into making the rest of the world believe that the way he's forced to work in his cubicle is the correct one, a process also known as cognitive dissonance reduction. You should see the spit foaming around his mouth when he types phrases like "When you are at work, help the business, don't shove you dogma up the ass of potential business partners."What matters is that more money flows in than out (that's how business works).
In the long run a proper solution will save money, rather than cost money.Since Ronald doesn't get his kicks from his job, nor from beating his pets when he gets home late from working overtime on yet another day helping the business recover from some disaster that should never have happened, his only reward in life is adversity on forums, by people pointing out that he's wrong. Not that he likes to be called wrong. No, not Ronald. He like to be right. But you see, every one of those reactions has a tiny flaw or incongruity somewhere. And when Ronald spots that, a deep sense of superiority invades him, and he knows that his way is the right way, even if other people see it as slavery.
And when that sense of superiority rises, you should see the smile on his face, just visible from the backlit lcd monitor in front of him. It's beautiful, in the sense that the smile from the clown in Stephen King is beautiful.
So, yeah, by all means, respond! You'll be making a miserable man feel a bit better. It's the only thing he has, so it's a good deed.
In 16 years, social workers will find the body of an middleaged man, looking older that he is, who died alone in his bed, wearing nothing but his google glasses, after complaints about the smell from the neighbors. A sardonic smile of superiority is stuck on his face. Analysis of his data streams will reveal that he's been reading and dictating forum posts for 72 hours without sleep. This is the first time this was diagnosed as the cause of death. In the years to follow, it will be observed more and more, and in a time-honored tradition, the cause of death will be named after the first casualty: Ronalditis.
-
what needed to have happened is that the IT guy should have called a meeting (including the business manager) and presented both ideas
the excel solution should still be presented nicely but interspersed with some terms such as "complicated", "manual process", "possible errors".
while the API solution should have "fully automated", "half the work is already done", "well tested"
-
A big part of this discussion could have been avoided by reading the original post properly.
To clarify:
1. It was NOT the business partner who requested the Excel solution, in fact it was them who asked us why we didn't want to use their existing web service that all of their other partners use. Using Excel sheets would only have introduced a potential source of malfunction, thus deteriorating their service for all their customers. In fact, if we had insisted on the Excel solution, the *partner* would probably have cancelled the cooperation.
2. The middle manager didn't come up with the Excel solution because she thought it was quicker to implement than a webservice interface, but because she doesn't know what a webservice is. Excel is the only IT-related thing she understands.
I think those two points are very clear from the OP, so I conclude that some people misinterpreted them on purpose to have something to troll about.
What was not said in the OP but apparently also needs to be clarified:
3. I don't know whether the manager had talked to the partner about the technical implementation. If she has, they would certainly have frowned upon the idea of using Excel sheets instead of the webservice they created for exactly that purpose. But as far as I know her, that doesn't keep her from pursuing that idea anyway. Maybe she expected our tech guys to convince the partner to use her solution.
A minor misunderstanding that also came up in one post:
4. It would have been understandable if top management just wouldn't have cared about the implementation, but they also didn't bat an eye about the whole cooperation being cancelled.Anyway, even if the story would have gone the way some people here understood it: You don't scrap a potentially multi-million Euro cooperation just because somebody disagrees with you over the implementation.
Managers are not supposed to know about or come up with implementation details; that's the reason why IT departments exist in the first place.
-
-
@TGV said:
@Ragnax said:
@Ronald said:
Yeah man, tell him. But remember: Ronald is a troll pur sang. Being dominated by a micromanaging PHB with no knowledge of software whatsoever, he channels his passive-aggressive energy into making the rest of the world believe that the way he's forced to work in his cubicle is the correct one, a process also known as cognitive dissonance reduction. You should see the spit foaming around his mouth when he types phrases like "When you are at work, help the business, don't shove you dogma up the ass of potential business partners."What matters is that more money flows in than out (that's how business works).
In the long run a proper solution will save money, rather than cost money.Since Ronald doesn't get his kicks from his job, nor from beating his pets when he gets home late from working overtime on yet another day helping the business recover from some disaster that should never have happened, his only reward in life is adversity on forums, by people pointing out that he's wrong. Not that he likes to be called wrong. No, not Ronald. He like to be right. But you see, every one of those reactions has a tiny flaw or incongruity somewhere. And when Ronald spots that, a deep sense of superiority invades him, and he knows that his way is the right way, even if other people see it as slavery.
And when that sense of superiority rises, you should see the smile on his face, just visible from the backlit lcd monitor in front of him. It's beautiful, in the sense that the smile from the clown in Stephen King is beautiful.
So, yeah, by all means, respond! You'll be making a miserable man feel a bit better. It's the only thing he has, so it's a good deed.
In 16 years, social workers will find the body of an middleaged man, looking older that he is, who died alone in his bed, wearing nothing but his google glasses, after complaints about the smell from the neighbors. A sardonic smile of superiority is stuck on his face. Analysis of his data streams will reveal that he's been reading and dictating forum posts for 72 hours without sleep. This is the first time this was diagnosed as the cause of death. In the years to follow, it will be observed more and more, and in a time-honored tradition, the cause of death will be named after the first casualty: Ronalditis.
You have no valid point so you go ad hominem. Yet you call *me* a troll.
Also you have no writing skills, this was not even entertaining to read, I'm pretty sure nobody will make it past the first few words. Good work.
-
@dhromed said:
@Ronald said:
That's going to make for one interesting night.
Notice that none of them is in a wheelchair. That's discrimination.
-
@ronin said:
A big part of this discussion could have been avoided by reading the
original postreplies properly.Coming up with the original story doesn't make you a Prophet. You also should pay attention to what people write, not to what you guess people write. No wonder your organization is having communication issues.
@ronin said:
Anyway, even if the story would have gone the way some people here understood it: You don't scrap a potentially multi-million Euro cooperation just because somebody disagrees with you over the implementation.
This is correct. Which is why there is more to the story than what you reported (or was told). My guess is that facing the lack of cooperation from IT the account manager got cold feet.
