Innovation is a choice

There’s nothing like a week in another city to get the innovation juices flowing, and London Fintech Week was exactly that (thank you Luis and team for another week of great debate, networking and insights).


There’s nothing like a week in another city to get the innovation juices flowing, and London Fintech Week was exactly that (thank you Luis and team for another week of great debate, networking and insights).

So, what is new in the world of Fintech? Well, if the speakers and panelists are to believed, and the messages were far too similar and consistent for them not to be…

…AI is playing an increasingly important role in the world and indeed in the world of banks – …  . It is clear that to win in the investment banking game will still require smart people – but we must couple smart banker types with AIs and we must change our definition of “banker types” to include engineers and mathematical PHDs.

…Blockchain is here, and it’s all grown up. No longer a concept for alternative funding and the underworld, the cryptocurrency conversation is upping the volume at the highest levels with countries like Canada, the UK and Singapore all running projects, and banks of all sizes experimenting and building applications both in crypto-coins and blockchain technologies. Even the highly volatile crypto-currency prices over the week did nothing to dampen the enthusiasm. With the rise of open source, I expect we will see increasing opportunities to move from our existing centralized models to new blockchain enabled ones in many economies and industries.

…Trust is no longer about relationships, nor the strength of your brand. It’s about ease of use and, increasingly, peer review. Customers are no longer seeking a similar experience to the one they get from other banking brands, they’re looking for an experience like they get from the mega brands like Apple and Amazon. Banks are going to need to up their game – and quickly!

Clients know that if they are not paying, they are the product. Both banks and clients know the power of their data – what will this mean in the future? How will this change their expectations of service? Security now becomes as important as service; will clients demand due diligence of their service providers to ensure that their data is secure?

…Innovation is a choice – it doesn’t just happen. This is potentially the most important message of all. Entities that are leading in the start-up and innovation space are choosing to  – they are seeing the possibilities that innovators bring and are finding creative ways to enable them. The innovation choice is being made at the highest level – countries like India, Canada, the UK, Germany, the Netherlands, and China are all facilitating innovation communities and the start-ups and banks coming out of those countries are moving faster than others because of it. It is a choice because there are millions of reasons and costs involved with creating change, but forward-thinking leaders recognize the importance and their choice to enable, means they are leaping ahead.

…It’s organizational cultures that will make the space for innovation and those cultures look to leaders for the messages they need. Coincidentally, I just finished reading “Under the Hood” by Stan Slap where he describes how to maximise business performance. Culture understands leadership motivators beyond words and culture works exceptionally hard to protect its own existence – so innovation will simply not happen without leaders giving the right messages. Innovation is a choice leaders have to make and their actions will send the clear message.

Everything we know, the way we work and the way we behave was all once created as a leadership or cultural choice. In this exponential era, we will need to change the stories we tell, the way in which we work, the technologies we believe in. It’s ridiculously exciting – and it’s moving…well, exponentially! At last years’ event, there was talk of what blockchain is and what AI could conceivably do, this year it was all about what businesses are being built on these technologies. I can’t wait to see what the next year brings!

by Liesl Bebb-McKay


Extreme programming practices that mitigate Technical Debt

Technical debt, first coined by Ward Cunningham(TD) [1, 2], can be described as the dichotomy between the best design that takes longer to implement and a quick design and implementation for short-term gain. The technical compromise between these two designs and extra development effort needed to make changes to the latter software system represents debt.

1.   What is Technical Debt?

Technical debt, first coined by Ward Cunningham(TD) [1, 2], can be described as the dichotomy between the best design that takes longer to implement and a quick design and implementation for short-term gain. The technical compromise between these two designs and extra development effort needed to make changes to the latter software system represents debt.

A popular metaphor is that of monetary debt. If TD is not repaid as soon as possible, “interest” is incurred — this relates to the effort needed to implement changes in the future. When TD is not addressed and systems are patched with functional and bug fixes, it leads to an increase of software entropy [3, 4], a condition that deteriorates over time. In some situations, when creating a proof-of-concept (POC), it is acceptable to incur some degree of TD. This, however, is known at design time and should be addressed when the POC evolves into an official project.

Another symptom of TD can be compared to the law of unintended consequences. More often than not, poorly designed systems have longer release cycles and have higher resistance to change. This is due to the fact that when necessary code changes are made to one part of the system, unintended changes occur and have to be addressed. This increases the time of the delivery cycle and drives the cost of change higher, often leading to more pressure, which in turn creates more TD.

