- Zoltán Dankó is the head of the software engineering team at OTP Bank in Budapest. He emphasizes using open-source technology and giving engineers freedom in their work. - He focuses on hiring talented individuals and creating a supportive environment where people can develop their skills and find their "Ikigai" or purpose in their work. - Dankó runs workshops on topics like psychology and stress management to help the team work better together and avoid conflicts. Over 80% of the team chooses to participate in these workshops.

1. "We need money to exist, but if only
money can motivate you, it won't be
enough."
A Conversation with Zoltán Dankó, the head of the
software engineering team at the OTP Bank.
2021.09.15.
Source of the translation: Friss Diplomás Blog
I confess, I never came to the idea that having a conversation with
the head of a software engineer team would not be confined just to
codes and systems, but we would cover topics like psychology,
personality traits, and life goals, too. Although Zoltán Dankó
surprised me with this insight at the OTP Bank Group in Budapest,
he made a direct, open-minded impression, not to speak about
how he would pay attention to his colleagues and their needs. The
following interview will shed light on what type of professionals
would join the team and expect the newbies.

2. Tell us more about your job. How would you describe your day?
According to the official HR classification, I have the label Head of
the Software Engineer Team at the Distributed Systems
Development Directorate. I just translated it into plain language.
The Distributed Systems Development Directorate means that I
work in IT, representing an unusual approach with my team. There
are plenty of differences. First of all, we use open-source technology
in software development and the methodology as well. In banks
across Europe, it shows a different landscape. Not because it is a
Hungarian specialty, it is more a fact that the European banks don't
exploit this technological possibility and freedom either.
Because it is dangerous?
In reality, it is a misconception that open-source technology is
dangerous; the truth is just the opposite. Any code can be harmful;
it depends on how it was created in the first place. It does not
matter who developed the code; more critical will be if the code
proves harmful.
When we talk about closed code (about the product of a brand
supplier), we are not allowed to modify the code and fix the harmful
part. Instead, we have to inform the supplier about the fault and
request a change. How quickly and effectively it will happen is
another question.
We represent a different approach. Intelligent and experienced
engineers and professionals work in our team. We did not hire
them to tell them what to do, but they are experts who love and
understand their job. Therefore they also know how best to solve
specific issues. It gives us another option: if we have an error in the
code, they will fix it immediately. A pretty long time can elapse
between the two approaches.
Even years, I guess
That's right. I can make a dent in the universe. Let us suppose that
there is an error in open-source technology, for example, a
vulnerability. We may be able to overcome the obstacle even in
minutes. The other difference is that the supplier owns the closed
code. We, as the customer, get a license to use it, but we cannot

3. modify it. In contrast, all the codes written by our team belong to
the bank. We change or adjust it as we like.
It means more flexibility
Correct! Our following specialty is to create high-performance
systems at the lowest cost. You may buy high-performing software
if you have plenty of money, but designing one with a low budget
takes more thinking. It may be the reason why large companies
usually don't even make a try. We like the challenges. By
succeeding, many problems can be solved at once. We don't need
much money, our systems achieve high performance, and they
won't stop.
By the way, what does it mean the concept of a distributed system?
Let me explain the difference somewhat simplified by an example.
Until now, companies buy two computers, they run both, and if one
stops, the other takes over the service. Things become exciting if we
shut down one of them for maintenance. Of course, this time,
requests will be served by the operational one. During this period, if
the active computer fails for any reason, it means service
interruption, no customer will be served.
In a distributed system, like the one we use, we have five
computers, they run parallel with continuous communication. So if
2 or 3 computers stop working, it won't affect the service; requests
will be handled uninterrupted.
Why does not everyone do this way?
Because you only can accomplish this if you have software
engineers who profoundly understand their profession and don't
believe in the mantra, we can solve problems the old way and just
one way. Our following specialty is that we possess a high level of
diversity among our professionals. It enables us to choose the most
proper one from diverse options. Day by day, we exploit this
opportunity; every colleague has a chance to realize their
professional dreams.
I define my job to provide them with the work conditions and the
environment to realize their dreams in absolute freedom. We hire
professionals who enjoy the freedom to create new things, and I

4. don't need to explain to them all the time what they should do. They
gratify their passion for work freely, "without any constraints," which
may not be allowed them somewhere else. Expert discussions
refine the first concepts and determine which one could best solve
the business problem at hand.
So, people management best describes your role?
Yes and no. I like to characterize myself best as a commando troop.
I am dropped in the line of fire with a moderate amount of means,
and I have to set foot in IT questions and people management
issues or what else may come. I have to stretch a protection shield
at the perimeter of the team to keep corporate politics out. Our
experts should focus on professional topics in the first place. I would
describe the job that I am entitled to secure this work environment
for my colleagues all the time.
Providing them with uninterrupted working space
Within the team, we should balance the diversity and preserve
harmony. That was the reason behind the development program
we initiated two years ago. We aimed to enhance the skills and
knowledge of the colleagues that they, as humans, are aware of
how they function.
I remember the funny warnings in advance from my peers that it
was a bad idea to approach software engineers with psychology.
But I like challenges. I said, let us see what would happen. Now, this
is the second year of the program.
Can you mention some topics?
We talk about questions like how memory works. We let go of the
concept that the memory is like an SD-Card. Information will be
recorded and then retrieved. In reality, it works entirely differently.
So, we worked through the topic in a workshop enriched with tasks
in an interactive way. The next one was about our fears, our
anxieties, or how to handle stressful situations. Our main target
with the workshops has been to reduce the number of conflicts.

