Change Is A Necessity For Growth, But Should Be Approached Thoughtfully

Problem

As a startup, you get used to doing things in a certain way. It is easy to forget what is going on in the industry, mostly because you are always under the pressure of delivering quick iterations and meeting metrics.

This pressure is especially prevalent for the growth team whose objective is to get as many metrics as possible from the top of the funnel.

Because we were not up to date on the industry standards and some of the engineering best practices, we had accumulated enormous technical debt, which remained in the back seat for too long.

The bulk of the problem was that the codebase between two different significant parts of the web-app was duplicated in large parts. The immediate effect of this was seen every day during implementation, testing, and ultimately on the metrics. The PM had to choose which users could see the latest product updates based on the developer/QA effort and business impact. Ideally, all the users should get the latest UX enhancements.

I understood what the next architectural improvement should be to increase developer productivity and velocity to ship product features. We would need to build a shared component library. To begin with, both of these apps would build features using the fully tested shared components. Eventually, as we build more single-page apps and micro-frontend services, this library would be a foundational layer. Nobody was opposed to this idea.

However, the devil is in the details, and there were conflicting beliefs on how we should build this library.

Two different groups felt strongly about how we should deal with this. One thought we should define the standards based on how we had always done things, and then the other group believed we should use the latest industry standards to create our new shared library. Due to the disagreement between both parties, things became stalled.

Having a code base with the latest industry standards, for a language or technology, has many advantages in improving security, performance, etc. Moreover, when new engineers join the team, they work in a familiar environment and get onboarded sooner. In this particular case, the details of the language or framework are not as important as understanding the disagreement and the underlying reasons behind it.

Actions taken

I observed that there was a tendency for engineers to join different camps, which was led by two people. It took me a while to understand, and it was not a lack of agreement that we needed the shared component library. It was the lack of alignment between two senior engineers. It took me a few iterations to understand where the problem was and why there was opposition from multiple angles.

However, if I had to peel the layers, the problem became more simplified.

Next, I talked to the engineer who had worked with us for the past seven, eight years. I asked him about his process and why he was inclined to do things the way he always had, despite the new industry standards.

He had a logical explanation. He was wondering why they had to change. He explained that we were so used to the way we did it that changing it might be counterintuitive. Sometimes it is nothing more than a straightforward process. Their eyes and mind worked to a particular style, which would be incredibly hard to change.

I thought that was an excellent argument.

However, we are a growing team. We want to onboard five to six new engineers in the next six months, maybe more. These new engineers are likely to be up to date on the industry standard, not the way we are doing it. It would not make much sense for us to say, “Hey, this is the company way. You need to change and unlearn these things so that you can learn the outdated way we do things?” How do you think the new engineers would feel?

This point seemed to click for him, and it explained the crux of the problem nicely. Simply put, the company way is not the right way in many ways. We had to make some choices.

What works for five engineers does not work for ten or fifteen. As you have more and more engineers working on the team in a common codebase, there is a higher potential for conflict and personal preferences if there are no standards or guidelines.

The other thing I recognized was the need for the two camp leaders to work together.

To work towards that goal, I had a two on one meeting with the senior engineers. I called them together and explained that their indecisiveness and lack of alignment is costing the business because our velocity is significantly high for small features. Having a shared library to de-duplicate code is not a novel concept and should have been implemented by now. We need to come to a consensus and look at the bigger picture.

I explained to them that there are industry standards, and we should follow while doing our best to account for personal preferences wherever applicable. Since there is not one defacto standard, and we things are always evolving, we can strike a balance.

Lessons learned

In that two-on-one meeting, we all learned that the old camp needs to understand it must evolve to some of the new industry standards. On the other side, we recognized that the people who are advocating for industry standards need to empathize with those that will be impacted by the changes.

Each side had to give something to gain something. This realization helped us figure out the best strategy for everyone. At the end of the day it worked, it worked well.

Overall, the culture within my team is fantastic right now. Even more impressive, both of the camp leaders have moved on to newer positions. One of them is an engineering manager, and the other is a technical lead manager of the team.

Nevertheless, I did learn that there is no silver bullet. For me, that is the biggest thing to learn as a leader. Do not jump to conclusions or take sides. You may be tempted to follow one way or the other, but it is imperative to be mindful when making cultural changes, especially when you are making a change that is going to affect engineering day to day.

My role was to identify the need for change and to facilitate the transition. I did not make any decisions on how the shared library should be built or structured. The team was empowered to make the right choices once they were aligned and agreed on the big picture and impact.

Change is costly, and the longer we do not change, the more expensive it can become. However, the change should be incremental. Do not just rip the bandage off. That is going to disrupt the developer workflow entirely.

It is so important to strike a balance.

You need to be very truthful. You must define and explain the impact and cost of the problem and the solution. It is more than just resolving conflict. When you approach it in ways that empower people and teams, they will also come up with solutions that work while accounting for the impacts and costs. This approach leads to learning and growth opportunities that resonate with everyone. Not only will this approach help you convince your team that changes are needed, but you can also convince your leadership of the necessity of change.