Some causes of TD:

  1. Last minute emergency additions or omissions of functionality;
  2. Incompetent technical leadership and bad systems architecture;
  3. Efforts to minimize startup capital;
  4. Outsourced software engineering;
  5. Ignoring industry standards;
  6. Building tightly coupled code with modularity Loosely coupled code is easy to modify or change; and
  7. Non-existent test suite, continuous integration and deployment


TD manifests itself in the following examples:

  1. Countless branches of same code base, often for single customer releases;
  2. Database SQL stored procedure spanning a 1000 lines of code (LOC);
  3. Continuous version releases to fix bugs;
  4. Frequent patching of a legacy system; and
  5. Very large methods within

Figure 1: The author’s depiction of technical debt

2.    What is extreme programming?

Kent Beck [5] is widely considered as the creator of the XP software development methodology. XP is a frontrunner to many of today’s more modern software development methodologies. It is a lightweight, practical methodology with a focus on software quality and responsiveness to stakeholder requirements and change.

Intensive requirement analysis and extensive documentation are omitted from the process. Teams are small and focused, with a heavy emphasis placed on simplicity and short development cycles. User stories are a core doctrine of XP. Projects are initiated by the final users creating user stories describing the behaviour and functionality of the software system. Before any coding begins, functional testing of the requirements is conducted, with automated testing throughout the lifecycle of the project. Code is constantly refactored to reduce complexity, drive efficiency and adhere to standards. The result is extensible and maintainable code.

Good relationships between software engineers and stakeholders are also considered a cornerstone of XP as defined in the XP value system: communication, simplicity, feedback, courage and respect.

A software engineering team does not necessarily follow every XP practice. Self-organizing teams use and follow the XP practices that suit them at a point in time. As the software engineering team grows in maturity, so more XP practices are incorporated or omitted.

Given that most software systems are in a state of flux, XP adapts with the software system without being a technical barrier. XP manages this by having both technical and management practices. There are several XP practices, but for the purposes of this blog, the primary practices of XP are broken down in Table 1.

Table 1: Primary extreme programming practices

2.1  Modularity violations as a cause of technical debt

When code follows a good design and strictly adheres to standards such as the SOLID principals [6], changes to one module do not affect another module. A module can be described as a “unit whose structural elements are powerfully connected among themselves and relatively weakly connected to elements in other units.” [7]. This inherently creates an orthogonal design.

“Orthogonal design is the union of two principles, cohesion and coupling [8]”. To be more specific, loosely coupled code creates high cohesion, which makes responding to changes very easy and predictable. Positive side-effects of orthogonal design lead to clear and logical structure of relationships and create significant reuse.

Modularity violations occur when changes to one module unexpectedly induces changes to another module. This is not orthogonal design and a key indicator of TD. Changes to the code are not easily made and time estimation becomes inaccurate.

These violations must be identified and rectified by relentless refactoring, a cornerstone practice of XP. Strict and comprehensive coding standards must underpin the refactoring efforts of code, another important XP practice. The two XP practices complement one another and when used together lead to a direct and significant decrease in TD.

In the research paper Comparing Four Approaches for Technical Debt Identification, substantive findings are made by Zazworka et al. A very high correlation exists between Modularity violations and change prone classes, so much as 85% as shown in Table 2 below.

Table 2: Correlation between Modularity Violations and change prone classes [9]

2.2  Technical debt estimation variance

An integral function of software engineering is estimate development time for maintenance and new components. TD can have a significant impact on such estimations. Variances in estimation are depicted by the Cone of Uncertainty. Instead of being certain of the estimations given, TD creates increased uncertainty at the later stages of the lifecycle, where estimates should be more accurate (shown in Figure 2). This negatively impacts cost, productivity and project schedules.

Figure 2: Adapted Cone of Uncertainty impacted by technical debt [10]

Deadlines frequently being missed and so-called unforeseen changes to the code during the development cycle are indicative of time estimation variance due to TD. Accurately predicting development duration is not an easy task, TD makes this exponentially more difficult. Most estimates are given at the start of the phase, when TD is encountered estimates become inaccurate due to the extra work effort involved.

2.3  Measurement of Technical Debt

In the research recorded in Measuring Architectural Technical Debt [11], Kuznetcov defines TD as follows:

[TD] Principal – cost of eliminating TD (Code Debt, Design Debt etc.).

[TD] Interest probability – the probability that the type of TD will have an impact on the system (likelihood of imminent refactoring).

[TD] Interest amount – the extra cost incurred for addressing the TD (cost of modifying a module earmarked for refactoring as opposed to the cost of modifying after refactoring).

TD : { TDprincipal, TDinterest }

           man hours           work incurred           loss of productivity

