I am quite happy where I am, doing what I am doing and the pay is just fine. I don't want the headaches, political bickering and exposure to hostile fire that being the IT Manager entails.
One thing you might consider, howerver, is that your contentedness with your current situation might be heavily dependenent upon the current management. If your #1 is replaced with someone else, this could change drastically.
By taking the promotion, you have more control over the direction of the department and nurturing the climate you have become so comfortable with.
If you do convince your company that you are not the right person for this job, you should still volunteer to take a more active role in the management, so that you can ensure that the environment you like persists for a while longer.
Explicit hierarchy is sometimes necessary for blame assignment, but is rarely the actual operational leadership structure. The price for displaying leadership from within the ranks is exposure to increased responsibility by promotion.
It may be that you just have to have an honest discussion with the decision makers about this. But make sure you yourself understand why you don't want this position, and can articulate that fact to your management (without bursting into tears or hollering at people).
This is right up there with storing data in the mode bits of directory entries in your filesystem, then tar'ing the directory structure up and sending it to someone else.
From some of my experiences as a systems consultant to large corporations, it seems to me that there will be instabilities related to the hasty and ill-conceived replacement of systems deemed 'non-compliant', though no reasonable effort was undertaken to discover whether or not the system would actually have failed.
Simply because, for example, the OS vendor makes no guarantees about specific versions of their OS, entire systems are replaced, on a tight deadline, by already overworked systems staff who probably don't understand all of the functions performed by the system (which they may have inherited and treat with an "it seems to work--don't touch it" attitude).
As the "deadline" approached, the more hastily these systems were replaced.
The major effect of this will likely be an increased load on systems staff as they stamp out various brushfires, possibly leading to a little churn in the industry.
Then again, I suppose those who wish to may, for the nonce, continue to live under the spectre of being plunged into darkness, chaos, and strife.
Now there's an interesting idea. Anyone interested in developing "A Pattern Language for Online Communities?" A list of little self-contained wisdoms which make online communities work.
The size of a community definately has an impact on how well it clicks. Too, I think, the ease of use and the transient nature of to-days electronic messaging tools (News, Email, Web: NEW) create a completely different dynamic from the On-line disucssion (OLD) tools of the mid-80s.
300 baud was the perfect speed, because you could read an entire 'room' without having to page through it. You could pause if you needed, but generally didn't need to. When most of the BBSs I called on a regular basis upgraded to 1200 baud, I would generally still call at 300. The pace fostered thoughtful replies, and clever, often deep banter. I still have close ties to people with whom I developed online relationships. I wish that I could recover some of the content which was generated.
At one point, a bunch of folks who met through BBSing, rented a house together. The house had 4 telephone lines, and you had to call one of the BBSs and scream "Voice call" or "Bomb Threat" through the carrier negotiation tones to talk to anyone voice. Great callerID! There were some people who would call each of the BBSs in the house in turn, probably not realizing they were all in the same room.
While to tools in use were slow, the times and relationships were dynamic. Regular parties sprouted around the online musings. Seattle formed a Telecommunications Users Group (TUG) which met regularly. There were feuds between various BBSs, etc.
Far too much of the email I get today consists of just a single URL. The odd thing is that I've experiemented with various forms of web-based BBS and online forum, and none seems to click. Slashdot has some interesting ideas for managing huge communities, but spending lots of time moderating can take away one's will to participate more meaningfully.
Weblogging bas become a sort of community, with popular webloggers banding together and sharing content, and doing things offline together. And I have seen some topic-specific forums work very well (scripting.com and WikiWikiWeb (http://www.c2.com/cgi/wiki?WelcomeVisitors) as two examples.), but weblogs are often topic focused (I run one such weblog, Bubble Chamber, http://jimfl.yi.org:88) or web focused, and don't have room for discussion. The BBSs had lots of various, evolving topics, which you could participate in, lurk, or ignore, and there was a great diversity of interest.
So, like ecosystems, you have to have the right mix of species, not too big, (with a path down the middle. Yes, a PATH, a PATH, Nik!), and where people can read what has come before and decide to join in the middle (email can't do this), sometimes months after the conversation has gone dormant.
I, too have been in the situation of finding that too many "restrictions" cause the more savvy users ("power lusers") to attemtpt to subvert them.
I'm glad to have seen it called out in print.
This phenomenon points up the fact that most of the security functionality being implemented is aftermarket layers upon software systems which are inherenltly not secure, and not impedance-matched across platforms. Until information systems are designed from the bare-metal up with sound, standardized information security practices in mind, this phenomenon will persist.
A successful attempt to subvert the security of a system should render it inoperable (like a dead man switch) and the data effectively lost to the author of the subversion and every one else until an authorized principal intervenes.
The system also needs to distinguish sensitive data and non-sensitive data, secure conduits and insecure conduits--somewhat like Perl's taint mechanism. If inconveniences are only assiciated with sensitive operations, the users are less likely to revolt.
Slashdot Mirror
Ummm. April 1 is next month, y'all.
What's next is AppleScriptingiTunes.slashdot.org
You can do it in John Conway's head.
One thing you might consider, howerver, is that your contentedness with your current situation might be heavily dependenent upon the current management. If your #1 is replaced with someone else, this could change drastically.
By taking the promotion, you have more control over the direction of the department and nurturing the climate you have become so comfortable with.
If you do convince your company that you are not the right person for this job, you should still volunteer to take a more active role in the management, so that you can ensure that the environment you like persists for a while longer.
Explicit hierarchy is sometimes necessary for blame assignment, but is rarely the actual operational leadership structure. The price for displaying leadership from within the ranks is exposure to increased responsibility by promotion.
It may be that you just have to have an honest discussion with the decision makers about this. But make sure you yourself understand why you don't want this position, and can articulate that fact to your management (without bursting into tears or hollering at people).
Whatever happens, good luck!
This is right up there with storing data in the mode bits of directory entries in your filesystem, then tar'ing the directory structure up and sending it to someone else.
From some of my experiences as a systems consultant to large corporations, it seems to me that there will be instabilities related to the hasty and ill-conceived replacement of systems deemed 'non-compliant', though no reasonable effort was undertaken to discover whether or not the system would actually have failed.
Simply because, for example, the OS vendor makes no guarantees about specific versions of their OS, entire systems are replaced, on a tight deadline, by already overworked systems staff who probably don't understand all of the functions performed by the system (which they may have inherited and treat with an "it seems to work--don't touch it" attitude).
As the "deadline" approached, the more hastily these systems were replaced.
The major effect of this will likely be an increased load on systems staff as they stamp out various brushfires, possibly leading to a little churn in the industry.
Then again, I suppose those who wish to may, for the nonce, continue to live under the spectre of being plunged into darkness, chaos, and strife.
Now there's an interesting idea. Anyone interested in developing "A Pattern Language for Online Communities?" A list of little self-contained wisdoms which make online communities work.
Perhaps one already exists?
The size of a community definately has an impact on how well it clicks. Too, I think, the ease of use and the transient nature of to-days electronic messaging tools (News, Email, Web: NEW) create a completely different dynamic from the On-line disucssion (OLD) tools of the mid-80s.
300 baud was the perfect speed, because you could read an entire 'room' without having to page through it. You could pause if you needed, but generally didn't need to. When most of the BBSs I called on a regular basis upgraded to 1200 baud, I would generally still call at 300. The pace fostered thoughtful replies, and clever, often deep banter. I still have close ties to people with whom I developed online relationships. I wish that I could recover some of the content which was generated.
At one point, a bunch of folks who met through BBSing, rented a house together. The house had 4 telephone lines, and you had to call one of the BBSs and scream "Voice call" or "Bomb Threat" through the carrier negotiation tones to talk to anyone voice. Great callerID! There were some people who would call each of the BBSs in the house in turn, probably not realizing they were all in the same room.
While to tools in use were slow, the times and relationships were dynamic. Regular parties sprouted around the online musings. Seattle formed a Telecommunications Users Group (TUG) which met regularly. There were feuds between various BBSs, etc.
Far too much of the email I get today consists of just a single URL. The odd thing is that I've experiemented with various forms of web-based BBS and online forum, and none seems to click. Slashdot has some interesting ideas for managing huge communities, but spending lots of time moderating can take away one's will to participate more meaningfully.
Weblogging bas become a sort of community, with popular webloggers banding together and sharing content, and doing things offline together. And I have seen some topic-specific forums work very well (scripting.com and WikiWikiWeb (http://www.c2.com/cgi/wiki?WelcomeVisitors) as two examples.), but weblogs are often topic focused (I run one such weblog, Bubble Chamber, http://jimfl.yi.org:88) or web focused, and don't have room for discussion. The BBSs had lots of various, evolving topics, which you could participate in, lurk, or ignore, and there was a great diversity of interest.
So, like ecosystems, you have to have the right mix of species, not too big, (with a path down the middle. Yes, a PATH, a PATH, Nik!), and where people can read what has come before and decide to join in the middle (email can't do this), sometimes months after the conversation has gone dormant.
I wonder how many of the "small, hungry, unknown" companies are reading Gartner while at the same time flying under their radar...
We could call what MS does "Brandardizing".
I'm glad to have seen it called out in print.
This phenomenon points up the fact that most of the security functionality being implemented is aftermarket layers upon software systems which are inherenltly not secure, and not impedance-matched across platforms. Until information systems are designed from the bare-metal up with sound, standardized information security practices in mind, this phenomenon will persist.
A successful attempt to subvert the security of a system should render it inoperable (like a dead man switch) and the data effectively lost to the author of the subversion and every one else until an authorized principal intervenes.
The system also needs to distinguish sensitive data and non-sensitive data, secure conduits and insecure conduits--somewhat like Perl's taint mechanism. If inconveniences are only assiciated with sensitive operations, the users are less likely to revolt.
The USAF uses telephones too. Also, I don't think ADA is a munition.
Terrififc. World War 3.0.2b.