Collins: Permission
Better to beg forgivenes for bending rules on a successful delivery, then getting unemployed waiting for permission.
~ Aristotle Sabouni
Created: 2003-05-10 |
Obnoxious[edit | edit source]
Possession is 90% of the law, right?
I decided that the forms and things took way too much time, and I was in earlier (and often stayed later) than many others. So if I just checked the loading docks before/after hours, I could have whatever I wanted, and it would be months or years before others figured it out. Generally, I'd order whatever I took; so that others would eventually get theirs - but it was an interesting system, taught to me by the more Senior Aerospace Engineers. (It wasn't stealing, since the company was paying either way -- it was more cutting in line, when no one was looking).
I later learned this system is frowned upon in other businesses, and how obnoxious it truly is; so I pretty much stopped it. But the whole softer concept of "it is easier to ask forgiveness than it is to ask permission" sort of stuck.
While my solutions to problems were sometimes obnoxious (the midnight requisitions, and so on), I did get things done. And generally, people understand people that if you go through all the proper channels and you repeatedly fail, you still failed. And if you succeed, well then a little bitching by those who did things the right way, is a small price to pay for that success. I preferred stretching the rules for success, to following them into failure.
So I snatched victory from the jaws of defeat through cheating or stretching, "I did what you told me" and failing was worse than ignoring them and making it work.
- Not enough resources? Allocate more.
( Not allowed to buy something? Borrow it or lease it.
- You know you're not supposed to work overtime, but you won't succeed without it; do it anyways, and feign ignorance. You might get paid, you might not - but at least you succeed. And if you don't succeed, the gravy train may end.
- If you know a process is going to be long and drawn out or impossible, then fuck it and feign ignorance.
Assume you have more authority than you do. If you succeed, you'll probably be forgiven. So if (or when) you are forced to go rogue, make damn sure that you succeed.
My mother used to tell me growing up, "Excuses are made for failures", which I took a bit too much to heart during this era. If you have the impossible, then make it possible; it probably won't be worse than the alternative. People may not like you or your methods, but they respect the "failure is not an option" mentality, far more than they respect finger pointers and whiny losers.
Object code reports[edit | edit source]
I made mistakes too. We all do. You can draw outside the box, but don't go too outside the box. Don't be obnoxious, and don't be hard to work with (e.g. always right). I can rationalize why, complain about the processes, or claim that I was right; but does it really matter?
To give you an idea of some stupid processes, at one point I was requested by the QC (Quality Control) team, that we needed all of our object code printed out. You mean source code, right? No, object code. Object code is nothing but a bunch of numbers, and I was already turning in the source code; so this was lame. But someone had decided they needed object code, and it was written down somewhere, so I had to do this make-work crap.
I was pissed, so I complied in a literal and obnoxious way. I was giving them all of my object code listings, and they were happy with them. As I left, I mentioned; "By the way, for the last 3 years I've been turning in everything in septa-decimal (base-17) for an Octal based computer. If anyone in 3+ years had even glanced at the object code printouts, they would have noticed that not only did the listings not only have 0-7 (as in octal), not only did they have A's through F's in them (as in Hexadecimal), but they also had G's in them." I dropped the stack of the real listings on her desk, and reminded her how stupid the requirements were. While I met the technical requirements, it was quite a way to burn a bridge and punish someone for just doing their job, so a pretty hollow victory.
Mistakes are valuable if you can learn from them. Yes, my post-teenage sense of righteousness was assuaged; but there were better ways to go about it. After that I learned to try to exhaust more positive outlets of change, or not sweat the little stuff, before I resorted to the "screw you" approach.
Focus[edit | edit source]
I also tended to do many things that were outside the scope of my job. This can work for you and against you. I took a very liberal attitude; we need to succeed, and so if I have to unload equipment, or sling wires to succeed, then I'll do it. But there are downsides as well.
At Rockwell, I started bringing my Mac in. "Hey, the other Rockwell let me do it". Since I computers so well I was not only doing my own job, and helping with Documentation and other things, but I was also helping them throw wires, do IS/IT stuff, and network machines. There was always something to do, and I enjoyed that. And man does not live by code alone; you need to take a few mental breaks - and writing documentation, or helping IT, was a refreshing shift of gears. But I did learn that some use versatility works against you.
While my attitude was "it needs to be done", sometimes you aren't judged by the reality, it is the perception that counts.
You can be ahead of schedule on your part; but others will still attack you if you are helping others (and not doing "your" job). Let's face it, if you're too productive, you can make some people look bad; and they are looking for a way to get you back. And there are certainly some people that are so helpful that they can't focus or prioritize and get their work done first. Anything that you do to go above and beyond the minimum draws attention to yourself, and makes you a target.
While this is a little Machiavellian, it was enlightening nonetheless. I'm not saying don't do what you have to, or don't try to help others or make the project succeed - just know the costs ahead of time. In the end, the bosses understood my output, so nothing came of the complaints - but I learned something by having to go through the ordeals of being questioned or attacked for contributing too much.
Conclusion[edit | edit source]
Between the two Rockwell's, I learned a lot about hierarchy and permission, complying and results, and how to work channels of authority and people. The seven or eight years in Aerospace was a whole career for me; and they were formative years. I did some things well, some things poorly, and made some mistakes. Life goes on. I really think the difficulties I had, and coping skills I started to develop, served me well later in life.
🔗 More
| |
| |
| |
