.svg)
The Strategy Pattern interview series reveals how tech leaders make critical decisions in complex, changing environments. Drawing on real-world examples and repeatable frameworks, it provides actionable insights to anticipate challenges and guide organisations with confidence. You can read more and see other interviews in the series here.
David Linten, CTO of TrustPortal, faced a challenge that eventually confronts every technology leader. His team had won the Telefónica contract, beating Accenture in open competition to lead what was, at the time, the largest robotic process automation deployment in the world. What they did not yet have was a systematic approach to the structural failures that would begin accumulating almost immediately after the work started.
Sprint timelines refused to synchronise. Scope crept as the client worked around problems rather than solving them. Key people left and took critical knowledge with them. Then the robotics software released a version update that broke every automated process the team had built, and the knowledge needed to fix it was sitting inside a partner organisation with an incompatible way of working. Each checkpoint was a contractual commitment Telefónica had already made to its own customers. Missing one was not a delivery inconvenience. It was a cascading commercial failure.
What makes Linten's experience worth examining is not that he delivered the programme. It is that the path there was unstructured, costly, and repeatedly broken before a systematic approach emerged. This is an account of that journey and the framework he built from it.
TrustPortal was founded in 2017 by Chris Lamberton, who now serves as Founder and Strategic Advisor. David Linten joined as CTO, bringing a background that moved from physics into software engineering.
TrustPortal's core proposition has evolved from Robotic process automation (RPA) integration into what the company now describes as real-time Agentic HyperAutomation: orchestrating humans, AI agents, and legacy systems simultaneously to deliver complex workflows in seconds, without replacing existing infrastructure. Its platform is trusted across banking, insurance, utilities, and telecoms, with clients including Telefónica, EDF, IBM, OVO Energy, and others.
One of its flagship deployments remains contact centre transformation, where TrustPortal's platform surfaces real-time guided workflows for advisors, eliminating system-hopping, reducing re-keying, and completing outcomes on the call rather than in a follow-up queue.
The company works across the full delivery stack, from back-end banking systems through to front-end customer interfaces, and has built a sustained delivery partnership with Imaginary Cloud spanning over eleven years.
From the beginning, Linten's philosophy was: he doesn't work with developers, he prefers to call them engineers, and the distinction matters to him. A developer writes code. An engineer understands architecture. "We don't hire developers," he says. "We hire engineers. Everybody has their hand in architecture all the way down to actually writing lines of code."
That philosophy shaped every decision he made on the Telefónica programme, including the ones he wishes he had made sooner.
The Telefónica engagement brought TrustPortal into a delivery chain alongside EY as systems integrator and Blue Prism as the robotics software provider. The competitive tender had pitted TrustPortal and EY directly against Accenture. TrustPortal won, largely because its engineering team could move faster and with fewer errors than a larger organisation relying on separated departments and slower feedback loops.
What nobody said at the time was that winning a contract by being small, fast, and architecturally rigorous does not protect you from what happens next when you are operating inside a structure that is none of those things.
The programme was structured around three-month checkpoint cycles, each one a hard commercial commitment already made to Telefónica's B2B customers. The problems arrived almost immediately.
Sprint timelines between partners never naturally synchronised. TrustPortal would complete its portion of a cycle ahead of schedule, then spend the remaining time pulling other partners towards the checkpoint.
"Whenever you're working with partners, the sprints never really align in the real world," Linten explains. "You have to account for a lot of time to backtrack and try to catch up their side of the delivery in order to consolidate the end of the three-month cycle."
Scope creep followed. Telefónica continuously adjusted its requirements as the programme progressed. "A lot of companies at this level will not solve the problem. They will code around the problem." Every scope change accommodated without evaluation against the original brief was technical debt accumulating quietly in the background, with a future invoice attached. Research across more than 5,400 IT projects found a collective cost overrun of $66 billion, with every additional year of project duration increasing overruns by 15 per cent, a pattern TrustPortal was watching form in real time.
Then came the Blue Prism update. And people began to leave.
Each problem looked different on the surface. Linten would eventually understand that they all had the same cause.
TrustPortal's initial approach to managing the programme was logical. Assign the people with the greatest domain expertise as single points of contact across each workstream. Those people understood the project best. They could communicate most effectively with partner teams. They were the connective tissue of the delivery.
The risk was not visible until it materialised.
"During the project we had a lot of people move on and would lose that domain knowledge," Linten recalls.
When a key person left, the knowledge they carried did not transfer to a colleague or a document. It simply disappeared from the programme.
His response was structural rather than procedural. He introduced a minimum requirement of two people holding deep expertise in every critical domain. Not because it was good practice in the abstract, but because he had just watched what happened when that redundancy did not exist.
"Once that was done, our bug stacks dropped to next to nothing."
A bug stack is a cost. Knowledge concentration is a liability. Requiring two people to hold every critical domain is not a staffing overhead. It is a risk control mechanism with a measurable return. MIT Sloan Management Review identifies technical debt as a business liability costing US companies over $2.41 trillion annually, a figure that captures precisely the kind of accumulated cost that knowledge gaps produce when left unaddressed. What Linten had done was apply an architectural principle, eliminate single points of failure, to the human system of the programme rather than only to its technical components.
He did not yet realise how far that principle would take him.
Standing in the middle of the Blue Prism rebuild, Linten saw the connection he had been missing.
The misaligned sprints, the scope creep, the knowledge loss, the broken processes: they were not separate problems requiring separate fixes. They were the same problem expressed in different ways. Every one of them was caused by distance between the people who understood the domain and the people building the solution. Distance between the organisation that held the knowledge and the team that needed it. Distance between the business problem and the engineer assigned to solve it.
The knowledge to rebuild what Blue Prism had broken existed. It was sitting with the EY developers working on the IVR integration. Under a normal programme governance structure, the correct response would have been to raise the issue formally, wait for the partner organisation to mobilise, and manage the delay against the checkpoint. Linten did not do that.
"We made the decision to acquire those people to work for TrustPortal."
There was pushback. Absorbing another organisation's resources mid-programme is never straightforward, and Linten acknowledges that resistance was immediate. But the commercial logic was difficult to argue with.
"Bringing those people closer to the development stream and development process that we were building was absolutely critical to speeding up the delivery."
By collapsing the distance between the knowledge and the team, Linten removed the single largest source of lag in the programme. The feedback loop that had been running across organisational boundaries now ran within a single team. When something broke, the person who understood why it broke was in the same room as the person fixing it.
That was the insight. Not a management principle or a team-building philosophy. A structural observation: every layer of organisational distance between knowledge and execution is a source of lag, error, and risk. Reduce the distance, and the technical problems become solvable. Leave it in place, and no amount of engineering effort will compensate.
Fix the human architecture first. The technical architecture will follow.
What happened next at TrustPortal was not a single reorganisation. It was the incremental application of the same principle across every dimension of how the company worked.
The first change was the knowledge redundancy rule, applied programme-wide. Two people holding every critical domain, minimum. Not because the next person to leave would necessarily cause a crisis, but because the programme could not afford to find out.
The second change was more radical. Having watched TrustPortal grow from a startup into an enterprise and accumulate the familiar layers of middle management, Linten removed them entirely. Every developer, down to the most junior engineer, gained direct access to board-level decision-makers. Salespeople learned how engineers think. Directors became approachable by anyone with an idea.
"Any developer can ask anybody on the business side, from salesperson all the way up to director: I've got this idea. Can you tell me what the business problem actually is?"
This is not a cultural preference. It is a speed mechanism and a quality control. The further an engineer sits from the business problem they are solving, the more likely they are to solve the wrong version of it. Removing the layers does not just make the organisation feel better. It makes the output more accurate. Harvard Business Review's research on high-performing teams consistently identifies open access and candour between levels as a primary driver of team effectiveness and market-level breakthroughs, conditions that management hierarchy systematically suppresses.
The third change was onboarding. New hires at TrustPortal spend a minimum of three months integrating before contributing to production code. The process is designed to build mutual understanding across the team, not just technical competence in the new hire. Engineers learn the business domain. The business learns the engineers. Questions are encouraged without qualification.
"Because you've done the three months, because everybody knows each other at a personal level and understands how they think, the questions become more attuned to getting results."
For any CTO evaluating whether this investment is justified: teams that understand each other and the business domain produce fewer misunderstandings, fewer rework cycles, and fewer bugs. The three-month integration is not slow. It is the fastest path to a team that can operate without constant management intervention.
On the integration architecture itself, the Telefónica programme produced a principle that Linten has applied consistently since. Robotic process automation software works by defining processes at the screen and interface level: scraping specific fields, interpreting specific outputs, navigating specific user interfaces. When Blue Prism updated its underlying architecture, every one of those process definitions broke. The fix required a full rebuild, not a patch.
The lesson was that integration stability requires ownership of the full stack wherever possible. Every layer of distance between the team building the automation and the team defining the processes it automates is a maintenance risk embedded into the architecture itself. TrustPortal has deliberately maintained a full-stack engineering model ever since, with domain knowledge distributed across teams rather than concentrated in individuals or roles.
None of these structural changes made the Telefónica programme easy. Integrating new team members from EY into a delivery team already under pressure, on a programme with contractually fixed timelines, produced exactly the conditions in which engineering teams disengage.
Linten's response was the one that surprises people most when they hear it.
He protected ten per cent of every engineer's working week for self-directed research and development, and he maintained that commitment throughout the most pressured periods of the programme.
The rationale was not generous. It was operational. Engineers placed under sustained delivery pressure with no autonomy over any part of their working week stop thinking like engineers. They optimise for the metric in front of them, which in a delivery programme is sprint completion, rather than for the quality and longevity of what they are building. The protected time prevented that narrowing from happening. HBR's research on mission-critical knowledge finds that large-scale sustainable growth depends on people transferring deep expertise across domains, something that only happens when engineers have the space to think beyond the immediate delivery cycle.
"There's nothing worse than bringing somebody from somewhere and then putting them in a channel to work like a factory line. It's not how engineers really think."
The return on that commitment became visible in concrete terms recently. A protected R and D sprint running from November through to February produced the foundations of an entirely new TrustPortal product, delivered by two engineers working within their allocated time.
Linten also made a point of showing engineers the direct impact of their work. On a programme of this scale, it is easy for someone deep in a single component to lose sight of what they are contributing to. He made a practice of connecting people to the whole. "This is the bit you did. Look at it working in the biggest project in the world. This is your bit that's actually making a significant difference." That is not a motivational technique. It is information. Engineers need to see the system to think architecturally about their part of it.
This framework operates across three integrated dimensions.
The strategic dimension requires one discipline above all others: owning the diagnosis before delegating the solution.
Most delivery failures begin as planning failures. The problem arrives disguised as a technical issue. The instinct is to pass it to the engineering team. That instinct is wrong.
"The reason you have a business problem is because it wasn't planned properly in the first place. It is very unfair to then take that problem and create an ETA on a fictitious solution."
Linten's response was to build a mitigation architecture alongside the delivery architecture. For every workstream, a contingency plan existed before the checkpoint arrived.
"You can't ever take a business problem to the engineers and expect them to do your job for you. You have to take responsibility at the C-level."
Contingency planning costs less than contractual failure. That is the business case. Everything else follows from it.
The technical dimension addresses one reality: every layer of organisational distance between knowledge and execution is a maintenance risk embedded into the architecture.
When Blue Prism updated its underlying architecture mid-programme, every process definition broke. The knowledge to fix it was sitting with the EY IVR developers on a parallel workstream. Linten did not wait for standard programme governance to mobilise it.
The feedback loop that had been running across organisational boundaries now ran within a single team. When something broke, the person who understood why was in the same room as the person fixing it.
TrustPortal has maintained a full-stack engineering model ever since. Every engineer holds architecture responsibility alongside delivery responsibility. Domain knowledge is distributed by design, not by accident.
The cultural dimension proved the most complex. Structural changes that make logical sense on paper produce real friction when applied to people under delivery pressure.
Linten found that people respond in recognisable patterns. Some adapted immediately. Others needed visible evidence before they committed. A smaller number never fully adapted. His response to each group was structural, not motivational. The structure was changed so that the new model produced better outcomes, and people made their own decisions from there.
Management layers were removed entirely. Every developer gained direct access to the people defining the business problems.
"Any developer can ask anybody on the business side, from salesperson all the way up to director: I've got this idea. Can you tell me what the business problem actually is?"
New hires spend three months integrating before contributing to production code. Ten per cent of every engineer's week is protected for self-directed RnD.
That protected time produced the foundations of an entirely new TrustPortal product, delivered by two engineers within their allocated sprint. The investment was operational, not cultural.
The Strategy Pattern, originating in software engineering, defines a family of algorithms, encapsulates each one, and makes them interchangeable, allowing the decision logic to vary independently of the specific problem being solved. It is a behavioural pattern built for flexibility: a system that can swap its approach at runtime without requiring the surrounding architecture to be rebuilt.
Applied to organisational leadership, the logic is identical. A company should not be locked into rigid, outdated structures any more than a well-designed software system should be locked into a single algorithm. When the environment changes, the specific approach changes. The underlying decision framework does not.
Linten did not use this language to describe his approach. But across every decision he made on the Telefónica programme and every change he has made at TrustPortal since, the same pattern is visible: diagnose the structural problem first, address the human architecture before the technical one, and apply the same logic regardless of whether the challenge is partner misalignment, knowledge loss, or the arrival of agentic AI.
The Telefónica programme was completed on time. TrustPortal beat Accenture in the initial competition and delivered through every structural failure the engagement produced.
More significantly, the pattern has proven transferable. Linten has applied the same diagnostic framework to every major decision at TrustPortal since: the same sequencing, the same structural lens, the same instinct to look at the human architecture before reaching for a technical fix.
The current test of that transferability is agentic AI. TrustPortal's engineers are moving from writing code directly to directing AI agents towards architectural outcomes. The resistance Linten encounters is recognisable. Capable people who have built their professional identity around a set of tools are being asked to change their relationship with those tools entirely. The instinct is to keep reaching for the familiar. Gartner predicts that 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, making the transition Linten is managing not a future consideration but a present-tense delivery challenge.
His response follows the same pattern. He is not mandating adoption or measuring productivity against AI output targets. He is reframing the role at an architectural level: not a developer who writes lines of code, not a prompt engineer who inputs instructions, but someone who understands the business architecture well enough to direct a programme towards the correct outcome. And he is protecting the space in which engineers can experiment with the new approach before it becomes a delivery requirement.
The deeper challenge he is already designing for is social. "People are using agentic tools and actually becoming less connected with the people they know, because they are becoming less reliant on the information they have in their heads and going through the AI to get the same information." The human connections that make his model work may come under pressure as AI absorbs more of the information-retrieval function that human conversation used to serve. Maintaining the conditions for genuine collaboration across a team whose members increasingly interact with AI rather than with each other is the next structural problem he is preparing to solve.
He does not yet know the answer. But he knows which question to ask first.
Three categories of activity emerge once the structural diagnosis is complete.
Investment in delivery structures that concentrate critical domain knowledge in single individuals. Management layers that increase the distance between business problems and the people solving them. Timelines and ETAs applied to problems that have not yet been correctly diagnosed and owned at the appropriate organisational level.
Structural redundancy for critical domain knowledge across every programme, with a minimum of two people holding deep expertise in each area. Direct access between engineering teams and board-level decision-makers as a standard operating condition, not an exception. Protected time for autonomous exploration, even under delivery pressure, as an operational investment rather than a cultural gesture.
Existing client commitments and quality standards across all active programmes. The diagnostic habit of assessing the human architecture before attempting to fix the technical one. Onboarding processes that prioritise mutual understanding before production contribution.
Linten is direct about what makes this difficult in practice. "You can't ever take a business problem to the engineers and expect them to do your job for you. You have to take responsibility at the C-level."
That is not a cultural observation. It is a structural requirement. Until the business failure is correctly diagnosed and owned at the right level, passing it to the delivery team produces exactly the kind of costly, misdirected effort that the Telefónica programme encountered before the structural changes were made.
The specific details of the Telefónica programme are already historical. The partners involved, the version conflicts, the IVR integrations: none of that is the point.
What remains relevant is the decision framework Linten developed by working through every failure that programme produced. Not by planning for them in advance, but by recognising the pattern in them after they occurred, and building a structural response that would prevent the same failure from recurring in a different form.
The lesson is not to acquire partner developers, remove middle management, or protect ten per cent of engineering time. Those were the specific implementations of a more general principle. The lesson is to fix the human architecture before reaching for the technical fix, to reduce the distance between knowledge and execution, and to apply that logic consistently as the environment changes around you.
"Technology changes, but humans don't in the long run. Humans behave a particular way and you've got to be able to deal with it."
The only certainty is that the structural challenge will come. A key person will leave. A partner will fall behind. A version update will break what you built. A new technology will arrive and the engineers who mastered the previous one will resist the transition. At that point, the question is not whether you have the right technology. It is whether you have built the human architecture capable of responding to it.
If you would like to discuss how this framework can be applied to your organisation's technology transformation, platform migration, or strategic technology decisions, please contact our team.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
