Should I propose a big change as a newcomer?

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
16
down vote

favorite

6

I have been working in the IT department of a (relatively) small company for 2 months.

Recently the boss of another department (who is a former developer) told me that it would be nice if we started using some modern programming methodologies like automated tests and continuous integration. Since I am the only one who has some experience in the subject, he proposed me to give some presentations to my colleagues and to try to introduce the concepts to my team. However, since he belongs to another department, his word has no "official" value. I would need to propose these changes myself to my boss.

I am worried for two reasons:

1. These are big changes. Writing automated tests for legacy code is a slow and difficult task.




2. These methodologies require a certain discipline. As a newcomer, it will be hard to enforce this discipline to the whole team. If my boss only gives me half-hearted support, I am afraid I can find myself in an unpleasant situation with my senior colleagues.

Being the only "knowledge-holder" is a double-edged sword. It would make me precious, but it would also give me a big responsibility, maybe too much after just 2 months here.

What do you suggest?

software-industry management communication new-job

share|improve this question

edited Apr 3 '13 at 14:58

gnat

3,23273066

asked Apr 3 '13 at 12:29

lortabac

1865

• 
  
  
  

  
  

  
  
  
  
  
  

  
  What job title do you hold in the IT department? Developer, Senior etc..?
  – NikolaiDante
  Apr 3 '13 at 12:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
  – lortabac
  Apr 3 '13 at 12:38
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
  – Rhys
  Apr 3 '13 at 13:15
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
  – Rhys
  Apr 3 '13 at 15:23
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have you talked with your teammates about considering these changes?
  – JB King
  Apr 3 '13 at 15:55
  

  
  
  
  

 | 
show 5 more comments

up vote
16
down vote

favorite

6

I have been working in the IT department of a (relatively) small company for 2 months.

Recently the boss of another department (who is a former developer) told me that it would be nice if we started using some modern programming methodologies like automated tests and continuous integration. Since I am the only one who has some experience in the subject, he proposed me to give some presentations to my colleagues and to try to introduce the concepts to my team. However, since he belongs to another department, his word has no "official" value. I would need to propose these changes myself to my boss.

I am worried for two reasons:

1. These are big changes. Writing automated tests for legacy code is a slow and difficult task.




2. These methodologies require a certain discipline. As a newcomer, it will be hard to enforce this discipline to the whole team. If my boss only gives me half-hearted support, I am afraid I can find myself in an unpleasant situation with my senior colleagues.

Being the only "knowledge-holder" is a double-edged sword. It would make me precious, but it would also give me a big responsibility, maybe too much after just 2 months here.

What do you suggest?

software-industry management communication new-job

share|improve this question

edited Apr 3 '13 at 14:58

gnat

3,23273066

asked Apr 3 '13 at 12:29

lortabac

1865

• 
  
  
  

  
  

  
  
  
  
  
  

  
  What job title do you hold in the IT department? Developer, Senior etc..?
  – NikolaiDante
  Apr 3 '13 at 12:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
  – lortabac
  Apr 3 '13 at 12:38
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
  – Rhys
  Apr 3 '13 at 13:15
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
  – Rhys
  Apr 3 '13 at 15:23
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have you talked with your teammates about considering these changes?
  – JB King
  Apr 3 '13 at 15:55
  

  
  
  
  

 | 
show 5 more comments

up vote
16
down vote

favorite

6

up vote
16
down vote

favorite

6

6

I have been working in the IT department of a (relatively) small company for 2 months.

Recently the boss of another department (who is a former developer) told me that it would be nice if we started using some modern programming methodologies like automated tests and continuous integration. Since I am the only one who has some experience in the subject, he proposed me to give some presentations to my colleagues and to try to introduce the concepts to my team. However, since he belongs to another department, his word has no "official" value. I would need to propose these changes myself to my boss.

I am worried for two reasons:

1. These are big changes. Writing automated tests for legacy code is a slow and difficult task.




2. These methodologies require a certain discipline. As a newcomer, it will be hard to enforce this discipline to the whole team. If my boss only gives me half-hearted support, I am afraid I can find myself in an unpleasant situation with my senior colleagues.

Being the only "knowledge-holder" is a double-edged sword. It would make me precious, but it would also give me a big responsibility, maybe too much after just 2 months here.

What do you suggest?

software-industry management communication new-job

share|improve this question

edited Apr 3 '13 at 14:58

gnat

3,23273066

asked Apr 3 '13 at 12:29

lortabac

1865

I have been working in the IT department of a (relatively) small company for 2 months.

Recently the boss of another department (who is a former developer) told me that it would be nice if we started using some modern programming methodologies like automated tests and continuous integration. Since I am the only one who has some experience in the subject, he proposed me to give some presentations to my colleagues and to try to introduce the concepts to my team. However, since he belongs to another department, his word has no "official" value. I would need to propose these changes myself to my boss.

I am worried for two reasons:

1. These are big changes. Writing automated tests for legacy code is a slow and difficult task.




2. These methodologies require a certain discipline. As a newcomer, it will be hard to enforce this discipline to the whole team. If my boss only gives me half-hearted support, I am afraid I can find myself in an unpleasant situation with my senior colleagues.

Being the only "knowledge-holder" is a double-edged sword. It would make me precious, but it would also give me a big responsibility, maybe too much after just 2 months here.

What do you suggest?

software-industry management communication new-job

share|improve this question

edited Apr 3 '13 at 14:58

gnat

3,23273066

asked Apr 3 '13 at 12:29

lortabac

1865

share|improve this question

share|improve this question

edited Apr 3 '13 at 14:58

gnat

3,23273066

edited Apr 3 '13 at 14:58

gnat

3,23273066

edited Apr 3 '13 at 14:58

gnat

3,23273066

3,23273066

asked Apr 3 '13 at 12:29

lortabac

1865

asked Apr 3 '13 at 12:29

lortabac

1865

asked Apr 3 '13 at 12:29

lortabac

1865

1865

• 
  
  
  

  
  

  
  
  
  
  
  

  
  What job title do you hold in the IT department? Developer, Senior etc..?
  – NikolaiDante
  Apr 3 '13 at 12:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
  – lortabac
  Apr 3 '13 at 12:38
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
  – Rhys
  Apr 3 '13 at 13:15
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
  – Rhys
  Apr 3 '13 at 15:23
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have you talked with your teammates about considering these changes?
  – JB King
  Apr 3 '13 at 15:55
  

  
  
  
  

 | 
show 5 more comments

• 
  
  
  

  
  

  
  
  
  
  
  

  
  What job title do you hold in the IT department? Developer, Senior etc..?
  – NikolaiDante
  Apr 3 '13 at 12:35
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
  – lortabac
  Apr 3 '13 at 12:38
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
  – Rhys
  Apr 3 '13 at 13:15
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
  – Rhys
  Apr 3 '13 at 15:23
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Have you talked with your teammates about considering these changes?
  – JB King
  Apr 3 '13 at 15:55
  

  
  
  
  

What job title do you hold in the IT department? Developer, Senior etc..?
– NikolaiDante
Apr 3 '13 at 12:35

What job title do you hold in the IT department? Developer, Senior etc..?
– NikolaiDante
Apr 3 '13 at 12:35

@NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
– lortabac
Apr 3 '13 at 12:38

@NikolaiDante Simply developer. There is no formal junior/senior difference, but there are developers who have been working here for almost 10 years.
– lortabac
Apr 3 '13 at 12:38

3

3

Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
– Rhys
Apr 3 '13 at 13:15

Whats slower and more painful, one time writing of automated tests, or 50 times, manual execution for an old legacy codebase trying to test one of your changes?
– Rhys
Apr 3 '13 at 13:15

1

1

One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
– Rhys
Apr 3 '13 at 15:23

