The CTO vs Status Quo series studies how CTOs challenge the current state of affairs at their company to push it toward a new height … or to save it from doom.

“Only introduce complexity when it’s necessary”

Software architecture is not an easy idea to sell within an organization. After all, it’s something that only the engineering department fully understands. And yet, the same engineering department is required to have a complete understanding of the business.

But if you design your architecture with the business in mind from the start, you might not have to say, “It just can’t be done” to your colleagues from the product team as often.

Mujib has been part of Fixico’s growth from a start-up to a mature organization active in 11 markets. He told us what he had done and what he wished he had done if he could go back in time. Stick around if you want to find out:

• When to optimize your architecture
• How to best use microservices or modularization to your advantage
• Why, how, and when to collect metrics
• When it’s a good idea to get a dedicated software architect
• What the optimal software architecture feels like (and how to set yourself on a path to get there)

Meet Mujib!

Fixico today

Hello Mujib. Only a few months ago, Fixico signed a partnership with Europcar to extend its digital repair management services to Germany. That added more than 300 rental stations and their repair network to your portfolio.

Am I right to assume that this expansion also gave you a lot to think about as a CTO?

Mujib: Definitely. Germany was actually the first market we expanded to. we thought: “Germany is so close. Everything there should be the same.” But it turned out there were a lot of differences.

First, the culture is different, especially when it comes to compliance, privacy, and security. While the same laws applied, how people dealt with them and felt about them was totally different.

In the Netherlands showing the license plate is often not an issue, but people in Germany have different privacy preferences. As a result, we had to become more conscious and adapt to the local expectations.  

Another interesting challenge was the localization of services. In the Netherlands, a smaller country, we have a centralized system for vehicle and license plate registration, where the information is available from a centralised source. We naively assumed it would be the same in Germany – a simple API we could query. However, we quickly discovered that wasn’t the case. We had to figure out how to get vehicle information, and with so much to consider, we were left wondering: Should we create one system or two? 

We also debated which solution is the fastest. In the early stages, speed is crucial. No one is going to praise you for making fancy code or having a very efficient infrastructure.  What matters most is how fast you are compared to your competitors.

Ultimately, we opted for a middle ground. We developed a system that worked well at the time, but one that wouldn’t immediately support rapid scaling to multiple different countries. 

Naturally, this meant that we couldn’t easily scale our first experience with expansion to another country. We chose to focus on speed and execution in the moment rather than optimizing too early.

The problem with software architecture

The issue of market expansion is interesting in many ways, and today, I’m most curious about the software architecture angle.

Every time you extend your services, you add even more complexity to your architecture, more integrations, modules, and traffic. Does this ever worry you?

Mujib: At Fixico, we approach the complexity of scaling services with a strategic focus on sustainable growth. When we experiment with new technologies, we prioritize long-term stability over trendy solutions. Before adopting any solution, we assess its impact on our operations, ensuring it enhances our service without introducing unnecessary complexity—though that’s not always guaranteed.

For critical systems, we prioritize security and reliability. For more trivial features, such as dashboards and APIs, we focus on simplicity to stay agile. We selectively integrate microservices based on the positive impact they have on the user and developer experience early on to avoid over-engineering.

Our goal is to adopt technologies that not only meet our current needs efficiently but also align with our broader business objectives, ensuring every addition delivers real value.

I heard something similar when I talked with one of our experienced Software Architects. He told me that while scalability and flexibility are important objectives for fast-growing IT businesses to pursue, they both increase the complexity of architecture.

But how can you ensure that your level of complexity is in line with your business – not too big to handle, not too little for your needs?

Mujib: To ensure our architecture’s complexity is well-aligned with our business needs, we adhere to a simple principle: only add complexity if it directly benefits our end customers today. 

We closely monitor our performance metrics to anticipate needs a few months in advance,  maintaining an adaptable mindset to short-term and long-term changes. We set milestones and plan ahead, adjusting our approach as each milestone is reached.

