Back to resources

It's Time to Say 'No' to Manual Business Processes

Changing A Company
Conflict Solving
Internal Communication
Feedback
Team Processes

6 April, 2022

Henning Muszynski
Henning Muszynski

Head of Frontend at Doist

Henning Muszynski, Head of Frontend at Doist, talks about the cost of slow and arduous processes that add up over time and how to bring the changes systematically.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Leading A (Distributed) Team? Foster "Above the Line" Behaviors.

12 July

No online tool will address your team's ability to connect, collaborate, and deliver results if the individuals don't bring the right mindset to work.

Changing A Company
Building A Team
Company Culture
Leadership
Ownership
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

Managing Through a Team Reorganization

15 June

Mugdha Myers, former Engineering Manager at Google, discusses the challenges of leading a team through the ambiguity and anxiety caused by a large-scale team restructuring.

Alignment
Changing A Company
Strategy
Changing Company
Mugdha Myers

Mugdha Myers

Engineering Manager at N/A