Leadership and Team Management
Can you describe your leadership style when managing development teams, especially in high-pressure technology environments?
I firmly believe that effective leadership centres around empowerment rather than dictation. Whilst there need to be certain guidelines in place, I've always found that micromanagement is counterproductive. This philosophy becomes particularly relevant when we consider the current debate about returning to office-based work. Many long-standing people managers seem uncomfortable with remote working arrangements, primarily because they can't physically observe their staff—a mindset that, to me, speaks volumes about a lack of trust and empowerment
In my approach, I focus entirely on outcomes. I often tell our engineers that I'm not concerned with whether they've worked six, eight, or ten hours—what matters is delivering results and meeting our objectives. We've all encountered colleagues who simply 'put in the hours' without producing meaningful output. Conversely, we have team members who are brilliant but might be most productive later in the day. Some of our finest developers aren't morning people, but they truly excel in the afternoon and early evening. It's about providing the flexibility and demonstrating trust in your team to work in ways that best suit their productive periods.
I’ve implemented quite a flexible approach to this do this. While we obviously use Microsoft Teams for communication, we've empowered our team leads to manage their own scheduling. If a team collectively decides that 11:00 is the optimal time for their daily stand-up, that's perfectly acceptable. Similarly, if they prefer 8:30, that's fine as well. The timing isn't critical—what matters is ensuring everyone's aligned on the next 24 hours' objectives.
Different teams naturally develop their own working styles and preferences. It's worth noting that the adage about engineering teams rings particularly true: it takes considerable time to build a well-functioning unit. Any disruption, such as team members leaving, can be quite detrimental to productivity. That's why it's crucial to retain talented staff who understand their role and contribute to the team dynamic. When changes do occur, there's inevitably a period where the team's productivity may not match its previous levels.
Development Process: What methodologies do you prefer to use when managing development teams, and how do they align with the unique needs of the financial sector?
We've adopted a hybrid approach called Scrumban that marries the best elements of Scrum and Kanban, creating a fluid and responsive development process. While we maintain the familiar rhythm of two-week sprints, our teams aren't bound by the conventional 'plan-execute-deliver' cycle that typically characterises fortnightly sprints. Instead, we embrace a continuous delivery model where our teams can push changes to production multiple times throughout the day. Achieving this demands that we have a robust and fully automated test set. The Kanban influence in our methodology introduces thoughtful work-in-progress limits, with planning sessions naturally triggered when our backlog dips below predetermined thresholds.
We've structured our platform around well defined domains, with each area maintaining a singular, focused responsibility. Our teams operate as comprehensive 'build-run' units, taking full ownership of their respective domains. This encompasses everything from initial design and construction through to deployment, daily operations and ongoing support. Each domain effectively functions as a 'black box' to other teams, operating with clearly defined boundaries and interfaces.
This offers several advantages. First, it significantly reduces cognitive load—team members need only deeply understand their specific domain and how to interface with others, rather than grappling with the complexity of the entire system. Secondly, it enables more precise and focused testing at the domain level, rather than necessitating system-wide testing for every change. And finally, it creates a more scalable architecture, allowing us to extend the platform more efficiently through domain-specific components.
The approach allows teams to become genuine specialists rather than generalists, fostering deeper expertise while maintaining the agility needed in modern financial technology development.
Technology and Architecture:
Cloud Architecture: Given your experience with both pure cloud and hybrid environments, what do you consider the biggest challenges and advantages of each approach in a regulated industry like finance?
Cloud architecture presents a fascinating dichotomy of challenges and opportunities. From my experience, cloud computing is the preferred approach as it offers flexibility in scaling operations according to customer demand. The democratising nature of cloud technology means that even the smallest fintech startup can potentially harness the same computing power as a multinational corporation, achieving this scale within hours rather than the months or years traditionally required for physical infrastructure deployment.
However, there's a persistent misconception about cost savings. Cloud implementation isn't necessarily cheaper—in fact, it often proves slightly more expensive than traditional infrastructure. The real value lies in its operational advantages, particularly regarding resilience and disaster recovery. The traditional finance sector approach of maintaining costly, dormant disaster recovery sites is becoming obsolete. Instead, cloud architecture enables active-active configurations, eliminating the need for dramatic failover scenarios and emergency response teams rushing to secondary sites.
Emerging Tech: Are there any emerging technologies, such as AI or blockchain, that you believe will have a significant impact on financial technology architectures in the coming years?
The impact of emerging technologies on financial services architecture is particularly fascinating, with AI emerging as a transformative force in several key areas.
When we look at financial crime prevention, AI's application in Anti-Money Laundering (AML) and fraud detection stands out as especially promising. These use cases are particularly well-suited to AI because they require nuanced decision-making based on variable criteria, pattern recognition, and the ability to learn from historical data.
The trading sector has already embraced these technologies extensively. We're seeing sophisticated AI and machine learning algorithms being deployed by trading houses, and the rise of 'robo-trading' platforms has democratised automated trading for retail investors. This represents a significant evolution from traditional approaches, where institutions would rely on massive computational exercises, generating hundreds of thousands of Brownian motion curves across decades of historical data to satisfy regulatory requirements.
It's worth clarifying the distinction between AI and machine learning, as these terms are often misused in the industry. Traditional machine learning operates within predefined parameters—it's essentially pattern recognition and response based on established rules, albeit sometimes with fuzzy logic. What we're now seeing with modern AI is more sophisticated: systems that can extrapolate new rules from data, making connections and identifying patterns that weren't explicitly programmed. However, we're still far from true AI in the sense of self-aware systems.
The real quantum leap in financial technology may come from the convergence of AI with quantum computing. This combination is particularly intriguing—and somewhat concerning—especially in the realm of cryptography. Quantum computing has the potential to render current cryptographic methods obsolete, which could have profound implications for financial security. As these systems evolve, their complexity may well exceed our ability to fully comprehend their operations, particularly as we move into second and third-generation implementations.
Data quality and ethical considerations remain challenges, though. The effectiveness of these systems is fundamentally dependent on the quality and quantity of their training data. We've seen cautionary tales where AI systems, when exposed to biased or inappropriate data, begin to reflect those biases in their operations. This highlights a critical challenge in AI development: ensuring that we don't inadvertently encode human prejudices into these systems.
Garbage in, garbage out' remains relevant, even with these advanced technologies. Success ultimately depends on the quality of the input data and the robustness of the initial rules and parameters. As we continue to develop and deploy these technologies in financial services, maintaining this balance between innovation and responsible implementation will be crucial.
Strategy and Vision:
Future of Financial Technology: What do you see as the future of technology in the financial industry, particularly in terms of cloud and data management?
The regulatory landscape has evolved significantly over the past decade. Ten years ago, regulators were notably hesitant about cloud adoption, particularly for banks aiming to become cloud native. Their primary concern centred around physical asset visibility and control. However, this stance has transformed dramatically, largely due to collaborative efforts between cloud providers—particularly Microsoft—and regulatory bodies. Microsoft invested considerable resources in building trust and understanding with regulators, helping establish cloud computing as a credible platform for financial services.
Today, the pendulum has swung so far that regulators might question a financial institution's decision not to adopt cloud technology. A prime example is the UK's New Payments Architecture (NPA), intended to replace systems like Faster Payments, CHAPS and BACS. The regulators explicitly mandate cloud hosting for this initiative. The only remaining on-premises requirements typically involve specific security elements, such as dedicated leased lines and hardware security modules for signing and verification—legacy requirements that are increasingly viewed as outdated.
This shift represents a broader transformation in financial technology, where cloud infrastructure has moved from being a controversial choice to becoming the expected standard. The industry has recognised that the agility, scalability, and resilience offered by cloud solutions align perfectly with the demanding requirements of modern financial services. The key challenge now isn't justifying cloud adoption, but rather optimising its implementation within the regulatory framework while managing costs effectively.
Traditional concerns about security and compliance haven't disappeared entirely, but they've evolved into more nuanced discussions about implementation rather than fundamental objections to the technology itself. This evolution reflects the financial sector's growing maturity in cloud adoption and its recognition that cloud infrastructure can enhance rather than compromise security and regulatory compliance.
Building a Technology Roadmap: How do you approach long-term strategic planning for technology infrastructure in a rapidly evolving financial landscape?
Our approach centres around developing modular, adaptable infrastructure that can evolve with the rapidly changing landscape. At the core of our platform lies a fundamental settlement system—the essential infrastructure for moving funds between parties internationally. However, the real strategic value lies in how we've architected the system to accommodate future innovations.
Consider, for instance, our exploration of AI applications in liquidity management. The potential exists to develop intelligent systems that can anticipate business liquidity needs and optimise currency movements based on exchange rate cycles. However, this raises interesting questions about trust and autonomy. While we could begin with an advisory approach, the goal might be automated execution—similar to how robo-trading platforms operate today. The challenge doesn’t lie in the technical implementation, but in building the level of trust necessary for clients to feel comfortable delegating such significant financial decisions to automated systems.
Our architectural strategy deliberately employs a layered approach. The foundation layer handles core settlement functions—the basic movement of funds between parties. This base layer is intentionally streamlined and focused. Above this, we can construct additional service layers that introduce new functionalities without compromising the core system's integrity. This modular design allows us to remain agile and responsive to market changes whilst maintaining stability in our essential operations.
This layered architecture proves particularly valuable when considering emerging technologies and evolving market requirements. Rather than continuously modifying our core infrastructure, we can develop and deploy new services as overlay modules.
This approach enables us to balance innovation with stability. We can rapidly prototype and implement new services while maintaining the robust, secure foundation that financial services demand. It's about creating a framework that not only serves current needs but provides a platform for future innovation, allowing us to adapt to changing market demands and technological advances without compromising our core functionality.
Personal and Career Development:
Continuous Learning: How do you stay updated with the latest trends and technologies in cloud computing and financial regulations? What resources or methods do you rely on for your own professional development?
I've found TLDR's digests particularly helpful—they provide concise, bite-sized information with the option to delve deeper through referenced links when a topic captures my interest.
I also follow specific technical and financial blogs and keeping track of key individuals in the industry, particularly those from major technology providers like Microsoft whom I've worked with or followed over the years. Competitive intelligence also plays a crucial role—monitoring our competitors' innovations and approaches helps maintain perspective on industry direction and emerging trends.
Professional development extends beyond passive consumption of information, though. While I'd like to attend more industry conferences to engage with emerging discussions and developments before they become public announcements, our current operational constraints make this challenging.
As we grow, I'd like to establish our own technical meetups, positioning our organisation as a thought leader in the space. I'm particularly keen to encourage our principal engineers to contribute to our technical blog, sharing our innovations and learnings with the wider community. We've recently been discussing the tooling and management processes needed to support this initiative.
Advice for Aspiring Leaders: What advice would you give to someone looking to lead development teams in a regulated industry?
When leading technology teams in regulated industries, I've learned that you're never done learning. The most important thing is building the right team.
Don't surround yourself with people who just agree with everything. You need team members who will challenge your thinking and bring different perspectives. This is especially important if you have a strong personality - without other strong voices in the room, it becomes a one-person show where everyone just follows your ideas.
Yes, having multiple strong opinions can create some friction. But this tension usually leads to better decisions. When team members have to make solid cases for their ideas, the end results are typically stronger. This is particularly valuable in regulated environments, where decisions can have serious consequences.
Your effectiveness as a leader comes down to the quality of your immediate team. It's not about individual brilliance - it's about how well your team works together while maintaining their independent viewpoints.
