Digital transformation and DevOps culture with Patrick Kua

We spoke to Patrick Kua for our 0800-DEVOPS newsletter.

If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!

###

Patrick Kua is former CTO and Chief Scientist at N26, former Technical Principal Consultant at ThoughtWorks and a book author. His experience in building complex systems and organizations puts him among top people on my interview bucket list! And if it weren’t for COVID-19, we would have met this year on our annual QED conference where Patrick was announced as our keynote speaker… but we all know how this one played out. Nevertheless, I chatted with Patrick on some of these topics and I really hope to meet in person soon.

Ivan: Patrick, you worked as CTO and Chief Scientist of N26 bank. Let’s bust some myths! Can a traditional bank be as innovative, fast and nimble as a digital-native bank born and raised in the cloud?

Patrick: If a traditional bank is going to be as innovative, fast and nimble as a digital-native bank, they really need to embrace a digital-first culture. Unfortunately many traditional banks are still centred around a branch (in-person) and paper-based model – particularly a lot of the back offfice processes. Even when they have digitised their processes, many organisations (and not just banks) that go down the digital transformation route, don’t take the opportunity to reinvent their processes – they simple automate their existing processes and don’t question if they can do it completely differently given what technology enables today. A great challenge indeed!

Ivan: What are in your experience key things that a traditional bank needs to do differently to catch up with digital-native banks?

Patrick: There are three things I recommend traditional banks need to consider:

1.  1. Explore what can be done with technology today. It doesn’t have to be just banking, but also seeing what other digital-native companies do to be inspired by what might apply in their world
2.  2. Focus on Customer and Product first – Most banks are process and regulation concerned first. User experience and product-centric thinking tend to give way to process and regulation. Regulation is important but shouldn’t drive the customer and product experience.
3.  3. Build an Engineering Culture – Most banks still see IT as a cost-centre, not as a product development company. If they don’t build an engineering culture, they won’t find the good talent that allows them to build great product.

Ivan: What do you see as key challenges that organizations stumble upon on their way to digital transformation? Do you see any specifics in the financial industry?

Patrick: I touched upon these in previous answers. The challenges of a traditional bank are true for many companies under going digital transformation. A lot of this is cultural (rules, processes, structures and roles) and you need the couragous executives to challenge this who understand digital first thinking. The specifics about financial also applies to other industries like health that are heavily regulated. The intent of regulation must still be met, but the specifics, or how you meet the regulation need to be reinvented for a digital era.

Ivan: Regulations are often seen as a major obstacle for traditional banks. Do digital-native banks also conform to these regulations and how is their approach to regulations different?

Patrick: Not all digital-native banks are technically banks. Many are pseudo-banks (e.g. borrowing other bank’s licences) – which means they do not neccessarily need to conform to regulation but also people’s money is not necessarily protected. Other digital banks are true banks with a banking licence and, are of course, subject to the same regulation. Once again, it requires understanding what is required by regulation and taking the opportunity to reinevent controls using digital-first thinking.

Ivan: You are a co-author of a very relevant book Building Evolutionary Architecture. Can you tell us what are the typical legacy architectures and issues that you have seen that made you write this book?

Patrick: Back in the 80s-90s, change was slow. Architecturally significant decisions were often made very early, and the envirionment in which you built software didn’t change. This lead to both software processes that didn’t take in feedback very well. Agile solved this to a certain degree but many methodologies don’t specifically mention architecture – which lead to many teams forgetting to consider this. We wrote Building Evolutionary Architectures to help people reconsider how they approach architecture, and how to integrate that thinking into the way they build software today.

Ivan: When talking about DevOps, people often refer to various tools. You, on the other hand, talk a lot about empathy and software being a team sport. What is the importance of social aspects on software development and how have you in your organizations supported this?

Patrick: I describe DevOps as a culture of collaboration between Developers and Operations (their organisation, thinking and tools). Too many companies create a DevOps team/role only increasing the divide with a Developer-DevOps and DevOps-Operations handoff. Software development today means working with many people with different specialties in different areas. Even though we talk about full-stack engineers, I don’t know of any engineers that are experts in all fields at once – security, networking, infrasturcture, architecture, testing, etc. Yet at scale all of those skills are necessary which is why we have to collaborate quite well. Organisations that understand the nature of this invest in building those skills in all team members building software and also find ways to encourage and reward collaborative behaviour. Unfortuantely there are too many companies that still look at software as a feature factory. The factory metaphor is still rampant today – even though lean has also transformed the way most modern factory lines work.

Ivan: We’re not trying to undermine the importance of tools, process optimization, and automation. What has in your past organizations been the absolute minimum of process automation and what tools did you typically use?

Patrick: If you’re building strategic software, it’s essential to invest in Continuous Delivery and Test Automation. At scale, these tools are about increasing feedback which helps you manage growing complexity.

Ivan: Can you share with us what are you reading these days and who are the people you follow that make you think differently and do better?

Patrick: The best book that addresses the previous question is one by Nicole Fosgren et al, Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations.

###

We spoke to Patrick Kua for our 0800-DEVOPS newsletter.

If you’re interested in receiving interviews with thought leaders and a digest of exciting ideas from the world of DevOps straight to your inbox, subscribe to our 0800-DEVOPS newsletter!