Adopting a Mature Engineering Organization in Startups

Have you heard of software companies struggling to go through the stages of business development? Yes, of course, all of them do. The CEO oversees the company, ensuring that there are enough funds and the team is set up to get the right things done properly. But this is not a one time phase. It is an ongoing challenge. The company must continue to develop to remain competitive and infiltrate new markets.

Then, when the business is more established, the founder brings in a new funding round, and the company is ready to scale. At this stage in a business’s life, there is usually an existing MVP that was designed to get the company into the proven product/market fit stage. Instead of redesigning the MVP with an architecture that can scale the software product, new funding is used to build more features on top of the MVP.

Very few companies at this stage are redesigning their architecture and turning this step into an advantage that allows them to move faster in the future, but this is the best time to do so. Often, companies come to this understanding when it’s too late and will cost them 5-10X more. Yes, really.

We have worked with companies that reach this stage and struggle to move forward at their previous speed. The hacking culture is essential for early-stage companies, as this is the only reason they exist, but too many companies skip their best opportunity to transition to a more scalable architecture. So, stagnancy due to unscalable software products is typical for startup companies.

At this point, the founder thinks “No, we don’t want to slow down, as we just got the funds and need to show investors growth and revenue. We’d better do it at a more stable time, when we have more engineers and predictable revenue.” Along with this, there is a pervasive idea that investors want to see the growing headcount of a company, and founders will literally burn the round to get more valuation in the next one.

So, given the hacking nature of the startups, the software built in the company’s early days usually has what is called technical debt, and the architecture is designed to support a limited number of users. Additionally, outdated deployment and release practices result in it taking more and more time to ship new code. The high cost of software support and maintenance is another consequence of maintaining the hacking culture. The company must be redesigned with the best engineering practices and best-in-class software to move forward.

The transition to a mature engineering organization doesn’t just happen. Someone must inspire and challenge the team to pursue a higher standard of code. That may be the company’s co-founder and CTO, or one of the early engineers. Again, hacking and engineering are different skills, and team members will not learn the best engineering practices overnight, immediately after the company is funded. So, the challenge is tough to resolve, as hiring the right talent to progress can take many months to accomplish.

For example, one of our clients had a Ruby application, and it was quite a shock when we first audited it. Any implementation of new features resulted in a huge, unwanted side effect. Our engineers were faced with a codebase of 125,000 lines, containing 275 controllers and 413 models. The total size of the main project database was about 20 gigabytes, not taking into account the statistics and analytics databases, with a total volume of about 600 gigabytes. There were around 300 regular errors, and the previous team was unavailable for questions, leaving us to figure out all the intricacies of the code ourselves.

The client had set business goals and had a pool of new features waiting to be released to meet those goals and increase revenue. We were able to rearrange the codebase to achieve lightning speeds and start releasing new features in as little as two weeks. Not only were new parts of the system built, but the affected parts of the code were also optimized. In addition to the routine support, development, and implementation of features, we also:

Now imagine if our client had spent months hiring new talent to optimize their system, losing revenue all that time. Instead, they got three engineers and team lead in one day, to help them meet their business goals. And that’s not all. After helping them with their immediate needs, we implemented the best practices for development management, team building, and technical leadership. So, the results? The client won the market at a critical point and hired new engineers later, into their mature engineering organization.

There are other ways to develop mature engineering organizations, and the best option depends heavily on the specific situation of each individual company. However, the previously described method is one of the most effective. Yet, many companies are failing to adapt to the distributed team culture or software outsourcing. They struggle to evolve and change under the market conditions and try to fight for in-house talent against established organizations, resulting in high burn rates, revenue loss, and somethings wrong hires.

In fact, businesses spend a lot more time and money trying to get rid of the symptoms of the disease, when they should ideally start with the treatment of the core problem. We recommend that clients sit down with an architect and an analyst to work on the business value first and craft a strategy for implementing world-class-software and developing a mature engineering organization.

Enterprises often face a similar challenge, but for different reasons and on a different scale. Maybe I’ll cover more on this later.

But again, this is a manageable challenge, and companies find ways to solve it, either on their own or by partnering with software design and development companies. Both methods are valid, and the best option depends on the business’s goals.