One more question, i dont think being a new comer affects this question, its not you dont want to do it because youre new, but because you dont want it to become your responsibility, is this correct or not? If yes then we can edit the question to be more general and attract more answers
– Rhys
Apr 3 '13 at 15:23

Have you talked with your teammates about considering these changes?
– JB King
Apr 3 '13 at 15:55

Have you talked with your teammates about considering these changes?
– JB King
Apr 3 '13 at 15:55

 | 
show 5 more comments

8 Answers
8

active

oldest

votes

up vote
11
down vote



accepted

I wouldn't take the suggestion of the head of another department very seriously. I don't know why he talked to you and not your boss (or higher management), but it doesn't really sound right (there might even actually be a reason why he didn't talk to your boss directly). As you mentioned in your question, these changes are far from being trivial. They require serious planning and implementation, and such decisions can't be made on the run just because someone thinks it would be nice (even if that someone is an ex-developer-now-head-of-department).

Before taking any actions you should talk to your boss. Have a one-on-one conversation and tell your boss about this suggestion. Try to refrain showing any specific attitude (too anxious or enthusiastic). Tell about your confusion about this. This will help clarify the situation, as well as show your professionalism and attitude toward your job and your boss.

Edit: Some clarifications concerning the comments. What I mean is that you shouldn't dive into this task without first discussing it with your boss. I don't mean that you needn't make suggestions or try to improve anything _ its completely different from diving into a work that someone not quite authorized thinks you should do.

share|improve this answer

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
  – huntmaster
  Apr 3 '13 at 14:09
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Spoken like a true "Thats not how we do it here" stalwart.
  – IDrinkandIKnowThings
  Apr 3 '13 at 15:05
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
  – Rhys
  Apr 3 '13 at 15:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @RhysW, Please see my edit. I think you didn't get me right
  – superM
  Apr 3 '13 at 15:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
  – Rhys
  Apr 3 '13 at 15:31
  

  
  
  
  

 | 
show 1 more comment

up vote
3
down vote

The other answers have given a lot of good advice about when, whether, and how to make changes. But step back a bit: you are a newcomer to an organization, have been identified as having new knowledge, and have been asked to provide input.

The logical next step here is for you to give a presentation on the relevant technologies -- a "things I've learned" talk, in other words, just like the talk you would give to your coworkers after coming back from a conference where you learned a bunch of stuff. Making recommendations would be premature no matter how long you've been there; the first step in any consideration of change is education. You are in a position to educate. Do that first and then see what happens.

I've been at my current company for more than a decade. I've seen lots of people come in with new ideas, things that we weren't up on because that hasn't been our focus. The ones who come in and say "we need to do X" out of the gate have generally not gotten traction; on the other hand, the ones who have said "here's some stuff I've learned about X" have.

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

• 
  
  
  

  
  

  
  
  
  
  
  

  
  That's a sneaky, sneaky way of making people think in the necessary direction...
  – Deer Hunter
  May 6 '13 at 18:08
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
  – Monica Cellio♦
  May 7 '13 at 16:46
  

  
  
  
  

add a comment | 

up vote
2
down vote

I suggest bringing it up with your boss - specifically, ask about problems you (eventually) see. "Hey, why did our build break?" That gives your boss the opportunity to give you insight into the technical, business, and perhaps political stance of that particular issue.

If they wish it could be fixed, but don't know how, then suggest that its been dealt with via Continuous Integration in many companies.

If they dismiss it as nothing, maybe bite your tongue.

If they scowl and say 'you sound like the boss in that other department', then you know about the political minefield.

And in general, it's best to sell these things as 'best practice' solutions to problems, rather than change that you think should be done for the sake of change.

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
  – Rhys
  Apr 3 '13 at 15:08
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
  – Telastyn
  Apr 3 '13 at 15:52
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
  – Rhys
  Apr 3 '13 at 15:55
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
  – Telastyn
  Apr 3 '13 at 16:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are making a lot of assumptions based only off of your experiences, this isnt always true.
  – Rhys
  Apr 3 '13 at 17:02
  

  
  
  
  

 | 
show 1 more comment

up vote
2
down vote

Timing is critical in suggesting major changes. The first thing you need to do is have a good reputation with your current coworkers and boss. At two months you don't have a track record with them, I would wait until you do. Further changes are more likely to be accepted as the solution to a problem that is happening right this minute. So the time to suggest writing unit tests is right after something major broke on prod that could have been prevented if tests existed.

So write up your proposals in business terms (improved quality, lower costs, etc.) and hold onto it until the timing is right. Then bring them up. And remember, don't try to do too much at once. Pick the propossal most likely to be accepted as the first one you bring up. Having a success at a proposal gives you more credibility when you suggest the changes that are likely to be the hardest for others to accept.

Also start to find allies, other people who might be supportive of the changes you are interetsed in proposing. It is easier to get things accepted if the others are not fighting the idea. If you have people who have been there a long time, remember, they likely created the current system and they are invested in it. You will have to work harder to get them to accept change. Also do some reading about resistance to change. All organizations have this and it helps to understand it and understand why it occurs and how to politically deal with it.

share|improve this answer

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

add a comment | 

up vote
1
down vote

I would have suggested that this other department's manager take it up with your boss. If the head of another department wants your department to do something, it's not entirely appropriate to place the burden of decision on any member of your department (especially not a relatively new member such as yourself) outside of the department head/senior level manager.

share|improve this answer

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
  – acolyte
  Apr 3 '13 at 15:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
  – Rhys
  Apr 3 '13 at 15:57
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @RhysW ahh, I see then. I'll edit my answer.
  – acolyte
  Apr 3 '13 at 15:59
  

  
  
  
  

add a comment | 

up vote
1
down vote

Think 4 Moves Ahead

"A person is smart. People are dumb, panicky, dangerous animals and you know it."

While an individual may be a rational forward-looking tool for improvement, organizations usually aren't.

If you want to implement these improvements, the important question isn't to ask if you should propose these changes, but rather how to propose these changes with the best chance of success.

Perspective is Everything

Learning how is all about perspective. Who actually has the power to implement it? What horses do they have in the race? What is their goal? What are the potential problems they will face if they try to implement it?

These are the most important things to know, but they usually aren't apparent to people who just joined the organization. That's why lots of new employees who push for broad sweeping changes find themselves frustrated by the apparent irrationality of the system as a whole -- they can't see the rationality of each of the actors in that system.

Gaining Perspective vs. Gaining Trust

Not everyone cares about what their manager wants, or how the organization is set up, or how best to implement change that cuts across departments (it is really tedious work), so if gaining perspective isn't your thing, you can go the other route and try to gain trust.

Gaining trust of someone with the perspective means that they can form a partnership with you where they allow you to handle the technical side while they handle the politics side to implement the change. The key to building the trust is that you also need to trust the politically apt person with perspective as well, as you are limited in what you can do by what they can get the organization to accept.

So Should You Propose Change as a Newcomer?

This question is wholly dependent on two things:

1. Are you aiming for short term impact or long term success with this company?


2. Are you technically or politically gifted?

Short Term Impact

If you are technically oriented, then you can create something that works great as a side project to the extent that your boss is unable to deny its effectiveness. Many moons ago I worked in QA for some software, and wrote automated testing software that eliminated the need for me to do my job (I programmed my job out of existence). Your boss will have trouble saying that automated testing software is a bad idea when it has a proven track record for success.

If you are politically oriented, then you can spend a few weeks figuring out what your boss' role is in the organization, and how much he will let you get away with, and then ask him to allow you do to a side project within the realm you know he will let you do (as it won't cause harm to anyone else). This will allow you to create something you want to create, build trust with your boss, and allow you to build on it in the near future.

Long Term Impact

If you are going for long-term success, I wouldn't propose a big change. I would instead work on building trust (if technically oriented) or perspective (if politically oriented) so that I can leverage that to put myself in a position to make a bigger change later.

