Execution is everything: Why speed x quality wins the day

Richard Davies CEO, Allica Bank

26th February 2025 • 5min read

While I was COO at Revolut, Vlad Yatsenko - the company’s Co-Founder & CTO - commented a number of times about how opportunity cost of time is typically the biggest cost in a scaling company, and I’ve come to realise this is more and more true.

You need to have a good (which typically means simple) strategy, but beyond that, execution is everything, as that gives you return on time. 

It’s true that if the strategy is mediocre you can, at best, create a decent business through great execution. But strategy is much easier than execution. The world, including large incumbents and fintech communities, abounds with people who have strategic ideas and great slide decks, however very little of this ever reaches the start line, and certainly not the point of exponential scaling, due to the difficulty of execution.

So, what makes great execution? 

Speed of quality execution is the single most important determinant of a modern company’s success.

Exponential competitive advantage

Side note: people often associate speed with being riskier. I don’t believe this is the case – as the points below equally apply to risks / control issues – i.e. the ability to identify there is a (potential) problem, work out what to do about it, and execute the mitigation fast is a critical part of sustainable success.

Speed of quality execution is the single most important determinant of a modern company’s success. If you can go through the following cycle much faster than competitors, while making – on average – sensible decisions, you win:

1. Observe - new market trends, customer feedback, control issue.
2. Orient/Options -what could we do about this?
3. Decide - which option is best, or is it best to ignore it and focus on other opportunities/threats? 
4. Act - successfully execute implementation of the chosen option.

This needs to be coupled with Amazon’s one way vs two way door concept: most decisions are two way doors i.e. reversible – and so should be taken quickly and can be changed without severe impact if found to be wrong. The one way door decisions deserve a lot of thought, analysis and testing before fully committing – but these are actually rare.

Speed is how quickly you can Observe, Orient, Decide and Act. Quality is a function of both how good the option you decide on is, and how successfully you implement it. For example the successful launch of a new product typically means rapid iteration based on understanding customer/GTM feedback post MVP launch to achieve product-market fit. 

And the reason this wins so compellingly over time is the magic of compounding. This can be simply illustrated by looking at two companies; A and B. A is a traditional company that takes pains to analyse its decisions to maximise accuracy over speed, B takes a rapid approach to reversible decisions, sacrificing some accuracy. 

If we assume B takes twice as many decisions a month, and implements twice as fast, with A getting decisions right 90% of the time and B 75% of the time, we see the following.

By the end of year 3, company B is 10x ahead of company A, accelerating to 21x by end of year 4.

This is exactly the sort of exponential winners that have been seen in many different sectors as software has increasingly come to dominate how competitive advantage is achieved. I think Amazon is probably the best demonstration of this. They have managed to uniquely scale their advantage across three key dimensions: 

• Product: many different verticals.
• Segment: consumer, SMB, and enterprise.
• Geo: serving over 100 countries. 

Companies that can execute strongly in parallel across these three dimensions are truly exceptional in my view.

In delivering exponential competitive advantage, it is the combination of speed and quality in execution that is critical. In the above illustration, if company B’s decision and implementation success was only 50%, it barely builds any advantage over A despite being much faster – this is the classic case of the startup that builds rapidly but has to keep pivoting, abandoning past work. 

Scaling and the importance of Single-Threaded Teams

There are two capabilities that really start to differentiate companies that are great at execution:

1. Good quality of fast decision making – you take decisions quickly, and they are generally correct (see Amazon’s principles ‘Leaders are right, a lot’ and ‘Bias for action’).
2. The ability to execute successfully at pace – you get it live quickly, but don’t just make a bodge job. (Amazon principles ‘Deliver results’ & ‘Insist on high standards’).

These are easier when you are small – a strong founding team can be at the coalface making good quality decisions rapidly, while also being involved in the detailed execution of these. 

The problem is that as companies scale, they slow down. The small founding team becomes multiple squads, then a range of tribes and functions. Teams spend more time coordinating and communicating (a huge tax on time), and less time building. Every new product or feature intertwines across teams’ and function’s roadmaps. Teams need more meetings, people, and time to complete their work. The organisation gets tangled in a network of dependencies. 

The best way to solve for this is what Amazon call ‘Single-Threaded Teams’ (STTs) – or a similar model popularised in 2012 by two Spotify employees. There are lots of good resources that cover this model, so I won’t repeat all that here beyond a short summary extracted from ‘Single-Threaded Leaders at Amazon’:

• For each key initiative or service, there needs to be a leader whose focus is that initiative and that initiative alone. That person leads a separable, STT to deliver the initiative’s goals – and that leader needs to have real drive, a hunger for continuous learning, and a strong logical problem solving mindset.
• Single-threaded organisations structure themselves in ways that allow their teams to complete tasks without blocking others, waiting for others, or aligning decisions with others. Teams significantly reduce the time and energy spent in coordination if they can accomplish their goals without communicating with the rest of the organisation. Therefore, teams must have all required roles to fulfil their goal.
• A STT with a dependency owns driving the process to de-couple it. Dependencies delay results, increase frustration and disempower teams. To succeed, STTs need to have the minimum possible number of organisational and technical dependencies, even if the cost of separating the dependency is duplication.
• All squads should aspire to develop extensible self-service systems via internal APIs. Organisations need to get their services and infrastructure to the place where, like cloud service providers, additional “clients” have minimal impact on a team. An ‘away team’ method can be used by a squad to break a development dependency but if multiple teams keep needing to use the away team mechanism, then the host team needs to improve the service architecture to make it self-service and extensible. 

