Mixing
How soon should I advocate for making changes after starting in a new job?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
38
down vote
favorite
I recently started a new job at a new company as a Systems Administrator. The company is a small business with about 120 employees that, in my opinion, is on the cusp of becoming a medium-sized one within a few years. The culture is some what still that of a startup and I sense that some of their IT practices are more appropriate to the size and scope of their business as it was five years ago.
I have a tendency to advocate and push for change and improvement early after starting a new position. This genuinely comes from a place of enthusiasm, energy and desire to do good work the right way and not one of "I'm new the sheriff in town" or "let me tell you how you have been doing everything wrong" however I have come to learn how it can be perceived that way by co-workers. I also have developed a bit more patience as I know learning more about an environment before I start advocating for infrastructure changes allows me to be better at my job.
During the interview process I brought up some of these items for discussion and asked when my manager thought would be an appropriate period of time was before we talked about implementing some changes and his answer was six months so in a sense I have a direct answer to this question.
BUT some of the changes I want to advocate for I feel are very important and that they deserve a timely implementation:
- 20% of their desktop fleet is still on Windows XP
- There is no consistent patch management of the fleet. Lots of stuff is not patched.
- There is no ticketing system or formal method for users to request assistance
I think I can advocate that these projects should be started on now and not in six months (in my opinion they should have been started on a year or two ago). The organization is pretty flat, relatively receptive to information or suggestions being pushed "upstream" and agile. The company's market is not in technology and their IT infrastructure is in a support role not a product role.
We have another System Administrator who is my peer and we both report to an IT Manager whose primarily field of experience is development and not operations. The whole department reports to the Operations Manager who is direct report of the owner. The IT Manager is retiring soon (six months to a year) and it is not clear how that transition will be handled yet. I have a pretty large degree of independence but ultimately at this point I think the decision-making capability does not rest me. I would feel unconformable just making decisions without having the IT Manager and Operations Manager confirm them.
Should I advocate for these projects now? Or wait six months? Should I wait a shorter period of time? How can you determine when it's appropriate to start advocating for changes in a new job?
new-job company-culture
edited Apr 27 '14 at 14:58
René Roth
439411
asked Apr 26 '14 at 22:45
kce
1,1491214
 |Â
show 2 more comments
up vote
38
down vote
favorite
I recently started a new job at a new company as a Systems Administrator. The company is a small business with about 120 employees that, in my opinion, is on the cusp of becoming a medium-sized one within a few years. The culture is some what still that of a startup and I sense that some of their IT practices are more appropriate to the size and scope of their business as it was five years ago.
I have a tendency to advocate and push for change and improvement early after starting a new position. This genuinely comes from a place of enthusiasm, energy and desire to do good work the right way and not one of "I'm new the sheriff in town" or "let me tell you how you have been doing everything wrong" however I have come to learn how it can be perceived that way by co-workers. I also have developed a bit more patience as I know learning more about an environment before I start advocating for infrastructure changes allows me to be better at my job.
During the interview process I brought up some of these items for discussion and asked when my manager thought would be an appropriate period of time was before we talked about implementing some changes and his answer was six months so in a sense I have a direct answer to this question.
BUT some of the changes I want to advocate for I feel are very important and that they deserve a timely implementation:
- 20% of their desktop fleet is still on Windows XP
- There is no consistent patch management of the fleet. Lots of stuff is not patched.
- There is no ticketing system or formal method for users to request assistance
I think I can advocate that these projects should be started on now and not in six months (in my opinion they should have been started on a year or two ago). The organization is pretty flat, relatively receptive to information or suggestions being pushed "upstream" and agile. The company's market is not in technology and their IT infrastructure is in a support role not a product role.
We have another System Administrator who is my peer and we both report to an IT Manager whose primarily field of experience is development and not operations. The whole department reports to the Operations Manager who is direct report of the owner. The IT Manager is retiring soon (six months to a year) and it is not clear how that transition will be handled yet. I have a pretty large degree of independence but ultimately at this point I think the decision-making capability does not rest me. I would feel unconformable just making decisions without having the IT Manager and Operations Manager confirm them.
Should I advocate for these projects now? Or wait six months? Should I wait a shorter period of time? How can you determine when it's appropriate to start advocating for changes in a new job?
new-job company-culture
edited Apr 27 '14 at 14:58
René Roth
439411
asked Apr 26 '14 at 22:45
kce
1,1491214
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
2
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20
 |Â
