Nuri — formerly Bitwala; How To Manage An Ambitious Rebranding

This is not a marketing article. This is my way of appreciating everyone’s hard work and talking a bit about my experience, and showing the challenges we faced.

With this very uncomfortable situation on our shoulders, we were left with trying our best.

First off, we needed to onboard all the new people very quickly. Deadlines were very tight, and the amount of work was considerable.

Stage 1 — Hiring

Hiring experience at Bitwala tends to be very hands-on. There are usually two rounds of hiring that are in the hands of employed engineers. Interviewers are generally from the teams that’ll end up working with them. That makes it easier to assess whether it’s the people the team is going to be happy with.

Stage 2—Getting To Work

As ambitious as Bitwala is, there were a few things that we were lacking. Due to the huge amount of work on new features, our processes were not set up in a way that'd allow us to get new people up and running all that quickly. Another problem was a considerable amount of technical debt, which meant onboarding new people took even more time. That was a very big risk to the entire project. If we didn't get people up to speed quickly, we'd lose our very valuable time, and that'd risk the delivery.

My role was fairly clear. Set up the project and all the teams for successful delivery with as few problems as possible in the process.

Along with a specific hiring process, we also had a specific definition of done and certain other processes. That was critical as that also helped us to get started a bit quicker. Compared to our regular definition of done, we’ve had several changes:

  1. Any changes can't impact the current apps. As all our changes were deployed to production and were just hidden behind a feature flag, it was imperative that we didn't change anything in the existing app. Building a new app entirely wasn't an option (and I'm going to be talking about that later in the next more technically aimed article), and so we needed to migrate as much as we could as easily as we could. Therefore we knew all our redesign code is, in fact, the production code. So we treated all changes as such.
  2. Change requests required screenshots. This was a very visual project. And as we had a limited amount of reviewers, having screenshots of every state of the app was a faster variant of reviews. The alternative was only to run the code manually and check visuals. That'd be unworkable. This rule really helped us to get valuable visual reviews quickly and with a little effort from reviewers.

Having these risks taken care of early on resulted in zero breaking changes into our production app.

That, for me, was a major achievement.

Stage 3—Adapt

A value that was the root of Bitwala's existence from the very beginning.

The processes set up at the beginning were working well for some time. But as new challenges came up, we had to adapt.

As you can imagine, this project was very ambitious from the very beginning, and it came with many challenges. One of the major ones was the fact that we had other ongoing projects in the company.

That meant that we needed a focused effort on not just breaking current functionality but also the future functionality. We had to keep in mind that our delivery also doesn't limit the delivery of other teams.

The only solution to this was to increase the communication between the teams and continue with targeted reviews. The communication meant more meetings, and the time was scarce. But it was unavoidable. The targeted reviews were already happening. People who'd work on a certain feature would be in the reviewing process of the redesign work that'd touch the feature. We've done targeted reviews as much as possible since it meant we could avoid having to have everyone in the loop, and it'd help us avoid bugs more effectively.

Stage 4-Nuri Grand Release

Probably the most difficult part of the entire project. If we had to adapt during development, in this phase, we needed to adapt way more. That doesn't mean there was a lack of planning. It meant we had several plans, and they kept changing as we were developing a better way to execute this last phase.

I'm completely convinced that it's the dedication of the engineers working on this that made us make it through challenges like this.

At the testing phase, we found a couple of new issues (as one does when testing). Some of them were caused by the technical debt acquired over the years of rapid feature development at Bitwala. Others were regressions from ongoing projects. And some were tied with the redesign itself and its challenges.