From a burden technology to a growth enabler technology

Introduction 

As C-levels in high-growth companies, how often do you feel that your tech is lagging behind? Where so many trade-offs have to be made?

This article is aimed for you, to take on Brigad's journey to drastically improve your Product Engineering velocity: we now iterate on our product four times faster than before.

How can you cross the gap between a MVP of a product driving traction and tech built to drive scale-up growth? How can you turn your early stage startup’s tech to a scale-up startup’s tech? 

At Brigad, this step hasn’t been attained in a jiffy...

Let’s jump back in time and introduce ourselves.

Brigad’s mission is to make work accessible and attractive to all.

We aim to become the leading European platform that matches companies and skilled self-employed. To date, we operate in the hospitality and healthcare industries, both in France and the UK.

The road to achieve our mission is made of challenges. 

Lately, we realized that we were at a crossroads on a technical point of view. We saw that we were about to hit a ceiling: The more we iterated on the product, the slower it was.

This slowdown is the result of choices taken during our early days.

My motto has always been that the product should never be the bottleneck of growth.

As an early stage startup with limited resources, we often had to make compromises and tradeoffs to have a product that allowed a 3x YoY growth. And we often focused on the product at the expense of the tech.

And then, we reached a point where the actual product was good enough to support our Sales playbook, but our technical debt was definitely there and became the highest risk for the company's growth.

So, we chose to change course. It was time to grasp the nettle, and to start a long-awaited refactoring to turn a burden technology into a growth enabler technology that drives faster product iterations, organizational changes and eases the execution of business opportunities.

And this new strategy proves its worth: 

• PMs are now able to push code into production,
• Our iteration capacity has significantly increased.

But how did we get there? What was our thought process?

In this article, I will share with you:

• Our elements of analysis, what exactly led us to start such a move, 
• How we managed to set this up at Brigad, 
• How you can set up this strategy in your own company to speed up your growth and strengthen your business, product and organization.

Analysis 

Initial context 

At the beginning, we were in the same situation as many young companies: 

• We didn't have enough experience to take a step back from our product and its evolution over time, 
• We couldn't definitively forecast our growth specifics,

• I said to myself: “Tech, like Product, shouldn’t be the bottleneck of our growth.” 

But we lacked resources. Every euro was important. We couldn’t always afford to refactor along the way. We made some tradeoffs and took some shortcuts. 

When we found our Product Market Fit, the goal was to improve the MVP, by delivering all the key features to address our market needs. 

Few words regarding our market needs. At the beginning, the growth of our MVP was exclusively made with SMBs. But quickly after, we started to have touchpoints with bigger groups. But our product was not complete enough to be distributed in large companies.  They needed much more features such as a proper corporate space, invoices collections, different payment workflows, a more automated financial infrastructure, and so on… 

Five years later

But, five years later, this strategy caught us. We felt that the tide was turning. Slowly but surely, our tech was becoming a burden for our growth. In 6-9 months, as soon as the rhythm would accelerate, we would have truly lost our velocity.

We reacted. Several triggering factors played in our new orientation: 

• A Momentum Period: Our product was ahead of time and we had enough resources. We had to ride the wave before it was too late. 

• Our way of designing the tech: As a CTO, one of my responsibilities is to define the right level of technical investment. To control technical debt and to avoid over engineering. As a tech company, your tech is your main asset. It should always be a concern for the C-level group and the investors. An uncontrolled technical debt is a critical risk for your company's health.
• A push from Product and Tech teams: Product and Tech teams were fed up with the decreasing velocity and decreasing confidence in what we shipped. They also had a good view of our weaknesses and our actual and future major product needs. 

In our heads, it was clear that it was the right timing to change course and to take the time to heavily invest in our tech.

Setting up at Brigad

Our main product is a two-sided marketplace where each audience needs a significant number of complex features to have the best quality of service we aim to provide. 

These features are very different and require very different skills. Some are related to well refined-UX, others concern automation of complex processes, and last, having an end-to-end payment infrastructure up and running. 

At Brigad the key principles regarding our tech are: 

• A modular tech: where it's easy to add new features in our product. 
• A tech that favors fast development cycles.
•  A tech accessible for even non-dev.

Refactoring 

Before the refactoring, we defined several tech goals: 

• To focus our refactoring on the back-end.
• To list all our drawbacks and chuck them out.
• To create an accessible tech to onboard everybody, even not engineers.
• To elaborate a new architecture which looks like a puzzle with a lot of pieces.
• To automate as many tasks as possible to step up our capacity to deliver. 

But during the refactoring, our goals progressed: we took advantage of the opportunity to audit our front-end and we also reviewed the way we integrate design, because it was a pain point as well, that became even clearer when the back-end velocity began to rise sharply.

So we decided to invest time and efforts in the front-end integration strategy, by creating a cross-platform design-system, which considerably reduces the time needed to integrate design at scale, on both, web and native mobile. 

Our roadmap was reshaped: we focused 80% on the refactoring and 20% on urgent iterations. 

In the end, our refactoring consisted of writing 500k lines of code, which lasted 12 months, with 7 months without significant product upgrades. 

Before going forward with such refactoring. It's very important to align all the team with this strategy. Everybody needs to understand why we need to do this, what it will bring and why we can't wait. This alignment is crucial within the product team, but especially for the team out of the product & tech spectrum. Everybody in the company should be aware of the upcoming refactoring and be aligned with it.

Also teams need to understand how they will  be affected during the refactoring. That some well-awaited product features won't be released before months if not more.