At Any Rate...

Beware political land mines. People from other departments suggesting you propose sweeping changes reeks of political opportunism and screams "Danger Will Robinson" to me. Talk to your manager and figure out what he's thinking. Like it or not, your manager is going to have a large impact on what change you can implement, and getting to understand him (or getting him to trust you) is a good idea.

At the same time, it's a bad idea to upset the manager in another group as well. So I'd be careful not to use this opportunity to get on your boss' good side by making that manager look bad.

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

add a comment | 

up vote
0
down vote

Unless you were brought specifically to make changes then I think it is way to soon for the new guy to be telling everyone how what they are doing is wrong. Many times when a company is doing something that the conventional wisdom believes is wrong, it turns out there are valid reasons for doing it that way. If you don't know the history of how things got to where they are and it turns out that change is not really practical because of company/project specific isses then it makes you lose credibility at precisely the time you are supposed to be building your credibility.

My advice to anyone who is new is to first watch, listen, learn and most importantly build your credibility. Who knows, if you do what I say you might learn something. There are times where you'll find that the conventional wisdom is wrong for your company's particular situation. It very well may be that the way they are doing it is easier/better/more-suited for their tasks, once you get used to it. Even if they are doing it wrong, if your coworkers have trust in you then convincing them to change becomes hundreds of times easier than having some new guy telling them how they've been doing it wrong all this time.

In the meantime, if you really are serious about bringing in changes, see what you can do about getting a setup just for yourself to use. Maybe someone else will be curious about what you are doing and like what you did, and they'll show someone else and it'll grow without much effort at all on your part. At the very least, you will have figured out how to make your changes work at that particular company when the time comes that it is appropriate to start pushing your changes.

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

add a comment | 

up vote
0
down vote

I would find a particular code sample that is particularly intricate or prone to breaking an set up the automated testing for that code. Lead by example. If there are systems that have unusually significant quality problems, offer to use your methodologies to test them. Rather than saying 'we should all do this', 'do this' on your own, and let some of the benefits accrue before promoting it more widely.

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

add a comment | 

Your Answer

StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "423"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
noCode: true, onDemand: false,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);

 

draft saved

draft discarded

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

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f10832%2fshould-i-propose-a-big-change-as-a-newcomer%23new-answer', 'question_page');

);

Post as a guest

Name Email

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();


);
);

8 Answers
8

active

oldest

votes

8 Answers
8

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
11
down vote



accepted

I wouldn't take the suggestion of the head of another department very seriously. I don't know why he talked to you and not your boss (or higher management), but it doesn't really sound right (there might even actually be a reason why he didn't talk to your boss directly). As you mentioned in your question, these changes are far from being trivial. They require serious planning and implementation, and such decisions can't be made on the run just because someone thinks it would be nice (even if that someone is an ex-developer-now-head-of-department).

Before taking any actions you should talk to your boss. Have a one-on-one conversation and tell your boss about this suggestion. Try to refrain showing any specific attitude (too anxious or enthusiastic). Tell about your confusion about this. This will help clarify the situation, as well as show your professionalism and attitude toward your job and your boss.

Edit: Some clarifications concerning the comments. What I mean is that you shouldn't dive into this task without first discussing it with your boss. I don't mean that you needn't make suggestions or try to improve anything _ its completely different from diving into a work that someone not quite authorized thinks you should do.

share|improve this answer

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
  – huntmaster
  Apr 3 '13 at 14:09
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Spoken like a true "Thats not how we do it here" stalwart.
  – IDrinkandIKnowThings
  Apr 3 '13 at 15:05
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
  – Rhys
  Apr 3 '13 at 15:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @RhysW, Please see my edit. I think you didn't get me right
  – superM
  Apr 3 '13 at 15:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
  – Rhys
  Apr 3 '13 at 15:31
  

  
  
  
  

 | 
show 1 more comment

up vote
11
down vote



accepted

I wouldn't take the suggestion of the head of another department very seriously. I don't know why he talked to you and not your boss (or higher management), but it doesn't really sound right (there might even actually be a reason why he didn't talk to your boss directly). As you mentioned in your question, these changes are far from being trivial. They require serious planning and implementation, and such decisions can't be made on the run just because someone thinks it would be nice (even if that someone is an ex-developer-now-head-of-department).

Before taking any actions you should talk to your boss. Have a one-on-one conversation and tell your boss about this suggestion. Try to refrain showing any specific attitude (too anxious or enthusiastic). Tell about your confusion about this. This will help clarify the situation, as well as show your professionalism and attitude toward your job and your boss.

Edit: Some clarifications concerning the comments. What I mean is that you shouldn't dive into this task without first discussing it with your boss. I don't mean that you needn't make suggestions or try to improve anything _ its completely different from diving into a work that someone not quite authorized thinks you should do.

share|improve this answer

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
  – huntmaster
  Apr 3 '13 at 14:09
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Spoken like a true "Thats not how we do it here" stalwart.
  – IDrinkandIKnowThings
  Apr 3 '13 at 15:05
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
  – Rhys
  Apr 3 '13 at 15:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @RhysW, Please see my edit. I think you didn't get me right
  – superM
  Apr 3 '13 at 15:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
  – Rhys
  Apr 3 '13 at 15:31
  

  
  
  
  

 | 
show 1 more comment

up vote
11
down vote



accepted

up vote
11
down vote



accepted

I wouldn't take the suggestion of the head of another department very seriously. I don't know why he talked to you and not your boss (or higher management), but it doesn't really sound right (there might even actually be a reason why he didn't talk to your boss directly). As you mentioned in your question, these changes are far from being trivial. They require serious planning and implementation, and such decisions can't be made on the run just because someone thinks it would be nice (even if that someone is an ex-developer-now-head-of-department).

Before taking any actions you should talk to your boss. Have a one-on-one conversation and tell your boss about this suggestion. Try to refrain showing any specific attitude (too anxious or enthusiastic). Tell about your confusion about this. This will help clarify the situation, as well as show your professionalism and attitude toward your job and your boss.

Edit: Some clarifications concerning the comments. What I mean is that you shouldn't dive into this task without first discussing it with your boss. I don't mean that you needn't make suggestions or try to improve anything _ its completely different from diving into a work that someone not quite authorized thinks you should do.

share|improve this answer

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

I wouldn't take the suggestion of the head of another department very seriously. I don't know why he talked to you and not your boss (or higher management), but it doesn't really sound right (there might even actually be a reason why he didn't talk to your boss directly). As you mentioned in your question, these changes are far from being trivial. They require serious planning and implementation, and such decisions can't be made on the run just because someone thinks it would be nice (even if that someone is an ex-developer-now-head-of-department).

Before taking any actions you should talk to your boss. Have a one-on-one conversation and tell your boss about this suggestion. Try to refrain showing any specific attitude (too anxious or enthusiastic). Tell about your confusion about this. This will help clarify the situation, as well as show your professionalism and attitude toward your job and your boss.

Edit: Some clarifications concerning the comments. What I mean is that you shouldn't dive into this task without first discussing it with your boss. I don't mean that you needn't make suggestions or try to improve anything _ its completely different from diving into a work that someone not quite authorized thinks you should do.

share|improve this answer

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

share|improve this answer

share|improve this answer

edited Apr 3 '13 at 15:28

edited Apr 3 '13 at 15:28

edited Apr 3 '13 at 15:28

answered Apr 3 '13 at 12:49

superM

2,34421927

answered Apr 3 '13 at 12:49

superM

2,34421927

answered Apr 3 '13 at 12:49

superM

2,34421927

