Jeez, I wish my boss would read this article.
Writing an article for El Reg takes between two hours and several weeks of research. Different articles have different origins. I usually have some techie-type problems occurring that could make for an interesting article, but every so often I get a bug about something and dive into a pile of off-topic research. I have been …
Thursday 13th October 2011 13:24 GMT Anonymous Coward
Thursday 13th October 2011 13:25 GMT Paul Smith
If writing for El Reg has taught you anything...
...it should have been that your perception of the number of syllables we commentards are prepared to tolerate is orthogonal to the clarity of the conceptualisation you are attempting to portray. It should also have tought you to use your dictionary as frequently and as carefully as your thesaurus. You might then have known that an ode is supposed to rhyme.
Thursday 13th October 2011 15:00 GMT Anonymous Coward
What goes down, will come back up.
Personally I'd already learned to leave cable monkeying to cable monkeys. The ones I've worked with mightn't've been very smart but they were far better and quicker with cables than I am. On the same note, I had a brand new high density scsi terminator that I immediately bent a pin on. So I went to the nearest ee-nerd and asked him to right it. He was a bit nonplussed at the request but if I'd tried I'd broken the pin, requiring a new terminator.
And yes, el commentards will get you, and for good reason. Wouldn't be proper techies if they weren't proficient in pedantry. Still and all, the "it's about the people, stupid", is an epiphany I've had before, and many have gone before. Such as MIT's* athena project where they found out the hard way that some things are people problems. And people problems cannot be solved through technology. Technology might help, but it works poorly if it is to be the entirety of the solution.
Of course, as someone with no social skills to speak of, I can relate that dealing with people always is a bit of bother so we'd just as soon not do it at all. There are parallels with those autists currently being a big hit with software testing companies. All techies probably are just a little touched, including yours truly. It also means that especially techies need very good bosses, but since there are (too) few of them they'll usually end up elsewhere leaving few options but the scum of the earth to lord it over IT.
Which is to say, get yourself a copy of, say, _The Essential Drucker_** and read all about how the structure of a company ought to work. That'll give you the baseline background to understand what's going wrong and why your company needs a (better) CTO, or at least someone from IT to regularly sit in on their extended sushi lunches^W^W^Wboard meetings. There is hack value in management, though most materials are about being good little alpha dogs and other rat racing techniques. And we all know that even if you win the rat race, you're still a rat. But since we're stuck in it anyway, there are a few things worth knowing about how the game is rigged.
* Of course one of the most disappointing commiters of crimes to email I've worked with was a MIT graduate. Amazing how clueless smart people can be. And so it goes.
** But disregard the bit about lack of formal qualifications meaning automatic fails. The basic idea is sound but the execution isn't, and anyway for relatively new things like computing it just doesn't work very well. MCSE, comptia A+, and for that matter most MBAs, should be clear enough attest to that. And that's before noticing that formal education in general has gone down the crapper over the last few decades.
Thursday 13th October 2011 15:03 GMT Anonymous Coward
"Writing an article for El Reg takes between two hours and several weeks of research." True.
Add 'between two and several kegs of beer' and you are good to go. Perhaps it won't be any easier, but it will soften the blow of (perhaps) interviewing all the PFYs and BOFHs out there.
Around here, the *actual* IT is a third party hired company, but for menial tasks as un-jamming the laser printer, replacing its toner, or even checking if the ethernet cable is on.... that would be me, doing it for free. I guess some places have that sort of inside people, but not dedicated to it. It is all about getting it done ( no pun) specially if is MY job in the print queue. Trying to complain is just like using a dull-edge knife. On your neck. Repeatedly.
Thursday 13th October 2011 16:03 GMT Anomalous Cowturd
Thursday 13th October 2011 18:51 GMT Trevor_Pott
Friday 14th October 2011 06:15 GMT Anomalous Cowturd
Friday 14th October 2011 11:01 GMT Trevor_Pott
Not nearly so interesting as the cataclysm that was my parents' divorce!
My upbringing did however leave me a largely introspective person. If nothing else, I feel I am somewhat rare amongst IT folks because I often take time out to look at myself, my behaviours, how I am communicating with others and trying to find ways to improve. Parents were big believers that any and ever personality issue could be managed and overcome with adequate willpower, patience and education.
I question the real world applicability of that, excepting that said introspection periodically spawns an article such as this one. (Or that Anonymous feature of mine. That eas entirely borne out of a bit of introspection and a desire to understand how various internet nerds tick.) If nothing else, they attract a reasonable # of comments…
Thursday 13th October 2011 16:13 GMT Graham Marsden
Thursday 13th October 2011 16:20 GMT Anonymous Coward
Thursday 13th October 2011 16:21 GMT BinaryFu
And now back the the article's actual subject...
Well written, sir. I have never understood the whole "I'm better than you/more important than you" mindset in a workplace.
Have your boss leave for a month vacation sometime - I'm sure he'll do it, there's still a few months left in the year. Nothing happens. Everything just keeps right on going, you hardly even notice.
Let one person from the IT department be sick for a few days and the world falls apart.
Anyone in IT should consider US vs THEM as a solid mentality. WE fix things. THEY break things. Period.
Thursday 13th October 2011 18:54 GMT Trevor_Pott
WE fix things. THEY break things. Period.
I don't know about you, but if I am being honest, then I break things just as often as any other user. Most especially when I am trying to implement $project for $manager or trying to fix $bad_programming_bug in $ancient_program.
Testbeds are fine and good, but when you put things into production they go boom, almost without fail. Sysadmins are users too.
If you want an "us versus them," I am still trying very hard (every single day) to overcome my burning hatred and inbuilt prejudice against programmers. You see, my job is all about providing my clients (and their users) with CHOICE. Freedom to do things in a new and innovative way. The flexibility to use a different business process and workflow to accomplish a task.
This leads to efficiencies that give that business an edge over competitors. They make money. I get paid.
Programmers however are a completely different breed. They write a program with a very narrow usage case in mind. It is to work this way, on this kind of system, with these inputs and those outputs and never shall anything else ever be considered AMEN.
So 99.99999999% of my job involves trying to invent a widget or a thingamabob that converts “how people actually work” into “how the programmer demands that you work” and then do the same to the outputs. Contacting programmers with feature requests etc is utterly bloody pointless because they have no intention of helping you “kill their children” by approaching the task with a different workflow.
(I ask you: if you and your competition all use the same programs in the exact same way, what is there to differentiate you from them? Why should a potential client choose you over them? What edge do you bring if everyone is doing everything exactly the same way? http://dilbert.com/strips/comic/2008-09-03/)
If I am being honest, there is far more animosity in my life (that I am putting real effort into overcoming) towards developers than there ever will be towards users. Users break things, sure. But in my experience only 5-10% of them are so stubborn that they don’t learn from the experience.
Conversely, only 5-10% of developers I have ever interacted with have been anything excepting “stubborn to the point of aggravating uselessness.”
But I am working to grow beyond that prejudice. Working. Very. Hard.
Thursday 13th October 2011 20:49 GMT Anonymous Coward
Thursday 13th October 2011 22:52 GMT Denarius
Friday 14th October 2011 09:48 GMT Anonymous Coward
I work as the sole IT guy in what might be described as a /very/ hi-tech environment with over 700 people - each of whom is doing bizarre things with gaggles of computers.
My requests for leave have been denied. "We need you here".
We did have 5 IT guys but through retirements and deaths, I am the only one left. Beancounters won't let us hire. This is all great for job security but I'm not so sure about my mental health.
Friday 14th October 2011 09:45 GMT CD001
ye-es ... let's see, in the small (maybe medium-sized) business I work for (100+ people) we have a grand total of 1 in-house web-monkey, which would be me. I'm also the only person proficient to program in C++ or C# and pretty much the only DBA.
So long as marketing let me know in advance of any ad-tracking, mod_rewrite malarky they want setting up beforehand I can normally take a couple of weeks holiday without having to remote in... unless SagePay falls over *sighs*
Sunday 16th October 2011 01:37 GMT Samuel Jackendoff
> Anyone in IT should consider US vs THEM as a solid mentality.
> WE fix things. THEY break things. Period.
You have forgotten that without USERS there is no need for US (the fixers and the builders).
Business + IT = Business++
Business - IT = Business (a store can still use a register and a cash drawer if necessary)
IT - Business = null (or games, but no need for all of us)
Also, remember that USERS usually break things that we design and build poorly. I am currently doing tech support + teaching in a poorly funded elementary school. The tech support problems that I am dealing/fighting with -- along with lack of resources -- more often than not can be traced to poor planning, poor implementation and/or poor programming by folks that assume that they understand the needs of their users without having spoken to a user about how the gizmo (hardware or software) needs to work in order to be of use. Oh yeah, the other big problem that we are fighting is to have enough network & hardware techs paid for (by the suits) to come to handle the problems that I am locked out of.
The USERS are a vital part of the equation. Without them, there are no jobs for techs/propeller heads/programmers/ etc.
Thursday 13th October 2011 20:43 GMT Will Godfrey
Thursday 13th October 2011 20:54 GMT David Haig
Can I defend the developer please? All they do is take the specification from users / PM's / bloke in the pub*, ask the pertinent question 'Is that EXACTLY what you want ? There's no other way you will use this programme?' get the reply 'Yes, that's all we want' and build what's been asked for. Along the way they supply mock ups and test beds for the users to test, and await feedback as to whether they have grasped the essence of what is required.
Finally they hand over the finished product to the project sponsor, who at last gives it to the users that will actually use it only to find that they don't actually work the way that has been described to the developer. Nobody in control asked the right people about what they wanted! Developer now demoralised and bald, due to all the hair pulling.
Sysadmin arrives to try and wedge square programme into round hole - blaming developer, who is now completely bolshy as it is a fixed price contract. No surprises the sparks fly.
Meanwhile, some beancounter with o-level VBA has created a workround in Excel that does what the users want but the internal logic is known only to them and users some form of self modifying macro linked to multiple other worksheets. Works fine till he/she leaves and collapses in heap 2 days later. Now its both the Sysadmin's and Developer's problem.
By the way, I'm on both sides here - and I've done the func spec stuff as well. In the end, never trust anything you are told in a meeting called to thrash out a spec - find the person who is actually going to use the software and take them to the pub ......
* = The bloke in the pub probably has a better grasp of what he wants than the others - once (in a former life) had a designer draw a plan for a stage set on a packet of Gaulois in a pub for us to build and we got it out on time and under budget. He won a prize for it as well!
Friday 14th October 2011 06:17 GMT Trevor_Pott
I have done development myself. Indeed, I am still lead developer on three different projects. The difference between a developer I can work with and one I can't is all in the attitude.
If I approach a developer and say "I have here a Big Bag Of Money, and I need the following features/changes made within X time frame" the developer should say "yes I can do that" or "no I need more time."
What the developer should most emphatically *NOT* say is "why would you need that? Obviously you are doing everything wrong because you don't understand the workflow we are trying to accomplish here!" I understand just fine. Lack of developer clue here is stemming from the inability to grasp that "one size does not fit all."
So as much as I am trying to get over my prejudice towards developers, I keep running up against developer obstinacy at every turn. I am sick of having to code custom middleware because some developer is too damned proud to accept that their design doesn’t meet everyone’s needs.
This is made infinitely worse when dealing with developers who are sitting on top of /the only piece of industry-specific software that does anything close to the job required./ Then they are in the position to really tell everyone to bugger off: there simply isn’t an alternative to their offering on the market.
So you build hacks. And kludges. And stacks and stacks of custom middleware.
AND THEN…the developer realises that you violated their pride by going ahead and creating a tool to do the thing they explicitly refused to do. So they change how their software works, and you have to go back and rewrite some chunk of your middleware. (Especially bad in this day of hosted SaaSy apps and automatic/forced updates keyed to some “call home” online DRM.)
So you end up in some vicious battle of trying to alter your application to deal with some stubborn dev with – quite frankly – the entirely thing should have been settled by an appropriately large bag of money right at the outset.
The worst of the worst slime are the devs who get themselves into a niche, then try to built a “stack” of software on top of it. Some critical application that your entire business – hell your entire industry – couldn’t live without is created, and it’s reasonably good. The catch is, that it won’t import/export data or that feature requests are made into entirely separate products that tie into the core product.
So you end up with some Redmondian super-stack of software costing you *just* the little bit less per year than it would cost you to hire enough devs to completely rewrite the software on your own, zero input into the development cycle, zero hope of ever breaking free of the lockout and zero trust in that the vendor won’t turn around and Oracle the prices on you.
But I am trying not to be bitter. I don’t have time for prejudice. I just have to get the work done, and provide my clients with computer systems that do what they want it do.
No matter how many square pegs need bodged into round holes to do it.
Friday 14th October 2011 09:45 GMT Sam Liddicott
you are wrong
The fact that you don't know that you are wrong emphasises it.
Your leading scenario starts off with a big big IF: If I approach a developer and say "I have here a Big Bag Of Money, and I need the following features/changes made within X time frame"...
It rarely happens, and usually the customer does now know what they want for any project that is funded with a Big Bag Of Money.
They may think they do, but they really really don't. They don't understand that 1:1 and 1:n relationships differ significantly in design and will blithely claim a 1:1 relationship and then later admit to some rare exceptions thinking that the rarity of the exception allows a 1:1 design.
Big Bag Of Money means high risk, means the developer had better find out the different between what the customer really wants and what they say they really want.
My "Why do you want that?" has become "did you know your current software already does what you are trying to get?"
Developer obstinacy often stems from experience and a refusal to be embroiled in an impossible attempt to deliver the wrong thing and then get the blame.
The irony is that you describe your pains as a developer which you wish to avoid, and then rage at other developers ability to avoid this pain.
Obviously your large bag of money isn't enough to get the developer to do what you want without question, but you blame the developer and not your bag of money.
Friday 14th October 2011 10:54 GMT Trevor_Pott
Guys, give me a little credit here, please. I am not talking about getting push back from developers in instances where you approach them with vague requests for features that don’t have a usage case. I am not talking about asking for features that are in the application already. (Step 1: peruse the helpfile/manual. Step 2: Ask on the forums. Step 3: e-mail dev and ask if feature exists.)
Let’s put some concrete examples on the table here.
Example 1) So I have a point-of-sales system that is trying hard to evolve into a “manage all the things” kind of application. CRM, ERP, inventory management, accounting, etc. Our company has been using it for ~20 years, and are one of the largest deployments. We have paid for features in the past, driving functionality changes that were long overdue.
We pay our bills on time, we pay extra when we have a feature request. We have a dedicated on-site body just to deal with this application, he knows the ins and outs, he knows the developers, he knows enough about databases, programming and systems administration to properly convey “what we want to do” into the appropriate dialect fo nerd.
For business reasons, we changed out payment provider. The extant payment provider was costing us a great deal of money, and wouldn’t allow for many advanced features like online payment integration, etc. This was a long process that took the company months and tens of thousands of dollars.
A year later, we approached the developer about the possibility of integrating the point-of-sales system with that payment provider. We had never done payments directly from within the software before, but were hoping to begin such. We offered a Big Bag Of Money, provided a gigantic pile of API links, and even put them in touch with the geeks from the payment provider who were eager and willing to work with the POS devs to get this done.
The POS devs flatly refused. “We integrate with [the payment provider we binned a year ago.] If you want to use a payment provider from inside of our software, use them. We don’t care why you don’t like them, change your business around because we have zero intention of ever providing support for another payment provider.”
I was *floored*. I brought it back to my CEO who then escalated this within the dev’s company. No dice: the response was “adapt to us, we will not add this feature for you.”
Sot he Big Bag Of Money is going into a pot that will hopefully soon allow us to ditch this application, and move our POS/accounting/etc. package to that provided by a better developer. (And no, the developer didn’t come back to us with “give me more money.” Money wasn’t the issue. They just weren’t going to do it, no matter what.)
Example 2) An industry specific application was developed with a very narrow usage case in mind. Essentially: it was coded for the desktop environment of the developer in question, with the idea that end users would always be single entities. The database and its attendant front end were single-user, the netcode so bad that nothing you could ever do would cause the thing to read files over the network faster than ~2Mbit.
Almost immediately, people with more than one body that had to use this program ran into problems. Multiple people needed to be able to access the database from multiple PCs. Businesses larger than “the one man shop” needed to be able to make use of division of labour such that one body could be dedicated to order tracking, one to reordering one to database input, etc.
The developer was offered a Big Bag Of Money. The dev was given concrete, specific requirements, including links to APIs, relevant libraries (and the licensing requirements of each,) they were given specific usage cases and everything that I as a developer myself could ever have asked for to “do the job right.”
The developer’s response – and I kid you not – was “change your business practices.” The developer said that he just wasn’t going to support that kind of environment. If you had more work than one person could handle, simply divide it in two. Each person with a completely isolated, dedicated instance on a dedicated box.
Individual A would be responsible for records on system A, and individual B would be responsible for records on system B. If you wanted to get hold of information contained in A, then you would have to talk to the individual responsible. They would do absolutely everything regarding records in that database.
Absolutely, incomprehensibly, world-endingly INSANE.
That sort of ethos wasn’t acceptable in the 90s, let alone in today’s massively interconnected world! But, it is quite literally the only piece of software that does anything remotely like it, so the developer gets to do whatever they want.
What did I – the dirty network admin – do? I set up a virtual server with a dozen VMs, put an instance inside each of them, then created a middleware website that tracked which VM contained information on which record. I then ensured that anyone in my client’s organization could RDP into those VMs in order to look up/change info. It wasn’t pretty, but he end result was a multi-user usage environment.
The developer was *NOT AMUSED*. Again, this – like most instances – wasn’t a matter of “not offering enough money.” The developers simply won’t budge, no matter what is offered. In this case, there were multiple companies willing to pool money and resources to Make This Happen. Money WOULD BE FOUND if that were the only issue: without this software, the job simply couldn’t be done.
In the end, this group of companies put their money towards hiring a pile of their own developers and have not only written a new application that does everything $stubborn_developer’s app did, but very nearly has met all the feature requests of the group of sponsoring companies.
So stepping back from the hypotheticals and the “well, users and their specifications are never good” and all the developer horror stories, here are a pair of concrete examples of why devs have gotten under my skin for my entire career. I have more. Many more.
I have done development involving scope creep. I have gotten requests for features that already exist. What I don’t get is a developer denying a feature request that has a solid usage case and is legitimately backed by a Big Bag Of Money. Developers who say “alter your business practices to suit our software” are, IMHO, the worst of the worst that IT has to offer.
They are right up there with a network admin who flat out states “it cannot be the network” and doesn’t even check.
There are good devs, I am sure of it. The guys at Plex are a beautiful example of developers with the perfect attitude. But they are, in my personal experience, rare. I recognize that my personal experience does not necessarily reflect the real world – I haven’t experienced all of it, have I? – thus why I am trying to overcome my prejudices rather than caving in to them.
I am sure you all have horror stories of your own that have caused you to become prejudiced in one way or another. Have you never found it hard to look past those frustrations? Am I alone in having to work to overcome the sum of my past bad experiences with $class_of_IT_geek? The often divisive nature of inter-disciplinary rivalries in IT would seem to suggest otherwise…
Friday 14th October 2011 22:45 GMT Anonymous Coward
Silliness I've met? Network-y bloke who insists DHCP is only good for small deployments as you must have static allocation in large networks because "dhcp doesn't scale" or something. Telco ripping out all the copper and needing three techies to put three pairs back in the same cabinet, after convincing them to even honour their contract in the first place. Working 80+ hours a week and having the veep of profanity in languages he doesn't speak tell you you're "not committed"--who himself refused to commit to filling a power vacuum paralyzing IT (in a software company) in a sensible manner. Ran out of the meeting to not miss on the sushi his veep friends had in the conference room over.
People backing out your commits and redoing it slightly differently accompanied by some rant about how stupid you are (disregarding other people on the list who'd argued for the same thing, requiring crystal balls to infer style preferences, that sort of thing). Or, foo, go read tdwtf. "brilliant paula bean" is one of those that've stuck in my memory. I occasionally read it and can laugh about it, too.
Them's bad apples, ID10Ts, you name it. I don't know what their reasons were but the reasons were probably good to them. Free market theory dictates that if it isn't be good for you, you ought ditch them by the wayside. So shrug and move on. Make sure you can. Keep the brass informed and if they can't be kept informed bugger off to where they can. I burned out instead and got myself ditched by the wayside. I suggest you prioritize keeping your sanity.
Friday 14th October 2011 09:48 GMT Anonymous Coward
Time to cool down a bit then
"Why would you do that anyway?" is a fairly natural developer response reflex. I agree that it is exactly the wrong thing to say, though not quite the wrong question to ask. Good developers reflexively look out for generalities. Very good developers look for that beyond just the code. So it helps to ask what the overall goal is. If they ask the right questions the right way they ought to be able to (unless the askee is very dull/obstinate/bitter/etc./all of the previous) ferret out what was really needed. This assumes, of course, that the programmer hasn't gone bitter or just isn't all that good and isn't as a result mostly or only out to secure his job, reach his targets, stick to the clock, not bugger up the codebase too much with "requests", and so on, and so forth.
Doesn't change that here, too, most communication is about how badly the communication goes. In that respect the drive is a bit counter to productive. It would be better to have, say, someone who does easy scripts and chunks to lighten the load of the users, and then periodically round it all up and pour it into a less temporary* solution, see if that works. In the end you'd end up with smoother workflows and less glue. You'd also need much more organic approaches and tighter integration or at least shorter communication lines, and, oh, well-trained communicators.
Now you figure out how to point the signs and align the stars to get there, mistah fixah mon.
* I know that supposedly temporary stuff outlasts supposedly permanent stuff. This is about the fix to that.
Friday 14th October 2011 07:56 GMT OzBob
There is no “one true way” for users. One of my favourite sayings is “the user is always right about what they THINK! they want, not about what they actually need, nor about what is best technical practice”. (As you can guess, I don’t get put in front of the customer much!) The ability to find a design that bridged these positions is what made Steve Jobs a world-class innovator.
Developers are no longer the minor deities worshipped as mystical and paid in gold, they are commodities to be thrashed into producing goods before being discarded and replaced. They now have very little contribution to the analysis of the product and even less control over their destiny (hence why I moved sideways and got into sysadmin work).
There is also a special circle in hell for Network Admins, as “its never the network”. They do have the luxury of being able to hide behind access restrictions and silos of knowledge, which can prevent them being pulled up by other areas over their failures.
Trevor, I can guarantee you there is a member of the hierarchy in your organisation who looked up at some point and thought “someone should do something about this breakdown in communication / working relationship” then went back to their own world. Another favourite catch-phrase of mine, used several times with several PHBs; “Management was an adjective long before it was a noun”.
Friday 14th October 2011 10:55 GMT Trevor_Pott
Nail --> head.
Communication between various tentacles of IT is often terrible. Gods know, I'm no saint; I shoulder my share of blame here too. Indeed; my CEO and I discuss it regularly. It's really interesting to me how we can all get "the wrong impression" of someone very easily.
There are people in this world who think that I exist only to prevent them from doing what they want. It's not true - I'd love to help them, because helping people gives me the warm fuzzies - but I often have to do that very mean thing and ask them to clarify their request.
"It's broken" does not tell me what I need to know to start solving a problem.
“I didn’t do anything!” is yet another common statement that is entirely unhelpful.
By and large however, if you come to me and are willing to talk about your issue – rather than make sweeping demands without being willing to listen to potential niggles in your Grand Plan – I will do my damnedest to help you. Even to the point of working 16-18 hours a day, 7 days a week.
The problem is that when someone comes to me with “I need A, B and C” and I return to them with “this causes issues with X, Y and Z: for me to move ahead we have to have a discussion with the stakeholders for those areas before I can do anything,” it can all go badly. I am sure some of it is presentation – I am working on improving soft skills! – but some of it is the individual involved as well.
I find that business/accounting types are able to sit down with me and discuss the issues surrounding their request. They have a problem, in order to affect a resolution you require these resources and/or these other problems solved first. They seem able to deal with this pretty transparently.
IT nerds however – and for some reason sales/marketing people – don’t seem as universally accepting. For reasons I fail to comprehend, a significant % of those professions take any roadblocks to solving their issues personally.
I have actually been accused of trying to sabotage someone because I refused to install a pirated copy of Photoshop on their computer, insisting instead that we get funding clearance from the beancounters. (I don’t have a software budget of my own; I cannot dip in to any funds of any kind to “make this happen.” Software that expensive absolutely must be cleared by the brass.)
Communication is huge. Huger than huge. It is the number one reason behind project (and business) failure. The hell of it is we all seem to thing that we’re not the problem, that we have nothing more to learn in the “how to communicate” department.
Makes for interesting articles, though!
Friday 14th October 2011 19:34 GMT I ain't Spartacus
Don't think I've ever commentarded on one of your articles before, so just wanted to say thanks, you've written some interesting stuff, that I've enjoyed reading.
I found myself working in a weird finance/buying role for a large retailer. What amazed me was the absolute contempt that the shop staff were held in by head office staff. Admittedly the staff in the stores weren't necessarily always the brightest and the best - what's that saying about what paying peanuts gets you...?
However, THEY got nice people to give them these small green pieces of paper, then put them into bags and took them to the bank. While all WE do was spend the small green pieces of paper they'd worked for on stuff (mainly our salaries)... It may have been true that they wouldn't be able to cope without us, but no-one seemed to grasp that the reverse was also true. Plus we were getting paid more than them, getting offered share options, and getting to sit in comfy chairs with a coffee, while doing our jobs.
Even if that attitude was fair about the store staff, the taint was apparently also carried by the store managers. The single most important roles in the business. The guys who had the most ability to affect how many small green pieces of paper we could plunder from our customers. Such that no-one could be promoted above store manager, as they were clearly also the scum of the earth. So all the good ones left, with predictable results.
We seem to be wired to need people to despise as part of the bonding process of belonging to a group. Perhaps we're all chimps at heart - we just don't express ourselves by picking lice off our friends and flinging poo at our enemies.
...Except, maybe on Friday nights...