I don't think this was ever explained to you in the level of detail
required. I consider that my failure. I should have prepped you
better.

So, with that in mind, please review the following and make sure you
agree with it, and I am not expecting too much, or tell where you need
better support / training to do what is expected of you.

Your job is to support a very complex workflow.

While it is centered in Perl and shell script programs running on {{SYSTEM_NAME_1}},
it reaches out and makes use of many sets of programs on multiple
systems.

These systems include the Windows based {{FILE_TYPE}} spooler for the actual spool
file generation, the mainframe for {{MF_CICS_APP}} updates, the Windows box (via
FTP) that hosts the MAIL.DAT folder, and every desktop that runs the C-#
front end.

In some cases we are able to ask the help desk to support the core user
interaction issues, such as the C-#/Samba integration. If a single
system fails, it is not that bad, since they can use a different desktop
to submit their jobs.

In other cases, such as {{SYSTEM_NAME_1}}->Windows spooler or {{SYSTEM_NAME_1}}->MF,
you are the core "goto" guy. All problems are yours. You may not have the
technical ability to actually solve them, and it becomes a "chase down
the real tech and make them address it".

There is never a Linux problem, a Windows problem, or a Mainframe
problem with this system. They are ALL spooling production problems.

So, when you are asked to fix a production problem, you can never say it
is not your problem. They are all your problems. The key issue is
tracking down the person who can fix it as soon as reasonably possible.

In the case of MF {{SPECIAL_MF_SOFTWARE}} problems, the only person who can help you is
{{MF_SYSTEMS_PROGRAMMER}}. {{MF_MANAGER}} may be able to coordinate dealing with
{{MF_SYSTEMS_PROGRAMMER}}, but {{MF_SYSTEMS_PROGRAMMER}} is the person doing the work.
If there is a {{SPECIAL_MF_SOFTWARE}} problem and you are unable to personally contact
{{MF_SYSTEMS_PROGRAMMER}} (get an email response, talk to him on the phone), you must
escalate as soon as possible. Get a hold of {{IT_DIRECTOR}}. Without
{{SPECIAL_MF_SOFTWARE}} {{MF_CICS_APP}} updates, we stop printing. Once
{{MF_SYSTEMS_PROGRAMMER}} is working on it, you must be available to test a {{MF_CICS_APP}}
update. You can never toss a problem "over the wall" and expect it to be fixed, you have
to be part of the solution.

In the case of Windows spooler issues, either {{WIN_ADMIN_1}} or
{{WIN_ADMIN_2}} should be able to help you, but the key issue is that you are
able to test the moment they say they think it is working. If you
can't get either of them working on your problem, you need to speak to
{{HELP_DESK_ADMIN_MANAGER}}. If {{HELP_DESK_ADMIN_MANAGER}} is unavailable,
you need to speak to {{IT_DIRECTOR}}. Do NOT accept that they will "get to it".
This is core print production, the whole company STOPS when this fails.

In the case of a Linux problem, get a hold of {{LINUX_ADMIN_1}} or {{LINUX_ADMIN_2}}.
If you can't get either, get {{HELP_DESK_ADMIN_MANAGER}}. No
{{HELP_DESK_ADMIN_MANAGER}}? {{IT_DIRECTOR}}.

In the case of a {{3RD_PARTY_HARDWARE}} job submit problem, {{MF_MANAGER}} should
either be able to help or contact the people at {{3RD_PARTY_HARDWARE_COMPANY}} to help.
No {{MF_MANAGER}}? Get {{IT_DIRECTOR}}.

You should always keep {{HELP_DESK_ADMIN_MANAGER}} in the loop if you are about to go
on a high pressure "get it done" effort. She needs to be aware of what her people
are doing, and she gets to juggle what they do. But if she does not juggle it the
way you want it, go to {{IT_DIRECTOR}}. Do not accept that you are a lower priority
unless {{IT_DIRECTOR}} says so. If that actually happens, put it
in writing, email it to him, and make him confirm it. While this may
seem drastic, sometimes people don't realize how important a problem is
unless it is written down. Or maybe the situation was misunderstood
until that point.

If you can't get a hold of {{IT_DIRECTOR}}, track down {{CTO}}. Work through
{{CTO_SECRETARY}} when trying to get {{IT_DIRECTOR}} or {{CTO}}.

Also, keep {{MIS_DIRECTOR_YOUR_BOSS}} in the loop (email, etc), but do not expect
him to follow up with other people. That's your job.

You might find yourself in the position where people stop liking you
because you are a pain in the ass. This is probably a good thing. It
means you are doing your job, and making them do theirs when they don't
want to. On the other hand, it could be an indication of a fragile
system or a poor design that needs to be fixed. If it gets to that
point, it is time for us to review how we do things.

While you should keep me in the loop, and ask me for help if you REALLY
need to, you should attempt to do without me. If you find yourself
relying on me too much, it means you are not ready to do it alone. I
think you have enough exposure, have reviewed the code long enough, and
have been through enough problems that you should be able to handle it.

There is no other person in the company that I am aware of that is in a
position to help you. The help desk people cannot, the MF COBOL
programmers cannot, no one. The computer operator can help you with
phone numbers, but it is still your responsibility to contact people and
make sure they are working on your issue.

You should probably review this email with {{MIS_DIRECTOR_YOUR_BOSS}}.
He may have some contrary viewpoints on how to do your job. Or he may
add his stamp of approval.

Let me know if you have any questions.

{{ME}}