2,34421927

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
  – huntmaster
  Apr 3 '13 at 14:09
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Spoken like a true "Thats not how we do it here" stalwart.
  – IDrinkandIKnowThings
  Apr 3 '13 at 15:05
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
  – Rhys
  Apr 3 '13 at 15:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @RhysW, Please see my edit. I think you didn't get me right
  – superM
  Apr 3 '13 at 15:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
  – Rhys
  Apr 3 '13 at 15:31
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
  – huntmaster
  Apr 3 '13 at 14:09
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Spoken like a true "Thats not how we do it here" stalwart.
  – IDrinkandIKnowThings
  Apr 3 '13 at 15:05
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
  – Rhys
  Apr 3 '13 at 15:07
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  @RhysW, Please see my edit. I think you didn't get me right
  – superM
  Apr 3 '13 at 15:30
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
  – Rhys
  Apr 3 '13 at 15:31
  

  
  
  
  

4

4

Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
– huntmaster
Apr 3 '13 at 14:09

Exactly, it doesn't sound like you were hired to improve the current process by implementing these things, so don't feel like it's your responsibility. It's fine to run it past your boss as an idea, but don't take ownership just because someone who is not your boss mentioned it might be a good idea.
– huntmaster
Apr 3 '13 at 14:09

Spoken like a true "Thats not how we do it here" stalwart.
– IDrinkandIKnowThings
Apr 3 '13 at 15:05

Spoken like a true "Thats not how we do it here" stalwart.
– IDrinkandIKnowThings
Apr 3 '13 at 15:05

2

2

People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
– Rhys
Apr 3 '13 at 15:07

People are rarely hired just to improve the workplace for others, but everyone has the ability to suggest improvements to workflow themselves, it goes without saying, you wouldnt expect someone to not discuss a problem just because they arent getting paid for it would you? The guy has come across a way that his job could be improved, the whole reason he wants to talk to his boss about it is because he wasnt hired to do it but wants to bring it to the companies attention
– Rhys
Apr 3 '13 at 15:07

@RhysW, Please see my edit. I think you didn't get me right
– superM
Apr 3 '13 at 15:30

@RhysW, Please see my edit. I think you didn't get me right
– superM
Apr 3 '13 at 15:30

Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
– Rhys
Apr 3 '13 at 15:31

Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
– Rhys
Apr 3 '13 at 15:31

 | 
show 1 more comment

up vote
3
down vote

The other answers have given a lot of good advice about when, whether, and how to make changes. But step back a bit: you are a newcomer to an organization, have been identified as having new knowledge, and have been asked to provide input.

The logical next step here is for you to give a presentation on the relevant technologies -- a "things I've learned" talk, in other words, just like the talk you would give to your coworkers after coming back from a conference where you learned a bunch of stuff. Making recommendations would be premature no matter how long you've been there; the first step in any consideration of change is education. You are in a position to educate. Do that first and then see what happens.

I've been at my current company for more than a decade. I've seen lots of people come in with new ideas, things that we weren't up on because that hasn't been our focus. The ones who come in and say "we need to do X" out of the gate have generally not gotten traction; on the other hand, the ones who have said "here's some stuff I've learned about X" have.

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

• 
  
  
  

  
  

  
  
  
  
  
  

  
  That's a sneaky, sneaky way of making people think in the necessary direction...
  – Deer Hunter
  May 6 '13 at 18:08
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
  – Monica Cellio♦
  May 7 '13 at 16:46
  

  
  
  
  

add a comment | 

up vote
3
down vote

The other answers have given a lot of good advice about when, whether, and how to make changes. But step back a bit: you are a newcomer to an organization, have been identified as having new knowledge, and have been asked to provide input.

The logical next step here is for you to give a presentation on the relevant technologies -- a "things I've learned" talk, in other words, just like the talk you would give to your coworkers after coming back from a conference where you learned a bunch of stuff. Making recommendations would be premature no matter how long you've been there; the first step in any consideration of change is education. You are in a position to educate. Do that first and then see what happens.

I've been at my current company for more than a decade. I've seen lots of people come in with new ideas, things that we weren't up on because that hasn't been our focus. The ones who come in and say "we need to do X" out of the gate have generally not gotten traction; on the other hand, the ones who have said "here's some stuff I've learned about X" have.

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

• 
  
  
  

  
  

  
  
  
  
  
  

  
  That's a sneaky, sneaky way of making people think in the necessary direction...
  – Deer Hunter
  May 6 '13 at 18:08
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
  – Monica Cellio♦
  May 7 '13 at 16:46
  

  
  
  
  

add a comment | 

up vote
3
down vote

up vote
3
down vote

The other answers have given a lot of good advice about when, whether, and how to make changes. But step back a bit: you are a newcomer to an organization, have been identified as having new knowledge, and have been asked to provide input.

The logical next step here is for you to give a presentation on the relevant technologies -- a "things I've learned" talk, in other words, just like the talk you would give to your coworkers after coming back from a conference where you learned a bunch of stuff. Making recommendations would be premature no matter how long you've been there; the first step in any consideration of change is education. You are in a position to educate. Do that first and then see what happens.

I've been at my current company for more than a decade. I've seen lots of people come in with new ideas, things that we weren't up on because that hasn't been our focus. The ones who come in and say "we need to do X" out of the gate have generally not gotten traction; on the other hand, the ones who have said "here's some stuff I've learned about X" have.

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

The other answers have given a lot of good advice about when, whether, and how to make changes. But step back a bit: you are a newcomer to an organization, have been identified as having new knowledge, and have been asked to provide input.

The logical next step here is for you to give a presentation on the relevant technologies -- a "things I've learned" talk, in other words, just like the talk you would give to your coworkers after coming back from a conference where you learned a bunch of stuff. Making recommendations would be premature no matter how long you've been there; the first step in any consideration of change is education. You are in a position to educate. Do that first and then see what happens.

I've been at my current company for more than a decade. I've seen lots of people come in with new ideas, things that we weren't up on because that hasn't been our focus. The ones who come in and say "we need to do X" out of the gate have generally not gotten traction; on the other hand, the ones who have said "here's some stuff I've learned about X" have.

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

share|improve this answer

share|improve this answer

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

answered May 6 '13 at 14:55

Monica Cellio♦

43.7k17114191

43.7k17114191

• 
  
  
  

  
  

  
  
  
  
  
  

  
  That's a sneaky, sneaky way of making people think in the necessary direction...
  – Deer Hunter
  May 6 '13 at 18:08
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
  – Monica Cellio♦
  May 7 '13 at 16:46
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  That's a sneaky, sneaky way of making people think in the necessary direction...
  – Deer Hunter
  May 6 '13 at 18:08
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
  – Monica Cellio♦
  May 7 '13 at 16:46
  

  
  
  
  

That's a sneaky, sneaky way of making people think in the necessary direction...
– Deer Hunter
May 6 '13 at 18:08

That's a sneaky, sneaky way of making people think in the necessary direction...
– Deer Hunter
May 6 '13 at 18:08

1

1

@DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
– Monica Cellio♦
May 7 '13 at 16:46

@DeerHunter exactly. A new employee isn't in the best position to push, but anybody can inspire. (And, in my experience, the best leaders do way more inspiring than dictating.)
– Monica Cellio♦
May 7 '13 at 16:46

add a comment | 

up vote
2
down vote

I suggest bringing it up with your boss - specifically, ask about problems you (eventually) see. "Hey, why did our build break?" That gives your boss the opportunity to give you insight into the technical, business, and perhaps political stance of that particular issue.

If they wish it could be fixed, but don't know how, then suggest that its been dealt with via Continuous Integration in many companies.

If they dismiss it as nothing, maybe bite your tongue.

If they scowl and say 'you sound like the boss in that other department', then you know about the political minefield.

