Meet Madalin, our Senior Design Authority in Cluj, who knows everything about Payments and creating successful teams.  

Madalin is a design thought leader and Payments SME involved in many projects, and he’s also a technical advisor for organisations that look for a lean transformation in a complex environment. He is passionate about Payments and Technical Excellence, always being up to date with the latest trends.   

His role is very complex, from providing senior-level pre-sales support to documenting solutions and architectures to giving guidance to delivery teams and overseeing the technical quality of project delivery. 


How do you define technical excellence?  

Technical excellence is applying a set of practices that are proven to bring value in order to deliver products that are robust, resilient, secure, performant and so on.  

In order to promote and apply technical excellence, you need a mix of knowledge, experience and passion. You need the knowledge to know what tools/practice/techniques you have available, and experience to know when and how to apply them in an optimal way. 

You need passion to keep learning, changing, and adapting to new challenges or situations. If you have passion, you’re most likely a self-motivated person and chances are you’re one of the doers rather than the ones that wait for things to happen. And you probably like learning new stuff. This will help you gather experience faster. Everything is connected. 😊 


How did you develop your career at Endava? 

I started as a developer in 2008 on an insurance project.  

In 2011 I was in the initial team that started the Worldpay account and took over the Scrum Master role of the initial team, focused on growing the account from that initial team to 23 Scrum teams (now). I then took a Design Lead and Scrum of Scrum Masters role as the teams started to grow.  

Afterwards, I became a leader of the Technical Leadership Scrum team.  

I also helped to develop the Java capabilities in Cluj and became what is now known as a Discipline Lead after a few years.  

In 2018 I took a role at AGU level becoming Design Authority (DA) focused on Payments and moved to a Senior Design Authority role leading a DA team at FIN2 sector level.  

But I’ll always present myself as a developer.  


What would you recommend to those who want to build a technical career path? 

There is a misconception that any technical person has a choice to make at some point in their career: you either go on a leadership path (still in the tech business, but more focused on managing people) or a technical path like Architecture, but in which you usually lose the hands-on aspect.  

If we do an analogy with doctors, it’s like making the experienced surgeons choose if they want to manage other medical professionals or be more like “consulting” surgeons.  

They are both valid options, but there should always be a third equally valid one: you become an even better surgeon (developer) so that you can do more complex stuff, in less time, more efficiently, incorporating previous lessons learned.  

So, my advice? If you still like writing code, don’t feel obliged to choose something else in order to advance in your career. Focus on doing things better, faster, more efficient, resilient, broaden your experience, focus on problem-solving not shiny technologies, never assume you are the smartest in the room.  

Get into uncomfortable situations, take the lead, and ask for help when needed. Don’t focus only on the tech skills, soft skills are equally important: it’s hard to propose a technical solution if you don’t have the right skills to present it or convince people of its benefits. 

What are the tools/ technologies you are mastering?  

Mastering is a strong word, and I don’t like to overstate my capabilities. I’m pretty comfortable with any Java-based technology and old and modern architectural and software design paradigms: monoliths, SOA, microservices, cloud, CI/CD, etc. I’m a strong believer in automation in any form. Even if it might not be considered a tool or technology. 

I also think it’s important to have the right level of processes and standards. I’m always puzzled by the extremes: either people say “we are Agile, we don’t need architecture” (you can replace architecture with virtually anything) and the opposite where you start from something simple and put layers, processes, roles and interaction, while still calling it Agile.  
 

What is your strong suit? 

Resilience and endurance. I have no problem doing the non-shiny work. I have this motto (which might sound a bit cliché): Today I’ll do what others won’t, so tomorrow I can do what others can’t. 
 

What technical subjects do you prefer for knowledge sharing sessions and Pass-It-Ons? 

Innovative ways of testing, baselining quality and technical excellence in projects, application security, API design, and building resilient systems.