Yes, I have learned important things - all manner of geekery, electronic theory and application, shop technique, shortcuts, organization and documentation--
But the most important lesson I have learned never seems to stick; I keep getting tripped up by it over and over:
Never, ever make an honest report of problems encountered and how you have or plan to overcome them. Just solve it, shut up and move on. Only show finished work.
If you actually describe the process, even in the simplest of "problem>solution" terms, they'll just assume you're griping and can't actually do the job. Even if you have told them them you've already solved it or have the solution well in hand.
This may be something I am categorically unable to understand.
Nobody bloody well cares about the details of whatever it is I do down there in the engine room. They just want the whistle to blow when they pull the cord.
BUILDING A 1:1 BALUN
4 years ago
7 comments:
Don't forget to Scotty them while you're at it.
Sadly, that's a typical management attitude....
And if you must do something... unconventional, then remember: "It is far easier to get forgiveness than permission."
This advice is worth exactly what you paid for it.
I've not explicitly noticed that in my work, but perhaps I should use it as a lesson gained from the experience of others that I should heed.
Unknown, I'd like to think that the stuff that happens to me is not the only way things work out. Surely there must be jobs where honest reports of what you're encountering and working through are not met with the implication that you're not up to the task.
It depends on the specific circumstances. During my last stint in Corporateland, I tended to send in rather specific weekly reports. And one time....
I was assigned The Christmas-Tree Problem: as described, plugging in certain OC-48 boards caused all the LEDs in the system to turn on. Management was very interested in any progress I might make.
I spent the next many days delving into the problem and sending in frequent updates to the detective yarn (for that seemed the most appropriate format for writing it up). Eventually, I determined that the failure chain started with the OC-48 board having been designed (not by me) with excessive bulk capacitance between the hot-swap circuit and the power bricks... so that a normal system power-down event could cause the hot-swap controller to be damaged, with subsequent events leading to the soft-start FET failing shorted and, then, the fuses blowing.
I should still have the final story on a backup disk, somewhere. It did get some attention from the higher-ups.
In the subsequent years of consulting, I've mainly been reporting to techies, and they find detailed reports useful, even when the conclusion is: "Crap! My part database got corrupted last year, and the BOM I generated had 16V capacitors where there should have been 50V parts."
I have come to a similar viewpoint. Since one facet of my job is to order things like glues, screwdriver bits, and cotton swabs, I can sometimes order a minor doodad to JDI.
Post a Comment