Home
About
Apple
Career
Experiences
General
Graphics
Hardware
History
Humor
Interface
Networking
OS
Opinion
Politics
Programming
Quotes
Reviews
Security
Software
Sound
Thought
Web
Cheap International
Airfare Online
Wachovia online banking
Get Free Coupons Online
Finding the perfect
discount hot tub
Payday Loans
Stock Trading Online
Stuffed Animals
Smart Investing Online
|
|
Forgiveness and Permission
Results matter
By: David K. Every
|
Kind:
Created:
Size: |
Article
May 10,2003
7 KB |
|
|
 |
 here were some interesting techniques I learned at Rockwell about coping in Corporate America.
One was that possession is 90% of the law. 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.
I later learned this system is frowned upon in other businesses, and how obnoxious it truly is; so I pretty much stopped that. 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 get results. It doesn't matter if you go through all the proper channels if you repeatedly fail. And you will be given more leeway if you succeed.
Try the channels, keep trying the channels, and so on. Don't buck authority just because it is there. In fact, I think the better you are at following the rules and getting along, the more successful you can be. But there are exceptions to rules. There are many, many, many cases where you're told to do the impossible or do things in impossible ways. What do you do? My solution was to redefine the rules to make it possible. Failure is not an option. The more they push for the impossible, the further you have to stretch the rules to make it possible.
If you know you absolutely cannot do it the way that someone says (and that's only when you're sure), then do it your way. At least then you stand a chance of snatching victory from the jaws of defeat; which is better than the alternative of sure defeat and then trying to weasel out with "but I did what you told me". Sadly, most people that fail gallantly are going to still take the blame. So make the rules for success.
Not enough resources? Allocate more. Not allowed to buy something? Then 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. If you know a process is going to be long and drawn out or impossible, then forget about it or go around it.
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. Sometimes assuming more authority than you have is the only way to get things done. My mother used to tell me growing up, "Excuses are made for failures", which I took to heart. If you have the impossible, then make it possible; it probably won't be worse than the alternative.
Of course there's a balance to all this. You can't just do what you want, and you need to be part of a team and organization. But people respect the "failure is not an option" mentality, far more than they respect finger pointers and whiny losers.
           
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.
I proved I was right, and that no one needed this make-work. In hind site, it was a pretty hollow victory. Yes, they finally dropped the "object code" print out requirement. But I also pissed someone off in a major way, and was way more passive-aggressive than I needed to be. I ran into that person later, and there was always sort of a hurt and betrayal at what I'd done to her. (She'd had to reenter all the listings and admit her mistake in letting the first one's get past). I didn't need to do that, and I'd actually made more work for myself, by writing my own object listing conversion tool (for septa-decimal) just to prove a point.
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.
 
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.
   
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.
 Format for Printing  Mail
|
|
|
|
