Goodbye, ERFI!
by Zoltán Dankó
Future-Proof Organization Practitioner -- Human leadership fuels high performance. If you have open mind, I help add open culture to leverage open-source - Change is risk: doing the same leads nowhere. Let's move on!
„Everyone knew it was impossible until a fool who didn't know came along and did it.” - Albert Einstein
Embarking on a journey
It all started on 2 January 2017, an unexpected journey with ERFI (See note 1 below). I joined OTP Bank Group that day. (See note 2 below)
It was my job to establish a new team from scratch to deliver a large and complex real-time financial service for the Bank. As it turned out, our team should make a dream come true.
Good stories do not happen to us alone. So, I must mention Laszló Popovics, my ex-colleague, with whom we completed each other on this journey. We became a unique duo to ignite innovation on multiple levels.
We were told a dream about an accomplishment that did not come true in financial corporations across Europe till that day. It was thought to be impossible even to try. Let us see the founding principles we followed:
- The team consisted of internal employees only.
- Only hardware suppliers brought us commodity equipment.
- None software vendors.
- Only open-source technology.
- All codes belonged to the bank.
- Best software technology for real-time financial services in the world.
- End-to-end delivery, no pointing out to other teams.
- High-performance technology delivered at the lowest TCO.
We met benevolent individuals who recommended us to give up these plans at once since a professional with common sense could see from far away that it was a mission impossible. We listened to these voices politely and got to work with László.
Finding the software technology for next-generation real-time services
The first step was to identify the elements of the software technology. We were practical minds. Those companies were collected in our assessment which provided real-time financial services. These companies spent much money on research because it was a life-or-death quest for them. Therefore, we adopted the required elements for our purposes.
How to attract the right people?
As a next move, we wanted to find the “right stuff” in software engineering.
We quickly realized we did not need ordinary software engineers like many companies. Instead, our approach to recruitment was based on the mindset of the software engineers. That was the birth of our bold recruitment and onboarding methodology. A new mindset test was created to challenge the candidates. We did not test the candidates' personality traits but asked questions that depicted a holistic picture of the candidate.
Of course, the candidates went through technology and thinking roller-coaster. However, the backbone of the interview process revolved around the colleagues who would work with the recruits. My request for the colleagues was clear and simple: “At the end of the process, you have to decide whether it would be a good idea if you would sit next to each other with the candidate for eight hours long.”
Everything is about a good story.
We, humans, like good stories. Our new senior staff went after the story, too. What was the project about? Was it a bold challenge enough? Fortunately, they appreciated that they could barely find similar size projects often in a lifetime.
Methodology – which one to choose?
What could be the suitable methodology for work? In a bank. We voted to use Scrum. Bank professionals warned us that it was not the most appropriate methodology for a large-scale project in a bank. There were not many examples in Europe that we could copy them. We also knew that our team must cooperate with other groups in a traditional hierarchical working style.
Nicolaus’ present
On 6 December of the first year, Nicolaus brought a present to the IT management. We presented a live system of three nodes that processed transactions. 1,200 pieces a second. The software that managed the transactions was about to be upgraded to a new version while the system continued processing the transactions – non-stop. The upgrade was successful – without losing a single transaction. An experienced IT manager remarked with a polite smile on his face: “You know, an upgrade is always easier. Let us see the downgrade now.” Three clicks and the system went back to the previous software version – successfully. A green 0 showed how many transactions went lost. I have never heard such silence!
Surprises and responses
As we were progressing with the development of the new systems, and because we embarked on new paths, we could not ask for help, but we had to figure out the answers. We felt like traveling with a racing car at over 200 km/h and building or replacing some parts of the vehicle.
New teams emerged along with the onboarding of new colleagues. A technology core team with the most senior staff; business analysts with the capability to negotiate with the business colleagues until reaching a viable conclusion for how to develop a service for the long run. Test-automation team created excellent simulators and orchestrator; the DevOps team took care of our infrastructure and workstations. The HR and Communication teams helped stay on the road. Finally, we realized that we could only complete the best software with a specialized Security team that governs the development work, GDPR, and the prevention of cyber vulnerabilities.
Within less than two years, the time arrived for us to present our full-scale demo of the new systems. We were ahead of time so far that we had to use our simulators of legacy systems to show the audience how our systems managed the transactions correctly. The demo affected the audience; there was one question: who developed all the components presented in the demo? The answer was: Our Team
During this period, our R&D team experimented with mixed reality technology. With the help of Microsoft’s HoloLens, we imagined the virtual banking experiment beyond mobile phones. People were fascinated to try out this futuristic technology in person. If you want to experience it, watch this:
Self-organization methodology in the lab...or reality?
After two years of intensive growth in staff and experiences, we had to reflect on the lessons:
- Scrum was not the ultimate heaven methodology. We found that communication between teams could be improved.
- For some unknown reason, teams engineered the same piece of code despite the coordination of the Scrum masters.
- Personal conflicts often arose without real solutions – as it turned out later.
- The most painful part was the faith battle of the Scrum masters who could best explain the Bible of Scrum.
The only good news was that we delivered the promised software.
Deep considerations led us to a painful decision: we said goodbye to Scrum.
What next? We thought Teal could be a good choice, but we evaluated it as too diffuse at that time, and there were some written Bibles as well, so we did not want history to repeat the story.
We made a bold decision: we would start with self-organization. To keep it as flexible as possible, we named our version of self-organization a Pluralistic Methodology. Colleagues could use any rite or ceremony of any methodologies available on the market on two conditions: they had to love those ceremonies and support work effectively.
A team called Sentinel was created parallel with introducing the new methodology to support the transformation from Scrum to self-organization. Every team was represented in Sentinel. However, the members had their own tasks, so they were not eager to create fake ones to spend the working hours.
Self-organization …without leaders?
Our organization was flat. Only the larger specific groups had a leader like DevOps, Development, and R&D. 6-8 persons worked in a team. The Sentinel team supported them in different ways to improve cross-team communications and cooperation. This organizational structure had diverse functional consequences:
- Colleagues made the decisions in work-related questions.
- Responsibility for decisions remained on the team.
- Organizing information and cooperation were led by the team.
We learned several personal-related lessons as follows:
- No one needed to wait for the boss’/leader’s decision.
- The biases of the boss/leader did not corrupt the process.
- Only those who enjoyed self-organization could appreciate the freedom and responsibility.
- Some colleagues did not like the growth path, so they left the team.
I realized after four years, two of them in self-organization, that the only factor determining the success or failure of any methodology was this: the development level of a team member’s personality.
Human development workshops – On the way to a future-proof organization
So, if colleagues were not developed in their personality, they acted in any methodology, like being on stage. What if we help colleagues in this development process? The result will affect not only work but private life as well.
That was the birth moment of the ERFI personality development workshops. In the first year, it was mandatory for everyone to be on the same level. Each workshop lasted 25 minutes. (I was warned that software engineers did not like psychology very much.) These interactive meetings gave the framework to expand colleagues’ knowledge and practical tool repertoire in How memory works? What are fear and anxiety? What is a shadow personality? How do beliefs work in our life? What can the conflict teach us?
The new workshops were published in the second year, but this time it was up to the colleagues to decide whether they wanted to join. To my surprise, over 80% of my colleagues joined the workshops! In addition, they asked me to extend the length of the workshops to one hour because more than 25 minutes were needed to go deep into the subjects we discussed. I could not help but feel appreciated by this feedback.
Ultimately, the number of conflicts went down significantly after the workshops. I was happy to see in daily practice what my colleagues learned in the workshops. But I also realized that the effect of the workshops started to decline months later if someone did not incorporate the practices in the daily activity. We are humans; it takes effort all the time to grow.
Conclusion and results
Of course, we did not foresee what would happen. But we believed in the team that we could do it — each of us. I am grateful to each team member that they believed in me, and in return, I believed in them. Extraordinary things happen if mutual trust prevails.
Intangible results:
- Professionals wanted to join our team.
- Colleagues liked to come to work on Monday.
- Trusted environment.
- No or minimal corporate politics on the team.
- Helpful welcome to new colleagues.
Tangible results:
- The highly complex financial real-time system was delivered on time.
- In the first four years, we had an employee turnover of almost zero.
- One hundred ten professionals worked at a bank in a self-organization methodology.
- Metrics for the new systems after three years of live real-time operation:
- Planned downtime: 0 seconds.
- Unplanned downtime: 0 seconds
- License costs: 0.
- In 2020, our team was awarded the First Prize in an HR competition in the section: Future-proof Organization.
- We were invited to a Scandinavian bank group to share our experiences in technology and methodology.
In conclusion, we delivered the desired dream. Not just that. We created a human environment as practical proof that trust works wonders. Yes, it comes down to us and the environment we create around us. Leaders are responsible for initiating the process, but all their colleagues must help co-create the story. It helps a lot if a leader can handle their fears well since fear and trust cannot co-exist.
Finally, thank you for the passengers on this journey. All my colleagues who participated in the experiment may have learned that things can be different. Beliefs are not facts but potential trajectories. You decide to follow them blindly or question them and take another path. I will preserve the lessons I learned in these years. If someone tells me it is impossible, I will smile…and do it.
[1] ERFI= Elosztott Rendszerek Fejlesztési Igazgatóság; in English: Distributed Systems Development Directorate.
[2] This article is based on my experiences and memories, and it will reflect my personal opinion and vivid recollection of events.