5. I haven't thought at all that we would talk about such topics. So how did the team
react?
The first season was mandatory for everyone. To not crush the
colleagues' brains, we maximized the length of a workshop at 20-
25 minutes. I announced the second season as not mandatory. I
wanted to see who took it seriously. To my surprise, 80% of the team
subscribed to the workshops. However, they requested longer
sessions because we could not discuss the topics properly, so the
new sessions lasted 45-60 minutes. 6-8 colleagues participate in a
session. This number is not too high, so they dare to ask questions.
Better to deal with such questions that interest them.
Can you see the results in the workday?
We have had several positive practical experiences. More and more
people gave me feedback on the knowledge they acquired in the
workshops and the techniques for handling specific situations that
do work. Colleagues slowly tend to take care of each other; they
help the other recognize being stressed. If I realized the pattern in
a situation, I had the opportunity to prevent the chain reaction.
As new colleagues joined the team, they pointed out that they
would instead work at a company where these human
developments were taken care of. Two years ago, we created a
collection of guidelines that summarize how we would like to work
in teams, which rules we follow, and which behavior patterns we
welcome. One of them is the Ikigai concept: We need money to
exist, but if only money can motivate you, it won't be enough to
grow yourself and the team. We appreciate it as a great result if a
colleague can eliminate their prejudices against others about
religion, race, sex, or skin color in the working relationship. With the
realization, many fears will be removed at once that could have
been the source of a conflict.
Let's discuss the hiring process briefly. But, first, what is a job interview like with your
team?
We have designed complete recruitment, hiring, and onboarding
process. Upon a candidate is arriving, independent of it was an
internal recommendation or a headhunter, or any other source, we
decide based on the CV in what role we can imagine the candidate
may fit according to their qualifications. In case of a favorable

6. decision, the candidate fills in a test. Don't think of a usual
psychological test; the questions search more for the candidate's
way of thinking, decision mechanism, or behavior in situations. For
example, how would you cross a crowded square, or would you
apply for a job on the Moon?
If the candidate can successfully manage to get through this
hurdle, then a team interview follows. The candidate meets and
talks with our colleagues 1-1.5 hours with whom the candidate will
work. There is no fixed set of questions. It is up to the colleagues and
the situation. I set only one objective: they should be able to decide
after the interview definitely whether it will be a good idea to sit
next to each other a day long. Of course, they won't talk about bank
or business secrets, but beyond that, there is no tabu; they can ask
questions relating to any topic.
That was the last stop in the hiring process. In the end, we make our
decision whether the candidate fits our team culturally, personally,
professionally, or in any other respect. Then, the same task is given
to the candidate. Unfortunately, several senior software engineers
and experienced professionals could not meet the expectations
and failed the "mindset"-test.
How do you deal with the juniors without any work experience?
We apply the highest number of trainees in the bank. 10-12
colleague candidates, approximately 10% of the entire team at an
earlier time. Trainees land in our group either through the HR or
they apply directly from a university. We don't differentiate
between a trainee and a candidate regarding the hiring process.
Same tasks, same hurdles. After the onboarding process, the
trainee will be tasked with real problems like the "big guys." They
can see how our colleagues approach a task, which steps should be
followed, which rules should be applied at each stage. They can
catch the secrets of the profession.
Do they survive all of these?
The fittest do; they don't have any other chance. We continually
monitor our trainees whether they are ok, or our colleagues look
happy week after week. Trainees get feedback on where they
should give more effort, which behavior pattern is not acceptable,

7. and the same is true for the personality traits. Of course, not
everyone meets these high expectations, but I can name at least
three colleagues who started as a trainee, as many others, went
through our trainee program successfully. Since then, they have
become full-time employees in our team – in the past year and a
half.
Could you share some details about your trainee program?
Our trainee program lasts six months; it does not differ from what
we usually do day in and day out. If we want to prepare the students
for life, they should meet the exact expectations and experience the
same situations as our full-time employees. They sit next to the "big
guys," obviously, they get tasks they can solve. This way, it can be a
good measure for the trainee period how much they have grown
and become an integral part of the team. We monitor how
proactively they take on tasks, how assertive they behave, how
creatively the trainees solve specific problems, how good they are
at the collaboration, how to manage conflicts. We do not measure
them and the full-time colleagues differently; the same aspects
apply to everyone.
We mentioned the concept of Ikigai earlier. Have you found your Ikigai in this job?
I did; it is the reason why I have still been here. I enjoy working with
people; I like to build teams. It's a joy to establish an entire
environment where all of us can be a delight workwise and
humanwise.
What kind of advice would you give those who still have been searching for the right
job? Let us focus on the IT field.
I don't give any professional advice to anyone, especially not to
career entrants. It is irrelevant what they know and whatnot. If
someone eagerly wants to acquire a profession, it will be done. In
contrast, if a person cannot find motivation in anything, I can give
them the best advice, although nothing will happen.
And what would be your general advice?
My advice could be labeled as "soft skill." Learn how you as a human
function and behave, seek out what you like and dislike. Usually, I
ask about it as my first question in the interview: what do you want

8. to do most? Candidates get confused because they cannot
determine whether I meant what they would like professionally or
privately. It is no accident that I am not specific. I force the
candidate to talk about what they most want to do.
Many started to explain the work-life balance to me. It does not
make sense to me. We usually jump to the conclusion that life
should be the good one, and consequently, the work must be the
bad one. Our task is to balance them. This type of question can only
be asked if you hate your job. If you like what you do, you won't
count the hours when finally the 8 hours elapse, but you continue
to deal with the task as long as it feels good. We would like to see
this mindset in the colleagues because if you enjoy your job, you will
feel great about it and care about the quality of your work.
In contrast, if you hate your job, the result will not be worth
remembering. Is the situation familiar when a coercion
entrepreneur is executing a task in your home? How do you feel
about it?