Can you be a Hero in IT? - Lessons from real customer stories

Take a dose of enthusiasm! Add a dash of conscientiousness, then spice it up with a little persistence and curiosity! Mix it up and you’re done! Is the recipe for “heroism” that simple? :)

Who is the hero in IT today? Let’s be honest, in recent years the word itself has become a bit trite and overused in IT sector (too), but that doesn’t mean those, who stand out from the crowd with their attitude and professionalism, have disappeared. They do exist, but they do not advertise themselves over and over again.

Anyone who works in a customer-facing role knows that it is not easy to meet expectations and deal with unexpected situations at the same time. The team at Danubius IT Solutions, working mainly on banking, insurance and start-up projects, has encountered many challenging situations over the past decade, which their approach and attitude have successfully guided them through. From these, we caught up with the two founders, Péter Balogh (CEO) and Péter Halász (COO), and two other members of the team, Sarolta Fogarasi (Analyst Team Lead) and Balázs Csintalan (Software architect), to answer the question: is it possible to be a hero in IT?

Whose problem is it?

Client? The supplier? Both parties? Depends on what’s in the contract? Below, you’ll read stories that go beyond the “classic” customer relationship and problem-solving.

Production investigation and crisis management

Peter Halász begins with a recent case: “On a calm Friday morning, I received a notice that I had to pay a certain bill that day. I logged into the Internet Bank, but the transfer function did not work, and after logging out I could not log in again. No problem, I thought, I’ll do it in the evening, surely it was just a temporary system error. When I got home, I was surprised to find that the page was still down. As we work in a different area with the bank in question, I sent an SMS to one of our contacts. Soon I received a concerned reply saying that everyone had been working on the failure since the morning, but that they could not find a solution and could not identify the root cause of the problem.

As I like new challenges and was increasingly interested in what might be behind it, I logged into the system, as I had the privileges to view the logs. I quickly wrote to Peti (Peter Balogh - who was at the playground with his daughter) about what I was seeing and we started brainstorming, trying to work together to find out what could have happened. At around 9-10pm we managed to find some encouraging things. I quickly sent those to the IT manager, and five minutes later I found myself on a crisis management call with all the bank managers, developers, operators and representatives of the international supply partner involved.

Finally, after a couple of hours, based on our initial guidance, we managed to locate the error and find a solution, and the payment transfer system was back online at 1am. Afterwards, we were asked to prepare an incident analysis, which was sent to the parent company and the Hungarian National Bank together with our recommendations.”

Code reverse engineering or adventure into the unknown

“The company that used to run one of the insurance company’s claims settlement systems went out of business, leaving the insurer without support for one of its core systems, without even the source code, only the binaries.” - recalls Péter Balogh. “Several of their partners were asked who could help them to recover the source code, so that they could at least make bug fixes and legal, regulatory changes. We were part of that group and frankly we were quite excited about the task. A couple of colleagues rolled up their sleeves and within a week or two we had the reverse engineered version.

Devs worked on it a lot, especially the colleague who had a thought at ten o’clock one evening and, after working through the night - aided, of course, by the right amount of caffeine - , the result was there in the morning. Then we made a few more changes requested by the client as a proof of concept. Thanks to all this, the insurer continued to work with the existing applications for another year and a half, and when the need arose to replace the entire system, we were asked to do the job.”

Language difference is no barrier

Often, the success of a project depends on how much a team is deterred by less than ideal conditions: “A Belgian client of ours is developing a platform for primary and high schools, but after a while they realised that it would be worthwhile to separate the application according to the two types of schools. They gave us the development of the high school branch.

We travelled to them, assessed the needs and discussed the expectations. The interesting thing was that all the database code and documentation was available in Flemish, with no English words at all. This is not something any developer would dream of, yet no one in the team said they wouldn’t take on the task under these conditions: armed with their newly acquired Flemish vocabulary, they started to work on rewriting entire modules and important core elements in English to meet the new requirements. This was so well done that we had a year where this project generated the most revenue, making it an absolute success story in many ways.” - recalls Péter Halász.

Tip: Roll up your sleeves! Or if you have the opportunity to prove your skill, use it!

Working on a Friday (or any) night to troubleshoot a system that doesn’t belong to you or your team is not a rewarding task. This kind of attitude is not self-evident, but at Danubius, helping each other and solving problems together - whether internally or with the customer team - is a basic building block of day-to-day operations.

What does this look like from a staff perspective? Balázs Csintalan himself noticed the problem with the above-mentioned bank transfer system, tried to unravel the error, and when that failed, he indicated to Peter that a serious bug could block the operation.

“I am not dealing with issues that are not related to my project because of any pressure on me. Since bugs of this depth are not very common, if they do occur, it’s good to fix them, as there is a lot to learn and improve from them. Peter Halász and I often tackle some of the more complex problems together, and in many cases we don’t even stop until we find a solution. These successes are always a source of pride: it feels good to work in a team where we work together not only to deliver and operate as contracted, but also to provide the customer with full support and service. We also learn a lot from these cases.”

So what makes a hero?

“Going above and beyond the average expected performance, helping others, quasi-saving others or the project.” - these are the words of Péter Balogh, who adds that it would be an exaggeration to say that this kind of attitude is a recruitment criterion at Danubius, but there are certainly many like-minded professionals in the team.

There are fewer good references than a job well done, and honest professionalism is worth its weight in gold (and long-term or new partnerships). At Danubius IT Solutions, the aim is not to make our team indispensable in the life of the customer at any cost, on the contrary: we pass on the source code, help train the customer colleagues, and do not fear for our knowledge and know-how.

Of course, it is up to each individual to decide for himself what he means by heroism, but the above cases are excellent proof that it is worth being there when the majority either back down or do not even try to put in that extra bit. The one who at least tried will be remembered. The one who was willing to roll up his sleeves when it was not his job. These are the kind of deeds that are rarely talked about these days, but they are the ones worth talking about! 

If you want to be part of the Danubius team, don’t hesitate: one of the open positions might be waiting for you! And if you want to read more stories like this, check out the second part of this article right here.