Additionally, you need constant and continuous communication. If something takes too much time or effort with limited business impact, don’t be scared to take a step back and remove it. Replace it with something else and be open to trying different methods.

Managing software architecture – as a startup

We’ve looked into the future a little, but let’s take a step back now.

You’ve been with Fixico for 10 years now. You’ve seen it grow from a small startup to a big company with an international presence. Let’s talk about software architecture as this progression happened.

For starters, if you had to do it from the beginning, would you design Fixico’s initial software architecture setup the same way you did?

Mujib: When I joined Fixico, there was already a comprehensive platform in place with various dashboards. Our first step was to modularize this system by separating certain functionalities into APIs, starting with core features like notifications for apps, emails, and activity logging. This allowed us to better understand user interactions and system performance, such as email open rates and user behaviour.

As we evolved, particularly when shifting from a B2C to a B2B model, we continued this trend of isolating features into distinct services whenever their effectiveness was confirmed. This methodical separation helped us focus on what was working and expand it without overcomplicating the system.

Looking back, the gradual evolution of our architecture was pivotal. It helped us stay flexible and responsive to the platform’s needs. If anything, I would have accelerated this decoupling and validation process earlier to enhance our adaptability and scalability even further, but faster and more focused on the flexibility of the domain.

So, it seems that microservices can serve scalability well if you introduce them gradually. But I also heard about an interesting and less complex alternative to them that works for startups in particular: a modular monolith. What do you think about this approach?

Mujib: I appreciate the modular monolith approach, especially for its potential simplicity and efficiency. In startup environments with smaller teams that need to move quickly and deploy frequently, the modular monolith approach can be particularly effective.

While microservices offer significant benefits, they can introduce substantial overhead that’s often underestimated. Creating microservices just for the sake of it, without a clear organizational strategy, can dilute the benefits and complicate the development process. For instance, a single team managing multiple microservices while running the operations might struggle with inefficiencies and a scattered focus.

On the other hand, a modular monolith keeps things simple, making it easier for small teams to manage frequent deployments without spreading resources too thinly. It’s crucial, however, to avoid introducing complexity prematurely. Just like with microservices, complexity should only be added when absolutely necessary to serve real needs. Overmodularizing, much like overengineering with microservices, can create barriers—particularly when onboarding new developers particularly when there is no clearly defined direction.

In essence, both strategies have their place, and the choice largely depends on the specific needs of the business, as well as the structure and capabilities of the team. 

You made it clear that, especially at the beginning, business is simply so much more important than architecture. If you don’t find a way to make money, it doesn’t matter if you have perfect architecture. And finding that way often consists of changing, evolving, pivoting. There is little place for architectural maturity there.

But is there something else you can realistically do early on to help set the right stage for your application’s future scalability?

Mujib: The key is to build architecture with the developer experience in mind. It’s crucial to create an environment where engineers can efficiently develop solutions needed by the business without excessive constraints.

Giving engineers the freedom to innovate is essential. While the platform should be cost-effective, it must also scale effectively with the available resources to avoid unnecessary overhead. Employing scalable and flexible design patterns is beneficial, provided they align with our staffing capabilities and operational needs.

Moreover, having the right metrics in place is vital. These metrics should clearly indicate how the architecture meets business demands. If the team struggles to deliver impactful features with high velocity because of a poor developer experience then adjustments need to be made—not for the sake of complexity, but to genuinely enhance performance and support business growth.

Speaking of people, some startup companies may choose to acquire expertise in software architecture by teaming up with a third-party vendor. An experienced external team may impart a lot of practical know-how that will stay with the organization for a long time. When do you recommend this approach?

Mujib: Acquiring architectural expertise can be approached in several ways. Initially, recruiting experienced individuals is ideal, as building domain expertise within the team is a valuable asset—you then own the knowledge. If recruiting such talent isn’t feasible, then partnering with a third-party vendor becomes a viable option. 

