Software Engineering Excellence. Part 1. Realities vs Idealism

Working with dozens of companies as their fractional CTO gives us a unique perspective on common engineering challenges. Certain patterns emerge consistently, whether we're helping a Series A startup to scale the cloud infrastructure or guiding an established SME through a digital transformation journey. The core components of engineering excellence remain surprisingly constant across company sizes and sectors.

At the end of last year, during our quarterly CTO roundtable we started an interesting debate about what engineering excellence really means in practice. Moving beyond technical buzzwords, we get into territory that actually matters. One technical leader spent a lot of budget over about 18 months on a microservices transformation their team wasn't ready for. Another maintained a "boring" tech stack that consistently outperformed their competitors with much more sophisticated systems. Interesting… right?

The technology landscape has shifted dramatically over the past decade. Cloud computing became not only a standard option but usually the only option for many businesses. Microservices replaced monoliths. Web3 is changing the landscape of people's interactions. AI is rapidly transforming from buzzword to clear business opportunity. Yet the fundamental challenges persist. Teams struggle with scaling. Technical debt accumulates. The pressure to adopt new technologies never ceases.

A recent situation perfectly illustrates this dynamic. Our client (SaaS company) engineering team pushed hard for a complete authentication system rewrite, arguing their existing code was "ugly" and “outdated”. However, our analysis revealed that it can handle 100,000 daily users without issues. The real challenge wasn't technical - it was mostly to manage the team willingness for architectural perfection against actual business needs. So we found them another challenge, but this time much better aligned with business needs.

This pattern repeats across industries. Another client of ours, a fintech company, spent six months implementing event sourcing architecture, only to watch their velocity drop and struggle to hire developers who could maintain the system. Meanwhile, their main competitor launched three major features on their existing stack. Guess who is now in a better position?

Success often looks different from what you read in tech blogs. A bootstrapped SaaS company reached $10 million in annual recurring revenue using what many would consider outdated technology. Their monolithic Ruby-on-Rails application, deemed outdated by many great engineering minds, proved remarkably scalable and maintainable. While others rewrote their systems in the latest frameworks, this team focused on solving customer problems. Only recently they hired us to make the next step, but in a very careful and considered manner.

Engineering excellence manifests differently at various company stages. An early-stage startup tried copying microservices architecture inspired by a tech talk delivered by EasyJet, burning through half their runway with little to show for it. After our guidance on consolidation and simplification of their services their deployment frequency tripled. What works for bigger companies often proves disastrous for the smaller.

Technical debt is another thing that generates endless debate in engineering circles. Many teams treat it as universally bad, but reality proves much more nuanced. One marketplace deliberately chose to duplicate code across services during their expansion phase. This pragmatic decision helped them enter five new markets in six months. Once their market position stabilized, they had both the resources and knowledge to properly refactor their systems. So it’s always not only about doing the right thing, but also doing it at the right time.

Infrastructure choices is another type of decision that can make or break a growing company. A B2B SaaS startup initially insisted on building everything in-house - authentication, payment processing, and email delivery. They thought that relying on a 3rd party was risky and they wanted more control over everything. After several months of slow progress and mounting technical complexity, they shifted (with our help) to using established services for non-core features. This decision cut their time-to-market in half and significantly reduced operational overhead.

The numbers tell their own story. A marketplace tracked their development velocity before and after their microservices migration. The data showed almost 60% slowdown in feature delivery - an excellent reminder that architectural decisions have real business impact. Several other companies reported similar findings, challenging the assumed benefits of complex architectures. Don’t get us wrong, we love microservices and event-driven architectures and modern tech stacks

Successful engineering cultures share certain characteristics. They focus on outcomes rather than process. They make decisions based on data rather than trends. We know a company that transformed their development process by requiring business impact justification for every major technical decision. Their team's productivity almost doubled within less than 6 months.

The challenges keep evolving. AI and machine learning introduced new architectural considerations. Edge computing disrupts established patterns. Remote work transforms collaboration models. Yet the core principles remain - focus on business value, embrace pragmatic solutions, and build for sustainable growth.

These insights come from years of hands-on experience and hundreds of technical decisions. The next three articles in this series will explore specific challenges: scaling engineering teams effectively, managing the real costs of technical decisions, and making smart build-or-buy choices. Each piece will draw from actual field experience, not theoretical ideals.

The pursuit of engineering excellence isn't about following a predefined path. It's about making informed timely choices based on specific context and constraints. In practice success often looks different from popular narratives. Sometimes it means choosing the “boring” solution or older technology. Sometimes it means taking calculated technical debt. But it ALWAYS means delivering real business value.

Technology keeps evolving, but the fundamentals of effective engineering leadership remain surprisingly constant. The most successful teams focus on business impact, make pragmatic choices, and maintain the flexibility to adapt as their needs change. That's what real engineering excellence looks like in practice.