One of the most frequently used arguments behind the rise of Fintechs and especially neo-banks, is the inability of large incumbent banks to remain agile. Traditional financial institutions often struggle to rapidly adapt to changing customer expectations, evolving regulations, and technological innovation. Fintechs, by contrast, start smaller, carry significantly less historical software legacy, and operate with far less bureaucracy. Decisions are taken faster, teams move quicker, and products evolve continuously. In short: they are more agile.
Yet after speaking with many Fintechs and observing numerous start-ups and scale-ups from close by, I increasingly notice a paradox: many young Fintech companies begin to lose their agility surprisingly early, not because of business bureaucracy, but because their IT organization becomes the bottleneck. Ironically, this happens despite hiring highly talented, motivated, and technically excellent engineers.
In many start-ups, productivity drops almost immediately once the original founding engineering team starts expanding. The expectation is simple: more developers should mean more output. Reality is often very different. Even when new hires are excellent engineers, the total delivery capacity of the team frequently increases far less than expected, and sometimes barely increases at all.
Unlike large enterprises, where inefficiencies often originate from politics, outsourcing structures, rigid governance, or lack of incentives, the causes inside start-ups are usually much more subtle and often rooted in engineering culture itself.
One of the first reasons is continuous refactoring. Good developers care deeply about code quality and architecture. In start-ups, where autonomy is high and engineers are passionate, teams often continuously improve and refactor existing systems. Some refactoring is healthy, but too much refactoring becomes destructive. Large amounts of engineering effort get invested into "improving" systems without creating proportional business value. Teams end up polishing internal architecture while product delivery slows down. The challenge is not technical quality itself, but balancing engineering perfection with business impact.
Another important issue is the lack of documentation. Early-stage start-ups move fast and documentation is usually considered secondary. When only a few founding developers work on a codebase, knowledge exists implicitly inside the team and there is little need for formal documentation because everyone already understands the system. But once the team grows, this becomes a serious scalability problem. New joiners struggle to understand the architecture, design decisions, hidden workarounds, and historical context. Onboarding slows down dramatically and engineers spend increasing amounts of time explaining systems instead of building them. Ironically, the faster the company initially moved, the harder it often becomes for new developers to catch up later.
Another typical evolution is the absence of processes in the beginning, followed by an overcorrection later on. Small founding teams often collaborate organically without formal governance. Communication happens naturally, decisions are fast, and coordination overhead is minimal. This works extremely well until the team doubles or triples in size. At that point, companies typically introduce processes and governance structures to regain control. Unfortunately, many overcorrect. Suddenly there are excessive reviews, ceremonies, approvals, tracking tools, and architectural validations. The result is often the opposite of the intended effect: output decreases instead of increasing. The real challenge is finding lightweight coordination mechanisms that preserve autonomy while enabling scale.
Closely related to this is the difficulty of delegation and trust. Founding developers naturally know the codebase best because they built it and understand every shortcut, compromise, and design decision. As teams expand, these original engineers often struggle to delegate responsibility. They review every change, remain involved in every architectural discussion, and slowly become approval bottlenecks. This creates two problems simultaneously: senior developers produce less because they spend all their time reviewing and coordinating, while new joiners feel distrusted and underutilized, which quickly impacts motivation. Scaling engineering productivity therefore also requires scaling trust.
Another major productivity drain is the endless architectural discussion that emerges when several brilliant engineers work together. Software engineering is not an exact science and many architectural decisions involve trade-offs and philosophies rather than objectively correct answers. As teams grow, discussions become longer, more frequent, and increasingly theoretical. Without strong technical leadership, teams can spend enormous amounts of energy debating ideal solutions instead of delivering practical ones. Perfectionism becomes expensive.
At the same time, engineers are naturally attracted to new technologies. Most developers enjoy building new things far more than maintaining existing systems. As a result, growing engineering organizations frequently feel tempted to rewrite components, introduce new frameworks, adopt trendy technologies, redesign platforms, or rebuild existing functionality "the right way". Sometimes this creates real long-term value, but often it mainly introduces disruption and complexity. Technology renewal should remain a strategic business decision, not merely an engineering preference.
One of the most effective ways to maintain engineering productivity during growth is therefore having a senior technical leader with both authority and credibility. This role is extremely difficult to fill. Many companies assign architects to this position, but architects are not always trusted by engineering teams because they may no longer code actively, are perceived as disconnected from delivery reality, or are hired externally without historical context. As a consequence, teams may resist architectural guidance rather than embrace it.
The most effective technical leaders usually combine several characteristics: they remain partially hands-on, deeply understand the codebase, possess strong software engineering skills, and have enough authority and charisma to align teams around decisions and stop unproductive debates. In many successful start-ups, this role is initially played by one of the founders. However, as companies grow, founders themselves often become too far removed from day-to-day engineering realities. Maintaining technical credibility while scaling leadership becomes a challenge in itself.
Interestingly, many companies regain productivity by reorganizing themselves into smaller autonomous units again. Instead of building one large engineering organization, they split teams into smaller groups of a few developers (e.g. 3 to 5) supported by one or two functional profiles. These small teams communicate faster, make decisions quicker, retain ownership, and avoid excessive coordination overhead. Microservices can support this organizational model, but they are not a prerequisite. The real objective is not technical decomposition, but preserving autonomy and reducing organizational friction. Small teams scale psychologically better than large engineering departments.
The arrival of GenAI now introduces an entirely new dimension to developer productivity. Tools such as Anthropic Claude, Google Gemini, and OpenAI chatGPT can dramatically accelerate many aspects of software engineering, from challenging architectural decisions and generating design proposals to writing boilerplate code, generating automated tests, debugging issues, documenting systems, and helping developers understand unfamiliar codebases.
One of the biggest productivity gains appears when engineers need to work on systems they did not originally build. Tasks that previously required hours or even days of reverse engineering can now be accelerated significantly. GenAI can explain code structure, summarize logic, generate documentation, and even help developers make their first contributions to unfamiliar repositories much faster. For growing engineering organizations, this is potentially transformative.
However, GenAI also introduces new challenges. On large codebases, AI agents can sometimes drift out of control, generating excessive changes, consuming massive amounts of tokens, or moving into technically incorrect directions while appearing highly confident. Effective usage therefore requires active supervision. The best engineers are not those who blindly follow AI suggestions, but those who know when to guide, constrain, redirect, or stop the AI entirely. AI-assisted development is not autonomous development.
Despite the enormous acceleration GenAI brings to many engineering tasks, many organizations still struggle to measure dramatic overall productivity improvements. This may seem paradoxical because most developers genuinely feel substantially faster.
There are likely two important reasons for this. First, actual coding represents only part of a developer’s total workload. Large amounts of time are spent on meetings, coordination, onboarding, architectural discussions, debugging, reviews, incident management, and understanding business requirements. As a result, even a 50% efficiency improvement in pure coding time only has a small impact on total productivity. The bottleneck is often organizational rather than technical.
Second, the time saved through GenAI rarely remains unused. Developers quickly reinvest those gains into writing better tests, improving documentation, validating edge cases, challenging designs more thoroughly, and increasing code quality overall. This may not immediately accelerate visible feature delivery, but it likely (if sufficient pragmatism is kept) improves long-term maintainability and software robustness considerably. In other words: GenAI may not only make developers faster, it may also make them more ambitious.
Ultimately, the biggest threat to engineering productivity in growing Fintechs is often not lack of talent, motivation, or technology, but complexity. As organizations scale, coordination overhead, architectural debates, lack of trust, fragmented ownership, and uncontrolled engineering ambition slowly begin to dominate delivery capacity. GenAI will undoubtedly help engineering teams move faster, but AI alone will not solve organizational inefficiencies. The companies that remain truly agile at scale will likely not be the ones with the most developers or the most advanced AI tooling, but the ones that preserve small-team autonomy, maintain strong technical leadership, balance engineering excellence with business pragmatism, and use AI as an accelerator rather than a substitute for sound engineering judgment.
Comments
Post a Comment