show 2 more comments
up vote
38
down vote
favorite
up vote
38
down vote
favorite
I recently started a new job at a new company as a Systems Administrator. The company is a small business with about 120 employees that, in my opinion, is on the cusp of becoming a medium-sized one within a few years. The culture is some what still that of a startup and I sense that some of their IT practices are more appropriate to the size and scope of their business as it was five years ago.
I have a tendency to advocate and push for change and improvement early after starting a new position. This genuinely comes from a place of enthusiasm, energy and desire to do good work the right way and not one of "I'm new the sheriff in town" or "let me tell you how you have been doing everything wrong" however I have come to learn how it can be perceived that way by co-workers. I also have developed a bit more patience as I know learning more about an environment before I start advocating for infrastructure changes allows me to be better at my job.
During the interview process I brought up some of these items for discussion and asked when my manager thought would be an appropriate period of time was before we talked about implementing some changes and his answer was six months so in a sense I have a direct answer to this question.
BUT some of the changes I want to advocate for I feel are very important and that they deserve a timely implementation:
- 20% of their desktop fleet is still on Windows XP
- There is no consistent patch management of the fleet. Lots of stuff is not patched.
- There is no ticketing system or formal method for users to request assistance
I think I can advocate that these projects should be started on now and not in six months (in my opinion they should have been started on a year or two ago). The organization is pretty flat, relatively receptive to information or suggestions being pushed "upstream" and agile. The company's market is not in technology and their IT infrastructure is in a support role not a product role.
We have another System Administrator who is my peer and we both report to an IT Manager whose primarily field of experience is development and not operations. The whole department reports to the Operations Manager who is direct report of the owner. The IT Manager is retiring soon (six months to a year) and it is not clear how that transition will be handled yet. I have a pretty large degree of independence but ultimately at this point I think the decision-making capability does not rest me. I would feel unconformable just making decisions without having the IT Manager and Operations Manager confirm them.
Should I advocate for these projects now? Or wait six months? Should I wait a shorter period of time? How can you determine when it's appropriate to start advocating for changes in a new job?
new-job company-culture
edited Apr 27 '14 at 14:58
René Roth
439411
asked Apr 26 '14 at 22:45
kce
1,1491214
I recently started a new job at a new company as a Systems Administrator. The company is a small business with about 120 employees that, in my opinion, is on the cusp of becoming a medium-sized one within a few years. The culture is some what still that of a startup and I sense that some of their IT practices are more appropriate to the size and scope of their business as it was five years ago.
I have a tendency to advocate and push for change and improvement early after starting a new position. This genuinely comes from a place of enthusiasm, energy and desire to do good work the right way and not one of "I'm new the sheriff in town" or "let me tell you how you have been doing everything wrong" however I have come to learn how it can be perceived that way by co-workers. I also have developed a bit more patience as I know learning more about an environment before I start advocating for infrastructure changes allows me to be better at my job.
During the interview process I brought up some of these items for discussion and asked when my manager thought would be an appropriate period of time was before we talked about implementing some changes and his answer was six months so in a sense I have a direct answer to this question.
BUT some of the changes I want to advocate for I feel are very important and that they deserve a timely implementation:
- 20% of their desktop fleet is still on Windows XP
- There is no consistent patch management of the fleet. Lots of stuff is not patched.
- There is no ticketing system or formal method for users to request assistance
I think I can advocate that these projects should be started on now and not in six months (in my opinion they should have been started on a year or two ago). The organization is pretty flat, relatively receptive to information or suggestions being pushed "upstream" and agile. The company's market is not in technology and their IT infrastructure is in a support role not a product role.
We have another System Administrator who is my peer and we both report to an IT Manager whose primarily field of experience is development and not operations. The whole department reports to the Operations Manager who is direct report of the owner. The IT Manager is retiring soon (six months to a year) and it is not clear how that transition will be handled yet. I have a pretty large degree of independence but ultimately at this point I think the decision-making capability does not rest me. I would feel unconformable just making decisions without having the IT Manager and Operations Manager confirm them.
Should I advocate for these projects now? Or wait six months? Should I wait a shorter period of time? How can you determine when it's appropriate to start advocating for changes in a new job?
new-job company-culture
edited Apr 27 '14 at 14:58
René Roth
439411
asked Apr 26 '14 at 22:45
kce
1,1491214
edited Apr 27 '14 at 14:58
René Roth
439411
edited Apr 27 '14 at 14:58
René Roth
439411
edited Apr 27 '14 at 14:58
René Roth
439411
439411
asked Apr 26 '14 at 22:45
kce
1,1491214
asked Apr 26 '14 at 22:45
kce
1,1491214
asked Apr 26 '14 at 22:45
kce
1,1491214
1,1491214
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
2
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20
 |Â
show 2 more comments
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
2
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
2
2
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20
 |Â
