How can I get my co-workers to migrate to a new system without being too pushy?

Question

A few weeks ago I migrated our team repository from SVN to Git (just think of it as something we work with once to multiple times a day). As I expected the challenge wasn't the technical part but getting people to switch. My manager had expressed the desire to move to Git so I had taken the initiative as I felt confident and experienced enough to do so. Since then:

• I sent a couple of emails with simple instructions on how to setup indicating I'm available for questions and help
• I've demoed our new repo, showing everyone how it works and explaining Git
• My manager pointed out on a few occasions that he expected everyone to move to Git soon
• I made a test repository we intend to scrap just as a sandbox for people not to be intimidated by it.

Yet, no one's taken the steps to migrate just yet.

We're all adults here and I hate going after people asking if they've done something, I feel even more uncomfortable pressing the question since I'm new at this company (a month roughly).

I understand change is difficult and uncomfortable, what's a good way to deal with this situation without being too pushy yet without it dragging forever ?

Answer 1

Build a case

Why is this change needed?

Everything in your post talks about the logistics of switching. Did you build a case for actually switching? Does your team know how much better Git is for your team than SVN?

When persuading, people forget that the people they need to persuade do not necessarily know "why" something is needed. You probably are familiar with Git and think "of course Git is better than SVN!", but your team probably does not.

This is all important even if the ultimate reason is "because boss says so" as it helps with the process change even if the core motivation is "management."

---

Are you sure people git it?

Git is a different paradigm than SVN. If you gave a presentation it's entirely possible that no one really understood. And if you don't understand a VCS you are going to be very resistant to changing to it.

When you give a presentation, make sure to ask open ended questions like "What questions do you have?" instead of "Do you have any questions?"

An email likely was completely ineffective, since most people get many emails and a "FYI change coming!" email often go straight into the "not relevant" category.

---

Who's in charge?

Your question is... interesting in that your assignment of responsibility is fairly passive voice. Did your manager task you with leading the initiative? Or is your manager still responsible?

Someone needs to have ultimate ownership for the project. In your position, I would strongly encourage you to find a way to get your boss to drive the conversation.

You don't want to be the "new guy who makes everyone change everything" after a month...

---

What to do?

First, I'd set up a meeting with your manager. Talk with them about:

