The wrong way to introduce new processes

Problem

"My previous job was at an agency, where we made software for other companies. We had a couple of projects and customers, and I was responsible for each project running smoothly. The problem was that each tech team was working with several different processes, such as Trello, Jira, Hipchat, daily standups, pull reviews, waterfall or Agile. This resulted in us losing a lot of time at the beginning of each project, when we would decide on which processes we'd be using. It was also hard for me to manage, as I had to adapt to the different tools and processes while trying to ensure each project was progressing."

"The problem was that each tech team was working with several different processes... This resulted in us losing a lot of time at the beginning of each project."

Actions taken

"I decided to implement a single development process for everyone to unify processes. I also hoped it would standardize how we worked and would make transitions and management of the projects simpler."

"I decided to implement a single development process for everyone to unify processes."

"I decided to create the new process as I had an overview of the problems experienced in the teams. For weeks, I did my own research and tested new tools to find the most efficient ones. Then, I announced that there was a new process to all of the developers and shared it with all of them. I asked for their feedbacks even though I didn't really intend to make any changes."

"I decided to create the new process as I had an overview of the problems experienced in the teams. For weeks, I did my own research and tested new tools to find the most efficient ones."

"This was a complete disaster. The teams didn't want to change the way they worked and didn't like the tools I'd suggested. Everyone was furious, especially because we hadn't asked for feedback before deciding on the changes. As a result, their motivation dropped and they were unhappy, as they felt forced to use a new process they hated."

"This was a complete disaster. The teams didn't want to change the way they worked and didn't like the tools I'd suggested."

"Ultimately, I had to force everyone to use the new process by using my authority. People complained a lot at the beginning, so I discussed it with every single person in our one-one-ones every week and made changes to the process by integrating their feedback into it. From a business point of view, this was much more efficient. After three months, all of the developers were using the process and stopped complaining since they started getting used to it."

"Ultimately, I had to force everyone to use the new process by using my authority."

Lessons learned

"With the benefit of the hindsight, I now understand how I should have introduced this big change. First I should have told everyone WHY we were thinking of making a change, and talked to everyone to gather their ideas . This way I would have made them feel like they had a part to play in the decision. Then I could have designed my plan."

"With the benefit of the hindsight, I now understand how I should have introduced this big change."

"Looking back, I also realize that I should have left it available to everyone while I was building it, and invited people to comment while it was still in progress. I should have tested my plan with a small group before announcing it to everyone, and get their feedback before improving it."

"Looking back, I also realize that I should have left it available to everyone while I was building it, and invited people to comment while it was still in progress."

"Last but not least, I should have presented it as an experiment - if people think of it as an trial they will be more open to trying new processes."

"Last but not least, I should have presented it as an experiment."