And in general, it's best to sell these things as 'best practice' solutions to problems, rather than change that you think should be done for the sake of change.

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
  – Rhys
  Apr 3 '13 at 15:08
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
  – Telastyn
  Apr 3 '13 at 15:52
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
  – Rhys
  Apr 3 '13 at 15:55
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
  – Telastyn
  Apr 3 '13 at 16:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are making a lot of assumptions based only off of your experiences, this isnt always true.
  – Rhys
  Apr 3 '13 at 17:02
  

  
  
  
  

 | 
show 1 more comment

up vote
2
down vote

I suggest bringing it up with your boss - specifically, ask about problems you (eventually) see. "Hey, why did our build break?" That gives your boss the opportunity to give you insight into the technical, business, and perhaps political stance of that particular issue.

If they wish it could be fixed, but don't know how, then suggest that its been dealt with via Continuous Integration in many companies.

If they dismiss it as nothing, maybe bite your tongue.

If they scowl and say 'you sound like the boss in that other department', then you know about the political minefield.

And in general, it's best to sell these things as 'best practice' solutions to problems, rather than change that you think should be done for the sake of change.

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
  – Rhys
  Apr 3 '13 at 15:08
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
  – Telastyn
  Apr 3 '13 at 15:52
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
  – Rhys
  Apr 3 '13 at 15:55
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
  – Telastyn
  Apr 3 '13 at 16:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are making a lot of assumptions based only off of your experiences, this isnt always true.
  – Rhys
  Apr 3 '13 at 17:02
  

  
  
  
  

 | 
show 1 more comment

up vote
2
down vote

up vote
2
down vote

I suggest bringing it up with your boss - specifically, ask about problems you (eventually) see. "Hey, why did our build break?" That gives your boss the opportunity to give you insight into the technical, business, and perhaps political stance of that particular issue.

If they wish it could be fixed, but don't know how, then suggest that its been dealt with via Continuous Integration in many companies.

If they dismiss it as nothing, maybe bite your tongue.

If they scowl and say 'you sound like the boss in that other department', then you know about the political minefield.

And in general, it's best to sell these things as 'best practice' solutions to problems, rather than change that you think should be done for the sake of change.

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

I suggest bringing it up with your boss - specifically, ask about problems you (eventually) see. "Hey, why did our build break?" That gives your boss the opportunity to give you insight into the technical, business, and perhaps political stance of that particular issue.

If they wish it could be fixed, but don't know how, then suggest that its been dealt with via Continuous Integration in many companies.

If they dismiss it as nothing, maybe bite your tongue.

If they scowl and say 'you sound like the boss in that other department', then you know about the political minefield.

And in general, it's best to sell these things as 'best practice' solutions to problems, rather than change that you think should be done for the sake of change.

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

share|improve this answer

share|improve this answer

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

answered Apr 3 '13 at 12:58

Telastyn

33.9k977120

33.9k977120

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
  – Rhys
  Apr 3 '13 at 15:08
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
  – Telastyn
  Apr 3 '13 at 15:52
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
  – Rhys
  Apr 3 '13 at 15:55
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
  – Telastyn
  Apr 3 '13 at 16:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are making a lot of assumptions based only off of your experiences, this isnt always true.
  – Rhys
  Apr 3 '13 at 17:02
  

  
  
  
  

 | 
show 1 more comment

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
  – Rhys
  Apr 3 '13 at 15:08
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
  – Telastyn
  Apr 3 '13 at 15:52
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
  – Rhys
  Apr 3 '13 at 15:55
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  @rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
  – Telastyn
  Apr 3 '13 at 16:04
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  You are making a lot of assumptions based only off of your experiences, this isnt always true.
  – Rhys
  Apr 3 '13 at 17:02
  

  
  
  
  

Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
– Rhys
Apr 3 '13 at 15:08

Waiting until a problem arises can be costly when a deployment breaks and costs a few hundred million to a customer due to their lack of service. There is never any harm in discussing improvements pre-problem
– Rhys
Apr 3 '13 at 15:08

3

3

@RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
– Telastyn
Apr 3 '13 at 15:52

@RhysW - Poppycock. If the new guy goes in and pushes for improvements without knowing the problem he is fixing, or the political landscape he could easily set people against the improvements. Improvements only benefit the company if they're enacted.
– Telastyn
Apr 3 '13 at 15:52

Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
– Rhys
Apr 3 '13 at 15:55

Which is precisely why it doesnt hurt to bring it to his boss's attention. If it can solve the problem, the boss will push it, if it cant, the boss will tell him it wont work and explain why. Best case scenario, you solved a problem, worse case scenario you learned something new about the system and why your solution wont work. I dont see any downsides
– Rhys
Apr 3 '13 at 15:55

3

3

@rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
– Telastyn
Apr 3 '13 at 16:04

@rhysw - Do you really think the other department's boss didn't already talk to the OP's boss about it? I've seen this a half dozen times. One backwards department head rebuffs attempts at improvement as change for change's sake, or due to political spite, or due to simple ignorance of the impact the backwardsness causes. Since the direct tact failed, the other department head is trying to subvert the change into the department. Having the OP bring this up directly or calously would quickly destroy that process.
– Telastyn
Apr 3 '13 at 16:04

You are making a lot of assumptions based only off of your experiences, this isnt always true.
– Rhys
Apr 3 '13 at 17:02

You are making a lot of assumptions based only off of your experiences, this isnt always true.
– Rhys
Apr 3 '13 at 17:02

 | 
show 1 more comment

up vote
2
down vote

Timing is critical in suggesting major changes. The first thing you need to do is have a good reputation with your current coworkers and boss. At two months you don't have a track record with them, I would wait until you do. Further changes are more likely to be accepted as the solution to a problem that is happening right this minute. So the time to suggest writing unit tests is right after something major broke on prod that could have been prevented if tests existed.

So write up your proposals in business terms (improved quality, lower costs, etc.) and hold onto it until the timing is right. Then bring them up. And remember, don't try to do too much at once. Pick the propossal most likely to be accepted as the first one you bring up. Having a success at a proposal gives you more credibility when you suggest the changes that are likely to be the hardest for others to accept.

Also start to find allies, other people who might be supportive of the changes you are interetsed in proposing. It is easier to get things accepted if the others are not fighting the idea. If you have people who have been there a long time, remember, they likely created the current system and they are invested in it. You will have to work harder to get them to accept change. Also do some reading about resistance to change. All organizations have this and it helps to understand it and understand why it occurs and how to politically deal with it.

share|improve this answer

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

add a comment | 

up vote
2
down vote

Timing is critical in suggesting major changes. The first thing you need to do is have a good reputation with your current coworkers and boss. At two months you don't have a track record with them, I would wait until you do. Further changes are more likely to be accepted as the solution to a problem that is happening right this minute. So the time to suggest writing unit tests is right after something major broke on prod that could have been prevented if tests existed.

So write up your proposals in business terms (improved quality, lower costs, etc.) and hold onto it until the timing is right. Then bring them up. And remember, don't try to do too much at once. Pick the propossal most likely to be accepted as the first one you bring up. Having a success at a proposal gives you more credibility when you suggest the changes that are likely to be the hardest for others to accept.

Also start to find allies, other people who might be supportive of the changes you are interetsed in proposing. It is easier to get things accepted if the others are not fighting the idea. If you have people who have been there a long time, remember, they likely created the current system and they are invested in it. You will have to work harder to get them to accept change. Also do some reading about resistance to change. All organizations have this and it helps to understand it and understand why it occurs and how to politically deal with it.

share|improve this answer

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

add a comment | 

up vote
2
down vote

up vote
2
down vote

Timing is critical in suggesting major changes. The first thing you need to do is have a good reputation with your current coworkers and boss. At two months you don't have a track record with them, I would wait until you do. Further changes are more likely to be accepted as the solution to a problem that is happening right this minute. So the time to suggest writing unit tests is right after something major broke on prod that could have been prevented if tests existed.