show 2 more comments
4 Answers
4
active
oldest
votes
up vote
24
down vote
accepted
I suggest 3-6 months, with one exception... This is mainly to learn the existing processes and environment (no matter how flawed they may be), and to earn the trust of the existing staff.
The exception to this rule is if you're specifically hired to solve an existing problem (e.g. "help us implement VMware" or "design a new HIPAA-compliant infrastructure"). Additionally, if you have a mandate to make the required changes, it's okay to try to get buy-in earlier than the 3-6 months.
I'm a systems administrator on occasion. I've definitely made the mistake of going into an environment with "guns blazing" and losing the buy-in of peers, despite gaining C-level support. I got my way, but lost the trust of the support staff. Those jobs lasted 2 weeks and 4 months. Not good.
I've also waited to make suggestions after the 3-6 month period with mixed results. It was a good way to test the company. If all goes well, and your voice is heard, the credibility goes a long way. If the firm is not open to change or improving processes, that's a good time to plan an exit. That unwillingness or deep tribal knowledge says a lot about the culture and company values.
Additional notes:
When it comes time to make suggestions, please have a solution along with your proposal. Saying something like, "this server equipment is inferior" is much different than, "I have evidence that we can improve stability and uptime by replacing our existing equipment with this particular make|brand|model".
Also, try to frame your IT arguments in terms of the business impact and bottom-line instead of geeking-out on the technology. Many decision makers view IT personnel as tech-nerds, and are likely to dismiss arguments that only focus on the technology side.
And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
edited Apr 13 '17 at 12:14
Community♦
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
add a comment |Â
up vote
33
down vote
Great Question. Being new, while learning everything about the environment, I would begin by asking questions at least for the first six months as recommended by your manager. I'll specifically take the XP situation as an example, but this can apply to anything you feel could be improved.
1. Learn why things are the way they are
For example, while you're learning the environment, start off with
- Why is so much of the environment still running XP?
You may or may not receive a good answer in return. Obsolete/Unmaintained/expensive-to-upgrade software sometimes plays a part, but that is information essential to your plan for upgrading, should you just to make one (and a great sysadmin would!).
Sometimes things are the way they are because it worked in a pinch and there was either no need to change it, no time, or a combination of the two. Knowing why something was implemented will also help you when suggesting change because any change must solve that problem. Also, by digging deeper, you may even find that the problem might not even exist anymore, which is an added bonus.
2. Make a valid case for change
This involves taking the information from step 1, listing pros and cons of both the current situation and your proposed change. Not having a plan and just suggesting a change makes us sometimes come off as
- Randomly complaining
- Wanting to 'change' the environment to be the way it was at $job-1 (making us seem unflexible)
These may or may not be true, but perception is important. For this reason, make a plan! Now that you have the pros and cons of both, make a plan for change. How the current way will be phased out, and how the new thing will be phased in. For a ticketing system, you may have to phase out (or greatly reduce) people stopping you in the hallway, emailing you personally, calling you, etc., and have them instead go through the single point of contact for their needs. This won't happen overnight if they're used to something different. However, a pro of this is that their requests are handled in a much more efficient manner, taken seriously, and there's less chance of someone 'forgetting something'.
How long to wait?
Now, to finally answer your question, I don't have an exact answer! My answer is after you have done the first two steps well, then propose the change. Your job is to keep the wheels turning, or if you prefer, keep the plumbing working. If you notice a pipe can be run better a different way, after two days on the job, start working on a plan to make it better, not just complain about it or emptily saying it needs changing. Some people who are used to doing things a certain way will resist, and think you are changing things for the sake of change, but you can help what people think, so you shouldn't let that stop or impede you.
answered Apr 26 '14 at 23:13
MDMoore313
760512
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
add a comment |Â
up vote
5
down vote
It is important to be perceived by your coworkers as an ally. They might not know that they need the improvements you are bringing to the office, but surely you do, because you are the person technically equipped to notice that.
However, I would not make great changes just now, though. My strategy would be as follows:
- define a timeline of achievable tasks in the short term (in this case, six months).
- start working as soon as possible in the improvements defined in the previous step. For example, you might have already at your disposal the resources to provide an automated installation server, or a centralized identity manager, or a System Center Configuration Manager. Choose only one task.
- when you feel you have everything you need to deploy a substantial change, notify your direct supervisor, explain to her what you have been doing, and propose a date to test the new service with a reduced target group. Explain the technical, economical or any other benefits this change provides.
- use the reduced target group of your first experiment to measure the team's resistance to change.
- because the new implementation of XYZ is going to be successful, you will have a positive feedback that will ease the path for further improvements.
- share with your supervisor the rest of the scheduled tasks you have in mind for the following six months.
In short, take advantage of the time you need to prepare for a substantial change (documentation, design, actual implementation, ...); start working now, but delay the actual changes to a point in the future, that allows your supervisor to be aware of them beforehand.
answered Apr 26 '14 at 23:30
dawud
19929
add a comment |Â
up vote
1
down vote
As a sysadmin in a similar-sized company (it's actually quite a parallel environment-wise), it's important to remember that while change is very difficult for some people take, a little push goes a long way.
Independence is a big deal since you can explore various ways of improving IT without all the red tape involved. Experimenting with changes, documenting your findings, then presenting them to the people who make the decisions is the proper way to go. Including your co-workers who will be dealing with these changes in discussions about what they'd like to see improved and understanding the current environment will help decide what and when to make changes.
answered Apr 27 '14 at 1:35
Nathan C
1396
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
24
down vote
accepted
I suggest 3-6 months, with one exception... This is mainly to learn the existing processes and environment (no matter how flawed they may be), and to earn the trust of the existing staff.
The exception to this rule is if you're specifically hired to solve an existing problem (e.g. "help us implement VMware" or "design a new HIPAA-compliant infrastructure"). Additionally, if you have a mandate to make the required changes, it's okay to try to get buy-in earlier than the 3-6 months.
I'm a systems administrator on occasion. I've definitely made the mistake of going into an environment with "guns blazing" and losing the buy-in of peers, despite gaining C-level support. I got my way, but lost the trust of the support staff. Those jobs lasted 2 weeks and 4 months. Not good.
I've also waited to make suggestions after the 3-6 month period with mixed results. It was a good way to test the company. If all goes well, and your voice is heard, the credibility goes a long way. If the firm is not open to change or improving processes, that's a good time to plan an exit. That unwillingness or deep tribal knowledge says a lot about the culture and company values.
Additional notes:
When it comes time to make suggestions, please have a solution along with your proposal. Saying something like, "this server equipment is inferior" is much different than, "I have evidence that we can improve stability and uptime by replacing our existing equipment with this particular make|brand|model".
Also, try to frame your IT arguments in terms of the business impact and bottom-line instead of geeking-out on the technology. Many decision makers view IT personnel as tech-nerds, and are likely to dismiss arguments that only focus on the technology side.
And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
edited Apr 13 '17 at 12:14
Community♦
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
add a comment |Â
up vote
24
down vote
accepted
I suggest 3-6 months, with one exception... This is mainly to learn the existing processes and environment (no matter how flawed they may be), and to earn the trust of the existing staff.
The exception to this rule is if you're specifically hired to solve an existing problem (e.g. "help us implement VMware" or "design a new HIPAA-compliant infrastructure"). Additionally, if you have a mandate to make the required changes, it's okay to try to get buy-in earlier than the 3-6 months.
I'm a systems administrator on occasion. I've definitely made the mistake of going into an environment with "guns blazing" and losing the buy-in of peers, despite gaining C-level support. I got my way, but lost the trust of the support staff. Those jobs lasted 2 weeks and 4 months. Not good.
I've also waited to make suggestions after the 3-6 month period with mixed results. It was a good way to test the company. If all goes well, and your voice is heard, the credibility goes a long way. If the firm is not open to change or improving processes, that's a good time to plan an exit. That unwillingness or deep tribal knowledge says a lot about the culture and company values.
Additional notes:
When it comes time to make suggestions, please have a solution along with your proposal. Saying something like, "this server equipment is inferior" is much different than, "I have evidence that we can improve stability and uptime by replacing our existing equipment with this particular make|brand|model".
Also, try to frame your IT arguments in terms of the business impact and bottom-line instead of geeking-out on the technology. Many decision makers view IT personnel as tech-nerds, and are likely to dismiss arguments that only focus on the technology side.
And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
edited Apr 13 '17 at 12:14
Community♦
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
add a comment |Â
up vote
24
down vote
accepted
up vote
24
down vote
accepted
I suggest 3-6 months, with one exception... This is mainly to learn the existing processes and environment (no matter how flawed they may be), and to earn the trust of the existing staff.
The exception to this rule is if you're specifically hired to solve an existing problem (e.g. "help us implement VMware" or "design a new HIPAA-compliant infrastructure"). Additionally, if you have a mandate to make the required changes, it's okay to try to get buy-in earlier than the 3-6 months.
I'm a systems administrator on occasion. I've definitely made the mistake of going into an environment with "guns blazing" and losing the buy-in of peers, despite gaining C-level support. I got my way, but lost the trust of the support staff. Those jobs lasted 2 weeks and 4 months. Not good.
I've also waited to make suggestions after the 3-6 month period with mixed results. It was a good way to test the company. If all goes well, and your voice is heard, the credibility goes a long way. If the firm is not open to change or improving processes, that's a good time to plan an exit. That unwillingness or deep tribal knowledge says a lot about the culture and company values.
Additional notes:
When it comes time to make suggestions, please have a solution along with your proposal. Saying something like, "this server equipment is inferior" is much different than, "I have evidence that we can improve stability and uptime by replacing our existing equipment with this particular make|brand|model".
Also, try to frame your IT arguments in terms of the business impact and bottom-line instead of geeking-out on the technology. Many decision makers view IT personnel as tech-nerds, and are likely to dismiss arguments that only focus on the technology side.
And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
edited Apr 13 '17 at 12:14
Community♦
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
I suggest 3-6 months, with one exception... This is mainly to learn the existing processes and environment (no matter how flawed they may be), and to earn the trust of the existing staff.
The exception to this rule is if you're specifically hired to solve an existing problem (e.g. "help us implement VMware" or "design a new HIPAA-compliant infrastructure"). Additionally, if you have a mandate to make the required changes, it's okay to try to get buy-in earlier than the 3-6 months.
I'm a systems administrator on occasion. I've definitely made the mistake of going into an environment with "guns blazing" and losing the buy-in of peers, despite gaining C-level support. I got my way, but lost the trust of the support staff. Those jobs lasted 2 weeks and 4 months. Not good.
I've also waited to make suggestions after the 3-6 month period with mixed results. It was a good way to test the company. If all goes well, and your voice is heard, the credibility goes a long way. If the firm is not open to change or improving processes, that's a good time to plan an exit. That unwillingness or deep tribal knowledge says a lot about the culture and company values.
Additional notes:
When it comes time to make suggestions, please have a solution along with your proposal. Saying something like, "this server equipment is inferior" is much different than, "I have evidence that we can improve stability and uptime by replacing our existing equipment with this particular make|brand|model".
Also, try to frame your IT arguments in terms of the business impact and bottom-line instead of geeking-out on the technology. Many decision makers view IT personnel as tech-nerds, and are likely to dismiss arguments that only focus on the technology side.
And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
edited Apr 13 '17 at 12:14
Community♦
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
edited Apr 13 '17 at 12:14
Community♦
1
edited Apr 13 '17 at 12:14
Community♦
1
edited Apr 13 '17 at 12:14
Community♦
1
1
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
answered Apr 26 '14 at 23:26
ewwhite
1,48711017
1,48711017
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
add a comment |Â
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
+1 for "if you're specifically hired to solve an existing problem." Driving change isn't easy, but it is easier if the one who hired you wants you to do it.
– O. Jones
Apr 27 '14 at 13:49
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
@OllieJones: Even then I think "Learn why things are the way they are" mentioned in BigHomies answer is mandatory too.
– PlasmaHH
Apr 27 '14 at 20:35
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
+1 And $$$ (or £££) is king! If you can save money or reduce costs with a solution while improving aspects of the above, you'll have a much easier time in life :)
– Chethan S.
Apr 30 '14 at 4:48
add a comment |Â
up vote
33
down vote
Great Question. Being new, while learning everything about the environment, I would begin by asking questions at least for the first six months as recommended by your manager. I'll specifically take the XP situation as an example, but this can apply to anything you feel could be improved.
1. Learn why things are the way they are
For example, while you're learning the environment, start off with
- Why is so much of the environment still running XP?
You may or may not receive a good answer in return. Obsolete/Unmaintained/expensive-to-upgrade software sometimes plays a part, but that is information essential to your plan for upgrading, should you just to make one (and a great sysadmin would!).
Sometimes things are the way they are because it worked in a pinch and there was either no need to change it, no time, or a combination of the two. Knowing why something was implemented will also help you when suggesting change because any change must solve that problem. Also, by digging deeper, you may even find that the problem might not even exist anymore, which is an added bonus.
2. Make a valid case for change
This involves taking the information from step 1, listing pros and cons of both the current situation and your proposed change. Not having a plan and just suggesting a change makes us sometimes come off as
- Randomly complaining
- Wanting to 'change' the environment to be the way it was at $job-1 (making us seem unflexible)
These may or may not be true, but perception is important. For this reason, make a plan! Now that you have the pros and cons of both, make a plan for change. How the current way will be phased out, and how the new thing will be phased in. For a ticketing system, you may have to phase out (or greatly reduce) people stopping you in the hallway, emailing you personally, calling you, etc., and have them instead go through the single point of contact for their needs. This won't happen overnight if they're used to something different. However, a pro of this is that their requests are handled in a much more efficient manner, taken seriously, and there's less chance of someone 'forgetting something'.
How long to wait?
Now, to finally answer your question, I don't have an exact answer! My answer is after you have done the first two steps well, then propose the change. Your job is to keep the wheels turning, or if you prefer, keep the plumbing working. If you notice a pipe can be run better a different way, after two days on the job, start working on a plan to make it better, not just complain about it or emptily saying it needs changing. Some people who are used to doing things a certain way will resist, and think you are changing things for the sake of change, but you can help what people think, so you shouldn't let that stop or impede you.
answered Apr 26 '14 at 23:13
MDMoore313
760512
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
add a comment |Â
up vote
33
down vote
Great Question. Being new, while learning everything about the environment, I would begin by asking questions at least for the first six months as recommended by your manager. I'll specifically take the XP situation as an example, but this can apply to anything you feel could be improved.
1. Learn why things are the way they are
For example, while you're learning the environment, start off with
- Why is so much of the environment still running XP?
You may or may not receive a good answer in return. Obsolete/Unmaintained/expensive-to-upgrade software sometimes plays a part, but that is information essential to your plan for upgrading, should you just to make one (and a great sysadmin would!).
Sometimes things are the way they are because it worked in a pinch and there was either no need to change it, no time, or a combination of the two. Knowing why something was implemented will also help you when suggesting change because any change must solve that problem. Also, by digging deeper, you may even find that the problem might not even exist anymore, which is an added bonus.
2. Make a valid case for change
This involves taking the information from step 1, listing pros and cons of both the current situation and your proposed change. Not having a plan and just suggesting a change makes us sometimes come off as
- Randomly complaining
- Wanting to 'change' the environment to be the way it was at $job-1 (making us seem unflexible)
These may or may not be true, but perception is important. For this reason, make a plan! Now that you have the pros and cons of both, make a plan for change. How the current way will be phased out, and how the new thing will be phased in. For a ticketing system, you may have to phase out (or greatly reduce) people stopping you in the hallway, emailing you personally, calling you, etc., and have them instead go through the single point of contact for their needs. This won't happen overnight if they're used to something different. However, a pro of this is that their requests are handled in a much more efficient manner, taken seriously, and there's less chance of someone 'forgetting something'.
How long to wait?
Now, to finally answer your question, I don't have an exact answer! My answer is after you have done the first two steps well, then propose the change. Your job is to keep the wheels turning, or if you prefer, keep the plumbing working. If you notice a pipe can be run better a different way, after two days on the job, start working on a plan to make it better, not just complain about it or emptily saying it needs changing. Some people who are used to doing things a certain way will resist, and think you are changing things for the sake of change, but you can help what people think, so you shouldn't let that stop or impede you.
answered Apr 26 '14 at 23:13
MDMoore313
760512
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
add a comment |Â
up vote
33
down vote
up vote
33
down vote
Great Question. Being new, while learning everything about the environment, I would begin by asking questions at least for the first six months as recommended by your manager. I'll specifically take the XP situation as an example, but this can apply to anything you feel could be improved.
1. Learn why things are the way they are
For example, while you're learning the environment, start off with
- Why is so much of the environment still running XP?
You may or may not receive a good answer in return. Obsolete/Unmaintained/expensive-to-upgrade software sometimes plays a part, but that is information essential to your plan for upgrading, should you just to make one (and a great sysadmin would!).
Sometimes things are the way they are because it worked in a pinch and there was either no need to change it, no time, or a combination of the two. Knowing why something was implemented will also help you when suggesting change because any change must solve that problem. Also, by digging deeper, you may even find that the problem might not even exist anymore, which is an added bonus.
2. Make a valid case for change
This involves taking the information from step 1, listing pros and cons of both the current situation and your proposed change. Not having a plan and just suggesting a change makes us sometimes come off as
- Randomly complaining
- Wanting to 'change' the environment to be the way it was at $job-1 (making us seem unflexible)
These may or may not be true, but perception is important. For this reason, make a plan! Now that you have the pros and cons of both, make a plan for change. How the current way will be phased out, and how the new thing will be phased in. For a ticketing system, you may have to phase out (or greatly reduce) people stopping you in the hallway, emailing you personally, calling you, etc., and have them instead go through the single point of contact for their needs. This won't happen overnight if they're used to something different. However, a pro of this is that their requests are handled in a much more efficient manner, taken seriously, and there's less chance of someone 'forgetting something'.
How long to wait?
Now, to finally answer your question, I don't have an exact answer! My answer is after you have done the first two steps well, then propose the change. Your job is to keep the wheels turning, or if you prefer, keep the plumbing working. If you notice a pipe can be run better a different way, after two days on the job, start working on a plan to make it better, not just complain about it or emptily saying it needs changing. Some people who are used to doing things a certain way will resist, and think you are changing things for the sake of change, but you can help what people think, so you shouldn't let that stop or impede you.
answered Apr 26 '14 at 23:13
MDMoore313
760512
Great Question. Being new, while learning everything about the environment, I would begin by asking questions at least for the first six months as recommended by your manager. I'll specifically take the XP situation as an example, but this can apply to anything you feel could be improved.
1. Learn why things are the way they are
For example, while you're learning the environment, start off with
- Why is so much of the environment still running XP?
You may or may not receive a good answer in return. Obsolete/Unmaintained/expensive-to-upgrade software sometimes plays a part, but that is information essential to your plan for upgrading, should you just to make one (and a great sysadmin would!).
Sometimes things are the way they are because it worked in a pinch and there was either no need to change it, no time, or a combination of the two. Knowing why something was implemented will also help you when suggesting change because any change must solve that problem. Also, by digging deeper, you may even find that the problem might not even exist anymore, which is an added bonus.
2. Make a valid case for change
This involves taking the information from step 1, listing pros and cons of both the current situation and your proposed change. Not having a plan and just suggesting a change makes us sometimes come off as
- Randomly complaining
- Wanting to 'change' the environment to be the way it was at $job-1 (making us seem unflexible)
These may or may not be true, but perception is important. For this reason, make a plan! Now that you have the pros and cons of both, make a plan for change. How the current way will be phased out, and how the new thing will be phased in. For a ticketing system, you may have to phase out (or greatly reduce) people stopping you in the hallway, emailing you personally, calling you, etc., and have them instead go through the single point of contact for their needs. This won't happen overnight if they're used to something different. However, a pro of this is that their requests are handled in a much more efficient manner, taken seriously, and there's less chance of someone 'forgetting something'.
How long to wait?
Now, to finally answer your question, I don't have an exact answer! My answer is after you have done the first two steps well, then propose the change. Your job is to keep the wheels turning, or if you prefer, keep the plumbing working. If you notice a pipe can be run better a different way, after two days on the job, start working on a plan to make it better, not just complain about it or emptily saying it needs changing. Some people who are used to doing things a certain way will resist, and think you are changing things for the sake of change, but you can help what people think, so you shouldn't let that stop or impede you.
answered Apr 26 '14 at 23:13
MDMoore313
760512
answered Apr 26 '14 at 23:13
MDMoore313
760512
answered Apr 26 '14 at 23:13
MDMoore313
760512
answered Apr 26 '14 at 23:13
MDMoore313
760512
760512
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
add a comment |Â
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
11
11
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
"Learn why things are the way they are" +1
– Guido Preite
Apr 26 '14 at 23:20
3
3
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
Item 1 is important. I hate it when people start bashing the way we work before they understand why we work that way. In some cases it's because we are lazy and haven't bother with fixing things that aren't broken, but most of the times there's a legitimate reason for doing things the way we do or using the tools we use.
– Fredrik
Apr 28 '14 at 7:43
4
4
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
@Fredrik Yes, the reason is usually Technical Debt ;)
– ewwhite
Apr 28 '14 at 13:17
add a comment |Â
up vote
5
down vote
It is important to be perceived by your coworkers as an ally. They might not know that they need the improvements you are bringing to the office, but surely you do, because you are the person technically equipped to notice that.
However, I would not make great changes just now, though. My strategy would be as follows:
- define a timeline of achievable tasks in the short term (in this case, six months).
- start working as soon as possible in the improvements defined in the previous step. For example, you might have already at your disposal the resources to provide an automated installation server, or a centralized identity manager, or a System Center Configuration Manager. Choose only one task.
- when you feel you have everything you need to deploy a substantial change, notify your direct supervisor, explain to her what you have been doing, and propose a date to test the new service with a reduced target group. Explain the technical, economical or any other benefits this change provides.
- use the reduced target group of your first experiment to measure the team's resistance to change.
- because the new implementation of XYZ is going to be successful, you will have a positive feedback that will ease the path for further improvements.
- share with your supervisor the rest of the scheduled tasks you have in mind for the following six months.
In short, take advantage of the time you need to prepare for a substantial change (documentation, design, actual implementation, ...); start working now, but delay the actual changes to a point in the future, that allows your supervisor to be aware of them beforehand.
answered Apr 26 '14 at 23:30
dawud
19929
add a comment |Â
up vote
5
down vote
It is important to be perceived by your coworkers as an ally. They might not know that they need the improvements you are bringing to the office, but surely you do, because you are the person technically equipped to notice that.
However, I would not make great changes just now, though. My strategy would be as follows:
- define a timeline of achievable tasks in the short term (in this case, six months).
- start working as soon as possible in the improvements defined in the previous step. For example, you might have already at your disposal the resources to provide an automated installation server, or a centralized identity manager, or a System Center Configuration Manager. Choose only one task.
- when you feel you have everything you need to deploy a substantial change, notify your direct supervisor, explain to her what you have been doing, and propose a date to test the new service with a reduced target group. Explain the technical, economical or any other benefits this change provides.
- use the reduced target group of your first experiment to measure the team's resistance to change.
- because the new implementation of XYZ is going to be successful, you will have a positive feedback that will ease the path for further improvements.
- share with your supervisor the rest of the scheduled tasks you have in mind for the following six months.
In short, take advantage of the time you need to prepare for a substantial change (documentation, design, actual implementation, ...); start working now, but delay the actual changes to a point in the future, that allows your supervisor to be aware of them beforehand.
answered Apr 26 '14 at 23:30
dawud
19929
add a comment |Â
up vote
5
down vote
up vote
5
down vote
It is important to be perceived by your coworkers as an ally. They might not know that they need the improvements you are bringing to the office, but surely you do, because you are the person technically equipped to notice that.
However, I would not make great changes just now, though. My strategy would be as follows:
- define a timeline of achievable tasks in the short term (in this case, six months).
- start working as soon as possible in the improvements defined in the previous step. For example, you might have already at your disposal the resources to provide an automated installation server, or a centralized identity manager, or a System Center Configuration Manager. Choose only one task.
- when you feel you have everything you need to deploy a substantial change, notify your direct supervisor, explain to her what you have been doing, and propose a date to test the new service with a reduced target group. Explain the technical, economical or any other benefits this change provides.
- use the reduced target group of your first experiment to measure the team's resistance to change.
- because the new implementation of XYZ is going to be successful, you will have a positive feedback that will ease the path for further improvements.
- share with your supervisor the rest of the scheduled tasks you have in mind for the following six months.
In short, take advantage of the time you need to prepare for a substantial change (documentation, design, actual implementation, ...); start working now, but delay the actual changes to a point in the future, that allows your supervisor to be aware of them beforehand.
answered Apr 26 '14 at 23:30
dawud
19929
It is important to be perceived by your coworkers as an ally. They might not know that they need the improvements you are bringing to the office, but surely you do, because you are the person technically equipped to notice that.
However, I would not make great changes just now, though. My strategy would be as follows:
- define a timeline of achievable tasks in the short term (in this case, six months).
- start working as soon as possible in the improvements defined in the previous step. For example, you might have already at your disposal the resources to provide an automated installation server, or a centralized identity manager, or a System Center Configuration Manager. Choose only one task.
- when you feel you have everything you need to deploy a substantial change, notify your direct supervisor, explain to her what you have been doing, and propose a date to test the new service with a reduced target group. Explain the technical, economical or any other benefits this change provides.
- use the reduced target group of your first experiment to measure the team's resistance to change.
- because the new implementation of XYZ is going to be successful, you will have a positive feedback that will ease the path for further improvements.
- share with your supervisor the rest of the scheduled tasks you have in mind for the following six months.
In short, take advantage of the time you need to prepare for a substantial change (documentation, design, actual implementation, ...); start working now, but delay the actual changes to a point in the future, that allows your supervisor to be aware of them beforehand.
answered Apr 26 '14 at 23:30
dawud
19929
answered Apr 26 '14 at 23:30
dawud
19929
answered Apr 26 '14 at 23:30
dawud
19929
answered Apr 26 '14 at 23:30
dawud
19929
19929
add a comment |Â
add a comment |Â
up vote
1
down vote
As a sysadmin in a similar-sized company (it's actually quite a parallel environment-wise), it's important to remember that while change is very difficult for some people take, a little push goes a long way.
Independence is a big deal since you can explore various ways of improving IT without all the red tape involved. Experimenting with changes, documenting your findings, then presenting them to the people who make the decisions is the proper way to go. Including your co-workers who will be dealing with these changes in discussions about what they'd like to see improved and understanding the current environment will help decide what and when to make changes.
answered Apr 27 '14 at 1:35
Nathan C
1396
add a comment |Â
up vote
1
down vote
As a sysadmin in a similar-sized company (it's actually quite a parallel environment-wise), it's important to remember that while change is very difficult for some people take, a little push goes a long way.
Independence is a big deal since you can explore various ways of improving IT without all the red tape involved. Experimenting with changes, documenting your findings, then presenting them to the people who make the decisions is the proper way to go. Including your co-workers who will be dealing with these changes in discussions about what they'd like to see improved and understanding the current environment will help decide what and when to make changes.
answered Apr 27 '14 at 1:35
Nathan C
1396
add a comment |Â
up vote
1
down vote
up vote
1
down vote
As a sysadmin in a similar-sized company (it's actually quite a parallel environment-wise), it's important to remember that while change is very difficult for some people take, a little push goes a long way.
Independence is a big deal since you can explore various ways of improving IT without all the red tape involved. Experimenting with changes, documenting your findings, then presenting them to the people who make the decisions is the proper way to go. Including your co-workers who will be dealing with these changes in discussions about what they'd like to see improved and understanding the current environment will help decide what and when to make changes.
answered Apr 27 '14 at 1:35
Nathan C
1396
As a sysadmin in a similar-sized company (it's actually quite a parallel environment-wise), it's important to remember that while change is very difficult for some people take, a little push goes a long way.
Independence is a big deal since you can explore various ways of improving IT without all the red tape involved. Experimenting with changes, documenting your findings, then presenting them to the people who make the decisions is the proper way to go. Including your co-workers who will be dealing with these changes in discussions about what they'd like to see improved and understanding the current environment will help decide what and when to make changes.
answered Apr 27 '14 at 1:35
Nathan C
1396
answered Apr 27 '14 at 1:35
Nathan C
1396
answered Apr 27 '14 at 1:35
Nathan C
1396
answered Apr 27 '14 at 1:35
Nathan C
1396
1396
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f23220%2fhow-soon-should-i-advocate-for-making-changes-after-starting-in-a-new-job%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Have you asked around to find out why the environment is how it is? maybe there is a piece of software that only runs on XP that needs to be rewritten or replaced. Maybe there is already a plan under way to phase out xp. Maybe some systems are under strict requirements or regulations to not patch because patches do break software. Maybe management wants an informal interaction between IT and the rest of the company and doesn't want an externally facing ticketing system to get in the way.
– atk
Apr 26 '14 at 22:59
@atk - I have asked around and there are reasons that those changes haven't been implemented but I think the reasons are more appropriate to when the business was smaller. I don't necessarily want to get into the why or how of supporting those projects in this question (trying to keep the scope narrow). I'm more interested in when it's appropriate to start advocating for change without coming off as the "new sheriff in town".
– kce
Apr 26 '14 at 23:03
2
Each of the changes you want to make requires time and resources and as such, needs buy-in from your management. You can prepare/submit an improvement proposal including the business rationale for the proposal, and you can develop that proposal into a plan if management is interested in taking it further. As a new hire, you bring new insight as an outsider to the situation and in that respect, you can't avoid being perceived as the new sheriff in town. But you can largely mitigate the negative aspect of that perception by being willing to work through the hierarchy and being open to feedback.
– Vietnhi Phuvan
Apr 27 '14 at 10:58
For the specific projects you mention, getting rid of XP should be easy to motivate to management on security grounds and it's not an issue of "making changes" but just doing your job. Likewise, you should be able to get patches up to date as a routine part of doing your job; setting up a system to keep things that way can be done as a later project.
– David Richerby
Apr 27 '14 at 12:10
possible duplicate of How can I get co-workers to buy into some of my ideas?
– gnat
Apr 27 '14 at 21:20