For example, during our expansion into Germany, we leveraged third-party expertise for compliance-related projects, making it more efficient to collaborate with experts who are already familiar with these local requirements. Utilizing third-party vendors in such scenarios can bring valuable expertise and ensure compliance without diverting significant internal resources from core business activities.

Managing software architecture – as a scale-up

Let’s now tackle the scale-up stage.

At some point, your company started to figure itself out, and the number of customers rapidly increased. You mentioned that you started collecting data early on. But isn’t the scale-up stage, when you have more customers, the right time to really focus on metrics such as cloud cost per user or error rate? 

Mujib: Absolutely, the scale-up stage is critical for intensifying focus on key metrics to manage growth effectively. Essential metrics such as deployment speed, recovery time, and error detection are crucial as they directly impact operational efficiency and customer satisfaction.

It’s vital to have the right data at the right time. Inadequate data not only slows down decision-making but also complicates the development process, leading to bottlenecks that can hinder growth and competitiveness.

As the organization grows, the complexity of managing multiple teams and larger applications also increases. This requires robust plans for metrics that address both operational efficiency and evolving customer value. For example, effective automation becomes necessary to streamline processes and reduce overhead.

Moreover, as more customers adopt our solution, minimizing downtime becomes more critical—each minute of downtime translates to direct business loss. Compliance with service level agreements (SLAs) and maintaining stringent cybersecurity measures are not just operational needs but are key to fulfilling our promise of exceptional service to our customers.

Gathering the right metrics may also help you convince stakeholders that there’s a need to optimize architecture or re-architect it completely.

In your experience, is it easier to convince other managers to give you the time and resources needed for such initiatives in a more mature scale-up environment?

Mujib: Convincing stakeholders to allocate resources for architectural changes hinges on how effectively you present your case, regardless of the company’s stage. Speed is important, but aligning with business goals, and keeping up with industry standards and outpacing competitors is crucial. Presenting how our performance stacks up against these benchmarks over time provides a solid foundation for any argument for change.

For example, rather than simply stating the need to upgrade outdated technology, I focus on how such changes will enhance our development speed, minimize risks and scale operations, directly linking these upgrades to potential business growth and improved service delivery to customers. This approach shifts the discussion from technical needs to business impacts, which is required by stakeholders.

It’s essential to emphasize that while developer satisfaction is important, the primary driver for architectural changes should always be the business impact. If the current architecture impedes our growth or service quality, it justifies a re-architecture, not just for technical improvement but for substantial business benefits.

So, listen to the business and re-architect according to its needs?

Mujib: Yes, and the best way to do that is to collaborate with the product and other departments. Figure out together where the architecture should be in your product roadmap.

So, again, fostering cross-functional teams proves very important.

Speaking of team building, an interesting aspect of the architecture debate is whether you should democratize architectural knowledge by having everyone be responsible for it a little bit or, to the contrary – hire a separate architect, creating something of an architect guild within your ranks. What do you like better and why?

Mujib: At Fixico, we’ve experimented with both strategies and found value in each. We are committed to empowering our engineers to make informed architectural decisions, fostering a sense of ownership and broadening their skill sets. This empowerment is beneficial for both personal development and our business objectives.

However, we also recognize the importance of specialized knowledge, especially as we scale. Initially, we encourage a generalist approach where everyone can contribute to architectural discussions and decisions. This helps in building a robust foundation where team members are versatile and proactive.

As our needs become more complex and our team grows, we integrate specialized architects who bring deep expertise in specific technologies. This expertise is often critical and requires experiences that are typically gained through specialized roles in different companies.

Ultimately, starting with a generalized approach and gradually introducing specialized architects allows us to maintain flexibility and adapt to changing needs while ensuring that our architecture can support advanced and specific requirements.

Managing software architecture – as a mature organization

Let’s move to the final phase.

There comes a time when a business is mature enough for the architecture to catch up with it finally and become mature itself. What are some key markers of a mature software architecture for you?