So write up your proposals in business terms (improved quality, lower costs, etc.) and hold onto it until the timing is right. Then bring them up. And remember, don't try to do too much at once. Pick the propossal most likely to be accepted as the first one you bring up. Having a success at a proposal gives you more credibility when you suggest the changes that are likely to be the hardest for others to accept.

Also start to find allies, other people who might be supportive of the changes you are interetsed in proposing. It is easier to get things accepted if the others are not fighting the idea. If you have people who have been there a long time, remember, they likely created the current system and they are invested in it. You will have to work harder to get them to accept change. Also do some reading about resistance to change. All organizations have this and it helps to understand it and understand why it occurs and how to politically deal with it.

share|improve this answer

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

Timing is critical in suggesting major changes. The first thing you need to do is have a good reputation with your current coworkers and boss. At two months you don't have a track record with them, I would wait until you do. Further changes are more likely to be accepted as the solution to a problem that is happening right this minute. So the time to suggest writing unit tests is right after something major broke on prod that could have been prevented if tests existed.

So write up your proposals in business terms (improved quality, lower costs, etc.) and hold onto it until the timing is right. Then bring them up. And remember, don't try to do too much at once. Pick the propossal most likely to be accepted as the first one you bring up. Having a success at a proposal gives you more credibility when you suggest the changes that are likely to be the hardest for others to accept.

Also start to find allies, other people who might be supportive of the changes you are interetsed in proposing. It is easier to get things accepted if the others are not fighting the idea. If you have people who have been there a long time, remember, they likely created the current system and they are invested in it. You will have to work harder to get them to accept change. Also do some reading about resistance to change. All organizations have this and it helps to understand it and understand why it occurs and how to politically deal with it.

share|improve this answer

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

share|improve this answer

share|improve this answer

edited May 6 '13 at 14:20

edited May 6 '13 at 14:20

edited May 6 '13 at 14:20

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

answered Apr 3 '13 at 14:21

HLGEM

133k25227489

133k25227489

add a comment | 

add a comment | 

up vote
1
down vote

I would have suggested that this other department's manager take it up with your boss. If the head of another department wants your department to do something, it's not entirely appropriate to place the burden of decision on any member of your department (especially not a relatively new member such as yourself) outside of the department head/senior level manager.

share|improve this answer

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
  – acolyte
  Apr 3 '13 at 15:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
  – Rhys
  Apr 3 '13 at 15:57
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @RhysW ahh, I see then. I'll edit my answer.
  – acolyte
  Apr 3 '13 at 15:59
  

  
  
  
  

add a comment | 

up vote
1
down vote

I would have suggested that this other department's manager take it up with your boss. If the head of another department wants your department to do something, it's not entirely appropriate to place the burden of decision on any member of your department (especially not a relatively new member such as yourself) outside of the department head/senior level manager.

share|improve this answer

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
  – acolyte
  Apr 3 '13 at 15:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
  – Rhys
  Apr 3 '13 at 15:57
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @RhysW ahh, I see then. I'll edit my answer.
  – acolyte
  Apr 3 '13 at 15:59
  

  
  
  
  

add a comment | 

up vote
1
down vote

up vote
1
down vote

I would have suggested that this other department's manager take it up with your boss. If the head of another department wants your department to do something, it's not entirely appropriate to place the burden of decision on any member of your department (especially not a relatively new member such as yourself) outside of the department head/senior level manager.

share|improve this answer

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

I would have suggested that this other department's manager take it up with your boss. If the head of another department wants your department to do something, it's not entirely appropriate to place the burden of decision on any member of your department (especially not a relatively new member such as yourself) outside of the department head/senior level manager.

share|improve this answer

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

share|improve this answer

share|improve this answer

edited Apr 3 '13 at 16:04

edited Apr 3 '13 at 16:04

edited Apr 3 '13 at 16:04

answered Apr 3 '13 at 13:53

acolyte

3,0531632

answered Apr 3 '13 at 13:53

acolyte

3,0531632

answered Apr 3 '13 at 13:53

acolyte

3,0531632

3,0531632

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
  – acolyte
  Apr 3 '13 at 15:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
  – Rhys
  Apr 3 '13 at 15:57
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @RhysW ahh, I see then. I'll edit my answer.
  – acolyte
  Apr 3 '13 at 15:59
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
  – acolyte
  Apr 3 '13 at 15:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
  – Rhys
  Apr 3 '13 at 15:57
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  @RhysW ahh, I see then. I'll edit my answer.
  – acolyte
  Apr 3 '13 at 15:59
  

  
  
  
  

Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
– acolyte
Apr 3 '13 at 15:49

Might I ask why my answer was downvoted? This is the policy I follow in the rare events something like this occurs, and I think it is in my interest to understand why such a course of action might be bad.
– acolyte
Apr 3 '13 at 15:49

From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
– Rhys
Apr 3 '13 at 15:57

From my perspective, nothing wrong with the actual answer but the other boss never made it an official task for him to do, it sounds more like the other boss mentioned in a discussion that X would have been nice, and if the OP agreed then 'here is a pathway to get it done' by making a powerpoint and going to the boss
– Rhys
Apr 3 '13 at 15:57

1

1

@RhysW ahh, I see then. I'll edit my answer.
– acolyte
Apr 3 '13 at 15:59

@RhysW ahh, I see then. I'll edit my answer.
– acolyte
Apr 3 '13 at 15:59

add a comment | 

up vote
1
down vote

Think 4 Moves Ahead

"A person is smart. People are dumb, panicky, dangerous animals and you know it."

While an individual may be a rational forward-looking tool for improvement, organizations usually aren't.

If you want to implement these improvements, the important question isn't to ask if you should propose these changes, but rather how to propose these changes with the best chance of success.

Perspective is Everything

Learning how is all about perspective. Who actually has the power to implement it? What horses do they have in the race? What is their goal? What are the potential problems they will face if they try to implement it?

These are the most important things to know, but they usually aren't apparent to people who just joined the organization. That's why lots of new employees who push for broad sweeping changes find themselves frustrated by the apparent irrationality of the system as a whole -- they can't see the rationality of each of the actors in that system.

Gaining Perspective vs. Gaining Trust

Not everyone cares about what their manager wants, or how the organization is set up, or how best to implement change that cuts across departments (it is really tedious work), so if gaining perspective isn't your thing, you can go the other route and try to gain trust.

Gaining trust of someone with the perspective means that they can form a partnership with you where they allow you to handle the technical side while they handle the politics side to implement the change. The key to building the trust is that you also need to trust the politically apt person with perspective as well, as you are limited in what you can do by what they can get the organization to accept.

So Should You Propose Change as a Newcomer?

This question is wholly dependent on two things:

1. Are you aiming for short term impact or long term success with this company?


2. Are you technically or politically gifted?

Short Term Impact

If you are technically oriented, then you can create something that works great as a side project to the extent that your boss is unable to deny its effectiveness. Many moons ago I worked in QA for some software, and wrote automated testing software that eliminated the need for me to do my job (I programmed my job out of existence). Your boss will have trouble saying that automated testing software is a bad idea when it has a proven track record for success.

If you are politically oriented, then you can spend a few weeks figuring out what your boss' role is in the organization, and how much he will let you get away with, and then ask him to allow you do to a side project within the realm you know he will let you do (as it won't cause harm to anyone else). This will allow you to create something you want to create, build trust with your boss, and allow you to build on it in the near future.

Long Term Impact

If you are going for long-term success, I wouldn't propose a big change. I would instead work on building trust (if technically oriented) or perspective (if politically oriented) so that I can leverage that to put myself in a position to make a bigger change later.

At Any Rate...

Beware political land mines. People from other departments suggesting you propose sweeping changes reeks of political opportunism and screams "Danger Will Robinson" to me. Talk to your manager and figure out what he's thinking. Like it or not, your manager is going to have a large impact on what change you can implement, and getting to understand him (or getting him to trust you) is a good idea.