• What you did (presentations, etc.)
• What was the outcome you expected (people to change)
• What was the outcome that actually happened (people didn't change)
• Ask what your next steps should be
  • You can even say you don't want to be pushy as the new person
  • Maybe ask about a timeline (perhaps your understanding of "soon" was very different)

Now, if your manager has no idea what is going on (unlikely... but possible) you will want to make sure they understand the implications of changing.

Understanding that it is not a "some-people-switch-to-Git-slowly-while-others-work-in-SVN" approach is important. Ultimately someone needs to have a plan, with a specific date/timeframe when Git goes live. You want to come out of this meeting either knowing this information or trusting your manager either has a plan or will create a plan.

Likely your manager, if even remotely competent, will take ownership and resolve this quickly at this point. If not, they will have a better understanding of team culture and can provide better specific steps.

Answer 2

If the manager expressed the desire to move to Git (or any other new technology) then it is their responsibility to notify everyone that the change will be effective by a specified date (X days from the announcement).

The announcement should be explicit that the new technology will be active and fully functional by the said date, and at the same time, the old technology will be made obsolete, either by removing it, or in that case, make the SVN repository read-only.

The announcement should be made by the manager. The announcement should also include something like: "If you have concerns about the new technology, please come to see me and discuss it".

Answer 3

In your entire question, I don't hear a single reason why anyone benefits by using git.

The truth is, you'll hit a learning curve and a bit of re-tooling that will slow people down in the short term. There are many valid reasons to move to git, and I would never go back to svn myself, git is vastly superior in many ways--but that's not the point. I use git, know it, and know what I like it. If I received an email saying I had to switch with no real benefit spelled out, and knowing it would trip me up for a while, I'd wait until threatened before bothering. Someone else may argue you into a corner, and then I can ignore this and go on working. There may be a history of this for other edicts from above.

So how do you deal with people ignoring you? Sit with someone influential and see if you can switch him over. You may have to do that 2-3 times. Then let them do the evangelizing. If they don't, feed back upstream that the top people see no benefit, and it's a waste of resources. In this case I don't think that will happen, since the workflow changes git introduces do have benefits.

Answer 4

This is an eternal challenge when leading developers, we're very stubborn.

Something to ask yourself, and communicate to the team, is why the switch was made. Was it too much time spent dealing with merge conflicts? Collaboration with a git-centric team? The desire to use some sort of tooling?

If the switch was made for a vague reason or the manager's personal preference, this resistance is to be entirely expected and maybe even they have a point. If it was to solve a problem or take advantage of an opportunity, the team needs to know what pain they will no longer have to experience, or what benefits they can expect.

Listen to their concerns, and make sure the git setup is addressing them. If they have legitimate concerns, reconsider the switch. Plenty of successful projects are using SVN.

Once this communication happens, I would set a date and shut down the SVN server. Don't release anything not committed to the central git repo. Don't keep the SVN server up just in case someone can't figure out the commits are local now and need to be pushed, when they have to make the change they will, and before that they probably won't.

Answer 5

A confused mind always says "NO".

I've migrated several customers from SVN to git and help establish git policy and workflow. The #1 problem is technical.

Git has a profoundly different philosophy behind it than SVN.

Doing a single demo will not suffice for daily technical usage.

Trying to use git, particularly if you come from an svn background will at first seem easy, and then become very confusing. Confusing = NO.

You do not say how well versed you are in git, but you should at least be a few steps ahead of everyone else before you attempt to move them. Otherwise, a lack of knowledge about how to use git and solve problems in git will be a further deterrent.

I recommend that you write a document about how to do daily tasks (are you a rebase shop or merge shop? are you using any git workflows?), solve problems, use branches (a very POWERFUL feature of git), pull and push, and finally recover from a merge conflict.

Once you have that, then you'll give them comfort that they'll be able to use the new system.

Then, choose a repo and get with the developers that work on that code and ask them to switch, and STAY WITH THEM. Turn off svn for that project and make their move as easy as possible by STAYING WITH THEM. Tell them you'd like them to pilot it. STAY WITH THEM when they do their first 5 - 10 pull/merge/push tasks.

Once they get used to it, and find out how to "think" in "git" then they will be your biggest advocates.

Then, repeat with the rest.

Answer 6

For this specific case (SVN to Git) I am not sure if it is useful to force the change onto all users. There are Git-SVN bridges available (eg. git-svn or SubGit) which give interested developers most of the advantages of Git while allowing other developers to keep using SVN.

The underlying idea is to tell your developers what to achieve, not how to achieve it. Here are the pros and cons of this approach, based on my experiences with git-svn:

Pros:

• people can switch from SVN to Git in their own time, rather than having to take time out in a stressful phase
• trailblazing developers can experiment with Git, can develop company-specific workflows, can find pitfalls, and can later teach their colleagues
• people can realize the usefulness of the new tool just by seeing their colleagues using it
• or, if the new tool is actually not an improvement, only the trailblazers will have to migrate back, reducing the costs sunk into a bad decision
• some trailblazing developer might actually find that eg. Mercurial+SVN is a much better tool for your work than Git+SVN. By not forcing specific tools onto developers they might come up with better solutions.

Cons:

• developers will feel encouraged to spend work hours for finding their own perfect VCS solution. Then again, this might happen anyway.
• some developers might never try the bridge software at all (due to laziness or unwillingness to learn new tools). If you finally want to switch from SVN to Git for real, you still have to deal with these people
• you can't use the new tool in all aspects (eg. git-svn still has some drawbacks versus a native central Git repository)
• you send the message that decisions are made by developers, not by management. Management itself might not like this message; also, developers might get too free-wheeling in future decisions. IMO this is an acceptable tradeoff, but in some businesses it might not be.
• if you have other reasons for a tool change (like, pressure from further-up management, or technical reasons brought on by Sysadmin department), the actual decision must probably be made by management and not be developers
• this approach only works for very specific cases. Switching from CVS to Git this way would be very difficult already, and switching eg. your bugtracking tool this way might not be possible at all.

Answer 7

It is a very useful skill to be able to effect change in an organization without having the authority to mandate it. It takes a light touch and explicit consideration of your audience. In many organizations, it's the only way to get things done. As it happens, my current role is all about being able to bring a larger organization with me to better technologies and processes.

The first step is to understand where the team is right now. Learn the specifics of their problems. Find out what the current technology (SVN) does well for them and what problems it has. Understand why they're working the way they are. Maybe they're doing some things that seem suboptimal, but it's not the technology driving those actions, but because there's something else they want that those things enable. For example, parts of my current company use a source control tool that is really, really bad for developers using source control, but offers a clear and automated promotion path to production across a number of (legacy) technologies. A big part of this is to understand all of the different people affected by a solution: it may not only be the developers accessing source control, but the release managers, the people involved in deployments, the auditing team, etc.

Step two: figure out what your proposed solution is going to improve for them, and figure out what else needs to be there so they don't lose the qualities of the old solution that are working for them. The organization's goal is to make things better! So you need to know precisely what the new solution will make better, what it will make worse, and ensure that things are better overall than they would be otherwise. And if at all possible, make it better for all stakeholders! If something is better for dev but harder for release management, you will have a fight. If you can make things better for both groups, you will get people to agree. To continue the example, you could use Git for developer source control but then automatically deliver artifacts to the old tool for deployment. You've made life better for dev while retaining the parts that worked well for operations.

Next, start small and learn. Pick a small group of people and get them to start using the new solution. This is important for two reasons. First, you need to start small so that you can ensure that it works. You can work out any problems. You can find things you missed. But more importantly, as one person you can only work with and educate so many people at once. During this initial phase, you are building a group of people that can help on the front lines with questions and advocacy. (This is often called "train the trainer.") Let the advantages shine through: "You mean I don't need to waste an hour and a half doing merges every sprint? You mean it tracks not only package changes but moved functions?" Assuming that the change is a good one, you should be able to make these people your cheerleaders.

After this, repeat with larger groups. Ensure you understand their needs, their problems. Show them the value of the change. Your solution may adapt as it reaches larger groups. That's OK. Different teams have different needs, which is why nobody in a large company is upset that some people use MS Word and others use InDesign.

Nowhere in the above do you need HR authority to mandate a change. In fact, the need to resort to "Do this because I'm your boss" usually shows a failure to follow the above steps, because either you don't understand why a change makes things better for people or because it doesn't make things better for some people but you will force them to do it anyway. (Unfortunately, things like audit and security often come down like this: making things easier for one group but harder for another, without finding a way for both teams to win.)

Answer 8

In my opinion, your boss abdicated this responsibility to you instead of delegating it. He didn't offer any suggestions on how to persuade the others and probably wanted you to break the bad news so he didn't have to listen to everyone complain.

It would be nice to know why the other team moved to Git so everyone could decide if it makes sense for everyone else to use it. Are you all going to be working on the same project? Does it make it easier to shuffle developers from one project to the other with at least not being concerned about whether or not they know how the code is being managed?

I realize people don't like change, but when you have sound reasons for doing things, many people will follow even if it is not their preference. Get some insight and possibly a level of authority from your manager to be more persuasive or he's going to have to do it himself.

Answer 9

Well if you are new, I normally wouldn't take responsibility for something like this. It may seem weird, but maybe they still see you as 'the new one'.

I would still go after them, and say they have to migrate and it's an order from the manager. Don't go all mad but just politely say it. You'll not achieve anything by being mad. Don't be afraid to tell others what to do as you have to be able to do those kind of things in a company.

Maybe you could ask them why they didn't listen to the email, though I doubt it will help it could let you know why they didn't migrate yet.

---

Don't just keep on emailing. The manager can ask you why not everybody migrated yet since you took the responsibility, if you say you emailed them, told them in person and they still didn't listen, it's less of a problem then then when you only emailed them.

Answer 10

People are busy and, by default, often won't take time away from their work to do something that they feel is unproductive. Often, the only way to deal with a situation like this is to use a stick as well as a carrot.

For example, as well as the demos, emails and instructions etc. you need to set a deadline for users to migrate. Once the deadline has been met, maybe offer a few day's grace period and then remove their access from SVN. If they still require access, have them submit a request to management to have it re-enabled.

Answer 11

Simple:

If you offer 2 ways of doing things, make both ways available, and allow both ways to be used, that is not a migration. It's the creation of chaos.

To migrate people on a new system you need to actually migrate. This needs a migration plan. A migration plan can be as simple as "From Monday, all new work will need to be checked in to git, svn will be used only for the existing release branches and no new branches will be created in svn. Mr Tony Lao is responsible to answer any questions you have on git, and will follow up with anyone who violates the new policy."

A good migration plan gives people advance warning, lets people provide input (and acts on that input)*, communicates each step clearly, and is flexible to change. If anyone is surprised once svn is turned off, the migration plan failed miserably.

*If people tell you they don't want to move to git, they will provide reasons. Listen to them, not to convince them, but because they may be right. If the team doesn't want to move, and the manager doesn't want to force them, there will be no move.

Answer 12

There is no reason for you to try to force everyone to use git. Let people adopt it as they see fit. Our company which is small has an SVN server and a git server and project managers can choose which one they want to use.

Arbitrarily forcing people to use tools you favor is a morale-busting move. Don't do it.

Also, as I am sure you are aware git is significantly more complex than SVN because it is a peer-to-peer system. That is great if you are doing a highly diversified open source project. But for simple, top-down projects with a single manager, the extra flexibility git provides is largely superfluous.

I use git for my own personal hobby projects because I bounce around a lot from different computers, but at work I continue to use SVN because it is a more simple model and at work we have zero need for peer-to-peer functionality. In fact, for the projects at work I do not want git because creating private repositories is exactly what I DON'T want people doing.