Slashdot Mirror
Ask Slashdot: Biggest IT Management Mistakes?
snydeq writes: Sure, nobody's perfect. But for those in charge of enterprise technology, the fallout from a strategic gaffe, bad hire, or weak spine can be disastrous, writes Dan Tynan, in an article on the biggest management mistakes in IT. "Some of the most common IT gaffes include becoming trapped in a relationship with a vendor you can't shake loose, hiring or promoting the wrong people, and hiding problems from top management until it's too late to recover." What are some other career- and company-destroyers you've witnessed in your years in IT?
Focusing the department on nothing but fire stomping and not focusing on preventative design/administration.
Implementing SAP
Outsourcing
Outsourcing your SAP implementation
People in India can't possibly know your business, your other employees or your customers as well as qualified, competent, real live boots on the ground in the US of A.
The two biggest mistakes I see is that a dev team which is doing fine gets cut and the people outsourced or offshored. Sales and quality hit the shitter, but management doesn't care one whit about that, since to them, the only people that matter are the S&M guys (sales/marketing), so more gets offshored.
Executives with no IT experience running IT departments.
Intel destroying itself?
Microsoft's history is filled with abuse. Important 3rd comment: Possibly some other person from India...
Windows 10 is possibly the worst spyware ever made.
We hired a company to port our whole email system to Google. They showed up totally ready it seemed until I discovered that one of the director's email history packages was linked directly to a lower level book keeper's email simply because both of their names started with the letter C.
When I found out I hit the roof and called the guy in and had an emergency meeting. What other bungles had happened? They made promises to fix it.
A week later I get an email that it's all fixed and sure enough I went on the same computer and the package was there still and just partially disabled. The company had just done the minimal effort to knock off work early.
I tell you that this type of attitude is PREVALENT today in IT. Apathy.
How to fix? Better AI. Most of the stuff that can be done on computers can be done BY computers now... we only have to standardize and make things more uniform... without going extinct in the process!
Computers never experience apathy, or better yet, apathy can be programmed out... but all computers start there... apathetic.
To what extent will you make them care about humanity? All of you working in IT today have a shot at making this world better. Robots to serve us willingly. Expansion into the universe. We can't do it without them. The calculations to pilot ships out of our solar system require AI... to turn long journeys into safe and short ones.
The dangers of knowledge trigger emotional distress in human beings.
Biggest one I've seen is -- duh.
Practically every mistake in IT is recoverable, except for failing to manage customer expectations.
In particular the two ways in which I can specifically think of that lack of customer expectation management becomes a project killer are lack of solid requirements (e.g., constantly changing requirements), and mismatch between the developer's idea and customer's idea of what the deliverable should look like.
I think that the requirements one is the worse of the two because it is so easy to have this conversation:
cust: Can you just add in this one little change here? ....
dev: Sure thing
cust: While you're at it
Code Complete covers this pretty well with the analogy of building a house. "Moving" a wall is really easy when the house is just a drawing on paper. It is considerably more difficult once the foundation is poured, the walls are up and the roof is on. People building houses know that asking to move a wall in the later stages means lots of money and time on the project. However, because software is an intangible and you can't see it taking shape in the same way as a house it is much more difficult (for someone who is not a software developer) to appreciate that things that seem simple might actually be major architectural tasks for the project.
Always make sure your sales team includes a dedicated engineer. They will help keep them in line, and mitigate situations in which a customer was promised something like running Internet Explorer on AIX.
If you post as Anonymous Coward, don't expect a reply.
Something that I've encountered is a sales contract signed with no provisions for upgrades. The end result is that we sold a product to a government entity... and then were forced to maintain it on old hardware, while the systems around it were changed and upgraded. There was nothing in the contract that forced the customer to upgrade, so they didn't, and we had to hire ever-more-expensive engineers to maintain this legacy system.
The big one I've seen with my current employer is that they've failed to expand their IT staff as the organization as a whole has expanded. The predictable result is that nothing but the most urgent requests gets handled promptly, and minor problems fester indefinitely.
There's no point in questioning authority if you aren't going to listen to the answers.
Is definitely a mistake. Lol
Look at all the boobs in charge, and look at all the places no one is in charge. It's a fucking looney bin.
I recently worked for a startup with a real big asshole brogrammer who never was in the office and always was misunderstanding what was going on. Eventually I caught on to these charades. He was also lying to investors about our startup actually containing AI when it couldn't have been farther from the truth. To cover my own ass I sent a text message to the CEO warning him that we were committing fraud. After that the mark was on my head. Our "brogrammer" calls me into a room and says that I'm toxic. I counter by asking him his working hours and if he understands what fraud is. Over the next few weeks regardless of what happened I was ripped into a room and told how toxic I was.
Of course I was let go shortly after because the dumb CEO who always called me "his brother" was well aware of the sham and apparently didn't care. The crazy sociopath actually thought that I would still be friends with him after being fired. He also thinks it's some point I will come back to work for him, likely whenever that brogrammer finally leaves. I wonder if he knows that I'm planning on telling the FTC and his investors about this "AI" company. It's a bunch of regex matching natural language to appear as if you are speaking to a digital assistant. They're actually telling customers that this is a real AI system.
I would call this a serious mistake because their entire future is essentially in my hands. Since this Psychopathic CEO thinks I'm his friend and going to keep the lid on this, he's just plodding along blowing his money on other endeavors. I'll just let him build a little bit more of a paper trail for me before I strike. That's what you get for listening to the brogrammer.
I've seen them all, but "buying products or services from Oracle" ranks pretty high up. Or more generally, putting faith in a vendor because of a glossy ad in "CIO Magazine" or somebody in management getting kickbacks. Nontechnical managers are incapable of making these decisions, but want to feel like they're in control, so they try anyway.
The biggest mistake any company makes? Treating IT as a cost center. Enjoy your understaffed, underfunded, and unrespected division that makes the entire company work.
and spend seven hours a day shitposting, spamming, and generally being a nuisance here.
I ask because my company doesn't involve the IT manager in any company meetings. None. Zip. Zero. Nada.
They make technology decisions in the meetings, even signing contracts for new hardware and software without any input.
No, I'm not making this up. And yes, I need to get out of there ASAP.
time on slashdot
In about March, we started moving everything to Microsoft, and they audited us in August. About $250k worth of internal time later, they gave us the final bill. We didn't know, for example, you couldn't run Visual Studio Professional on Amazon on nondedicated hardware. Amazon charges $2.185 per hour for that which is $19,140.60 extra per year. We're paying $1,199 per year already for VS for every developer, so we assumed we'd be allowed to use it with no extra charges. We were wrong. I think the total bill after the audit was over $130k plus the extra almost $20k per year on Amazon. We don't even yet use Windows for production(customer facing stuff)!
Not implementing and operating a data backup system properly.
I have been bit by this myself and I thought I was doing a good job at it. (I'm not an IT manager -- I'm a software engineer who often gets shoved the IT manager's job for one reason or another.)
Almost every other failure can be mitigated but not this one.
When a company focuses on taking care of their Employees, then the employees can focus on getting work done, getting the client taken care of.
Part of that is keeping employees skilled. You might think the worst that could happen is that they outgrow your company and move on because they've become highly skilled. That's not true at all. They could be underskilled and stay right where they are ...until the company goes under.
Awk! Pieces of eight. Pieces of eight. Pieces of seven... ERROR: General Protection Fault. [Paroty Error.]
CIO's and technical leaders who refuse to step away from the Technology and let the business drive the investment direction have, in my experience, resulted in a number of high-waste scenarios.
I've been called in to consult on a number of cases where a CIO wants 'X', potentially the next bleeding edge shiny technical doohicky, that they have no idea of their use case, but was suggested by their buddy to look into... who then, when their staff provide empirical evidence that there will be no business benefit, and overall business loss due to TCO and other 'hidden' costs, ignore the position and push ahead with the product anyway.
They re-discover the cost holes later, when licensing costs are 5x that of what they had budgeted for at the start of the financial year. Only to remove it cause its actually got no business benefit.
I understand taking risks to find new products, and the oft true perception that staffers are completely resistant to change, but when faced with quality evaluation showing there is no benefit, refusing to not withdraw an opinion or commitment shows poor leadership and a stubbornness that wont benefit business at all.
So he must be a awesome manager! Or at least that was what the board of directors thought.
9 months later my whole division (+130 employees) went bankrupt and was shut down due to mismanagement and bad decisions.
The whole Japanese IT sector is littered with incompetent managers who all seem to have worked a few years for YahooJapan or Rakuten.
Arriving at the new hospital data center (a room 500 ft from the old data center) before anyone else (including IBM), doors open, snowing a blizzard out at 25 degrees, calling the CIO and asking him if he'd been in the room lately.
Nope.
Asking him if he had the electrical contractor's number Call it. There is not s single power outlet visible. Not one.
Yeah, they closed up the walls and painted, the electrical sub never got called.
Extension cords. Frantic 220 installs. Mangled sheetrock. The AS/400 came up about 5:30pm. I was secretly pleased our NetWare cluster was in failover...
We got done about 10:30pm on a Sunday night. No one every asked if this was an IT blunder or or a contractor blunder, but I never discussed it with the CIO , ever. He paid the overtime. My boss was litersally, genuinely speechless, a first for him. This was the same client who had a Token_Ring network that would beacon furiously on a regular basis. IBM took three months to say they couldn't do anything with the CAUs/LAMs, and they should come out and be replaced with switches. Took me asn entire afternoon to find the loose DB-9 interconnect on an 8230 chassis, the ones that were welded on back then. Bolted it in place, problem solved, we did put in the T-C switches during the move. I credit Laura Chappell, her presentation on Token networks at Networks Expo when she was with Novell, and Lanalyzer, for making me a lot of money. Thanks you, Laura!
Now there was the client who, after much analysis, believed his app vendor and replaced our 16MB Token-Ring network with 100Base-T, since they were adamant that Ethernet would outperform Token. This required recabling, drops from the ceiling, because we had reused the existing Cat 3 PDS in floor trays, but that wouldn't do for 100Base-T. No, it made no difference. The vendor them blamed NetWare and AdvantageDB, and in came the NT 4 server. The IT supervisor was the owner's son, but that's not why I questioned his competence.
I don't know how that came out because they wouldn't use us for that, we were a 'NetWare shop', despite my finishing my MCSE. Fine. I know the new guys presented migrating NetWare to NT at our Novell user group two months later. That's how it was back then. Feh.
deleting the extra space after periods so i can stay relevant, yeah.
...was caving and hiring the the admin by boss, the CEO, wanted me to hire, not the one I wanted to hire. Badddddd mistake, but she did end up letting me fire him after a series of highly visible fuckups.
Wow! That's amazing. The title at that link: Equifax hired a music major as chief security officer and she has just retired.
Equifax Faces Mounting Costs and Investigations From Breach.
The Equifax Breach Was Entirely Preventable
But still, the Intel and Microsoft spyware seems more destructive.
Know what results are needed.
Does a medical database have to track phone calls, public and private databases to ensure every person who had a test got their results?
If a person had contact with a professional over a result? That person never got a result and never saw the professional after a test was done.
That a person actually got their results and did not move to another part of the country?
Bring in an expert who has worked with the exact problem around the world and who can make a database work in your country.
Real skills and the local experts get network and database they want.
Have political and gov move in and demand they be allowed to build the network with gov staff and other contractors who have no skills.
Thats how big gov can fail.
Take a project from the gov that has the skills and give to the politically connected private sector.
The contractors have no skills.
Thats how contractors can fail.
Stop using people with no skills. Stop allowing people to work on complex projects who did not pass their exams and got given a decade of social advancement.
IT can work if the right experts in the private sector, gov, mil or as contractors are found.
Stop advancing very average people with no skills into the IT sector every generation.
Find professionals that can understand complex problems.
Domestic spying is now "Benign Information Gathering"
See subject.
The worst I have seen at multiple places (my employers and their customers) is usually inaction.
Bad choices, inexperience,etc, can be bad, but usually when someone just sits on things or puts them off (due to a plethora of reasons) causes harm in the computing environment but also within the IT team who are ultimately held accountable for the actions not taken.
Time and again, it's the sunk cost fallacy. A system that an organization might have spent a few million dollars to build is just not shaping up into anything they can use, but they keep at it rather than ditching it and seeing what they can do to change things.
What ironic about this is that I think agile actually encourages the sunk cost fallacy because teams will go "oohhh we can 'pivot' a little each sprint." Uh, no. If it's deep-fried dog shit for an architecture, and design you're not going to "pivot" out of this. It gets even worse when you have a management culture that doesn't understand refactoring; most of the agile teams I've been on have had managers who flat out don't care about technical debt and think they can default on it which reinforces the problems with the sunk cost fallacy down the road.
... it was actually just RDP to a remote server.
At the first management/vendor meeting, I got to ask the first question: "How will response time compare to what we have now, with our servers in-house?"
"Oh, it will be much faster!"
It got worse from there.
I asked the owner if he knew that light slowed down in a medium and he said he did.
We already used RDP to the desktop and he KNEW about the latency.
Management ignored the red flags I threw on the play and put everything on the cloud against my recommendation.
We were a law firm and a time came when an elderly couple traveled from far away to sign some wills and the goddam cloud was down.
The family law practitioner blew her fucking top and confronted me and told me to implement Plan B.
I told her, "Ma'am, Plan B is Plan A."
It cost a fortune, but they paid termination fees and put everything back the way I had it before they went nuts.
It little behooves the best of us to comment on the rest of us.
Don't be like Equifax. Don't hire a music major to be your CSO. Hire a cyber security major with 20 years of relevant experience. Someone whose knowledge is evident from years of posts about security you can see on your favorite tech site.
Btw, I'm a cyber security major with 20 years of security experience.
We were on Linux for our file server for a decade and ended up needing to switch to Windows. We were tired of not having a good consultant and Windows consultants were easy to find.
The mistake incidentally was not in switching to Windows per se; it can easily do the added tasks we need of it and Linux could not. The mistake was in thinking the issue was in finding good Linux consultants-- the issue was simply in finding good consultants period.
There ya go, enough content for several years worth. May have to go through the wayback machine to find it but there is a litany of stories that still resonate to this day.
Wheel of Time: Book by Book and Sumview (summary review) Bigdady92 style: http://bigdady92.blogspot.com/
Letting the manager retire and not replacing them for months. Headless is not a good look.
So hot for $Billions of University Market share, they destroyed why Universities shared.
Going into IT management.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Look up the Phoenix Pay System. Currently half a million open pay problems, with no resolution in sight. No testing in advance; no fallback in case of problems; and a management culture of hiding problems.
IT managers should never consider the enduser, i.e., the company's employees, in their decisions. Perhaps its absence on the list indicates that's obvious.
I've seen many hardware projects run into trouble because the selected hardware platform is too small for the software. The temptation is huge to start the hardware project early. However, if you don't know how fast the software is, how do you know if the hardware will be fast enough?
If the software is larger than the initial estimate (it usually is), and the hardware started too soon, then the hardware needs to be redesigned (often with software changes) and this is expensive.
Not firing, correcting, or demoting idiot managers is a big problem. Some managers are excellent kiss-ups, but treat their employees like dirt. Get feedback from their underlings, and if you see problems, do something about it. Sometimes with pressure from above they'll mostly correct bad habits, but if they don't, bootem!
Table-ized A.I.
Could be worse. I worked at a place where there were random cert audits, and the auditor would check your cert ID. If you were not current with your MCSE, you were fired on the spot for "failure to maintain adequate training."
IBIS.
Unix, an obscure operating system developed by bored researchers in an attempt to get a better game playing experience.
Then read everybody's email and when employees secretly back-stab each other, you send their email to the others resulting in massive infighting and instant implosion of the company..
A place I worked bought thousands of ink jet printers.
Mistake #1. Not getting a supplies contract
Mistake #2. They were a name brand printer will known for clogging cartridges and breaking. (I don't want to get sued so no, I'm not naming names.)
Mistake #3. Bought a long term support contract and paid for it in advance.
Result - they rented warehouse space to store the printers until the warranty ran out multiple years later.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
Our CIO decided 10 months ago that putting resources in AWS was not the best way forward. He then commissioned a review and cost analysis of of our AWS resources and a parallel study of what they would cost in Azure. He then decided we would double down on our on data center. Then he chose Azure. Then our data center. Now.... who knows, but we're losing customers and continuing layoffs while he fucks off and seeks out that silver bullet for his resume.
There's a widespread belief in IT that test code and UI are easier than other coding tasks.
It's completely false. Both are harder than other coding tasks. Your senior devs tell you to assign these projects to junior devs because they don't want to do them. They don't want to do them because they're much harder than other coding tasks.
It's win-win for the senior devs: they get easier work, and when the junior devs struggle, it makes the senior devs look even better. "oh, man, they can't even write a test suite. Well, I guess I should get the big bonus this year."
Put your best devs on test and UI. Put your junior devs on the simple stuff: backend work.
1) remove OWA and replace it with Citrix. Stupidly slow.
2) stop providing laptops or desktops to developers, because cost cutting
3) refuse to build better internal applications like time sheet. Cost cutting
4) think home grown solutions are better than established software and force them on staff
5) not understanding client requirements and then expecting on schedule delivery.
...between non-IT people making strategic IT decisions AND coming into budgeting discussions with the "they can do it cheaper in India" comeback to everything. Many times those two converge. I worked in an IT shop during the dot com bubble bursting and the guy that ran the IT division was a salesman. 2.5 years of idiocy that I have enough source material inspiration to write at least 10 seasons of a sitcom. No word of a lie...not a single thing that idiot every did was right. I was the lead dev of that careening ship of fools and eventually got fired because I made one too many comments when I pointed out at an "all hands on deck meeting" that not one of the past 12 sentences that exited his mouth failed to contain a buzzword or some other insipid stupidity as opposed to speaking to the rest of us like competent adults. But that lead me to doing mostly contract work since then and I make most of my money from firms that are re-onshoring their previously offshored application development/maintenance. Whenever I'm approached by someone as to my availability I ask fairly quickly if the application they're asking me to take on is or was ever based offshore. If they concede that it was, I automagically tack on $15-$20/hr additional if for no other reason than to afford the inevitable increase in my aspirin and antacid budgets...and to possibly teach them a lesson.
It's not the biggest problem, but it's one that I've seen a lot and isn't often recognized: Trying to fix organizational problems with IT systems.
What I mean is, if people aren't doing their jobs because management won't enforce the rules, you can't fix that by putting in an automated system that notifies people that they aren't doing their jobs. If people don't know how to do the job because they're dumb and untrained, you can't just give them a sign-in to online training courses and expect them to catch up.
Things like management and training take effort and attention, and until AI gets clever enough to make managers obsolete, an automated system isn't going to do it.
Management by glossy adds.
"Storage team" was moving from Vendor N to Vendor E. Lots of files on Vendor N arrays. Users made heavy use of WIndows/Unix cross links. Storage "wizards" were completely unaware; did almost no due diligence.
Move starts on a holiday weekend before major customer release was due. Wizards unaware that users were changing files. Wizards do their backup from N and restore to E, place E in service. Engineering goes nuts, nothing will build, can't find their files (links broken). Wizards throw up their hands, saying "we didn't break anything".
Of course, what was backed up was old by now. "IT executive" (BTW, didn't even finish his business degree, much less any technical degree) decrees: "PUT IT BACK THE WAY IT WAS". OK, great, now the builds (sort of) work but changes made on Saturday and Sunday were lost, so what is built is not up to date. "Executive" and "wizards" throw up their hands again, saying "this is application specific data, we don't know how to fix it".
Actually, it's just Unix files, so if they had been inclined to help, they could have. However, they were not. Phone call to my boss on Sunday night, explaining only as much as needed to indicate the "wizards" were basically throwing this in the user's lap.
Cue me and two other guys picking through the changes and restoring consistency to the files, based on priority needed to make customer delivery. We wrote a bunch of scripts to figure out the mess laid on us by "storage wizards" (who kept saying "we don't write scripts, we maintain your storage"). These guys were completely incapable of sorting through their own mess.
The mess was a mass of directories and two partial "backups" (each directory) which were inconsistent from what the "wizards" said they did. They couldn't tell the same story twice in a row, and had no timeline of what happened when.
They screwed up routine backups for at least 3 years until someone challenged them to test them, then they stalled for 2 more years fixing the problem. The switch from N to E was supposed to be completed in one year; it took two because E didn't have the link feature that users had exploited in the N product. This was supposed to save the company tens of thousands of dollars. Rather, they ran BOTH the N and E equipment for a whole year while "wizards" had to learn how to make E equipment do what N was doing before.
Executive and "storage wizards" keep their jobs for years following.
"We Have to be in the cloud" (although we have limited reason to scale up/down)
"We Have to run docker/containers" (although we no more than 2 or 3 of any one item, and not a single dev knows how to properly package anything)
"We Have to have DevOps" (no, this doesn't mean hiring yet another team to put in between your devs and ops people -- it means the exact opposite)
"We're agile" (no, this doesn't mean it's OK to ship crappy code)
Stop chasing buzzwords, and just do your job
great in theory - absolute shitfight in practice.
nothing like having to wait on vendors to fix something for a couple of weeks for something you can fix yourself in 15 minutes.
Make sure you actually can restore. Do it regularly. Restore to different hardware. If using tape, restore using different tape drives. Make testing restores a routine thing. When I was a boss, we did daily backups onto tape and same day read the tapes at the offsite recovery site (about 30 miles away).
During my career, I've seen two restore failures where they'd been backing up for years but the backups were no good and they had no idea.
"Almost every wise saying has an opposite one, no less wise, to balance it." - George Santayana
....
Doing business with Oracle.
And Microsoft.
Peter principle
Denken hilft.
I once tried to ride a cheap bicycle without considering the gyroscopic forces of two bike wheels spinning at road speed.
The wheels came off, and I've learned my lesson.
I don't want to say politicians are stupid. Most of them are very hard working and smart. However they are used to giving instructions to some one else to give some one else to implement. This means when the time comes to implement something and the poor guy doing the job discovers the rules are contradictory he can't push back. The contradictory rules are literally the law.
In Canada the federal government negotiates a pay contract with various unions to come up with the rules for how employees are payed. They don't however negotiate a new contract, they negotiate changes to the existing contract. So they add extra rules, and then the government add more rules, and then yet again more rules are added to conform to labour laws for maternity and overtime etc. So after 150 years we ended up with something that was a total mess and humans basically made judgement calls as to which rules seemed the most relevant to an individual employees case. A few years ago the Canadian government decided to have one automated system handle all of their payrole. It was called the Phoenix pay system. They also got rid of the humans making the decisions before Phoenix was ready and rolled out. It has easily been the biggest IT failure in Canadian history and will take years and hundreds of millions to solve.
There are 300,000 Canadian federal employees. If at the end of the day it cost one billion dollars to design a pay system, that would be over $3000 per employee. I think it's safe to say if it costs you $3000 to figure out how to pay each employee your pay system is way way to complicated.
A company that I worked for outsourced the desktop to a company with low support/maintenance fees but high charges for changes or deployment of new software. This was done by a new IT manager without consultation of all departments, seemingly based on "My desktop changes a couple of times a year". Many teams needed regular updates, for example a web testing team upgraded several browsers monthly, developers had to apply security patches to local web servers to match production, etc. At the end of a year an analysis shown that the company was paying three times as much, with the turnaround time for changes and issues going from three days to ten days.
Every time there is a new vice president, the department code changes and everything gets reorganized for no reason other biggest than to show that things are different under the new VP.
So, the IT management mistake is... management?
I think Nokia hiring the Microsoft guy from the US was a serious mistake for the company that was transformed from a lagging market leader into a patent troll.
Buying microshaft products easily the biggest mistakes in all IT departments I have seen.
The fix for all ills was Linux. So why not start with Linux in the first place?
The biggest companies in the world all use Linux.
Whether its in China, NASDAQ, google, Amazon, Netflix, Oracle, AI, etc
'Nuff said
---- The above post was generated by the Turing Institute. Maybe.
Biggest IT Management Mistakes?
By believing that people in IT are engineers, especially ones that work at an engineering company. Their role is to support and to get things working behind the scenes, rather than being the star of the show.
Just because you work with computer equipment and infrastructure doesn't make you a technical genius.
It didn't cause serious company problems but the funnietst management mistake I have seen was...
Manager buys demo copy of some "amazing" speech recognition package with a view to selling to cusomers.
Manager: Set it all up.
Me : I can install it but you will need to set up your voice on it.
Manager: No! You set it up and do that tecchie stuff.
Observation, manager has a strong southern English accent. I have a slight Scottish one.
When he started to use the system expecting me, it made out less than 75% of what he said. I ended up assisting with that successful sale. The manager then spent the time needed talking to the system and it worked for him as I predicted.
Apparently, the customer thought it was quite funny too.
I'll see your Constitution and raise you a Queen.
Seen this several times. A new software and/or hardware solution for some reason. Then just implementing it without asking users.
So much easier if you ask users. They will explain how it will be used, saving a lot of time later as well as moaning. On a more important level.these key users will sell it to the rest as it is "their" project.. thus less moaning.
Don't fight for your country, if your country does not fight for you.
Home grown solutions can often be better than established software, but only if properly planned...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
If your company relies on IT, don't cut your IT staff to save money. No good will come of it.
Just ask Autonation USA, you know the used car company that was going to do for used cars what Blockbuster did for video rental. Their business model revolved around touch screen kiosks that customers could come in and use without being bothered by sales people. The kiosks were always having problems after updates and patching and each store had an IT person. To save money, management started laying off IT people. Eventually, it was just me to cover four states and they wanted me to drive my own vehicle, pay for my own hotel rooms and foo, etc.. and apply for reimbursement. When I asked if I was going to get a promotion and/or raise, I was told no. I quit a week later.
Implementing Scrum or any other short-term based development pipelines where one is not allowed to think more than a few weeks ahead.
Agile(tm)
Nuff said.
We had a VP who we called a sea gull manager as in he'd fly in, shit all over everything and fly out.
One day I get an email from Rackspace saying they were going to shut us off. I forwarded it to the VP and the Controller, then tried to call the VP. When I finally got through he told me he was in meetings and couldn't handle it. So I went and visited the CFO and Controller - I told them that not expediting payment would be a business ending move. The CEO heard it too.
Few weeks later all of I.T. and Development are called into a meeting - telling us the VP of I.T. was being let go. Oops.
Once you offshore, you no longer have control. MOre importantly,the other ppl will figure out that they can compete directly against you in the same way that China's manufacturers compete against the idiots that are dumb enough to go there.
I would put security as number 2. BUT again, few are noticing that all of the companies being cracked by the russians have outsourced esp the production admin portion.
I prefer the "u" in honour as it seems to be missing these days.
I was once involved in second and third level support in a data center in a bank.
Due to a huge conctruction project, there was fears a digger would cut the power.
So they made a test, cutting off the primary power connection, to see if the secondary (and after that the emergency power) would take over.
Well, off the servers went. Turned out the secondary power was never connected, neither was the emergency power.
However they had a second data center ... which took over.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
It would be interesting to see if they could use an alternative.
Lack of metrics, not asking 1st and 2nd level techs for their opinion on a project/upgrade that is rolling out to the masses, and localized spreading of infectious projects.
Without metrics you will never know when the people that work for you are struggling short of asking them directly, chances are they won't voluntarily tell you out of fear for losing their job. When you can identify an issue it is easier to resolve.
1st and 2nd level techs are the ones that see everything wrong with the way the IT department is being run since they have to deal with the fallout from poorly planned projects every single day of their lives. As an example, a manager decided to upgrade a VPN server that required a client update and expected remote users to be able to follow instructions on how to do so by emailing them the instructions and placing the installer on a company server. They not only could not access the client to download it but the majority could not access their email. Compounding the problem were the usual spate of password expirations. All problems the remote support technician knew were going to happen and advised were going to happen as soon as the email blast had gone out. Had the manager asked for feedback regarding the rollout the issue would have been avoided saving an entire day lost to getting the remote staff back online. (I was a 3rd line tech at the time lending my assistance.)
What I refer to "localized spreading of infectious projects" is the habit of managers to walk through a cubicle farm and dump projects off on the first person they see sitting at a desk. There is an assumption made by management that if a person is sitting at their desk and not actively on the phone, face down in a heap of PC, or out dealing with systems then they clearly must not have anything to do. When in fact, the person was waiting for an imminent phone call from a VP needing urgent assistance, or just spent an hour and a half bashing their head into the wall trying to resolve some crazy edge case bug and is taking a few minutes to regain their sanity. Never mind that said person does 2.5 times the workload of everyone else already, dump the project off on them because they are at their desk. Uggh. It's for that reason I spend as much time as possible away from the desk to avoid that crap.
Giving people without proper skills, ability experience or similar too much responsibility. Just about every other huge mistake spawns from this. I've seen one case a junior, practically a kid, with no knack for the technical, barely any skill, capability, etc but with attitude problems and over confidence to boot given sole responsibility for an office with well over a hundred people doing heavy/varied highly computer dependent web focused work and with significant IT needs. The results were catastrophic. Another time for a growing development team in another company someone with barely a year and a half commercial web development work was hired instantly into a senior position yet lacked the knack, skill, experience, etc. Again, catastrophic results. Measuring skill and aptitude in IT is incredibly difficult. People don't quite appreciate this.
It's worth noting this doesn't always fail. When people who are way in over their head realise it they tend to do fairly well. Sometimes, humility can matter more than technical skill. Unfortunately a lack of that is what contributes to people being put in way too deep. Combine incompetence with over-competence though and expect not only failure but drama, fireworks, massive overspends, people quitting on the spot, sometimes even violence, etc.
Other failures can be more subtle. Being inconsiderate is a common one. New people coming in and not realising the difference between things being genuinely bad and simply bad for them because it's not what they did before and that worked for them. Alternatively putting the needs of IT first and not realising or considering what others are doing that IT is meant to be supporting. A company with just an IT department isn't a company. There's no such thing as an IT first company. It's a service it provides to itself to assist in whatever it's real business it. Even "IT companies" are just doing that for other companies.
Another biggest mistake is not focusing on the basics. So many times have I seen people fixing everything with new technical tools when half the time problems originate from existing tools were never used properly and simply things such as keeping tidy, archiving things no longer needed, being organised, etc are completely overlooked.
It's worse than that.
The current project costs to FIX Phoenix are around $1B, that doesn't even include the implementation costs.
The only thing that can be said in its favour is that it at least looks fixable, unlike the old system (which was notoriously unreliable, although still better than the current state of Phoenix)
The most expensive, wasteful, credibility damaging, productivity reducing, and sheer chaos producing IT management mistake in my experience was the decision by a certain freight company to outsource IT. The two-letter outsourcing company, who will remain nameless, in sales presentations (which I attended) painted a rosy picture of a "right shore" solution with capable vendor-trained personnel in several call centers across the world, so that no matter what the local time, the call center would be on local daytime, which would help them draw the best talent for the job, etc etc. They were offering best-in-class for a fraction of the cost of in-house IT.
Upper management, who honestly thought that the entire job of IT was to push a button whenever a light came on, bought it hook line and cancellation penalty. As is often the case, they shook their collective fingers at us and told us "you'd better document your job thoroughly before you leave". Devops, my department, maintained a fairly extensive knowledge base, so it was only a matter of printing out all of our written procedures and handing them over (with two hands, because it was a lot of paper)to management of the outsourcing vendor. And, they lost them. So we printed them out again and handed them over. And they lost the second batch too. I'm convinced that they never intended to keep them. (More on that below.)
Our last day was Friday, which was also the cutover day. I had transferred to a department that was being retained, so got to stick around and see the carnage. It was fascinating in exactly the same way a high speed head-on collision between two passenger trains is fascinating. You're retching, but you can't look away.
This was back when Blackberry was still a thing, and all the execs carried one. BES went down Saturday and remained down for two weeks. This was the sign to upper management that things were perhaps not going as swimmingly as advertised.
The helpdesk was a shambles. You couldn't understand them, they didn't know what to do or whom to contact, and major incidents would just disappear in the system and never get addressed. Employees would come to those of us who survived the layoff and BEG us not to make them call the helpdesk.
The outsourcing vendor shook their fingers at us and said that those damned former employees had not documented their jobs well enough. I had a (third) copy of our procedures, and the names of the managers I'd handed them to both other times, and argued that we had in fact made a good faith effort, just ask these people. Only to find out that those managers no longer worked for the company. Curious.
The vendor said they could recover from our former IT employees' incompetence, but it'd Cost More Money. And that was the other shoe dropping.
Some former IT personnel were rebadged, so occasionally stuff still got done. They worked long hours in very stressful situations. Most of them moved on as soon as the economy started to improve.
Promises of a "right shore" solution were absolute fabrications. The entirety of IT, except for those few overworked rebadged employees, was a single call center in lower central India, manned by people apparently plucked off the street, sitting at card tables with IP phones.
The company tried to improve response by sending a number of people over to India to train the personnel there, but ran into an interesting phenomena -- as soon as employees of the outsource service got training, they WENT ON TO BETTER PAYING JOBS. This training effort served to flush out the people with any experience, causing an influx of new people who couldn't find an "enter" key with a gun to their head.
A major plumb for people who got a little experience was getting off night shift, which was our day shift. So as soon as we'd built a relationship with an admin and taught him to do valuable things, he'd brag about how he's finally getting off night shift, and we'd never hear from him again.
Speaking of which, I don't think th
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
At the very end, you couldn't resist flying your true shill colours. You don't even seem to grasp the basic distinction between B2B and B2C, or it's elementary corollary.
M2M = level playing field
M2B = ???
M = multinational
??? = probably a lot of quiet sobbing in a private stall of the boy's bathroom, if the Molly Maguire–inspired multinational malefactor doesn't barge in there, too.
I'm personally not making much hay out of your sumo satisfaction survey.
The collective human neural network uses a simplifying heuristic of only back-propagating blame when triggered by a large political step change.
* the very first superhero story we teach young children is The Little Engine that Could
* the very first horror story we teach young programmers is the fallacy of rewriting an annoying legacy system from scratch
* the very first right-stuff story we teach young MBAs is Angela Duckworth's grit
* the very first war story we teach young patriots is "remember the Alamo"
If you had a single anthropological gene in your body, you might ask yourself why the Lore of Persistence calls shotgun every time.
It's actually a fairly important and instructive life lesson to play out a losing hand. Because when your subconscious mind observes you stubbornly suffering through a losing hand, it goes "well, damn I better organize things to not go in that direction next time".
If you're fickle enough to change your stripes at the first arithmetic breeze, there's a risk that your subconscious mind never fully internalizes consequence.
But then again, if you strive to be 100% rational all of the time, the subconscious mind becomes just a bunch of baggage in the basement one can never properly boot.
not paying your staff enough to give 2 shits about their job
Get real. The same goes for facilities, accounting, etc.: companies need them, and they couldn't operate without them, but they're still cost centers, by definition. They do not generate revenue but they cost money, ergo they are cost centers. How hard can it be to understand.
The fact that you provide a laptop and 5GB of email storage to the salesman who sells product to customers doesn't mean you're generating revenues. And you know what? It's a good thing. Because managers in cost centers only have to control costs. Managers in profit centers must control costs while turning a profit, it's a lot more frustrating. If you're pissed because they stopped providing free gatorade (to save money), you would go batshit crazy if you also had sales quotas. If your company has bonuses tied to the company overall performance you probably already blow a gasket when the bonus is lower because revenue went down.
Here's a simple summary from our friend Wikipedia:
The main function of a cost centre is the tracing of all expenses linked with a certain function.
See, it doesn't say "a cost centre is a shameful thing that one must try to not be part of even if it means twisting the meaning of words". It's simply an accounting concept.
People are really getting emotional and irrational over this, not sure why.
lucm, indeed.
You are saying he should not report the fraud his employer is committing. Is this some sort of "don't snitch" thing?
First, nothing he described is "fraud", so there's no need for you to hyperventilate. Also he no longers work there, so it's not his employer. And finally, yes, snitching is for little bitches. We're not talking about whistleblowing on a ponzi scheme, this is petty and highly arbitrary.
Grow the fuck up.
It always makes me laugh when someone says or writes "grow the fuck up", because not only does it show a lack of self-awareness, it's also the kind of weak statements hysterical cunts makes when they run out of wild accusations. It has never worked in the history of arguments.
lucm, indeed.
Hiring someone to fix an IT department that's a complete shambles, and firing them a year later because "things are working fine now, we no longer need her"
Biggest mistakes? Letting a CFO set technical direction based on 'intuition' and/or something he/she heard at the club or read online. God save us from tunnel visionaries.
Organization? You must be joking..
I’ve seen many specific examples, but since I forget the details and they all seem to have the same basic cause, let me focus on that: irrational hubris and narcissistic egomania.
Whether it’s believing white papers and betting the farm on them, or following the latest platform/product fads (https://www.youtube.com/watch?v=b2F-DItXtZs), or the belief that you should only hire rockstars, Alphas, divas, etc., the smartest people in the world (a.k.a. techies) sure do some really irrational and illogical things.
Maybe it has to do with only hiring young people, people who haven’t had time to even recognize their own mistakes, let alone accept them and learn from them. I think that smug arrogance is best exemplified by a quote from the Zuckerberg: “I want to stress the importance of being young and technical. Young people are just smarter.”
Also, there’s the Dunning-Kruger effect (https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect). Here’s a pro tip from an old fart that’s been around the block a few times: rarely is the person who claims to be the smartest, the smartest. If your HR practices rely on you only hiring people who talk the talk, you are fucked. Really good people often don’t look like it on the surface. They often don’t sing their own praises. They often aren’t even aware how exceptional they are.
Management decided that copying client backup data to spinning disks was expensive so they just piled the disks in to a storage facility. They also decided that a proper disk tracking system was an unnecessary expense when there were so many cardboard boxes just laying around unused. After all who ever needs a files from a backup from last year? They also neglected to write sunset clauses in to the backup contracts so they get to keep all those degrading disks in storage for ever.
Hiring technically proficient, but socially inept, people into management positions.
Many errors are somehow related to time management and estimation. And especially if we are talking about large companies with a lot of projects and teams, then to consider and track the load of each of developers, the accuracy of estimates provided, possible risks may be really difficult whatever experienced and talented your manager is.
Separately, we could talk about problems specific to a certain type of teams. For example, when managing remote workers, not everyone can organize the correct workflow and interaction of team members. In the best case, the collaboration of modern teams should be organized completely asynchronously and flexibly. That is not always followed in IT companies. This is just one of many examples. Many answers cover other cases. Hiring employees, weak teamwork, low awareness of the current work status, used methodologies, tools and so on.
But anyway, most of the errors are related to the human factor. And most of them can be solved by maximum automation of the workflow, using the right tools, minimizing bureaucracy. Modern technologies make it possible to avoid many mistakes when properly used.