At the same time, it's a bad idea to upset the manager in another group as well. So I'd be careful not to use this opportunity to get on your boss' good side by making that manager look bad.

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

add a comment | 

up vote
1
down vote

Think 4 Moves Ahead

"A person is smart. People are dumb, panicky, dangerous animals and you know it."

While an individual may be a rational forward-looking tool for improvement, organizations usually aren't.

If you want to implement these improvements, the important question isn't to ask if you should propose these changes, but rather how to propose these changes with the best chance of success.

Perspective is Everything

Learning how is all about perspective. Who actually has the power to implement it? What horses do they have in the race? What is their goal? What are the potential problems they will face if they try to implement it?

These are the most important things to know, but they usually aren't apparent to people who just joined the organization. That's why lots of new employees who push for broad sweeping changes find themselves frustrated by the apparent irrationality of the system as a whole -- they can't see the rationality of each of the actors in that system.

Gaining Perspective vs. Gaining Trust

Not everyone cares about what their manager wants, or how the organization is set up, or how best to implement change that cuts across departments (it is really tedious work), so if gaining perspective isn't your thing, you can go the other route and try to gain trust.

Gaining trust of someone with the perspective means that they can form a partnership with you where they allow you to handle the technical side while they handle the politics side to implement the change. The key to building the trust is that you also need to trust the politically apt person with perspective as well, as you are limited in what you can do by what they can get the organization to accept.

So Should You Propose Change as a Newcomer?

This question is wholly dependent on two things:

1. Are you aiming for short term impact or long term success with this company?


2. Are you technically or politically gifted?

Short Term Impact

If you are technically oriented, then you can create something that works great as a side project to the extent that your boss is unable to deny its effectiveness. Many moons ago I worked in QA for some software, and wrote automated testing software that eliminated the need for me to do my job (I programmed my job out of existence). Your boss will have trouble saying that automated testing software is a bad idea when it has a proven track record for success.

If you are politically oriented, then you can spend a few weeks figuring out what your boss' role is in the organization, and how much he will let you get away with, and then ask him to allow you do to a side project within the realm you know he will let you do (as it won't cause harm to anyone else). This will allow you to create something you want to create, build trust with your boss, and allow you to build on it in the near future.

Long Term Impact

If you are going for long-term success, I wouldn't propose a big change. I would instead work on building trust (if technically oriented) or perspective (if politically oriented) so that I can leverage that to put myself in a position to make a bigger change later.

At Any Rate...

Beware political land mines. People from other departments suggesting you propose sweeping changes reeks of political opportunism and screams "Danger Will Robinson" to me. Talk to your manager and figure out what he's thinking. Like it or not, your manager is going to have a large impact on what change you can implement, and getting to understand him (or getting him to trust you) is a good idea.

At the same time, it's a bad idea to upset the manager in another group as well. So I'd be careful not to use this opportunity to get on your boss' good side by making that manager look bad.

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

add a comment | 

up vote
1
down vote

up vote
1
down vote

Think 4 Moves Ahead

"A person is smart. People are dumb, panicky, dangerous animals and you know it."

While an individual may be a rational forward-looking tool for improvement, organizations usually aren't.

If you want to implement these improvements, the important question isn't to ask if you should propose these changes, but rather how to propose these changes with the best chance of success.

Perspective is Everything

Learning how is all about perspective. Who actually has the power to implement it? What horses do they have in the race? What is their goal? What are the potential problems they will face if they try to implement it?

These are the most important things to know, but they usually aren't apparent to people who just joined the organization. That's why lots of new employees who push for broad sweeping changes find themselves frustrated by the apparent irrationality of the system as a whole -- they can't see the rationality of each of the actors in that system.

Gaining Perspective vs. Gaining Trust

Not everyone cares about what their manager wants, or how the organization is set up, or how best to implement change that cuts across departments (it is really tedious work), so if gaining perspective isn't your thing, you can go the other route and try to gain trust.

Gaining trust of someone with the perspective means that they can form a partnership with you where they allow you to handle the technical side while they handle the politics side to implement the change. The key to building the trust is that you also need to trust the politically apt person with perspective as well, as you are limited in what you can do by what they can get the organization to accept.

So Should You Propose Change as a Newcomer?

This question is wholly dependent on two things:

1. Are you aiming for short term impact or long term success with this company?


2. Are you technically or politically gifted?

Short Term Impact

If you are technically oriented, then you can create something that works great as a side project to the extent that your boss is unable to deny its effectiveness. Many moons ago I worked in QA for some software, and wrote automated testing software that eliminated the need for me to do my job (I programmed my job out of existence). Your boss will have trouble saying that automated testing software is a bad idea when it has a proven track record for success.

If you are politically oriented, then you can spend a few weeks figuring out what your boss' role is in the organization, and how much he will let you get away with, and then ask him to allow you do to a side project within the realm you know he will let you do (as it won't cause harm to anyone else). This will allow you to create something you want to create, build trust with your boss, and allow you to build on it in the near future.

Long Term Impact

If you are going for long-term success, I wouldn't propose a big change. I would instead work on building trust (if technically oriented) or perspective (if politically oriented) so that I can leverage that to put myself in a position to make a bigger change later.

At Any Rate...

Beware political land mines. People from other departments suggesting you propose sweeping changes reeks of political opportunism and screams "Danger Will Robinson" to me. Talk to your manager and figure out what he's thinking. Like it or not, your manager is going to have a large impact on what change you can implement, and getting to understand him (or getting him to trust you) is a good idea.

At the same time, it's a bad idea to upset the manager in another group as well. So I'd be careful not to use this opportunity to get on your boss' good side by making that manager look bad.

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

Think 4 Moves Ahead

"A person is smart. People are dumb, panicky, dangerous animals and you know it."

While an individual may be a rational forward-looking tool for improvement, organizations usually aren't.

If you want to implement these improvements, the important question isn't to ask if you should propose these changes, but rather how to propose these changes with the best chance of success.

Perspective is Everything

Learning how is all about perspective. Who actually has the power to implement it? What horses do they have in the race? What is their goal? What are the potential problems they will face if they try to implement it?

These are the most important things to know, but they usually aren't apparent to people who just joined the organization. That's why lots of new employees who push for broad sweeping changes find themselves frustrated by the apparent irrationality of the system as a whole -- they can't see the rationality of each of the actors in that system.

Gaining Perspective vs. Gaining Trust

Not everyone cares about what their manager wants, or how the organization is set up, or how best to implement change that cuts across departments (it is really tedious work), so if gaining perspective isn't your thing, you can go the other route and try to gain trust.

Gaining trust of someone with the perspective means that they can form a partnership with you where they allow you to handle the technical side while they handle the politics side to implement the change. The key to building the trust is that you also need to trust the politically apt person with perspective as well, as you are limited in what you can do by what they can get the organization to accept.

So Should You Propose Change as a Newcomer?

This question is wholly dependent on two things:

1. Are you aiming for short term impact or long term success with this company?


2. Are you technically or politically gifted?

Short Term Impact

If you are technically oriented, then you can create something that works great as a side project to the extent that your boss is unable to deny its effectiveness. Many moons ago I worked in QA for some software, and wrote automated testing software that eliminated the need for me to do my job (I programmed my job out of existence). Your boss will have trouble saying that automated testing software is a bad idea when it has a proven track record for success.

If you are politically oriented, then you can spend a few weeks figuring out what your boss' role is in the organization, and how much he will let you get away with, and then ask him to allow you do to a side project within the realm you know he will let you do (as it won't cause harm to anyone else). This will allow you to create something you want to create, build trust with your boss, and allow you to build on it in the near future.

Long Term Impact