TD can be expressed as an array where TDprincipal is independent of TDinterest. In keeping with the debt metaphor, the principal debt can be higher that the interest incurred or vice versa.

Various approaches are available to calculate the TD principal. Curtis et al. describes the TD principal value as a function of must-fix problems, the time required to fix, and the cost of the fix. Source code analysis provides actual counts and values calculated against input variables and the code itself. In the code, structural problems, modularity violations, LOC and duplication (to name but a few) all provide input for this analysis. TD can then be expressed as a product of this source code analysis. The principal amount of TD can be calculated using the high-level formula:

TDprincipal = Nmust-fix issues x Ttime required x Ccost incurred

2.4  Technical debt mapped to XP practices

All software systems develop some pain points over time. These pain points are based on the ISO 9126 [12] standard. (This standard has been revised by the ISO/IEC 25010 [13] standard.) A generic indicator of software quality can be defined by six characteristics: functionality, reliability, usability, efficiency, maintainability, portability [12].

These points are dealt with as they arise, and they are also indicators of TD. In Figure 3,  the author adapted the original diagram by Zazworka et al. [14] to reflect a mapping with the relevant mitigating XP practices.

By analysing the characteristics of each XP practice and variants of TD, a mapping can be made of the XP practices that effectively reduce the relevant form of TD.

Figure 3: Adapted Technical Debt landscape [14]

2.4.1  Coding standards – Directly influence the actual structure, composition and interaction of a software system at its lowest level. This can include guidelines and rules that the software engineer has to follow when writing code. This important practice touches on every part of the design, writing and testing of code.

2.4.2  Continuous integration – Facilitates in the feedback of system health and interaction in a continuous and predictable manner. As code is written and checked into version control, an extensive process of compiling, testing and deploying is started. Feedback is provided from all these sub-processes. Processes fail fast and provide immediate information.

2.4.3  Incremental design – Allows for the evolution and advancement of the software system in small manageable and measurable increments. Small releases are easy to scrutinize for TD. Also, small frequent releases are highly productive and stakeholders perceive a growing healthy software system.

2.4.4  Refactoring – Allows for the evolution and advancement of the software system on a code level and keeps the system at an optimal level of engineering excellence. If the code is frequently refactored, it becomes familiar to the software engineering team and TD is dealt with proactively.

2.4.5  Test-first programming – Software defects are kept at a minimum. The addition of new functionality is made simpler and more visible due to observable and trackable test results. As all the tests pass, the software system’s integrity is maintained and confirmed. As the system grows, the test suite grows too.

3.      Findings

Research indicates that there are various approaches to measure and indicate the extent of TD. This applies to both TDprincipal and TDinterest as described in Section 2.3. Only once there is a manifestation of a standard approach, can tools like SonarQube [15] come to fruition and be more scientific [11]. The SQALE[16] method has been widely adopted as a standard way of measuring and expressing TD. The adoption allows for increased feedback and evolution of the method.

Apart from the common causes of TD discussed in this paper, disconnect between technical staff and management is a major cause of project overrun and subsequently TD. This is exacerbated by the lack of further learning by middle management. Middle management also influences technology decisions and lack of understanding technology leads to an increase in TD.

When XP is implemented effective mitigation of TD occurs naturally. XP has had a significant impact on software engineering in the last decade. CI, Refactoring and Test-first programming have been instrumental in this, especially in the management of TD [17].

Each practice addresses one or more forms of TD [18]. Coding standards combined with refactoring and static code analysis directly increases code quality. Refactoring also aids in the writing of unit tests. Further, if done correctly, code will always be in a better state than before refactoring took place. Every new feature is built off a better base than the previous feature — this is true continued improvement. CI reduces the cost of integration and provides continuous feedback, and mitigates operational debt. Incremental design allows for the focus to be on functionality needed now, small increments and modularity counter design debt. Effective use of Test-first programming dramatically reduces defects and increases code quality, this mitigates code and test debt [19, 20].

In previous research [21] conclusive empirical evidence was provided in the written responses of interviewed software engineers. Applying a points system to the ranked XP practices provides a clear hierarchy of effective- ness. The Coding Standards XP practice is ranked first by a substantial margin. Refactoring and incremental design follows in rank respectively. Lastly, test-first Programming and continuous integration occupies the last two positions respectively.

Table 3: XP practices ranking

4.      Conclusion

The five XP practices are intrinsically linked in their ability and effectiveness in the mitigating of TD. The effect of following all these practices drastically reduces levels of TD. The power of these XP [22] practices lie in fact that they complement and follow on from each other. Most modern agile methodologies heavily incorporate these five practices, a testament to their importance.

