challenges and non technical managers 2

[VE]

What do you do when you run into a problem that needs to be solved and your manager, who is not technical (business manager), demands that you tell them excactly when you will have it fixed?

What do you say when they imply that your job is easy? When they ask you how long something will take, and when you give them an honest estimate they get mad and tell you that you have to have it done in 3 days?

Is it just time to get out of here before I get fired?

 

[edfair]

Haven't had that for a long time, but my usual response was "I can't tell you until I figure out what is broken, and I'm still working on that".

Agree that the job is easy, just a matter of putting a drop of oil on something. The hard part is figuring out where to put it.

You're not going to be happy working for someone who treats you like that. Probably time to be looking around. I went through it 3 times early in my career.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[Noway2]

About the only way I can think of to combat this type of situation is to make sure they understand that you have a process to follow to get to the solution. Chances are that you can give some sort of estimate of what the next X steps will take, so start there. Hopefully you also have some experience with past events and can draw upon and reference those.

 

[VE]

thank you for allowing me to vent.

I will try both of your suggestions, as well as start sending out my resume. Not getting fired is important, but having a job that I don't dread every monday morning is also important.

Thank you
VE

 

[goombawaho]

I had the opposite problem - non-technical manager and didn't really care as long nobody was breathing down his neck/knocking on his door. "Bosses - can't live with 'em, can't dump 'em down a well." But some are better than others.

I'd agree that updating resume is #1 followed by scoping available options in the market. If you can't "manage" his behavior with rational discussions and time estimates, then you are doomed because he's irrational. That irrationality will bleed over into your evaluation and employment status. A shame.

 

[SteveTheGeek]

I've had a few managers like that too. A Dilbert comic described it exactly for me - the PHB figures that if they don't understand it, it must be easy. I agree with the above - the immediate action should be to break down and lay out the steps with time estimates (and probabilities) of each step. Beyond that, start looking at the job market and exploring your options. Life is too short to be spending eight hours a day being miserable when there are solid alternatives available.

CompTIA: A+ (WfW 3.11), Network+
Microsoft: MCSE+I (NT4)
Novell: CNE (4.11, 5.0)
Citrix: CCA (Metaframe 1.0)
Cisco: CCNA (current)
Working on MS 70-642 then CCNP...

 

[pgmr777]

VE.."dread" is the word..I know exactly what you are talking about.

 

[Martin999]

When I get how long a problem will take - the answer is simply "I'll tell you when I've finished it".

If it were suggested that my job was 'easy' - I would invite the person in question to do it for me.

 

[edfair]

If it were suggested that my job was 'easy' - I would invite the person in question to do it for me."

Had a manager and his tech specialist come to my account to show me how to fix things. Manager sat beside me while I dismantled, replaced broken part, and put back together a Friden adding machine (mechanical except for the cycle motor) that was part of an IBM keypunch. At the end of the day the operator on the next machine asked me to do the same fix on hers. Manager suggested that I use my spare, which I didn't have because he had refused to let me get one. He authorized it that moment.

The tech specialist worked on the other broken things but kept coming to me, describing the problem, and asking what it would take to fix it.

I was gone from IBM about 6 weeks later, went back into the customer as part of the new job, and would run across as many a 5 FEs taking care of some of the equipment I had carried by myself for 3 years. To keep me, or the new employer, from getting any of the spare parts I had built up they threw them away. Some of the parts were re-cycled and not available anywhere else.

The manager was gone before I was.


Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[goombawaho]

When I get how long a problem will take - the answer is simply "I'll tell you when I've finished it".

How many times have you been fired for having this type of attitude?? That's the equivalent of a middle finger as far as I'm concerned.

 

[edfair]

my statement:
"5 FEs taking care of some of the equipment I had carried by myself" gives the wrong impression. Management admitted that they had put all their eggs in my basket by not having other people trained on the stuff so they threw bodies at the problem. I suspect that they were worried about losing rental on 14 computers the customer had around the country.

Must admit that it was an ego boost at the time and a pleasure to take part in the disruption of their rental business as part of the leasing movement. At one point in 1966 it was projected that IBM would not own any punch card equipment after 1969 based on the rate that it was being transferred to leasing companies. Didn't happen, however.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[edfair]

quote:
"When I get how long a problem will take - the answer is simply "I'll tell you when I've finished it".

quote:
"How many times have you been fired for having this type of attitude?? That's the equivalent of a middle finger as far as I'm concerned."

