"Organizational issues" -- sore spots of IT?

Question

Is it common for "organizational issues" (such as politics, organizational inertia, and selective hearing -- think Dilbert) to cause more IT problems than computers and servers do?

Likewise, is it common for one's employers to not really know what said person's job entails, or even care, until such time as they have a computer glitch, and want everything dropped to have it fixed now?

What can be done to ameliorate such situations? (How about in a setting one step removed from business concerns -- not needing to increase profits or make clients happy -- such as in a governmental organization?) How do you take satisfaction in a job well-done when no one knows or really cares what you are doing? Indeed, how do you stay focused if it doesn't seem to matter if you do anything or not?

Assume that I'm exaggerating a little bit, and don't have a pressing desire to quit.

Edit: now a community-wiki question.

**Edit:**Thanks for all of the great answers. I wanted to add a few comments.

It is my opinion that a good manager should know what those he/she manages do, and those above him/her should have some idea. The head of IT here really doesn't know. If I go to a mechanic, I may have no idea what he/she does, but I will listen strongly to his assessment, and would get a second opinion before ignoring the advice, and the people running the mechanic shop really ought to know what they hired him for!

As for dropping everything to fix a computer glitch, upper management has been known to have one of the system administrators leave problems (such as users being unable to log in or use a computer that works reliably) to move contacts from one phone to a newer one, or to make their calendar synchronization.

The most frustrating thing is that nobody seems to have the power to change things. The people with the greatest ability to effect change have the least interest in doing so as they don't even understand what is broken.

It is hard only being noticed when things go wrong. A person needs a little bit of understanding or catharsis.

It is difficult to align oneself to the business objectives, as our stated mission seems to be contrary (and, indeed, as times in opposition) to what the people with clout in the organization are pursuing.

As for being the change I want to see in the world, that is definitely a factor of why I am still working for this organization.

Congratulations on the Joel Test for system administrators. That was an excellent idea.

Answer 1

It is common for "organizational issues" (such as politics, organizational inertia, and selective hearing -- think Dilbert) to cause more IT problems than computers and servers do?

YES. Any organization with more than one person will have "organizational issues", and almost always those will cause more headaches than the technical issues. This is a fact of life because although we are nerdy people, we are people. Further, the problem is just as prevalent in high-tech companies as in "normal" companies. IBM and Microsoft are just as bureaucratic and silo'ed as GM and Bank of America.

Likewise, is it common for one's employers to not really know what said person's job entails, or even care, until such time as they have a computer glitch, and want everything dropped to have it fixed now?

Sure. Do you know about or care about the jobs of a telephone service tech, the auto mechanic, the accountant, the plumber, the cashier, or the bank teller? No. But when you need something, you need it now, and you don't care about their issues. Again, this is not about computers specifically, it is about people generally.

What can be done to ameliorate such situations?

Be understanding of the other people in the organization, and ignore when they do not reciprocate. Recognize that they are just trying to get through the day, and recognize that almost certainly whatever problem brought them to you interferes with that goal. Don't expect them to understand your world and tailor themselves to it.

In the end, the only thing you can change is yourself. Think Gandhi.

How do you take satisfaction in a job well-done when no one knows or really cares what you are doing? Indeed, how do you stay focused if it doesn't seem to matter if you do anything or not?

If you need recognition and approval, you are in the wrong line of work.

Effective people in our business (system administration and support) are not noticed by their organizations, because the systems work and problems are handled calmly, quietly, and quickly.

Answer 2

Get out of departmental IT! Joel's blogged about why his time at viacom sucked for this reason.

Sad fact is that if you give good advice to a business as an employee it's questioned & untrusted. If a consultant walks in & gives the same advice for $10,000 its cherished.

Not all organisations treat their staff this way. Go work for a vendor & you might notice a difference. You can't change toxic culture like that, but you can choose where to work.

EDIT: It's obvious we need a Joel test for sysadmins! Help us create one!

Answer 3

Listen, my nephew bought a linksys access point and got my home network running in 5 minutes flat. Why do you bring up terms like attenuation and spectrum? You're just making it more complicated to keep yourself in work. I hardly think we need 85 access points to cover this campus... Welcome to the world of IT. A skill which is just as important as troubleshooting is people skills. Unless you can find a department with a really good manager who covers the politics for you.

A good IT department aligns itself with the organizational goals - no cares if a server is down or what hand waving you do to fix it, they only care if they can make widgets. You need to spend the time to educate your customers (the rest of the company) on how what you're doing makes their life easier.

And as tomjedrz said, you're in the wrong line of work if you need recognition. On average in the last 10 years I've been recognized less than once a year.

Answer 4

As an administrator being unappreciated is part of the job description. You're not front-facing, you're not working on the latest sexy project, nobody hears from you and nobody even knows you exist until things go wrong. Users come in and log on and they get their stuff; they expect this to happen, and they don't know that you may have been up until 4AM fighting like a hero to ensure that it did happen.