In its simplest form: “Technical debt is the difference between what was promised and what was actually delivered” [23]. This difference can not only be very difficult to measure, but also difficult to find the root cause for the difference. TD will always be incurred at varying degrees of cost. An argument must be made that a software system is born from the code itself, not the idea of a software system. The code captures not only the core business idea or solution to the problem, but the reasoning and cognitive ability of a group of people, an amalgamation of intellect. Code must be guarded, maintained, optimized and treated with a level of respect. The empirical evidence presented substantiates that the five XP practices aid in this.

With time the measurement of TD and tools reporting on TD will increase in sophistication. There is no single solution to measure, report and reduce TD but rather a combination of measures and practices. The astonishing amount of research papers and commercial literature on the subject is proof of this.

Adapting to change is crucial to any software system evolving over time. Empirical evidence shows that this evolution can have negative consequences, but the practices we use to measure and mitigate the impact are also evolving in their effectiveness.


[1]  W.Cunningham. “The WyCash portfolio management system.” ACM SIGPLAN OOPS Messenger , vol. 4, pp. 29–30, 1993.

[2]  Debt Metaphor – Ward Cunningham. URL Last accessed: 1 October 2016.

[3]  Software Entropy. URL Last accessed: 1 October 2016.

[4]  N. Ford. Evolutionary architecture and emergent design: Investigating architecture and design. IBM developerWorks. URL  Last accessed: 1 October 2016.

[5]  K. Beck and C. Andres. Extreme Programming Explained: Embrace Change, 2nd Edition. Addison Wesley, 2005.

[6]  Solid principles. URL Last accessed: 1 October 2016.

[7]  C. Y. Baldwin and K. B. Clark. Design Rules: The power of modularity. The MIT Press, 1999.

[8]  J. Coffin. Cohesion and Coupling: Principles of Orthogonal, Object-Oriented Programming. URL http:// Last accessed: 1 October 2016.

[9]  N. Zazworka, A. Vetro, C. Izurieta, S. Wong, Y. Cai, C. Seaman, and F. Shull. “Comparing Four Approaches for Technical Debt Identification.” Tech. rep., 2016. URL courses/esof522/handouts_papers/TDLandscape.pdf.

[10]  B. W. Boehm. Software Engineering Economics. 1981.

[11]  M. Kuznetcov. Measuring Architectural Technical Debt. Master’s thesis. URL 769526/z-mscis-s4340132-mkuznetcov-2014-08-28.pdf.

[12]  ISO 9126 standard. URL Last accessed: 1 October 2016.

[13]  ISO/IEC 25010 standard.     URL detail_ics.htm?csnumber=35733. Last accessed: 1 October 2016.

[14]  N. Zazworka. Technical Debt. URL Last accessed: 1 October 2016.

[15]  SonarQube. URL Last accessed: 1 October 2016.

[16]  SQALE. URL Last accessed: 1 October 2016.

[17]  N. Brown, Y. Cai, Y. Guo, R. Kazman, M. Kim, P. Kruchten, E. Lim, A. MacCormack, R. Nord, I. Ozkaya, R. Sangwan, C. Seaman, K. Sullivan, and N. Zazworka. “Managing Techni- cal Debt in Software-Reliant Systems.” Tech. rep. URL db80f0e465cfcad4077c5703ff1cdfd8e902.pdf.

[18]  J. Holvitie, V. L. nen, and S. Hyrynsalmi. “Technical Debt and the Effect of Agile Software Development Practices on It – An Industry Practitioner Survey.” Tech. rep. URL mtd/2014/papers/6791a035.pdf.

[19]  C. Sterling. Managing Software Debt – Building for Inevitable Change. Addison Wesley, 2010.

[20]  J. C. Sanchez, L. Williams, and E. M. Maximilien. On the Sustained Use of a Test- Driven Development Practice at IBM. URL 61b77e2df21b43d5e500341d5efec286c195.pdf. Last accessed: 1 October 2016.

[21]  C. Fourie. “EXTREME PROGRAMMING PRACTICES THAT MITIGATE TECHNICAL DEBT.” Tech. rep., School of Electrical and Information Engineering, University of the Witwatersrand, 2016.

[22]  Extreme Programming . URL Last accessed: 1 October 2016.

[23]  Escaping the black hole of technical debt. URL Last accessed: 1 October 2016.

by Carel Fourie

The essence of a FinTech team

Along my short career I find myself wondering what the keys to success are. I have come to the realization that though the media will tell us stories of successful individuals, few key inventions were conceptualized and industrialized by just one person. So what makes a successful team and how would you put one together?