If you are going for long-term success, I wouldn't propose a big change. I would instead work on building trust (if technically oriented) or perspective (if politically oriented) so that I can leverage that to put myself in a position to make a bigger change later.

At Any Rate...

Beware political land mines. People from other departments suggesting you propose sweeping changes reeks of political opportunism and screams "Danger Will Robinson" to me. Talk to your manager and figure out what he's thinking. Like it or not, your manager is going to have a large impact on what change you can implement, and getting to understand him (or getting him to trust you) is a good idea.

At the same time, it's a bad idea to upset the manager in another group as well. So I'd be careful not to use this opportunity to get on your boss' good side by making that manager look bad.

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

share|improve this answer

share|improve this answer

answered Apr 4 '13 at 0:59

jmac

19.4k763137

answered Apr 4 '13 at 0:59

jmac

19.4k763137

answered Apr 4 '13 at 0:59

jmac

19.4k763137

19.4k763137

add a comment | 

add a comment | 

up vote
0
down vote

Unless you were brought specifically to make changes then I think it is way to soon for the new guy to be telling everyone how what they are doing is wrong. Many times when a company is doing something that the conventional wisdom believes is wrong, it turns out there are valid reasons for doing it that way. If you don't know the history of how things got to where they are and it turns out that change is not really practical because of company/project specific isses then it makes you lose credibility at precisely the time you are supposed to be building your credibility.

My advice to anyone who is new is to first watch, listen, learn and most importantly build your credibility. Who knows, if you do what I say you might learn something. There are times where you'll find that the conventional wisdom is wrong for your company's particular situation. It very well may be that the way they are doing it is easier/better/more-suited for their tasks, once you get used to it. Even if they are doing it wrong, if your coworkers have trust in you then convincing them to change becomes hundreds of times easier than having some new guy telling them how they've been doing it wrong all this time.

In the meantime, if you really are serious about bringing in changes, see what you can do about getting a setup just for yourself to use. Maybe someone else will be curious about what you are doing and like what you did, and they'll show someone else and it'll grow without much effort at all on your part. At the very least, you will have figured out how to make your changes work at that particular company when the time comes that it is appropriate to start pushing your changes.

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

add a comment | 

up vote
0
down vote

Unless you were brought specifically to make changes then I think it is way to soon for the new guy to be telling everyone how what they are doing is wrong. Many times when a company is doing something that the conventional wisdom believes is wrong, it turns out there are valid reasons for doing it that way. If you don't know the history of how things got to where they are and it turns out that change is not really practical because of company/project specific isses then it makes you lose credibility at precisely the time you are supposed to be building your credibility.

My advice to anyone who is new is to first watch, listen, learn and most importantly build your credibility. Who knows, if you do what I say you might learn something. There are times where you'll find that the conventional wisdom is wrong for your company's particular situation. It very well may be that the way they are doing it is easier/better/more-suited for their tasks, once you get used to it. Even if they are doing it wrong, if your coworkers have trust in you then convincing them to change becomes hundreds of times easier than having some new guy telling them how they've been doing it wrong all this time.

In the meantime, if you really are serious about bringing in changes, see what you can do about getting a setup just for yourself to use. Maybe someone else will be curious about what you are doing and like what you did, and they'll show someone else and it'll grow without much effort at all on your part. At the very least, you will have figured out how to make your changes work at that particular company when the time comes that it is appropriate to start pushing your changes.

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

add a comment | 

up vote
0
down vote

up vote
0
down vote

Unless you were brought specifically to make changes then I think it is way to soon for the new guy to be telling everyone how what they are doing is wrong. Many times when a company is doing something that the conventional wisdom believes is wrong, it turns out there are valid reasons for doing it that way. If you don't know the history of how things got to where they are and it turns out that change is not really practical because of company/project specific isses then it makes you lose credibility at precisely the time you are supposed to be building your credibility.

My advice to anyone who is new is to first watch, listen, learn and most importantly build your credibility. Who knows, if you do what I say you might learn something. There are times where you'll find that the conventional wisdom is wrong for your company's particular situation. It very well may be that the way they are doing it is easier/better/more-suited for their tasks, once you get used to it. Even if they are doing it wrong, if your coworkers have trust in you then convincing them to change becomes hundreds of times easier than having some new guy telling them how they've been doing it wrong all this time.

In the meantime, if you really are serious about bringing in changes, see what you can do about getting a setup just for yourself to use. Maybe someone else will be curious about what you are doing and like what you did, and they'll show someone else and it'll grow without much effort at all on your part. At the very least, you will have figured out how to make your changes work at that particular company when the time comes that it is appropriate to start pushing your changes.

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

Unless you were brought specifically to make changes then I think it is way to soon for the new guy to be telling everyone how what they are doing is wrong. Many times when a company is doing something that the conventional wisdom believes is wrong, it turns out there are valid reasons for doing it that way. If you don't know the history of how things got to where they are and it turns out that change is not really practical because of company/project specific isses then it makes you lose credibility at precisely the time you are supposed to be building your credibility.

My advice to anyone who is new is to first watch, listen, learn and most importantly build your credibility. Who knows, if you do what I say you might learn something. There are times where you'll find that the conventional wisdom is wrong for your company's particular situation. It very well may be that the way they are doing it is easier/better/more-suited for their tasks, once you get used to it. Even if they are doing it wrong, if your coworkers have trust in you then convincing them to change becomes hundreds of times easier than having some new guy telling them how they've been doing it wrong all this time.

In the meantime, if you really are serious about bringing in changes, see what you can do about getting a setup just for yourself to use. Maybe someone else will be curious about what you are doing and like what you did, and they'll show someone else and it'll grow without much effort at all on your part. At the very least, you will have figured out how to make your changes work at that particular company when the time comes that it is appropriate to start pushing your changes.

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

share|improve this answer

share|improve this answer

answered Apr 3 '13 at 14:18

Dunk

1,10278

answered Apr 3 '13 at 14:18

Dunk

1,10278

answered Apr 3 '13 at 14:18

Dunk

1,10278

1,10278

add a comment | 

add a comment | 

up vote
0
down vote

I would find a particular code sample that is particularly intricate or prone to breaking an set up the automated testing for that code. Lead by example. If there are systems that have unusually significant quality problems, offer to use your methodologies to test them. Rather than saying 'we should all do this', 'do this' on your own, and let some of the benefits accrue before promoting it more widely.

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

add a comment | 

up vote
0
down vote

I would find a particular code sample that is particularly intricate or prone to breaking an set up the automated testing for that code. Lead by example. If there are systems that have unusually significant quality problems, offer to use your methodologies to test them. Rather than saying 'we should all do this', 'do this' on your own, and let some of the benefits accrue before promoting it more widely.

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

add a comment | 

up vote
0
down vote

up vote
0
down vote

I would find a particular code sample that is particularly intricate or prone to breaking an set up the automated testing for that code. Lead by example. If there are systems that have unusually significant quality problems, offer to use your methodologies to test them. Rather than saying 'we should all do this', 'do this' on your own, and let some of the benefits accrue before promoting it more widely.

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

I would find a particular code sample that is particularly intricate or prone to breaking an set up the automated testing for that code. Lead by example. If there are systems that have unusually significant quality problems, offer to use your methodologies to test them. Rather than saying 'we should all do this', 'do this' on your own, and let some of the benefits accrue before promoting it more widely.

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

share|improve this answer

share|improve this answer

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

answered Jun 15 '13 at 7:21

Meredith Poor

8,8661730

8,8661730

add a comment | 

add a comment | 

 

draft saved

draft discarded

 

draft saved

draft discarded

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

Name Email

StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f10832%2fshould-i-propose-a-big-change-as-a-newcomer%23new-answer', 'question_page');

);

Post as a guest

Name Email

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

Name Email

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

Name Email

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

Post as a guest

Name Email

Name Email

Name

Email

Name Email

Name

Email