There's actually quite a lot of job satisfaction to be had from that, but it's entirely up to your own attitude and approach. You either accept it or you move on, but if you can take your own personal pride in a job well done, I've found that a lot of other things become less intolerable.

I'm sure that I could tell the very same war stories as anyone else: the server replacement request that was refused until the old one died at the most inappropriate time (and your subsequent night without sleep as a consequence), the suggestion you've been making for years that was totally ignored until the smart-suited consultant makes the same one and gets drooled over by management for it, and so on.

In the end what it comes down to is that people don't analyze things until there is a crisis, and if you're doing your job well, that crisis rarely happens, and is very smoothly managed whenever it does. So like I said it's your own attitude to the job that counts. Just learn to take being unappreciated as a sign that you're doing your job well!

Answer 5

I somewhat answered this in another answer recently but this is a good topic. One of the key issues between IT and "the Others" (sue me, I'm a Lost fan) is that in the Dharmaville we call IT, we know what we're doing. We're happy. We understand our parts (for most part) and know how to do it well (again, for most part). The problem comes in how IT is utilized. In the past IT was the hammer that drove the nails. We came out, provided dumb terminals and as long as the mainframe and network were up nobody really questioned anything. Nowadays IT NEEDS to be seen as BUSINESS PARTNER. Nothing gets done without IT involvement now and when people fail to realize that you can't plan to put in a massive product and not even know if 1) It really will help anything 2) If it even works with what we have and if it doesn't what do we need to do to get there. We need to evolve our thinking and update our policies and procedures to accept these new changes or we'll always be stuck in the same old rut.

Answer 6

In my experience, a system administrator will only get noticed when things go wrong. If they are doing their job properly, they will rarely get noticed at all.

This is because people generally don't think "wow! the servers are running well today, nothing has gone wrong for ages, the system administrator is doing a great job!"...but they will notice the instant that something breaks or if they can't do something they want to do.

Other people have already said similar things in this thread, but I'd like to add that when you do get noticed or praised it will most likely be for the most trivial things that took you no time or effort or brain-power to get done....but the really hard things that you're actually proud of having achieved will almost certainly not be noticed or commented on.

You can either just accept this, or let it piss you off. Personally, it doesn't bother me much - I mostly just think it's a cutely amusing thing that weird non-geek people do.

Answer 7

It's pretty hard to say without understanding of what the specific "organizational issues" are. Without meaning to be offensive, can I point out that the problems of the organization (organizational issues) should be the problems of IT while "IT problems" (computers and servers) are not necessarily organizational problems.

The faster you get aligned to business needs the faster you get jumped on when there is a glitch because you are already on the biggest problems to business first. i.e. "everything dropped" until the biggest problems to business get fixed.

The obvious way to solve these problems are

1) Get aligned to business by setting up structure of the priority of systems. 2) Get a helpdesk set up which is clearly able to triage issues coming in and then classify them 3) Publish SLAs to ensure that users have clear expectations on how long it takes a particular type of problem to be fixed 4) Ensure there is root cause tracking so that every problem is solved instead of seeing the same symptoms reappear

E.G. System A before System B, critical issues before medium issues. E.G. Every System A critical problem falls into Group X and group X problems have an SLA whereby a plan to the solution will be out within 4 hours and a workaround will be deployed with X hours.

Answer 8

I previously worked for a small-sized company with organizational issues and misunderstanding about what my job entailed. Employees were wearing too many hats and reporting to too many different people. I managed to get them to make a little bit of headway towards cleaning that up after much complaining. I also tried to push for job descriptions (nobody had one), but it never happened. I managed to maintain my sanity by building a simple web-based task management system. Any time the pointy-haired boss wanted something done immediately, I would either sit down with him and reprioritize or ask him which things he wanted to scrap.

Now I work for a medium-sized company which is highly organized and they gave me a job description on the first day. Not everyone knows what I do, but my manager and everyone above him does, and everyone in my area does. Chaos is probably common, but there are good places to work out there.

Answer 9

It is common for "organizational issues" (such as politics, organizational inertia, and selective hearing -- think Dilbert) to cause more IT problems than computers and servers do?

Only if you work in a mismanaged IT department. IT needs to be an extension of the business goals of the company. I'm a big fan of ITIL or MOF as a way to organize IT as it gets IT to realize that the business is not a "customer" (like the old 80's mcdonald's IT management style tried to push) but a partner. It's overall Job is to deliver the options on how to solve or enhance a particular business problem. If politics and or inertia, selective hearing make the business decide to choose a different option than what you consider the "best", you have to remember that it's not your decision and you might not be in possesion of all the facts that brought the business to the decision.