Along my short career I find myself wondering what the keys to success are. I have come to the realization that though the media will tell us stories of successful individuals, few key inventions were conceptualized and industrialized by just one person. So what makes a successful team and how would you put one together?

The idealist within me wishes that I could provide a recipe for the ideal FinTech team. I would like to be able to say in order to revolutionize the world you need 5 analysts, 10 developers and 17 Data scientists but this still wouldn’t guarantee success. So what is the essence of a Fintech team? I may not have all the answers but I do think there are some common elements in truly successful teams.


The word purpose is over used but misunderstood. The true meaning of the word took on a new meaning when described by Viktor Frankl in his 1946 classic, “Man’s Search for Meaning” within the context of a World War 2 prisoner camp. Viktor was a neurologist and psychiatrist who was captured and lived in a prisoner of war camp. He shares his observation on the elements of motivation and depression that he observed in his fellow prisoners.  Personally I think Viktor does a better job at explaining it than I could.

Viktor explains that the reason people survived the Holocaust is they had something else to live for, a true purpose. Sometimes this was as simple as a desire to see their family again, in other cases it was more complex. It is this motivation by purpose is that I believe galvanizes a team.

Salim Ismail insists that all start-ups set a multi transformational purpose. These purpose statements need so be short and to the point so that there is no room for misinterpretation. If your purpose cannot be stated in one sentence, then it has not been distilled into its essence. This helps focus all team members at the same goal. Most importantly it means that all team members should believe in the purpose. Getting this right is almost impossible but I would be willing to bet that successful teams have gotten this right. My memory takes me back to South Africa’s 1995 Rugby World Cup winning team who went through the entire tournament with the purpose statement of “one team, one nation.” A purpose that resonates so strongly in all individuals within the team makes it impossible to fail.


I was in awe of these start-up stories outlining how a group of people started a multi-billion-dollar company in their garage.  In the past few years I found myself in the proverbial garage of multiple different acquaintances and friends, it was only then that I realized what was driving this behavior. I found myself drawn to this group merely because we were enjoying the hard work and the time we were spending with each other. It is easier to accomplish a complicated and long goal when you have good people around you that you connect with. I’m not at all saying that you need to be best friends with all your team members but I do believe that you need to find some commonality to have a human connection.

What about skills?

I’m am by no means diminishing the need for skilled people in your team. I am however making an assertion that even if you have the best skills, without a purpose and connected team you are doomed to fail. Pay more attention to the qualitative things when setting up the team. The things we take for granted like the feeling when you walk through the office doors, the vibe in the room, the “nice to have” social interactions.

So I guess my recipe is this:

Find a purpose that resonates with you. Then find a group of people that you can connect with. If the purpose resonates with your team, I believe you have a good chance of success.

by Tyrone Naidoo

Link to video:

Which race are you in?

As we hurtle head on in 2017 its becoming increasingly clear that no matter what generation you find yourself in – Xers embracing tech, Y’s passionately living the dream or Z pushing us all faster than we ever believed we could go – if you are not concentrating…this digital world will run right past before you blink.

At Finovate 2017 in London last week, I was struck firstly by the intensity of this pace – the leaps that tech has taken over the past year, but also, and more importantly, by the spirit of partnership.

No longer are we in a world where competition is about being the fastest or the smartest, we are living in a world where winning is about bundling those that are faster and smarter than you into meaningful solutions for the business you are in, and the clients that you serve.

In banking it’s too late for us to say “let’s build our own” or “let’s throw money at disruption”; we need to get our heads around connecting fintech dots to build the best solutions for our clients. In biometrics and authentication, the solutions are overwhelming, similarly in app design and integration.  Banking is less and less about paper trails and complicated products and more about integrating whole life solutions with ease of use and integrated platforms. It’s not at all about selling products and more about connecting the right client to the appropriate product they need for the time of their life that they are in – most often aided by a funkily named chatbot.  The world of social media and banking have converged already (yup ship sailed), payments is fast becoming something everyone does …everyone! We can already buy packaged analytics and information about pretty much anything we need.

Banking has morphed from functional practicality to gorgeous design, insightful user experience and lifestyle products that adjust to the needs of its customers. Tricky thing is that much of that “banking” isn’t coming from banks! So what on earth should banks be doing?

Concentrating? Yes. Trying to keep up? No. Collaborating? Absolutely!

