Principally Speaking: Elevating Perspectives with the Architecture Elevator

A conversation with Stephan Dowding, Principal Engineer for the Money Movement Clan.

When did you write your first line of code? For Stephan Dowding, he typed his at the tender age of 7.

A curious child with an unquenchable thirst for knowledge, Stephan was that kid who would dissemble his toys and anything mechanical just to understand how they work. His brush with an old ZX Spectrum in his house sparked a fascination with how computer programs operate. Armed with programming books borrowed from the library or bought by his parents, he began his coding journey, eventually pursuing computer science at university and earning a master’s degree in the same field.

Dowding described understanding the inner workings of computer programs as a neverending odyssey; one reason why he is still passionate about software engineering.

He began his software engineering career building internal software for a pharmaceutical company in the United Kingdom. He then ventured to other companies in different fields, although his task remained the same: building software. Then, his wife introduced him to Thoughtworks, a global tech consultancy firm, which he joined for 13 years. He made the decisive move to relocate to Singapore, marking a new chapter in his career and life in 2014. Finally, he was trusted with the role of Head of Technology in Thoughtworks Singapore in 2020.

Despite relishing his works at Thoughtworks, Dowding found himself mulling over a change. He never really acted on that thought until he met DKatalis’ Chief Engineering Officer, Alex Titlyanov, who invited him to join the company in building a digital bank. The invitation intrigued him, and he’s been a Principal Engineer for DKatalis since 2021, helming the Money Movement Clan.

Could you share a bit about what the Money Movement Clan oversees?

Stephan Dowding (SD): Sure. So, as the name strongly implies, Money Movement deals with making payments, debit card transactions, and ensuring the transactions show up in the transaction history and account statement. Ultimately, the money movement clan deals with all the parts that involve actually making transactions and actually moving money.

What makes our Clan unique, I think more so than with any other clan, is that when something goes wrong in money movement, people notice much faster. When people log into their banking app, they usually have the intention of moving some money; which consumers consider as the core functionality of a bank.

That gives us that unique perspective, that we have to make sure that we can give the users a good, reliable experience. And I think the part that also has the most challenges is there are many third parties in between when we’re moving money between our bank and another bank. So, how do we make sure that we can move the money in this uncertain space with a degree of certainty and safety?

Indeed, banking is a high-risk industry with tight regulations. Could you explain more thoroughly on the challenges and how do you tackle them?

SD: First, once the messages or transactions leave the bank, we effectively don’t have control over what happens to those messages anymore. But we do have to make sure that we put our own guard systems in place, so that if things don’t happen as they should, how can we make sure that we don’t do the wrong thing? How can we safely and reliably get back into the correct state? If we do it wrong, we might end up in places where either the bank potentially loses money, or the customer is given the wrong information; we want neither of those things. We want the customer to get the right information as to what has happened to their money, and we also want to make sure that the transactions happen reliably. It can be very challenging.

Then, as you said, banking is a high-risk industry, which is ultimately why we have all these regulations in place. When it comes to banking, everything is about trying to achieve balance. When sending money to another bank, it’s important to ensure that the balance aligns with what they believe they received, and vice versa.

We always have to make sure that we have that balance. And when things don’t balance out. We proactively start looking at the systems and all the steps along the way to see where things didn’t go right so that we can improve them.

That’s one of the key parts of what we do in money movement. It’s not all just creating new transaction types but also looking at our existing transactions and continuously trying to make them better, trying to improve them whenever we spot something that doesn’t line up. When we spot some area of unreliability, then we always proactively try to attack that area and improve it, making it more reliable to continuously improve.

With the high stakes that your Clan holds, as the Principal Engineer, what are your responsibilities?

SD: In the Money Movement Clan or in any clan, one of the key responsibilities of the principal engineers is to mentor the other engineers and help them with their career progression, whether they are junior or senior. We have a culture of continuous learning, and it is one of the co-responsibilities of the principal engineers to ensure and to encourage all the engineers to continuously learn and fulfill that culture. The other core part of the principal engineers’ responsibility is to, I think, have a broad view of what’s happening in the technology, and in the people space. We need to make sure that the software and the teams are growing in the right direction.