After fighting a losing battle over operator training with an AT&T division plus their failure to acknowledge that the parts stream was dry on their obsolete equipment they requested a meeting. One demand was made, 98% uptime of their equipment. Told them they wouldn't get that from me. The equipment contract was cancelled and they found a new supplier, who faced the same issues.
The IBM FE who had been servicing IBM owned equipment danced a jig when he heard that a leasing company was going to replace the IBM stuff when I took over his service responsibility.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[goombawaho]

It was Martin999 that I was referring to.

 

[edfair]

I know. Just commenting on the attitude and how I used it to get myself fired.

Ed Fair
Give the wrong symptoms, get the wrong solutions.

 

[DonQuichote]

Tell the manager that programming and system maintenance are crafts, not surveyor-belt types of work. And that, off course, they should be managed as such.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[willir]

Make it look easy.

Ask yourself why is the boss being pushy? Is the boss just being an ass, or is there a serious impact due to the down time. Usually there is a reason. Bosses do not like to hear complaints; rather they like to hear solutions to a problem

Get the user / users back to work in a short time so your boss does not have to nag.

How to make it easy depends on the size of the operation, budget available and such. You can fix a lot of problems before hand, or anticipate typical problems by planning accordingly.
- Standards
- Plan / contingency plan
- Test
- Protect yourself (in writing)

Use "standards" in your desktop build. Avoid as much customization as possible. Core build has typical applications used by 80 or 90% of your users -- MS Office, Adobe Reader and Flash type of thing, similar hardware.

How costly does downtime cost your user, your company -- use this as a case for having backup hardware, incorperate reduncy in your plans.
- Dead PC - Hot spares with standard build
- Dead server - VMware, failover clusers
- Network issues - redundency plan and contigency plan
- Printer issues - use redundency printing solutions
- Business critical app down - contigency plan

If this is a software issue, test, test and test again before deploying. Test any patches before deploying. I use beta testers at my site - they use the software or patched software 1 to 3 weeks before I deploy to others. Most problems will have occurred within this time frame. Oh yea, real important - get a formal by-off from your beta testers so if something breaks, you can demonstrate due diligence.

If the problem chronically reoccurs, look for a better solution. Training the user is a common solution. If a user frquently breaks their computer / software because of malware, then talk to management. If an app frequently breaks, get the owner to fix it.

Gets some tools in place so you can quickly diagnose the problems. Eg. Oracle server in Texas is not working and you are located in Boston. Your tools would be "ping", "tnsping", and maybe a test application to test functionality. Ping determines if this is a network issue, and by what you ping, you should be able to quickly determine where the failure is. Tnsping determines if you have a database problem. If you can tnsping the Sales database in New York but cannot tnsping the inventory database in Texas, then you know where to focus your efforts.

The tough ones:

Laptop users, especially remote users. Have not completely figured this one out yet. VPN, terminal servers, cloud computing where you have no idea on the type of network is available in the hotel and the super non-technical sales person with a heavy accent does not have a clue on how to describe the problem.

Third party / leveraged support resources that is weak, lack technical abilities, etc. You have very little control in this situation and you have to clearly communicate that you and your boss are dependent on the third party / leveraged support, and this was a decision made by corporate. When it comes up for contract renewly, be armed with statistical information that demonstrates why you are not happy, and if it is within your mandate, offer solutions. .

For any situation that impacts users, affects VIP, costs money, etc, have contigency plans for the situation. Because you are prepared, you can implement the contignecy plan within a short order to get the users / users working again, and your boss wont get ulcers.

If you do not have a contigency plan due to resources or lack finacing, identify this point of failure as a potential issue, and prepare your boss that if X happens, it may take hours / days to fix. I dont like using the "I told you so" argument, but "I told you so".

Oh, and if the problem "is your boss", or decisions they made, indicate ahead of time, that because of decision A, project B may be delayed by X days type of thing. Be tactful and prefessionaly here - big difference stating "Because you did..." vs "Since we currently lack...".

Bottom line is that planning contingency plans, testing, etc takes a lot of effort. Although you make the job look easy when you, the super hero, fly in to resolve a problem quickly, remember to take pride in your work. Contigency planning can also include a CYA plan if you know you are vunerable because of senior management decisions. A good boss should recognize you for your efforts. A bad boss will recognize you for your efforts ... after you leave.

Good luck.