It's Time to Say 'No' to Manual Business Processes
Head of Frontend at Doist
The High Cost of Manual Processes
When the team is small, there is likely to be less human error, and some processes' automation might be a low priority. However, as you scale your business, you need to automate many processes to eliminate the mistakes, improve efficiency, and keep pace with everything.
Previously, when we wanted to release a new update to our users, it took approximately four hours and numerous manual steps to complete the process. We'd have to merge our pull request, manually create another pull request, update some static files, and deploy different parts of the front and backend.
The process was undoubtedly error-prone, or in some cases, someone may have forgotten one of the steps, which led to the people in the team not doing it regularly. Some days, we had 1 - 2 releases in a week — which was not a lot in a fast-paced environment. Instead of having one change at a time, we had 10 - 20 modifications bundled into a single release.
And if something broke in the meantime, we'd have to recheck 20 of those changes to figure out the root cause of the breakage. That was a nerve-wracking experience because when something breaks, we'd want to fix it quickly or roll back instead of spending ample time on it.
How to Put an End to Manual Workflow Management
Like most people in the industry, we adopted continuous deployment. What that means for the users is that whenever we made a change, it'd automatically get deployed to all users. There is some variance to that, where we could've gradually deployed the processes to a certain percentage of our users until we knew that it was stable. However, we went on to deploy it to all users right away.
Initially, there were some pushbacks on it. To deploy the whole process all at once, we needed to be confident that it was adequately safe. We needed to have the changes tested manually and automatically, and provide a level of confidence in everyone.
Therefore, we first invested more into our automated test suite (or unit tests), where we tested a small piece of code. Moving forward, we also added end-to-end tests for our core workflows to try that the users can fully work with the system. Once we had all that in place, we started working on our continuous deployment.
Whenever someone proposed a change, we first had something called "continuous integration," which was like running some static code checking. Then we also had the code review process. Another team member would look at every change and run it locally to ensure everything was working. It was automatically deployed to all of our users when it was merged.
We also communicated this with our support team. Whenever we fix a bug, we keep them in the loop that it has been released. Nonetheless, we automated a changelog, so whenever we released something or made a change, there was a message posted to everyone in the company. It would let people know about the bug fixes and the new features.
Be Confident and Fast
- Be confident in the changes that you have to make. If you feel that something is necessary and would improve the team's efficiency, sell the idea to your team. Know the impact radius of your changes, and bring it on! Of course, you'll never be 100% confident about a change, but what you can be sure of is the ability to roll back any time.
- Don't wait to create the right opportunity and then implement some processes. The idea is to do something fast, try and test it; if it doesn't work, roll back and start again with something new. This is most effective in a fast-paced environment.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.