Finovate entrepreneurs brought solutions to banking problems we never even knew existed. They challenged views of what banks do and encouraged us all to ask “how can we help you help us help our clients?”  More importantly though, they showed what collaboration brings.  Over and over as the 7 minute spots passed by, it was clear that these entrepeneurs are building on what each other are building.  Each using bits of what others had built, to supersize the solutions they were prototyping.

And that is the way to stay in the race! So as we train for the year ahead, we need to make sure we have the insight to navigate the way forward, the partnerships with fintechs to supersize our banking offerings and the deep relationships with clients to package this stream of incredible ideas in ways that makes them not only satisfied but thrilled with the way they interact with our ecosystem.

by Liesl Bebb Mckay

Our book is yet unwritten

2016 was a year of discovery, of adventure, of breaking boundaries. For many it’s been a year of unparalleled innovation – especially for those of us that live in experimental spaces. We’ve long known that innovation is for the brave – those souls who dare to speak out, the curious ones asking “But who says?”.
As I reflect on bravery or courage or heroism, it dawns on me that bravery in any of its forms is remarkably like crazy – or is this simply a matter of perspective?

2016 was a year of discovery, of adventure, of breaking boundaries.  For many it’s been a year of unparalleled innovation – especially for those of us that live in experimental spaces. We’ve long known that innovation is for the brave – those souls who dare to speak out, the curious ones asking “But who says?”

img_6768As I reflect on bravery or courage or heroism, it dawns on me that bravery in any of its forms is remarkably like crazy – or is this simply a matter of perspective? Much of our lives as innovators requires us to quiet the voices in our heads yelling out “You can’t do that! It’s crazy!”. And it’s exactly this act of changing perspective that allows us to see possibility and create a new future – to disrupt our worlds. It takes a special kind of crazy to question assumptions that are years old, to challenge ideals and concepts that work well enough, to be that person in the room asking “why?”

In Adam Grant’s “Originals” (if you haven’t read it yet, what are you waiting for? It’s incredible!), he speaks about “Vuja De” –  the obvious reverse of Déjà vu – the concept of facing something familiar but seeing it with a fresh perspective that enables new insights into old problems.

In today’s world of work, one of the biggest issues we face is creating spaces where people can bring their excellence, where the uniqueness of the individual can be expressed to create winning innovation.  How do we create that winning culture?

For years we’ve followed the rules on how “work” is, a kind of imaginary Encyclopaedia Britannica of how we work. But that imaginary book was written before “we” were working! It was written before many of “us” entered the world of work! Us being women and millennials and innovators and also closet creatives, and evening gardeners and day-time-suit-wearing-iron-men and also… well, most everyone.

Let’s face it, this book was written for a bunch of folk who are now in the minority. And don’t get me wrong, it worked really really well back then, but for “us” in the workplace now, it really does fall short. Many of us feel that our workplaces just don’t enable the way we need to work. So why then are we still using that imaginary book as our core reference guide?

That way of work was perfect for specific workplaces, for a workforce that were all very similar (or were told that they had to be) and for a time that was, well…industrial revolution. We’re in a whole new time, with a whole new workforce, and yet – there is no new book!  We have moved from a world where work was about creating consistency, to a world where work is about embracing each individual’s unique contribution and, if we wish to see that reality, it means we are going to need that bravery to change our worlds of work.

img_6779And it’s right about at this point that I hear Natasha Bedingfield belting out “I’m just beginning, the pen’s in my hand, ending unplanned” and then…a great big ol’ penny drops…it’s time to do some re-writing!

In 2017 I’m keen to see these new chapters take shape.  Let’s take the time to write “the Wikipedia of work” for our future, one that works for us, one that creates space for innovation, for creativity, one that allows every person to thrive, one that isn’t creating a whole workforce of ill-fitting pegs.

We have already rewritten the chapter on dynamic working (literally rewritten), but there are still many chapters that we haven’t even begun to write. We’ve only just started the chapters on what the world of work look could like for single moms? What about the chapters on working dads? Or insomniacs? Or those that live far from their workplaces? Or nocturnals?

And what about the chapter on success? Does it still mean becoming the CEO? Really? What is success if you believe in balancing family and sport and work and creative hobbies? What could that chapter look like?

And what is a career? Is it really a straight-line 20-year plan? What if there was a chapter on changing careers mid-way? Or one on taking a break from your career? Or one on how to come back after a break?

Now is the time for a massive cultural innovation.  It’s the time for new chapters. It’s time for all you brave crazies out there to start recreating, it’s time to get writing. Take it home Natasha… “Live your life with arms wide open, today is where your book begins, the rest is still unwritten”

by Liesl Bebb-McKay

Bank of the Future: Quo Vadis?

