Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
Businesses Cloud IT Technology

Ask Slashdot: What Are Some 'Best Practices' IT Should Avoid At All Costs? (cio.com) 348

snydeq writes: From telling everyone they're your customer to establishing a cloud strategy, Bob Lewis outlines 12 "industry best practices" that are sure to sink your company's chances of IT success: "What makes IT organizations fail? Often, it's the adoption of what's described as 'industry best practices' by people who ought to know better but don't, probably because they've never had to do the job. From establishing internal customers to instituting charge-backs to insisting on ROI, a lot of this advice looks plausible when viewed from 50,000 feet or more. Scratch the surface, however, and you begin to find these surefire recipes for IT success are often formulas for failure." What "best practices" would you add?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: What Are Some 'Best Practices' IT Should Avoid At All Costs?

Comments Filter:
  • by Anonymous Coward on Tuesday June 13, 2017 @06:27PM (#54613217)

    ISO 9000
    ITIL
    TQM
    CMM

    You need to have to crawl before you can walk Management frameworks are for Olympic Class organizations.
    Suggestion - Build your own policies, procedures, and get those in place so you know what the pain points are before you try to implement someone else's idea of what's ideal in IT.
    Fred in IT

    • I heard people raving about ITIL so I tried to find out what it is. I still don't know because even thinking about it makes me fall alkdshjg;;dfpgsdgjgshgjpsdhfj gf skoppppppppppkgp

      • by haruchai ( 17472 ) on Tuesday June 13, 2017 @07:06PM (#54613433)

        I heard people raving about ITIL so I tried to find out what it is. I still don't know because even thinking about it makes me fall alkdshjg;;dfpgsdgjgshgjpsdhfj gf skoppppppppppkgp

        I went through the ITIL Foundations course quite a number of years ago. Could not fucking stay awake.
        The instructor was engaging, knowledgeable, they supplied us was a much coffee as we could stand, I kept going outside (in February) to keep myself awake and I still snored through the entire course.
        Managed to retain enough, long enough to pass the exam but I couldn't tell you the difference between a process & a function (by the ITIL definition) with a gun to my head.

      • It has its uses, especially if you use tools aligned to ITIL. If you try it without the tools, it is a bunch of guidelines and jargon. Not much sense that way.

        I was on a team building those tools, so we had to have the courses first, and they didn't stick well. Going through the requirements, they eventually made sense.

      • by AK Marc ( 707885 ) on Tuesday June 13, 2017 @08:58PM (#54614067)
        ITIL is a framework for continuous improvement. No more, no less. It's a tool designed to help you help yourself get better at what you do, whatever that is. A builder could implement ITIL, as could most industries.
    • by lucm ( 889690 ) on Tuesday June 13, 2017 @07:12PM (#54613469)

      ISO 9000
      ITIL

      I disagree. In both cases, the problem is not the framework (or standard), it's the blind trust in it and the misconception that it's going to make you deliver higher quality.

      They won't. But done right, both ITIL and ISO 9000 give you one thing: predictable, repeatable output. Maybe your desktop guys are not very good at reinstalling Windows, and maybe your X-Ray QA is not good at spotting bad weld jobs on titanium alloy. But if you're an ISO 9000 or ITIL shop, the procedure will always be the same so you can know in advance that 24% of desktops will need re-imaging and that 61% of QA will give false positive, so you can adjust your planning accordingly. The actual quality is not better or worse, but it's consistent.

      The alternative is to get sometimes good output, sometimes bad, depending on who gets the tasks, the time of day, was it before or after the first coffee break, etc. Maybe in such chaos you can find high quality once in a while, but it makes it very difficult to establish any kind of pipeline or planning.

      • by rgmoore ( 133276 )

        I disagree. In both cases, the problem is not the framework (or standard), it's the blind trust in it and the misconception that it's going to make you deliver higher quality.

        The big problem with adopting quality frameworks* is that people adopt them to check a checkbox without understanding how they are supposed to work. Lousy but reproducible work is the result of doing the bare minimum to get certification. Unfortunately, that bare minimum is still a lot of effort because you have to document all your

        • by lucm ( 889690 )

          Lousy but reproducible work is the result of doing the bare minimum to get certification.

          True. And a good symptom of that is when the service delivery team becomes a "ticket machine"; it becomes like the customer service counter at a retailer where they will basically accept a dead squirrel as an alleged broken toaster if it comes with a valid receipt.

          I didn't say it was easy, or that the majority of organizations get it right. But done right, it's gold.

      • "the problem is not the framework (or standard), it's the blind trust in it and the misconception that it's going to make you deliver higher quality."

        This. Almost always, frameworks like ISO 9000 or ITIL are the bright idea of someone in management. The people who actually ought to live this stuff have it imposed on them. In fact, the processes turn into stacks of paper sitting in a closet, ignored except when re-certification time rolls around.

        It's important to have processes that work for you and your org

      • done right, both ITIL and ISO 9000 give you one thing: predictable, repeatable output. Maybe your desktop guys are not very good at reinstalling Windows, and maybe your X-Ray QA is not good at spotting bad weld jobs on titanium alloy. But if you're an ISO 9000 or ITIL shop, the procedure will always be the same so you can know in advance that 24% of desktops will need re-imaging and that 61% of QA will give false positive, so you can adjust your planning accordingly. The actual quality is not better or worse, but it's consistent.

        By that definition of "quality", a McDonalds meal is of higher quality than a french chef's 4 course menu. The burger flipper has QA measures in place to make a burger taste like the same cardboard from Alaska to Zaire while the chef never can reproduce a meal exactly to the point if he has to take into account natural variations in availability and taste of fresh and/or local produced ingredients.

        Or wine... what gives the 2002 Chateau de quelque chose it's special quality is that it can not be reproduced e

      • The Commandant of the Coast Guard once told (a congressional committee?) that one COULD make a concrete life preserver according to ISO 9000 standards, so long as the paperwork was properly done.

        You're correct: adherence to the standard will give predictable output in the product, the documents that accompany it, and record keeping of the process used. It doesn't mean the product will be right for the needs or even objectively good but you'll be able to determine those from the documents. Some hands-on mi

  • None of those were best practices...

    Best practices are like, "never auto-commit schema changes, always dry run them first".

  • Buy not build. (Score:5, Insightful)

    by jellomizer ( 103300 ) on Tuesday June 13, 2017 @06:33PM (#54613267)

    I am not talking about common tools such as email servers, word processing, spreadsheet...
    But software core to the operation of your business. Companies will sell you massive enterprise solutions, filled with best practices and buzzword features.
    However the effort in implementing this is usually much more complex and costly than a small team of full time developers to make simple solutions to solve the problems unique to the business.

    These companies selling these solutions hire a team of full time employees just to support the company. Then they charge you for the software and their time plus the profit margin. So you end up paying more for features you don't use and extras that are hacked in and barely work.

    Your organization offers solutions, products or services that are unique. Why would you expect software and best processes to be the same.

    • Second-System Effect. What you're really buying is a programming framework in the end.

      • by Jeremi ( 14640 )

        Second-System Effect. What you're really buying is a programming framework in the end.

        Are you sure you didn't mean the Inner-Platform Effect [wikipedia.org]? (Although if you're really lucky you could end up with both simultaneously :) )

        • I did mean that, but forgot the name. But I'm pretty sure that it's the first stepping stone on the way to Inner-Platform Effect anyway. Very likely you have both.

    • Most companies I've been with are mortified at building. "C's" would rather spend 10x $$ and hire consultants to install a core business app from OTS (off the shelf) then build in the competitive advantage of their unique culture. I've actually been told "we don't want to be held hostage by programmers".
      • by AK Marc ( 707885 )
        And once the 10x more expensive OTS app is customized for them, they are hostage to their consulting company that set up their system.

        They are hostage to their developers when they hire 20 to build the thing in half the time, then lay off 90% when done, rather than hiring a team of 5, taking 4 times longer, and having a small core of good people, kept around forever, working on updates, upgrades, and continuous improvement on what they built.

        Faster, cheaper always win over quality.
    • by lucm ( 889690 )

      Your organization offers solutions, products or services that are unique. Why would you expect software and best processes to be the same.

      Spot on. Being the best at implementing whatever is in Gartner's magic quadrant is not a difference maker.

      Implementing this kind of enterprise product is often a minefield, especially since those products assume that:
      1) your business process are in line with the industry
      and
      2) you actually have well-defined business processes that apply to the whole organization

      which is almost never the case. Even inside a large, somewhat stable organization, rolling out a big ERP a la SAP is a nightmare because Branch X has

    • by MrLint ( 519792 )

      I only want to add the caveat that you have to have someone with some kinda clue how to evaulate the solutions your programmers are making.

      I've had a 'software developer' melt down because :
      1) The mere thought that the system java is updated because he need a very specific version, even tho he doesnt write aganist the system JRE
      2) The queries are to complex for jdbc/odbc and can only be done via the full Oracle client
      3) incapable of understanding that NTFS is the default file system for Windows XP, but is t

    • because if you hire an internal team you're paying them in your internal currency while you shuffle money about for tax dodging. That tends to be a lot of (largely imaginary) dollars. So you're spending $20 mil a year on paper and the outsources comes in with a $5 mil quote. Only problem is you're really spending about $1 mil of real dollars and suddenly you're out $4 mil and getting crappy service.
      • by AK Marc ( 707885 ) on Tuesday June 13, 2017 @09:24PM (#54614171)
        Goes with #4. Internal Chargebacks. If you do internal chargebacks, make sure they are lower than what it'd take a consultant to do the same job. I've seen the chargeback rate so high, it was easier for the developers drive to the store and pick up a Dell Server (or whatever), and install that instead of buying the IT Server Service. Then you have piles of "rogue servers" running around and a valid business reason to undermine your own IT department.

        When you spend $1M on IT and IT collects $5M on chargeback, making the "Service" profitable, at the expense of logic and reason, and leading to outsourcing.

        If chargebacks reflect the cost of providing the service, and are lower than can be obtained elsewhere, then it will only be a good thing. It demonstrates the value, and prevents budget squeezing.
        • by djinn6 ( 1868030 )

          I've seen the chargeback rate so high, it was easier for the developers drive to the store and pick up a Dell Server (or whatever), and install that instead of buying the IT Server Service.

          What if the chargeback rate is the real IT cost? Then picking up a off-the-shelf server would actually be the right choice for the company since it's so much cheaper.

          • by AK Marc ( 707885 )

            What if the chargeback rate is the real IT cost?

            Then fire your IT director/manager/CIO and hire someone competent. Done right, contractors are always more expensive.

            How can it cost more for the IT department to buy a Dell than someone with a credit card and no business account? How long does it take a programmer to build a server to a good standard? Will it be properly patched and supported after? If your IT department is actually more expensive than paying a programmer to buy and build his own server, then you are doing something wrong.

            Though, I'v

          • Lots of different types of servers needing individual TLC is stupidly expensive in the long run...

  • by bobbied ( 2522392 ) on Tuesday June 13, 2017 @06:34PM (#54613273)

    ALWAYS avoid adopting technology that you don't understand just because somebody on your staff or a salesman with some glossy sales flyer says it will be great! If your manager shows up with the idea, convinced that it's going to be the solution to all his problems and won't take your advice on the matter, update your resume....The devil is ALWAYS in the details...

    There is no silver bullet... Trust me, I've looked for years... However, that doesn't mean you cannot shoot yourself in the foot with a plain old lead round.

  • ITIL (Score:5, Informative)

    by prisoner-of-enigma ( 535770 ) on Tuesday June 13, 2017 @06:34PM (#54613275) Homepage

    From bitter personal experience, trying to implement the entire ITIL manual down to the tiniest detail instead of treating it as a guideline for what might be applicable.

    Case in point: my former employer had a dated-but-usable change management and helpdesk system they'd used for years. It was due for replacement. They brought in a non-IT project manager to design it. Mrs. Non-IT Project Manager proceeded to treat the ITIL guidelines as some sort of roadmap, demanding the most granular, process-laden, cumbersome, needlessly-complex system I've ever seen. It was universally reviled. Nobody understood it. Nobody was properly trained on it. Tasks that used to take hours now took days. People started working around it, not using it, in order to get even basic stuff done. The system required a complete overhaul -- this time using actual input from the people who would be using it and/or served by it -- and eventually became usable at a cost and schedule far beyond the original mandate.

    Meanwhile Mrs. Non-IT Project Manager was given a raise and promoted to somewhere where she couldn't do that kind of damage again.

    • by lgw ( 121541 )

      Sounds sadly common. Project managers shouldn't own the requirements in the first place, just delivery against agreed requirements.

    • ITIL is usually fully implemented by management companies that attempt ICT.
      ITIL is *NOT* for ICT companies that attempt management.

  • At the risk of being snarky wasting time on /.

    And blindly following banal best practices that may or may not apply in any given circumstance. In other words, learn from others, but always use you best judgement.

    • by lucm ( 889690 )

      I agree. I'd pick "right practices" over "best practices" any time. Unfortunately, the bigger the organization, the more difficult it is to get decision makers to embrace common sense over whatever 2 minutes of googling tells them.

  • This is one of those situations where the 'best practices' both look bad and are hard to get rid of because they(often) are the locally optimal approach in a situation that is unlikely to go well.

    If you follow those "best practices"; you are basically doing what you can to act like a contract or outsourced IT service provider despite being an internal unit. If that's the best relationship the department can have with the rest of the company, yeah, odds are that it isn't going to go all that well. Best ca
  • Password Changes (Score:5, Insightful)

    by darkain ( 749283 ) on Tuesday June 13, 2017 @06:45PM (#54613325) Homepage

    Forced password changes every X days. This just leads to people picking really shitty passwords. At one company I worked at for a while, they mitigated this by simply doing "simple word" + month + year. TOTALLY hard to figure out!

    • Re:Password Changes (Score:5, Informative)

      by sdinfoserv ( 1793266 ) on Tuesday June 13, 2017 @07:12PM (#54613461) Homepage
      It may be crappy - but forced password changes are required for many organizational level certifications. Example: PCI, wanna take credit cards, forced password changes required. Just like HIPAA, CJIS, SOX... and a bunch others...
      • And that's the problem! How can these certifications be taken seriously if they require policies that will either lead to even worse passwords or (if you try to enforce better passwords AND regular changes) to Post-It notes under everyone's keyboard!

        • And the answer is that HIPAA, SOX, and CJIS are all legal standards. IOW, they were drawn up by politicians, not by anyone with any understanding of IT.

    • by Thad Boyd ( 880932 ) on Tuesday June 13, 2017 @07:18PM (#54613497) Homepage

      The mandatory online security training we did the first day at GoDaddy actually recommended satisfying the mixed-case/symbols requirements by using an initial capital letter and an ending exclamation point.

      Course, Go Daddy is also the company where they fired one of the five guys on my team, didn't replace him, and then the next week started having daily meetings to discuss how our productivity had gone down 20%. Math was not management's strong suit.

    • Forced password changes every X days. This just leads to people picking really shitty passwords. At one company I worked at for a while, they mitigated this by simply doing "simple word" + month + year. TOTALLY hard to figure out!

      If you want to know what will happen if you don't force users to change passwords, just look on Facebook for their pets/kids name. I'm certain you won't find 80% of your passwords there or anything...

      (Oh, and don't forget to keep that a secret. We wouldn't want hackers to TOTALLY figure that out!)

      • Re:Password Changes (Score:5, Informative)

        by _Sharp'r_ ( 649297 ) <sharper@@@booksunderreview...com> on Tuesday June 13, 2017 @07:32PM (#54613565) Homepage Journal

        Enforce a single-sign-on long and complex password.

        That you rarely (years) require to be changed.

        Forcing a password change every 60 days doesn't accomplish anything but either create easily guessable variations, reducing the password space, or create lists of passwords, generally in something insecure for most people.

        • At my company, passwords are assigned by IT. They match up to your user name - all eight characters... +4 letters up, -4 letters down, +8 letters up, etc etc with a number thrown in somewhere.

          Don't think that user selected forced password change policies are the worst. I can literally log in as anybody in the company.
        • Enforce a single-sign-on long and complex password.

          That you rarely (years) require to be changed.

          Also, require 2FA with a convenient hardware token. Something like a Yubikey Nano.

          The problem with passwords alone, even long and complex ones, is that it's too easy for an attacker to acquire the password via phishing or social engineering. Adding the hardware token eliminates remote phishing attacks, and makes social engineering dramatically harder. It's odd, but people are much more reluctant to share a physical object than a password, even when they believe the the requester is legitimate. And even if

    • by Anonymous Coward on Tuesday June 13, 2017 @08:00PM (#54613719)

      As of NIST 800-63-3 forced password changes based solely on time interval is no longer a 'Best Practice'. Now the Best Practice is to expire passwords only when there is suspicion of account or system compromise.

      Sadly it will take some time before the many organizations who copied the old best practice into their own documentation can step up to current best practice.

      • Also, the old best practice was copied into a number of laws, including HIPAA and SOX, and it will likely be even more time before any of those are changed.

      • As of NIST 800-63-3 forced password changes based solely on time interval is no longer a 'Best Practice'. Now the Best Practice is to expire passwords only when there is suspicion of account or system compromise.

        Sadly it will take some time before the many organizations who copied the old best practice into their own documentation can step up to current best practice.

        I'm assuming you're referring to this stupidity found in DRAFT NIST SP 800-63-3B:

        "Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) and SHOULD only require a change if the subscriber requests a change or there is evidence of compromise of the authenticator."

        I've read through the DRAFT publications, deal with 27001/CSC/NIST standards on a daily basis, and this is the one of the dumbest recommendations I've ever read when it comes to password policy and system security.

        Unless you enforce it, users WILL NOT choose complex passwords. If you need further evidence of this, take a look at those Top 10 Worst Passwords lists that have been published over the last 20 years. They fucking n

    • People are always, always, the weakest link.

      If you let people choose passwords, they'll choose very bad ones. If you force them to change them regularly, they'll choose bad passwords with easily predictable permutations. If you force them to use generated good passwords, they'll write them on sticky notes and put them in email.

      I used to work with a guy who specialized in information security. He would run cracking programs against our systems and report any bad passwords to the appropriate manager. One of m

      • People are always, always, the weakest link.

        Are you suggesting we should change he users every 60 days? I'll vote for that!

    • You're missing the point.

      There have been hundreds of database breaches [haveibeenpwned.com] in the past few years. Every password in those databases should be considered compromised. However, it's most likely that an attacker will use the dumped passwords as a dictionary, or at most try a few simple variations for a known user. It's far less likely that they will be able to guess the "simple" password if it's different and random for every organization.

      Password reuse is a threat, and it's becoming more prevalent every day. The

  • by Hognoxious ( 631665 ) on Tuesday June 13, 2017 @06:55PM (#54613379) Homepage Journal

    If there's a best practice to avoid then avoiding it becomes a best practice, and then you should avoid avoiding it. Or something.

    • If there's a best practice to avoid then avoiding it becomes a best practice, and then you should avoid avoiding it.

      This. A thousand times this!

  • by Spy Handler ( 822350 ) on Tuesday June 13, 2017 @07:01PM (#54613411) Homepage Journal

    therefore, buy IBM

  • 1. Anything with rapid in it's name. Rushing stuff means it breaks. It may not break today, but it will break under heavy load when you're trying to do payroll.

    2. Do It All At Once. Trying to change multiple things at the same time inevitably means you didn't understand the implications of the massive retraining, the fact that the sales force can't complete transactions fully, and the fact that the world ain't perfect like the software and hardware think it is.

    3. Not having either rollbacks or testing, or c

  • I had a ton of experience building web apps as a contractor. I'd see lots of projects that were structured as strict OO projects, even though they were simple web apps. The level of complexity and time and expense it takes to build a complete OO application actually ran one of the companies I worked for completely out of business. They ran out of money before they finished the application. Ignoring some of the "best practices" whitepaper garbage would've gotten their application finished in half the tim
    • by Tablizer ( 95088 )

      It seems "web architectures" are just becoming unnecessarily complex, perhaps because architectural purists are over-doing pet concepts (not just OO), or because we are all waiting for a new web UI/standard to be invented so that "web apps" are not so damned Rube-Goldberg-ified.

      "We have to do it that way because the web has no state and is not a real GUI." We'll, let's find a way to give it real state & real GUI then, instead of fake it with blindfolded twirling back-flips, turning CRUD into Braille roc

  • by gweihir ( 88907 ) on Tuesday June 13, 2017 @07:06PM (#54613435)

    Or have very bad standards in the first place. That way, you are going to enjoy all "Web Application Worst Practices" that people can think of. I am currently assisting a customer wading thorough such a mess.

    Also nice: Fire people that created and understand the application after they have finished, but before anything is documented.

    And to top it off: Declare the proof-of-concept to be the final application. It is much cheaper!

  • by Anonymous Coward

    I disagree with Bob's #6, that it is a mistake to charter IT "projects."
    He says:

    >

    The problem is that IT does not have control over something like "increase sales effectiveness." It's nice to push that as a goal and justification for a project, but all IT can be held to is "implement Salesforce.com." That is our expertise and what we can deliver. Of course you can partner with other departments, but you shouldn't commit to nebulous goals that depend on them having their shit together and excelling.

  • by keith_nt4 ( 612247 ) on Tuesday June 13, 2017 @07:22PM (#54613513) Homepage Journal
    Seems to be my employer's philosophy, anyway.
  • they're colleagues. Coworkers. Not Customers. As soon as you make them customers you put everyone of your front line guys in an antagonistic position. That's because customers are where you make money. And they know it. You might appreciate them. Even like a lot of 'em. But there's always going to be tension there. And once you start offshoring (which if you're a medium+ sized company your bean counters will make you do) then all bets are off. They'll fight you tooth and nail.
  • by Snotnose ( 212196 ) on Tuesday June 13, 2017 @08:35PM (#54613963)
    Who have 20+ years experience in favor of outsourced "engineers" for 1/3 the salary and 1/10 the experience.

    / not bitter
  • by Anonymous Coward

    Companies usually define IT as a cost center because money goes into the pit and no money comes out. They prefer putting $100 into something and getting $200 out of it. Give the sales staff a huge expense account and huge sales commissions and the money just pours in. Give the IT staff entry-level pay and continuously cut their budget because all you ever see is money going down the drain quarter-after-quarter. At some point they determine they really don't need IT and they save even more money. #Fail

  • Oracle, SAP, IBM and other expensive licensing deals.

  • Boss: "Let's deploy this application to the cloud!"
    Sysadmin: "Does it make sense to put it in the cloud?"
    Boss: >Holds up a CIO magazine with a picture of a cloud on it< "Because it'll be in the CLOUD"
    Sysadmin: "What's this application going to do? What type of data is it going to be handling?
    Boss: "But it'll be in the cloud, it'll be <looks quickly in magazine> a fully virtualized extensible angular flask framework!"
    Sysadmin: "You're just reading buzzwords!"
    Boss: "Let's senergize our git repos w
  • The last large company I was in (a major bank) was indeed doing, I think, all of the recommended 12 practices - oh, hang on, you mean those are things we should not do? Damn!

    Those daily SCRUM meetings, including half a dozen people on speakerphone from what sounded like a busy market square in downtown Mumbai somewhere (complete with cow noises) - yup, they went really well.

  • by Opportunist ( 166417 ) on Wednesday June 14, 2017 @02:43AM (#54615245)

    No joke. It's a surefire way to grind your IT department to a halt and the rest of the company along with it.

    Number one on that list should be "Make people remember ridiculously long passwords, force them to change them every other day and make sure that they have to invent new passwords every time, with no semblance to any of the past 1000". Not only will you ensure that your help desk is drowning in "I forgot my password" calls, especially after days like Thanksgiving when there's a 4 day weekend, it will keep people busy coming up with new passwords.

    Number two is of course "and don't write it down". So you can make sure that people not only get creative in how they note down those 12+ character word salad you dished out to them, you can also make sure that they don't dare to talk to you anymore lest you learn where they wrote it down.

    I think you can easily take it from here. Make sure you don't forget to keep the storage team busy with ridiculous "Best Practice" backup requirements that are impossible to fulfill and you should be the best CISO ever. Well, at least on paper. And we all know you only make big leaps in your payment when you switch jobs, something you'll do often if you heed the IT Security Best Practice recommendations.

    Because you'll leave sunken companies behind you.

    • by ledow ( 319597 )

      Er... actually... almost all the recent security advice is NOT to do that with passwords. People are catching up and even domestic security agencies are recommending to stop that nonsense to government agencies, etc.

      Don't write it down - that's subjective. Granddad at home, where someone burgling him will get hold of his Facebook password that's used to look at grandkid photos? Yeah, not an issue. Office workers sharing logins in an open book? Not a good idea.

      In fact, I recommend that every workplace w

  • Anything more than the absolute minimum involvement by HR in hiring.
  • My last IT employer had a vast set of milestones they wanted to hit by 2012. Goals! ha

    One of them was to make the company be just like Zynga. Mind, Zynga was already in failure mode long before this visionary goal was born, and the work we did had absolutely nothing to do with anything Zynga did. .Very different products and markets.

    Apparently the people who did the goals only looked at revenue or some sort of number where Zynga looked great on paper. But some of us knew the truth and openly laughed

No spitting on the Bus! Thank you, The Mgt.

Working...