Likewise, is it common for one's employers to not really know what said person's job entails, or even care, until such time as they have a computer glitch, and want everything dropped to have it fixed now?

Not only is that a big YES but if it's not your manager, why should they know?

What can be done to ameliorate such situations? (How about in a setting one step removed from business concerns -- not needing to increase profits or make clients happy -- such as in a governmental organization?) How do you take satisfaction in a job well-done when no one knows or really cares what you are doing? Indeed, how do you stay focused if it doesn't seem to matter if you do anything or not?

That's where the frameworks help out. I'd introduce some sort of management framework as a way to smooth out all these problems. It's not a magic bullet but it goes a long way to solve this type of problem. Of course getting buy in for a solutions framework is likely to be a challenge.

Answer 10

If this is the situation you face then the departmental IT management has issues or their is a lack of communication between you and your manager. The IT management should have a clear vision of what they are delivering to the organization and some sort of metrics to show how you're doing. It's also their responsibility to deliver recognition to those who perform well and reward appropriately.

You have to look at this environment and decide if this is where you want to be long term. If not, keep your eyes open for opportunities. You'll have to work at it a bit but eventually you should be able to find an environment where you'll be happier.

Answer 11

In my experience as a data warehousing contractor most significant failure modes of IT in general and data warehousing in particular are political in origin.

I.T. projects almost always have to interact with other parts of the incumbent infrastructure. Unless you have very strong and savvy I.T. management the normal situation is an adhocracy with a growing case of bit rot. I have come to have very low expectations of I.T. management in companies I have worked with - they are generally a spineless lot and tend to not have authority to do their jobs anyway.

This means that most projects will be boxed in by political expediencies and anything but sticking plaster is very unlikely to have sufficient political backing to succeed. Currently I am working in an organisation where approval for a server has to hop through three governance committees.

Unless you have a strongly integrated operations and I.T. stratgegy you will also suffer from requirements being expressed in terms of an incumbent manual solution ot the underlying problem. Typically an I.T. function will have no authority to make changes to business processes. This combines with the political tendency to sticking-plaster solutions in a particularly toxic way.

Complex back offices tend to generate opaque business processes that accumulate over each other. Data on spreadsheets can hop through 4 or 5 people before reaching their final audience - this phenomenon is sometimes known as 'excel tourism'. These processes are often very poorly designed (never, ever let an accountant design core business processes if you have the option) and have massive inefficiencies and complex manual controls. Requirements in this environment tend to be complex, subtle and mostly undocumented. This environment is very prone to empire building and key man dependencies. In the data warehouse literature these people are known as 'gatekeepers' and are a key failure mode of data warehousing projects.

Working with such people fills me with warm, fuzzy thoughts about the practcal applications of waterboarding to requirements capture.

As as the cruft accumulates the cost of fixing the underlying problem grows, creating a feedback loop where the infrastructure just keeps decaying and gets more and more politically infeasible to fix. Most finance companies have so much crud in their back office that they are structurally incapable of implementing an effective data warehousing initiative.

The technology is now mature and available relatively cheaply - and it's not rocket science. There are almost no issues in modern IT that are fundamentally technology related. You will almost always find a political issue to be the root cause of a significant problem with I.T.

Answer 12

Where do the misinterpretation problems fit into your "organizational issues" vs. computers and servers? By this I mean if there is a specification that is open to interpretation and a developer and a tester have different understandings and someone has to come in and be the judge or referee to get things back on track kind of thing.

What one's job entails will often have an "and other duties as requested" which is a bit of a catch-all in terms of what one is supposed to do. Classic examples here can include learning things as one troubleshoots an issue and has to learn about some system or codebase as this is where the problem is found and one should be able to handle it.

To prevent these requires having good communications, process and personalities among the people so that things can flow well, IMO. That means from the top on down building a culture to handle things in a professional manner and have some conflict resolution procedures in place.

The satisifaction I take in a job well-done comes from the glow that the person using what I created or fixed allows them to do. They don't have to know what I did, just that it is done with a positive result. Another way to view this is the "Thank you" that one gets at the end and can go, "Yeah, I helped make that awesome experience," which generally perks up my mood most of the time. If it is repeated often then it may lose significance.

I have worked at places where I would almost swear no one cared at all about what I was doing and this did lead to a little burnout from a few different ways. One part is that some people would give me thanks for what I knew was a crappy job but they didn't think it was so bad. Another is being limited in one's box where if I go fix a bug I have to undo my work or I put in a new feature that wasn't approved and have to undo my work which can be really demoralizing as one could just think that, "If I undo what I did, why not just do nothing?" which led me to that situation of doing nothing and still getting paid.

Answer 13

In my large organization, you'd swear that the policy-makers are doing everything to keep people from achieving anything.

They are willing to pay me for not doing anything useful, and I've chosen to play with it. I'm not going to fight the system. At least not at the moment.