Individuals need to take decisions under a clear delegated framework of authority.

Implementing change in a regulated firm

We have been using a version of the Spotify squad/tribe/function model throughout my time at Allica, and we doubled down on that in summer 2024 by looking to move as far as possible towards a STT model. We did this to ensure we could keep executing successfully as a much larger organisation. 

The process was beneficial from the outset in identifying squads who were being asked to simultaneously deliver on multiple important threads - not a recipe for success. This led us to mobilising another 6 squads/STTs (bringing us to 21) to ensure each squad had a single key thread they own and drive.

The most critical element determining execution speed and success is autonomy + strong people. Autonomy can only be successful if you are clear on what a squad owns, so you can then have clear goals + metrics for the squad to iteratively deliver against, and these goals then give alignment back to the company strategy and OKRs. Autonomy with no alignment = chaos. 

In a regulated firm, particularly a bank, providing autonomy also means it is important that STLs understand what tolerance/appetite there is for small scale errors to enable decision making. There should be a clear basis of delegation of authority and where second line (risk) input is required in this respect. The aim should be to avoid the multiplication of governance committee/forum events required for a single initiative that often occurs in larger companies, which both dilutes accountability and slows the company – individuals need to take decisions under a clear delegated framework of authority.

The leader of the STT (and the leader of a tribe) is therefore a crucial role, particularly in a regulated business, as you want either good existing knowledge of, or the ability to learn very fast, across three major areas:

1. The customer / service domain (e.g. current accounts, asset finance)
2. How to build software products
3. Relevant risk & regulation (e.g. liquidity, financial crime)

This is a pretty rare combination. Often when hiring you can get two out of the three but need to take a bet on the person’s energy and aptitude to learn the missing dimension. In all cases drive, resilience, and a logical & data driven approach are key attributes in a single-threaded leader.

Allica Bank’s 11 principles

To finish, I thought I’d share the 11 principles (this is written for 11:FS after all!) we wrote as part of implementing STT at Allica. I’m sure we will iterate these significantly over time, as we learn what works best for us. 

1. Squads should only have a single thread wherever possible. It’s likely impossible to achieve fully, but if a squad is not single-threaded then we acknowledge that there is a much higher likelihood of any item on their roadmap slipping. 
2. For material new initiatives, we ensure STTs are in place – these should not be part-time baked into existing squads, or we will fail. This forces the need for prioritisation choices, and resources, into the foreground. 
3. For each STT there must be a dedicated leader capable of what is needed (requiring drive, learning, and logical problem solving) and that can be hard to find, so we need to ensure there is a heavy ongoing focus on talent search. 
4. Single-threaded leaders need to have a strong grasp of assessing and owning potential impacts and risks their work will create. We provide tooling to help identify and quantify different risks in order to have a structured approach to risk mitigation and acceptance.
5. Each STT needs to identify what their key dependencies are, and then it should be discussed how these can be eliminated. We expect it to take a number of months to move fully into the STT model, as there is a need (depending on STT) to refactor architecture, or hire resource. 
6. STTs involve ownership of building and iterating a clearly defined product/service. In the case of entirely new products this involves the end-to-end, in the case of scaled/scaling products this will be further broken down into key journey stages and capabilities.
7. It is key to determine how these interact over time – e.g. we are building out multiple different loan products and have squads focused on journey stages (application, underwriting, fulfilment, servicing) for our largest loan product today. The technical and data architecture and working model is critical here to eliminate dependencies, and for new products we should accept duplication for speed where required, while seeking to make existing capabilities extensible in a self-serve manner to other STTs. This is a key ongoing focus for Allica’s CTO and principal engineers

8. This includes both technical dependencies and specialist function dependencies;

   a) Technical autonomy to be given as far as possible to principal/lead engineer – i.e. STT is able to make choices and deploy code self-sufficiently using the away team model if necessary, with dependencies/blockers identified early and solutioned as soon as possible. Standardised documentation must be in place from all squads to support the away team model.

   b) Specialist functions are to be consulted early and provide thoughtful analysis of potential problems they foresee. If there is a heavy ongoing resource skill need, then hire dedicated for that STT. Otherwise external specialist resource augmentation on demand can be used.

9. STTs must maintain a standard form document, linked off Allica’s home page so their work is easily visible to all Allicans. This should be updated very regularly and cover in short format: a) purpose and scope of team, and who leads it, b) team's roadmap c) team's objectives including KPIs and current performance, d) team's constraints. 
10. Updates on a key initiative should typically be provided to stakeholders asynchronously rather than via regular recurring meetings which are a tax on time. Meetings should only be called where input on a decision is required.
11. Quarterly review meetings are held with each squad / STT. A key part of this is a focus on key blockers/dependencies the squad needs help with. Squads should feel free to raise blockers outside of these meetings with ExCo or CEO where they need help, rather than waiting.

To learn more about Allica Bank and how they're improving business banking for companies across the UK, visit allica.bank today.