Mujib: As Fixico steps further into maturity, a key indicator of our architectural maturity is the ability of teams to operate independently yet cohesively. Mature architecture at Fixico means having a system where teams are decoupled enough to scale their segments of the product autonomously, striving to excel and innovate within their domains. This setup allows for rapid development, high-quality, and impactful outputs.

Despite this autonomy, all teams maintain a high-level understanding of the overall system, ensuring their efforts align with our broader company goals. Management plays a crucial role in ensuring that while teams move quickly and independently, they remain aligned with the company’s direction.

The optimal situation needs to be maintained over time though. How can we ensure that the architecture continues to perform efficiently and even improves over time while giving the business the flexibility it needs to respond to changing business conditions?

Mujib: Effective architecture management hinges significantly on a robust decision-making process. Decisions should be reversible—this flexibility allows us to avoid the pitfalls of a rigid strategy and adapt quickly to new information or changes in the business environment. It’s crucial to avoid getting locked into decisions that no longer serve the business well, even if significant resources were originally invested.

Moreover, the software engineering environment must foster not just technical agility but also psychological safety, enabling autonomy for team members to propose and iterate on solutions without undue barriers. This environment encourages innovation and the continuous reassessment of solutions to ensure they align with business objectives.

Managing software architecture – the roadmap

Let’s take all these ideas we talked about and try to think about creating a generalized software architecture growth roadmap to sum things up.

Every business is different – that’s granted. But perhaps there are some universal pieces of advice that anyone can use at each of the three stages we talked about: a startup, a scaleup, and a mature business?

Mujib: For a startup, the stakes are high but not as high as they will be later, so prioritize speed and experiment a lot. Go for rapid development – you’ll learn the most from it.

Early on, I stayed very involved with engineering, perhaps a bit too much. Today, I advise managers who are joining startups to quickly and regularly engage with the business and commercial teams. Understanding how everything works financially and commercially is crucial.

For a scale-up, I’d advise to make sure that you are not the only person in charge, the only one making all the decisions. Everyone must understand the architectural issues and how they relate to business. That way, if an urgent project comes in, you should not become the bottleneck as a CTO.

The same goes for a dedicated software architect – even if you have someone like this, it should not absolve anyone from responsibility for architecture. So, make sure to distribute decision making early on.

Resources

While a lot of your expertise comes from practice, I bet you know some useful learning resources for CTOs who want to learn even more about architecture. Can you recommend some?

While much of my expertise has come from hands-on experience, there are a few learning resources I’ve found invaluable for further developing my knowledge of architecture and leadership in tech.

• The Culture Map by Erin Meyer – Since we work with a multicultural team, this book has been incredibly insightful. It dives into the nuances of how different cultures communicate and collaborate, which is crucial when building and leading diverse teams.
• Pragmatic Engineer Newsletter by Gergely Orosz – Gergely’s newsletter is a goldmine for software engineers and engineering managers. It offers practical insights, tips, and advice, which I find particularly helpful for navigating the challenges of engineering leadership.
• Lenny’s Podcast – This podcast is packed with insights from top leaders across industries, focusing on product, growth, and scaling. It’s a great resource for staying up-to-date on the latest trends and strategies.
• CTO Craft Slack Channel – A global community of CTOs where you can share experiences, challenges, and advice with peers. It’s been incredibly helpful for learning from others who are facing similar challenges.

These resources not only keep me updated but also offer new perspectives that help me grow as a leader.

What’s next? 4 actions for CTOs to take

So what do you think? How close are you to getting the kind of architecture that meets the expectations of everyone in your organization? Does it offer the best performance and developer experience and the lowest possible overhead?

Even if you’re not there yet, it’s only a matter of time with this action plan:

• Don’t over-engineer your architecture – optimize it for the current set of tasks, not the future ones.
• But do take care of your future by analyzing your past and present – collect the metrics you need to support your business.
• Don’t jump on bandwagons – pick only the technologies and tools that you can utilize to the fullest at present.
• Align the conversation about architecture with that about your business value – use it as the key driver of your decision-making in software architecture.

And don’t get stuck doing the wrong thing just because you’ve been doing it for a long time!