History is littered with examples of derided radical thinkers, revolutionaries and heretics who challenged the status quo. One of the best known examples is the Roman Inquisition’s denial of heliocentricism. The concept of the earth moving around the sun…


“Status quo, you know, is Latin for ‘the mess we’re in.” – Ronald Reagan



History is littered with examples of derided radical thinkers, revolutionaries and heretics who challenged the status quo. One of the best known examples is the Roman Inquisition’s denial of heliocentricism. The concept of the earth moving around the sun contradicted the Roman Catholic Church at a time when the rivalling ideology of Protestantism heightened the need to defend the status quo. Consequently, in 1616, Galileo was instructed by Pope Paul V to abandon his opinion that heliocentricism was a physical truth even though the well-educated of society at the time accepted the heliocentric view as fact.

While the Catholic Church’s confrontation of heliocentricism was rooted in religious dogma, incumbent financial service providers are arguably stymied by systemic and architectural impediments that make shifting the status quo a near impossible undertaking. The existing conditions in banking are defined by siloed structures built around deep functional specialisation, legacy systems embedded in spaghetti architecture, unwieldy cost bases and a product-centric market-orientation.


The elements of the status quo described here have a profound influence on our approach to dealing with the future. It is extremely difficult for incumbents to deal with the changes brought about by the proliferation of advances in digital technology that enable Fintech startups to challenge one of the world’s most established, tightly regulated, and mature industries.

The financial services industry is awash with more than 1,300 Fintech startups, across over 54 countries, that have attracted in excess of $80bn in funding since 2010 and they are attacking incumbent business models on the three fronts:

  • Pricing transparency through disintermediation of traditional service providers;
  • Democratisation of products and services previously reserved for exclusive market segments; and
  • Provision of a streamlined, intuitive customer experience that make the traditional service providers look like a shoddy alternative.

While the Fintech disruption has so far been more pronounced in the retail space, it would be naïve not to see this as an omen of a fire that will surely spread to corporate and investment banking.


“Those things which I am saying now may be obscure, yet they will be made clearer in their proper place.” – Nicolaus Copernicus



As clear as the threat and need to respond may be, the status quo can never be anything other than a feeble and flawed attempt of yesteryear to prepare for our future, fraught with uncertainty.

Our attempts to corporatise innovation and disruption are often informed by aspirations to emulate Silicon Valley. We all want to be more like Amazon, Google, Uber or Airbnb, so we strive to imbue our organisations with the same dynamism, appetite for failure and creative culture we regard as the panacea for deficiencies in our ability to innovate and disrupt.

What we forget is that as noble as our intentions may be, any disruptive play will face the resistance of the status quo in all its varied manifestations. Roadblocks to challenging existing conditions emanate from the vested interests of its custodians, their emotional attachments, outdated heuristics, the fear of lost revenues, cannibalization and obsolesce. These obstacles are not easily overcome.


“The riskiest thing we can do is just maintain the status quo.” – Bob Iger


To be successful in transforming the status quo, you need to begin by planting a seed at the heart of the organisation and nurture it. That seed is recognising the palpable risk implicit with defending the status quo at all costs. This recognition must occur at the highest levels of leadership, the custodians of the status quo who have the power to shape it. It’s well documented that the most common reason for failed initiatives is the lack of executive support. Solve this problem up front, and you have already won half the battle.

A word of caution though, recognising the risk of maintaining the status quo is only part of the solution as it does not address the systemic challenges faced by banks. For an innovation and disruption unit to be truly successful it must, as far as possible, operate within its own governance framework, unconstrained by the parent organisation’s existing circumstances. Furthermore, banks must be prepared to embrace open innovation principles and collaborate with their would-be fintech challengers. The growing trend towards collaboration between fintechs and banks is well noted and is most prominent in the corporate and investment banking domain.

These pieces of the puzzle are far more difficult to solve but are nevertheless the only way banks can break the shackles of the status quo, innovate freely and keep up with the pace of digital disruption determined by their agile couterparrts.

Counterintuitively, running an innovation and disruption unit such as RMB’s Foundery is less risky than sitting back and taking a wait-and-see approach. The Foundery is a bold declaration of RMB’s intent to challenge the status quo, at both an organisational and industry level.

by David Krawitz

5 simple steps to turning ideas into reality

Fintechs — and start-ups in general — are many and varied and, although we are definitely leaps ahead of the banking of the past, we still have work to do in creating sustainable change in the banking ecosystem. Here are 5 simple steps we believe can get you to meaningful banking transformation.