But during the refactoring, it's also very important to be resourceful and to find ways to tackle some big pains by finding some quick wins. Again, your product can't be a bottleneck of the growth.

In the end, as a tech leader, it's a game of balancing the bandwidth of the team between the refactoring and product iterations. And it’s very important to take the appropriate time to review feature requests not to miss some iterations that could have a big impact on the business.  

Regarding communication, it’s key to getting out of technical concepts and vocabulary when explaining a technical refactoring to non-technical teams. So I compared tech with construction work, more specifically with building a skyscraper. 

This was the picture I drew: 

“Imagine our users are tenants, our product is a flat (replicated for each user) and our tech is the building supporting all this.

If we want more tenants (users), we will have to add floors (product). But the foundations (our tech) must be solid, otherwise the whole building is at risk.

And if we want to better satisfy our tenants, we must provide some improvements in the flats over the time. Some of these improvements can require some heavy lifting in the building. 

Take the example of air-conditioning. It’s a major upgrade that will have a strong impact on tenants satisfaction. There are two solutions to install such system in a building:

• The first solution is to install individual appliances in each flat. It will require a lot of maintenance and the quality will be poor. 
• The second solution is a central air-conditioning system. This system is of much better quality, its maintenance is simpler (only one thing to maintain, to repair). However, the initial work will be longer and more expensive. But you will end up with a more sustainable system. 

The first solution could be considered as a quick-win. But the bigger your company is, the harder it gets to create and maintain quick-wins. At some point, you need to make significant product changes, and if your tech architecture and code are not fitted for that, it will become a bottleneck.

The main objective of our refactoring was to have a very modular tech infrastructure that favors the adding of users and some big product changes.  

It is a mandatory investment to enable tomorrow's growth.” 

Results

And, indeed, thanks to this refactoring, what we hoped  is now happening:

Our tech stack became very accessible, so PMs can now code and ship small features.

Product Managers can fully own a feature from design, through code to the deployment.

We iterate quicker than before and we have a solid testing strategy that gives more confidence in what we ship.

It’s so true that even one of our PM - Nicolas - moved to a position of a Product Engineer where his scope now includes a mix of missions between a Product Manager and a Software Engineer.

And here is a short interview with Nicolas on his new role at Brigad:

"Before with our tech, there were a lot of bugs. Now it’s a springboard for creativity! The performances of our product and its development have been improved considerably. I can develop simple features myself, without the help of developers and designers. In 2019, I couldn't have worked like this because the techs weren’t accessible to people without developer training and background. A new job is seeing the light of day in tech companies: Product Engineer. I understand the needs of the users and, at the same time, the tech problems. These two hats allow me to make good decisions. And when I am confronted with complex features, we take a classic pattern: a designer and a developer help me. It’s as simple as that.”

Therefore, our refactoring boosted and changed our organization: 

• Our software engineers focus on complex problems,‍
• A part of the engineering workflow is delegated to PMs who are tech savvy. 

Then, the development of a feature flows better because we have less mutual dependencies. But our engineers always glance at the engineering works of PMs.

In our human resources organization, we will formalize the fact that our profiles can  become full-stacks (and not only the engineers)!

Tech became even an enabler for opportunities in our organization! 

Setting up in your company 

Every business is different, so adopt these tips to suit your market, your tech, your product and your resources. 

Of course, the best case scenario is to have enough resources to afford technical refactoring along the way with your product iterations. 

But if you do not have the choice, choose your battles. 

• Rush your MVP. Found your PMF. 
• And when you can (with a larger and senior team, more resources, more experience), get an overview on the refactoring, define what you want to do. “What do we want to achieve?”

Take all the playbooks of your company and ask yourself: “Are our products a bottleneck of these playbooks?”. Example: you can't deploy in the UK because you don’t manage Pound Sterling. In other words, what pieces are missing?
It’s important to define when the Product will be mature enough for the stage of your company, meaning that it will be the right time to perform a large technical refactoring. 

• Create a unique roadmap for product and tech. Product and Tech must be aligned. They mustn't be competing. It’s the most important thing.‍
• If your business allows it, make sure that your tech is accessible to the greatest number of no tech people. Your tech will increase your growth. 

By making your tech an asset, we will leverage your business, product and even your organization! 

Keep in mind that tech is the main key to creating the leading tech company in a market.

Conclusion 

Too often, the good health of the code base isn’t a source of talk in companies, neither with the board of investors nor the leadership team. 

In my opinion, it’s a mistake. Often the board and C-level understand the weakness of their tech too late. Usually when it’s already a bottleneck of the growth. And at this stage, the road ahead will be long and painful. 

How to avoid this unpleasant situation? 

All C-Levels (not only the CTOs) must be aware that the tech is a key enabler for their product and their business. Sometimes it’s difficult to get to understand this because tech isn’t considered to be a direct subject of growth. 

But, in fact, it’s the main way to leverage your company. 

When this stage is crossed (and it’s not easy), ask yourself the right questions:

• What’s the role of our tech in our company? Do tech is used only to build a product, or does it play a big part of your operations too?
• How healthy is our tech?  
• What should the key principles of our tech be? Focusing on blazing-fast performances? Favor fast product iterations? 

To answer those correctly, nalyze :

• Your roadmap, 
• Your bugs and their effects,
• Your capacity of iteration,
• The feedback of your teams. 

When you have all these elements, in other words, a good view on the healthiness of your company, you can make the call.