Should I propose a big change as a newcomer?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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?

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.