aeroplane-boyFintechs — and start-ups in general — are many and varied and, although we are definitely leaps ahead of the banking of the past, we still have work to do in creating sustainable change in the banking ecosystem. Here are 5 simple steps we believe can get you to meaningful banking transformation.

Before we get into the details, a small spoiler alert is necessary…simple does not mean easy. In many cases, simple means quite the opposite of easy…you need to lose weight? (Don’t we all?) The solution is simple — quit sugar, kill the complex carbs, eat small meals and exercise at least 3-4 times a week — you see it’s simple!

But, we all know it’s not that easy. When that alarm goes off at 5am on a winter’s morning, how easy is it to drag yourself, your internal maniac kicking and screaming, from your delicious, cosy warm cocoon? Or when that 3pm slump hits and the vending machine choccies lure you closer with promises of joy and comfort and everlasting fulfilment, how easy is it to keep the craving at bay? You get the point.

In creating the necessary change for the banking ecosystem, we can apply 5 simple (but not easy) steps:


Boy in boxIf you believe that change is an imperative, and if you know that you need to create an impact in the banking space, then believe that you can change your world — and you will. A person who believes deeply is infectious — the stronger your belief, the more infectious your ideas, and the more profound the impact you can make.

Shifts always begin with a great idea and a great passion — if you have the idea or passion, trust that you can make it happen. Note to self: if you could believe in Santa Claus for like 8 years, you can believe in yourself for like 5 minutes…you’ve got this!

We have a massive amount of data in our heads that gets drowned out in the daily hubbub. We don’t need to hire a consultant or an expert to solve the problem for us…“they” or “the head of” or “the consultant” don’t know the answer that you already know — you know your business better than anyone else, you know your client better than anyone else, and you know the dissatisfaction better than anyone else — you just need the time to figure it out.


There is something magical in the power of a pack. “For the strength of the pack is the wolf, and the strength of the wolf is the pack.” ― Rudyard Kipling, The Jungle Book.

Once you begin the disruption conversation, you will realise the overwhelming number of others who believe that change is an imperative and who are looking for a place to make a difference.

Influence can be as powerful as the individual, but impact can be exponentially improved as a small team. Disruption in banking requires significant influence and (by definition) uncomfortable change by challenging assumptions. You will need a powerful pack with you in this journey. That may mean partnering differently or with players you have not considered allies in the past.


boxing-with-robotInnovation always stems from need. We identify needs most easily when they aren’t met. We need to be better at recording, and then challenging, our daily dissatisfactions.

Very few ideas actually happen in a flash of blinding clarity. All big solutions start with just a hunch. We circle around them for a long time before we finally hit the mark (and most often, a whole group of people hit the mark at the same time) and it’s the bravest who get the glory — think Darwin.

So what dissatisfaction exists in delivering the needs for banking as we define them? And, be brutally honest about what this dissatisfaction is — don’t just pick the easy answer. Opportunity exists when there is a frustration or a barrier to entry. What people want doesn’t change — how they get it does.


As a leader of change, you really need to know who you are leading. To create sustainable disruption, you need to test your thinking — widely, and repeatedly! Feedback is a powerful tool in honing the product you have and the language that will be appropriate for your organisation. You’ve probably heard the rule of mathematics: if it feels easy, you’re doing it wrong.

In the rest of life, if it feels too difficult you are doing it wrong, especially when it comes to creating change. Each organisation will require its own language and its own solutions. If it feels too difficult, get feedback and tweak the strategy until it begins to feel right for you.

To make an impact, we have to accept that we will fail in some way. So, what are you waiting for? The only way to get to an answer is to experiment. Experimentation in a highly regulated industry sounds pretty frightening – but remember that if the frustration or barrier to entry make delivering the need too difficult — there will be disruption — you are going to have to experiment with how to do that yourself. We are taught from tiny that failure really isn’t a great idea, and in banking even more so, but if you are going to be a really disruptive, you need to create an environment where good and bad ideas are embraced…simple….not easy.


Rocket boyThere will be failures and mistakes and difficult conversations, but each of these acts as an opportunity to adjust the strategy and to refocus on the end goal. In these moments, remember the steps: believe in possibility, the pack is bigger than the wolf, get into conversation, seek feedback and just keep on keeping on.

We said at the outset that these steps may not be easy. So, how do you start? It’s a simple case of ready, steady, GO! Just like quitting sugar, if you know your end goal and the reason you need to achieve it, you can access the power within you and then just start. Drag off those warm winter covers, say no to the vending machine and take the first step. The beginning may not be easy, but once you’re on the road it feels pretty great, and the satisfaction as you see the change happen is well worth the effort.

by Liesl Bebb-McKay