Because, when it comes down to the developers on the team, the less senior ones tend to look at the items they have to work on in isolation, thinking, “How do I solve the problem for this one item?” Hence, it’s the senior engineers’ and the principal engineers’ job to bring in the wider picture. We nudge them not to look at this item in isolation, but there’s also a wider picture around it that will influence how they approach and solve the task.

You don’t want to just solve that small item that you’re looking at. But you want to solve it in a way that targets the bigger picture that we’re aiming for.

An analogy called “the architect elevator” really stuck with me. The principal engineer is, I guess, the closest we have in DKatalis who could be considered an architect and have to be able to ride this elevator all the way up to the top, meaning solving these big problems and talking at the big picture level. And then, we also have to be able to ride that elevator all the way down to the bottom to talk to the most junior engineer in the clan who’s looking at a more specific class in the code. We have to be able to drill down to that new level and give reasonable, coherent guidance.

In terms of giving guidance to your team and perhaps others outside, do you have any preferred methods?

SD: I encourage them to come to me for one-on-one discussions. But it’s really up to them. Generally, the more senior ones would be the ones who will come to me, while the more junior ones are more likely to talk to the more senior ones within their team.

Also, during our refinement sessions, I draw out the big picture that we’re aiming for so they can see how their items should fit into the bigger picture. It helps them give a view into how they can solve these problems targeting what we’re aiming for. This is what we’re looking to achieve.

Here is this one item that we’re looking at, and this is how it fits into the overall picture.

Are you very passionate about mentoring others?

SD: I think it’s just something that I naturally grew into. When I got my first programming job, I was the only engineer there. At that point, it was a lot of self-mentorship. Then, the company started to hire other engineers, mostly juniors, so I had to guide them into how they could do things. I would arrange some sessions where I would talk to them on a day-to-day basis. Eventually, I forged some good relationships with those engineers there.

During my time at Thoughtworks, which has a very strong continuous learning culture, pretty similar to DKatalis, mentoring and being mentored is something that comes up very strongly there. ThoughtWorks has something called the “Sponsorship Program” in lieu of having traditional line managers, and each person is encouraged to find their own “Sponsor”. Towards the end of my tenure at ThoughtWorks, I had as many “sponsees” as I could realistically handle, so when new people would approach me, I would help them to find suitable alternatives, who could help them with their goals, rather than taking them on myself.

I think we’ve reached the end of our conversation today. Do you have any tips for aspiring engineers who want to thrive in the industry?

SD: If you want to pursue a career in coding or engineering in general, when you first start learning coding, don’t worry about the programming language you want to learn. It’s about your interest. And don’t worry about what kind of software you’re writing, especially when you’re starting off.

Especially when I think about my career, where one week, I’d be writing code in C#, and then the next week could be in Ruby. The week after that, in JavaScript, and then Elixir and all sorts of other weird and crazy programming languages. Having that solid grounding did help me jump from one language to another without too much difficulty.

Once you have a good grounding in your favorite programming language, my next tip would be to learn how compilers work. The thing that really opened my eyes was when I learned how the code that I’m writing on the computer gets translated into the code that the computer actually executes. Since I did that, when I’ve been writing my code, it is something that’s been valuable in that I can then understand how this code is working under the Hood. That has definitely enabled me to jump from one programming language to another more easily because I understand what’s happening at the base layer. When you get a different programming language, it’s just a case of remapping what the commands here mean to what the computer does under the hood.

Then, you want to start looking at system design and automated testing in order to get into proper professional coding. Because at that point, it’s no longer just coding but actually systems development. You want to make sure that you’re not just writing code, but you’re creating a solid system. And obviously, you want to have automated testing so that you can make sure that it’s doing what it’s supposed to.

That’s the progression of things that you need to learn. But I think that’s the order that helped me to get into a good solid grounding and understanding of everything that’s going on.

Do you thrive in a professional environment that encourages community learning and collective growth? You might want to join us!