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?

  • What job title do you hold in the IT department? Developer, Senior etc..? Commented Apr 3, 2013 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
    Commented Apr 3, 2013 at 12:38
  • 5
    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?
    – user5305
    Commented Apr 3, 2013 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
    – user5305
    Commented Apr 3, 2013 at 15:23
  • Have you talked with your teammates about considering these changes?
    – JB King
    Commented Apr 3, 2013 at 15:55

9 Answers 9


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.

  • 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
    Commented Apr 3, 2013 at 14:09
  • 1
    Spoken like a true "Thats not how we do it here" stalwart. Commented Apr 3, 2013 at 15:05
  • 4
    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
    – user5305
    Commented Apr 3, 2013 at 15:07
  • @RhysW, Please see my edit. I think you didn't get me right
    – superM
    Commented Apr 3, 2013 at 15:30
  • Apologies SuperM, my comment was actually directed at @Huntmaster, i mistakenly didnt tag him
    – user5305
    Commented Apr 3, 2013 at 15:31

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.

  • That's a sneaky, sneaky way of making people think in the necessary direction... Commented May 6, 2013 at 18:08
  • 4
    @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.) Commented May 7, 2013 at 16:46
  • 2
    I agree, the way you phrase it is really important. Got to avoid sounding like you're a know-it-all or accusing them of being out of date. You show them stuff you worked with and how it helped you there, and then they will hopefully start to put 2 and 2 together and realise it'll help solve problems they have.
    – R Davies
    Commented Jun 16, 2021 at 10:05

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.


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.

  • 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
    – user5305
    Commented Apr 3, 2013 at 15:08
  • 4
    @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
    Commented Apr 3, 2013 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
    – user5305
    Commented Apr 3, 2013 at 15:55
  • 4
    @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
    Commented Apr 3, 2013 at 16:04
  • 1
    +1 for the cautious approach. My particular case turned out to be a simple lack of time to organize a meeting between the 2 managers. Now the issue is solved, but your points are still valid in general.
    – lortabac
    Commented Apr 13, 2013 at 10:22

The gist of my answer is: Find out if this is a realistic task, one you would like to do and good for your professional career. If not, look for a new job.

As already suggested I would also suggest to talk to your boss first. And in a more informal way to your colleagues to get a better "assessment" about how they would feel about these changes. Also, read between the lines. If he says "yes", but is not really on board, this means "yes, but no".

Also, try to get a feeling about how they think about changes in general and the concepts / ideas / mindset of the things you want to propose. How do they deal with technical debt? Do they maintain code long-term, do they refactor etc.? Do they have experience in open source? So they do code reviews?

Look for sentences like:

  • "We have always done it this way"
  • "Never break a running system"
  • "We don't have time for this"
  • "We already tried that but had problems / didn't work ..."

If the boss is not (entirely) onboard OR if the colleagues have serious objections I would at least consider looking for a new job (especially if you are young) In your next job interview, ask specific questions to see if the development culture is a good fit for you.

I don't mean leave whenever there is a problem. I mean, leave if there is an unsurmountable resistance to change and you will get stuck assimilating to a culture and development practice that is not good for you personally or for your professional career.

On the one hand, handling this change would be a great experience for you and would probably look good on your resume. However, the question is how likely is it to succeed?

Why am I saying this:

  • It looks like your department and your colleagues are lagging behind you for things you find important and that are fundamental for writing good and stable code.
  • Is there anyone there who has more expertise than you (in this or in other fields?). Who will you learn from?
  • 1
    Here's the worst objection: "We told this to our boss repeatedly and he would have none of it". If the boss takes the suggestion from you after rejecting it multiple times, you're a marked man.
    – gnasher729
    Commented Oct 20, 2021 at 13:20

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.

  • 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
    Commented Apr 3, 2013 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
    – user5305
    Commented Apr 3, 2013 at 15:57
  • 1
    @RhysW ahh, I see then. I'll edit my answer.
    – acolyte
    Commented Apr 3, 2013 at 15:59

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.


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.


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .