We have been made aware of fraudulent attempts misusing our company’s name to deceive individuals in offering business and/or other opportunities.

DKatalis will not request personal information and/or payment in any form.

DKatalis is a technology company based in Jakarta and Singapore. We innovate and build digital solutions that drive digitalization. DKatalis currently does not have other business ventures outside of this area.

Official statements and updates from DKatalis are only shared through our official website and social media channels.

If you receive suspicious messages, do not click on the links, share personal information, or make any requested financial transactions. Always verify through our official channels before taking any action.

Beware of Fraudulent Activities Using DKatalis Name was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

In today’s fast-paced, highly competitive business world, knowledge-based organizations must stay agile to thrive. But how can companies balance the need for swift output delivery with the equally important goal of fostering a culture of seamless knowledge sharing? The key lies in creating a balance that enables efficiency while allowing room for learning.

The “Delivery First” mentality: A double-edged sword

In an economy where speed and results often define success, it’s not surprising that companies emphasize fast delivery. You’ve likely heard the common mantras: “Move fast, fail fast,” “Be focused,” and “The early bird catches the worm.” These phrases reflect the pressure to work relentlessly to complete tasks as quickly as possible, sometimes taking shortcuts or bulldozing through processes just to maintain momentum.

Organizations often reward these high-efficiency employees — those who get things done quickly and meet tight deadlines — by promoting them and offering financial bonuses. On the surface, this seems like a great strategy: rewarding productive workers for their hard work. However, this focus on efficiency can have unintended consequences that undermine long-term success.

The cost of overemphasis on efficiency

When the drive for output takes precedence, employees may experience burnout, stress, and demotivation. They may begin to feel like they’re running on a hamster wheel, constantly producing without time to reflect or learn. Eventually, some of the most talented people leave, taking their knowledge and expertise with them, leaving the organization weaker and less able to adapt in the future.

It’s not that efficiency is inherently bad. Delivering results is crucial. However, an unrelenting focus on speed and output can harm the organization’s ability to innovate, learn, and share knowledge. Without space for reflection and collaboration, employees miss opportunities to uncover better ways of working, address unresolved challenges, and contribute to collective learning. Over time, this harms the organization’s adaptability and growth potential.

The importance of fostering a learning culture

Building a culture of learning is challenging enough, requiring openness to new knowledge, intellectual humility, and a willingness to experiment. However, when faced with the “delivery trumps all” mentality, it can lead to counterproductive behaviors:

• Narrow focus on familiar tasks: Teams might prioritize tasks related to areas they’re already familiar with, avoiding new challenges or areas they don’t fully understand. This can prevent individual growth and product innovation.
• Working without collaboration: Rather than brainstorming or diagramming solutions together, team members may rely on their own limited knowledge, instead of engaging in collaborative problem-solving. Over time, this isolates new/weak team members and reduces the potential for cross-functional learning.
• Collaboration in name only: Teams might start with collaborative processes like breaking down work together, but eventually fall into the trap of executing work alone. As team members push themselves to deliver individual tasks quickly, they sacrifice collective problem-solving and shared learning.

At its core, the belief that productivity equals success often results in individuals working in isolation, which hurts overall product quality and the organization’s ability to adapt. This can lead to a vicious cycle where customer satisfaction decreases, financial performance drops, and layoffs ensue — further weakening the company’s ability to pivot quickly and strategically.

The power of learning as a team

The antidote to the “delivery first” mentality lies in a simple belief: People learn best when they collaborate. This belief is crucial for a company’s long-term success. When team members share knowledge freely, they catch issues earlier, get feedback faster, and improve both the product and customer satisfaction. Over time, this leads to better product adoption, higher financial performance, and greater employee satisfaction, reinforcing the cycle of knowledge sharing and collaboration within teams.

Moreover, the more your team members work together and learn from each other, the stronger the organization becomes. When people feel they are learning and growing, they’re less likely to burn out, more likely to stay engaged, and more likely to keep their teams long-lived. This retention of knowledge and talent strengthens the company’s overall ability to adapt to changing market forces, ultimately leading to greater success.

“All the project members who developed Epson’s first miniprinter were mechanical engineers who knew little about electronics at the start. So, the leader of the project team, who was also a mechanical engineer, returned to his alma mater as a researcher and studied electrical engineering for two years. He did this while the project was underway. By the time they had completed the miniprinter project, all the engineers were knowledgeable about electronics. “I tell my people to be well-versed in two technological fields and in two functional areas, like design and marketing,” the leader said. “Even in an engineering-oriented company like ours, you can’t get ahead without the ability to foresee developments in the market.”
Excerpt from https://hbr.org/1986/01/the-new-new-product-development-game.

Shifting the focus to learning through collaboration

The goal is not to eliminate efficiency but to balance it with a culture that encourages continuous learning through collaboration. This requires a shift in mindset and intentional actions to build an environment where learning is valued as much as output. Here’s a way how you can start fostering a culture of collaboration and knowledge sharing:

1. Map out existing domains and features

If your team tends to work in silos, it can be easy for individuals to lose sight of what others are working on. Mapping out the business features your team is handling, and the technical domains you’re tackling will help everyone understand how their work fits into the bigger picture. It also enables team members to see where they can share knowledge and learn from others. This transparency boosts morale and reinforces the sense of collective achievement.

💡Tip: Group related features together to give a clearer picture of your team’s domain and expertise.

2. Assess knowledge levels across teams

Knowledge sharing thrives in an environment of transparency. Encourage team members to identify what they know and what they don’t know, both about the business domain and the technical tools in use. This helps pinpoint areas where knowledge is concentrated or lacking, and it allows you to redistribute learning opportunities to ensure a more even distribution of expertise across the team.

💡Tip: Vulnerability is imperative to the success of this step. It’s ok to admit we are not experts at something, and it’s ok to say we are just novices.

3. Promote continuous learning within teams and between teams

Remind your teams that every task is an opportunity to learn. Encourage them to tackle new challenges, explore unfamiliar areas, and collaborate with team members to broaden their knowledge. By breaking the cycle of repeating the same familiar technical tasks or business features, you open up opportunities for growth, creativity, and innovation.

Encourage collaboration between team members with diverse backgrounds and skill sets. Promote team members to temporarily join another team to share or gain knowledge. This cross-pollination of knowledge and expertise is especially valuable in feature teams, where individuals bring different perspectives to the table. The more teams learn from each other, the more adaptive the organization becomes.

💡Tip: It’s imperative that management see their role as building long-term engineering and organizational capabilities by enabling teams to function autonomously and cross-functionally, as opposed to directing teams on what and how to deliver value to the organization.

Conclusion

Balancing delivery with learning is essential for maintaining an organization’s long-term success. By fostering a culture that values knowledge sharing and collaborative delivery, you empower your teams to solve problems more effectively. A commitment to learning will not only improve your product quality but also increase employee satisfaction, reduce turnover, and increase the organization’s ability to thrive in an ever-evolving business landscape.

So, next time you face the push to “deliver fast,” take a moment to consider the impact of that push and how your organization is also delivering value while maximizing learning. The result may be a more resilient, innovative, and successful future for your company as a whole.

Want to be a part of DKatalis and build the future of digital banking? We’re hiring!

Balancing Output Delivery with Team Learning: The Key to Organizational Agility was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: In case you are new to scrum, you might want to learn more about what a refinement looks like here.

By the book, a product backlog refinement (PBR) session is the space for clan teams to intentionally discuss why a Product Backlog Item (PBI) is in the backlog list, what the smallest value expected it’s going to bring upon release to market is, and a little bit about how to deliver the item. This is also where knowledge sharing happens.

I intentionally use the phrase “by the book” because that’s the most favorable situation that Agile Coaches hope for during PBR.

Continuous Improvement in refinement

At DKatalis, we embrace the spirit of continuous improvement—not only for our products but also in the way we operate as an organization. Establishing a continuously improved working system will create a self-managing group of people who contribute to high-quality results.

So, we realized that not just our products, but also the way we work on them during the refinement session itself needs improvement. To this end, the Partnership & Servicing (Clan) principal engineer invited staff engineers to observe the Servicing product area refinement sessions. The goal of the observers is to get data points on how the current refinement session is running, which will later become a reflection for teams to be aware of and create actions of improvement.

🚨 (Disclaimer: The observation and findings are based on sessions the Partnership and Servicing Clan runs. Other Clans might have different takes depending on their product area and team dynamic).

Observation of refinement sessions

While each team may have its own metrics to evaluate the effectiveness of a refinement session, there are some general areas worth considering:

1. Over-Engineering
   The team is unable to stop the discussion when it’s gone too deep into technical solutions. Why does this matter? Going too deep into a technical discussion will create an illusion of clarity to deliver the right value; hence, the team knows how to do it practically, but potentially, it will not deliver the valuable item or be over-engineered.
2. Refine as You Go
   The team understands that items can be refined multiple times (refinement isn’t the last chance to discuss the items).
3. Balancing Out
   There is a tendency to know everything (need to be clear on the ‘how’) before estimating and detailing all UACs in a single refinement. Hence, the team’s perception of estimation as the measurement of delivery must be detailed and precise.

Understanding the current situation gathered from observation data points, Agile Coaches and some of the staff engineers agreed to make requests for improvement to the team.

Refinement Session: Request for Improvement

After breaking down the observation findings, the Agile Coaches shared them with the whole clan at the start of the PBR session to provide transparency in the collaboration. They then share the request for improvements.

The crucial thing about requests is to create space for the team to clarify each request. That’s where an Agile coach takes time to align the expectations and the team’s perception. During clarification of the improvement request, the team validated their understanding of what the improvements might look like.

At the end of the clarification, the team gave their agreement to try implementing the improvement points and to experiment with them immediately in the refinement session.

Refinement Session: Experimentation on improvement points

After the PBR session, the Agile coach shared direct observations and highlighted the improvements that teams have made as follows:

1. Better Time Management
2 out of 3 mixed groups were able to identify when they had to wrap up a discussion on an item and move on to the next, even if the timebox was not finished.

2. Stakeholder Identification
1 out of 3 mixed groups was able to identify irrelevant stakeholders/users in the room and requested the right stakeholders to join the discussion.

3. Self-Managed Facilitation
2 out of 3 mixed groups are self-managed in appointing a ‘champion’ as a facilitator within the mixed group. The presence of facilitators is necessary in PBR sessions, as they are the personnel who help create the opportunity for the team to speak up their thoughts and guide the discussion towards a common goal (PBR goal of discussion). They also actively listen to the conversation, observe dynamics, and intervene when necessary. As mentioned earlier, Agile Coaches usually take on this role. However, Product Managers, Designers, or Engineers could also assume this role depending on the product areas.

Lessons from the experimentation

Clear requests for improvement and aligning expectations can lead to significant progress. From our experimentation. Here are key points to consider when pursuing more effective refinements for the sake of better delivery:

1. Increasing Awareness
   The team might not be aware of what they often do. Hence, sharing observation points transparently helps teams become more aware of their actions and behaviors.
2. Empowerment
   Giving teams the power and responsibility to modify how they work may lead to impactful changes.
3. Clear Communication and Transparency
   As the Agile Coaches did before the refinement session started, it’s important to clarify when requesting improvement from the team, making sure the team has the same understanding.
4. It’s an ongoing Process
   As we begin to empower team members to become facilitators, they need continuous support for facilitators to grow their skills. As they gain more experience by facilitating group discussion in refinement, their skills will grow, supplemented by feedback and guidance from seasoned facilitators.

Sometimes, we can become so focused on one aspect that we overlook others. Hopefully, this article could inspire more teams to reflect on their refinement sessions and explore ways to enhance them.

We'd also love to hear from you if you’ve had similar experiences or insights. Please share them in the comments!

Want to be a part of the culture of continuous learning and growth? Join DKatalis, we don’t byte 😉!

Refining the Refinement with Practical Experimentation and Feedback Loop was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

Benjamin Tan’s curiosity has always been strong, almost unstoppable, ever since he was a child.

The door to the computing world opened up to him when his parents brought home the household’s first computer when he was just an elementary schooler. While other children his age at that time tended to enjoy using the device, his interest was in how it actually works. His curiosity got the better of him, and he scrubbed the operating system, which led to his parents having to reinstall everything all over again. The occurrences happened so many times that his parents became semi-regular patrons of the repair shop, to the point where his father got irritated and told Ben to watch the repair person and ensure it wouldn’t happen again.

Still, they were supportive of his passion, despite not knowing whether Ben’s interest was just a phase or going to be a long-term thing. Gladly, their trust paid off as Ben stayed steadily strong, learning programming on his own before taking a bachelor’s degree in computer science at the National University of Singapore. He studied really hard during his time there and, afterward, was granted a scholarship to study technopreneurship at Stanford University in 2009. He managed to pave his way from Singapore to the bubbling tech scene at Silicon Valley.

Ben initially started out his career as a software engineer, doing web development for a French autonomous vehicle company. However, the seed of interest in machine learning has already been planted, and he grew it by learning from the ML team in his first company. There, he cultivated the skill in deep learning and built the necessary tools, which led him to eventually become part of the team himself. A new career path in his life is unlocked: becoming a Machine Learning Engineer.

In July 2021, Ben finally joined DKatalis as one of the first Machine Learning engineers, and as he spent more time at the company, his career expanded.

You’re one of the first members of our Data and Machine Learning team. Tell us about your journey in growing the team.

Benjamin Tan (BT): When I first joined DKatalis, the first year was spent really building out our machine learning operations capability because we started from scratch. So for the first three months, we started by building the Machine Learning platform. Then after that, getting the data scientists on board to use the tools because you need to teach them how to use them, you need to change mindset then as the team grew because when I came in, we had one machine learning engineer and two data scientists, which is kind of good because you can introduce things without a lot of destruction. Imagine if we already had 10 data scientists, then I would have to teach 10 people how to use it. In this case, I mean to credit how they were very supportive of my endeavors. Because They could easily say, “Ben, I don’t like the thing that you’re working on. I’m not going to use it.”

But I had their support, and we slowly started building the foundations, such as best practices, pipelines, and other important systems. This way, when other machine learning engineers join, we already have a pretty good set of things going, and they could come up with improvements and extensions. Now, we have grown by five times. And each person already knows the techniques and best practices. I think we’re in a pretty good state.

Once we have the machine learning infrastructure down, the next bit is how we make our work better and what tools we can use to do this. The ML Ops is always changing, with tools coming up left, right, and center. So, we spend some time doing proof-of-concepts to make sure that it’s our use case. We also embedded ourselves into the community quite a bit. So one of the things that I want to push people to do is to give back to the community, meaning, for example, in the Feast community, which is a feature store that we’re using, when we find bugs, we would highlight it, and at the same time, we contributed a patch. It’s a way of not only improving our work but giving back to the community.

Could you share with us what your team does?

BT: The data science team is really close to the business, and it’s slightly different from software engineering. For software engineers, there are multiple layers to go before you hit business. For us, for data scientists, it’s just one-degree separation. If you draw a line up, a data scientist will go directly up to a business person, the end of the story.

So, the projects that I’m handling would range across all the Business verticals. So, for example, I have projects that are doing fraud prevention and anti-money laundering, a lot of projects related to risk and go-to-market. And that’s just the business side.

There’s also the product side, where we would help people with onboarding, money storage, money movement, and so on. Our projects are not confined to just one aspect, they range across the organization. It’s good because the work is interesting and varied, but at the same time, there’s a lot of context to keep in the head.

• Android Package Classification in 60 Minutes
• BentoML Quick Start and Initial Impressions

You also recently became a Product Owner for Data Science, Risk, and Marketing Tech (MarTech), which brings more responsibilities to your plate. How are you embracing it so far?

BT: Well, it’s not like I’m playing two roles now. So I’m a product owner but also a principal engineer within the data team. It’s a lot more responsibilities.

I think the cool thing about being a product owner is that you see a lot more big-picture perspectives and the different dynamics that are at play. For example, being a product owner means that I can check with other product owners. Previously, when I was a machine learning engineer, all I could care about was data science, and that’s all. If someone told me about product strategies, I wouldn’t care much, just give me the fun coding projects.

But now I see products as a very important part of everything, and you can’t create products when you don’t understand the downstream. I think it’s one big opportunity that puts me in a really good position to ensure that the projects I’m working on make a high impact on the overall organization while also teasing out good projects for the data science team to work on.

Now, I’m obviously much closer not only with the product but also with engineering. I can already talk to the engineers in their language, and slowly learn to speak in the product language. There are some overlaps, but it still needs a fundamentally different set of skills. I’m taking this opportunity to really observe how the rest of the product owners operate and also try to get an idea of their thought processes.

How do you balance out all those responsibilities?

BT: The first thing is not to take on everything. If you have a good team, then obviously, you can always delegate tasks. But I think the other thing that’s very important is also to get regular feedback from multiple people regularly. So you’ll have to ask people, “Hey, how’s my driving like” every time because I mean, we’re all humans. A lot of times, you’ll have blind spots, and it’s always helpful to get feedback. Also, I guess one of the main things is to be humble.

One of the values that DKatalis believes in and pushes forward is purposeful growth. How do you put this into practice within your team?

BT: An interesting characteristic of the data science team is that everyone is highly educated. At that time, we had 3 PhDs and a bunch of Masters students. I kind of like to joke that I’m the least educationally qualified person on the team. Unlike in software engineering, where junior members might require more coaching and mentoring to upgrade their capabilities, a lack of skills is not a problem in the data team. When I recommend someone to take courses, it’s usually not for lack of qualifications.

What I’d like to do is direct them to good projects that can engage and require the team to use their skills to the maximum. Then, challenge them to think of creative ways where we can tinker with different use cases. We can go to business and say, “Hey, we have a suggestion for making this thing better using data science. What do you think?” And I think that’s a healthy dynamic.

In our last Retrospective, we discussed starting some kind of domain knowledge-sharing sessions, for example, in the realms of Go-to-Market (GTM) and other fields. I also think that when everyone is in the office, we can do reading groups. I’d also like for everyone to take different online courses and, after that, share the lessons with the rest of the team.

Talking about sharing, you have written 3 books and are an active Medium writer. What drives you to be productive and why is it important to share those articles?

BT: I believe that when you start writing things down, there must be clarity of thought. If you can’t think things clearly, you cannot put them on the paper or screen. Unclear thoughts will not work. Also, it’s a form of knowledge sharing, and teaching other people solidifies the concepts in your head. By writing books and articles, I not only get to share my knowledge but also clarify the thoughts and concepts I have in my head.

Furthermore, I write down the articles because they document my knowledge. There will be many situations where I need to get references; they were usually the same material I wrote some time ago. Every time, I was like, “Thank goodness I wrote everything down.”

Also, I believe that having the DKatalis engineers publish blogs will also help recruitment. As a software engineer, a company engineering blog will assist in assessing the level of engineering capability and quality. They can also get a glimpse of the projects that a particular company is working on.

Encouraging people, particularly data scientists, to build the blog writing habit is an uphill battle. They generally don’t like to write things down even though they are required to write documentation. But blog writing is different, and for some people, it’s a huge task mentally.

But let’s see, maybe I can bribe them with gummy bears or something.

Any tips for aspiring engineers?

BT: Never stop learning. I think software and data engineering are very unique jobs. The bar to learning is really low nowadays, as all you need is a laptop, an internet connection, determination, and grit. Many of the learning materials are now democratized, with people making high-quality code courses and content for free. There are so many high-quality resources available for free, so nothing’s really stopping you from digging in, understanding, and becoming an excellent software engineer.

Let me give you an example, if you want to be a dentist, you can’t go to Coursera or other online learning platforms and suddenly practice as one. For engineering, it’s completely different.

Interested in Ben’s helpful articles and tips for stepping up your Machine Learning game? Find them all here and don’t forget to hit the follow button!

Principally Speaking: A Shapeshifting Journey in Tech was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the user experience (UX) research process, a guideline often serves the function of a human’s heart: it becomes a vital organ that beats and resonates with the purpose of the research itself through multiple questions, tasks, or tests. Most researchers also expand their efforts to create a more systematic framework to assess both the quality of the product and quantify the usability of the experience (Salas et al., 2019).

Despite its importance, we can argue that not all guidelines must be rigid and attend to certain attributes that are meant to quantify the effort. Rooting back to the basic assumption of interviewing as a method, a semi-structured interview — mostly used in UX research — gave both the interviewer and the interviewee very little freedom. Thus, it is important to acknowledge the method’s restraint and reflect on what could be developed further.

If we knew what it was we were doing, it would not be called research, would it?

–Albert Einstein

The aforementioned quote highlights the importance of fluidity in research, in this case, its application to UX research. To put it in Schostak’s (2006: 92) words, an interview “…is not a simple tool with which to mine information. It is (rather) a place where views may clash, deceive, seduce, enchant”. It suggests that one should be open to how the user responds, to seek the particulars between the answers, or even being open to rethink the whole purpose of the product.

Rethinking the whole purpose of the product might seem scary–especially if you imagine throwing the hours under the bus and having to redefine the product’s purpose again, even starting from scratch. Nevertheless, as daunting as it might sound, this is an instrumental step in creating a user-centered solution. It takes a further step from merely taking on the user’s suggestion to creating a tailored experience for users (Rahman et al., 2024).

It is understandable that, as researchers, we tend to stick to the product's particulars and arrange the answers based on the development priorities. However, in order to achieve that instrumental step, we need to actively remind ourselves about the fluidity aspect of research. Taking in the term from a theatrical convention called the ‘fourth wall,’ researchers need to acknowledge the imaginary wall that might form between them and the user.

These practical steps might help UX researchers break the fourth wall with users and conduct reflective yet engaging interviews with their respective users:

1. Knowing when to be silent

Silence is undeniably awkward. Researchers sometimes developed the tendency to keep talking to maintain the conversation flow when conducting an interview. However, this could lead to (unintentional) undermining response to the user, even making an unconscious pitfall. As Leech (2002) suggests: just ask, then be quiet. Give the user time to process their answer. These meaningful seconds of silence will let the user know they are also taking control of the conversation flow and give the impression that the researcher is genuinely listening.

2. Read between the line

Collecting data through an interview is not a mere Q&A session. It is an art of interaction — despite the guidelines, the execution always comes back to the researcher’s hand to provide balance, address errors, and adjust the needs. Therefore, it is critical to read the user’s nonverbal gestures.

Do they look confused? Do they stutter? And if so, at which point did they stutter?

Taking notes of these non-verbal gestures is proven to enrich the insights gathered from the research, especially in noting the areas within the product itself. For example, a moment of stuttering followed by a positive response may be up for questioning. Researchers may take up on these cues for follow-up questions and probes — since the user is under no obligation to tell us the truth, researchers should actively gauge the information.

3. Acknowledge the positioning

An often neglected point is that an interview session could be intimidating for the users. The researcher could be perceived as someone with a certain knowledge of the product, while users with various backgrounds are important to give a diverse perspective on the research, those who came from non-tech have the tendency to take the ‘middle ground’. Thus, the user may develop a form of inferiority during an interview.

It is beyond the researcher’s control to change that, but the researcher could acknowledge the dynamics of positioning that happen during the interview. To address this, the researcher should avoid using complicated jargon or technical terms and use open-ended questions when creating the guideline.

Additionally, to acknowledge the positioning, the researcher could reassure the user that their perspective is significant with a simple introduction.

UX research requires a balance between structure and adaptability. As Einstein emphasized, embracing the uncertainty inherent in research is crucial.

By breaking down the metaphorical fourth wall between researcher and user, and employing practical strategies, researchers can conduct more insightful and engaging interviews. Ultimately, by letting the users know that they are also taking control of the wheel, UX research transcends mere methodology to creating a more meaningful product.

References

Leech, B. L. (2002). Asking questions: Techniques for semistructured interviews. PS: Political Science & Politics, 35(4), 665–668.

Rahman, W., Abdelkader, A., Lee, S., Yang, P., Islam, M. S., Adnan, T., … & Hoque, E. (2024). A User-Centered Framework to Empower People with Parkinson’s Disease. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 7(4), 1–29.

Salas, J., Chang, A., Montalvo, L., Núñez, A., Vilcapoma, M., Moquillaza, A., … & Paz, F. (2019). Guidelines to evaluate the usability and user experience of learning support platforms: A systematic review. In Human-Computer Interaction: 5th Iberoamerican Workshop, HCI-Collab 2019, Puebla, Mexico, June 19–21, 2019, Revised Selected Papers 5 (pp. 238–254). Springer International Publishing.

Schostak, J. (2006). Interviewing and representation in qualitative research. McGraw-Hill Education (United Kingdom).

Find this helpful? You definitely need to read more articles by our Katalis here and don’t forget to click that follow button!

Breaking the Fourth Wall in UX Research was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Ralitza Passileva and Marudi Tri Subakti

Developing groundbreaking products that profoundly impact lives requires a band of exceptional trailblazers committed to innovation. At DKatalis, we consistently raise our recruitment standards to align with our ambitious vision.

While our recruitment process may not substantially deviate from those of other tech companies (though we’ve heard some amusing feedback about the difficulty of our tests), we actively seek unique qualities in prospective candidates. Whether it’s technical expertise that aligns with our ever-evolving tech stacks or those distinctive, intangible personal traits, our selection process is selective.

This article serves as your guiding light, offering insights into navigating the DKatalis hiring process, and it can also be invaluable when pursuing opportunities in other tech companies.

The Process, in A Nutshell

In a nutshell, here are the five stages you’ll undergo when applying for a position at DKatalis tech team:

1. HR Interview

In this stage, you are going to have a discussion with our Talent Acquisition (TA) team. But please note that this might not be a ‘normal interview.’ At DKatalis, our TA will give you an overview of the organization, from our product and impact to the culture. You are also expected to share your career aspiration, which will help us understand your career path and whether our people team can help you reach it.

2. Take-Home Test

After the interview, our TA will send you the take-home test that challenges your technical capability. Each role has different tests based on the skillset needed for each function. Usually, the take-home test will take around 5 days to complete. FYI, our take-home test is tricky, but our TA team is open to answering any questions if you have difficulties while doing the assignment.

3. Technical Interview

Once our hiring managers review your submitted take-home test, we will invite you to a technical interview with our engineering team. They will inquire about details related to your submission and other questions about the position you applied to. This interview is very informal — so please relax and enjoy the conversation.

4. Bar Raiser

In this stage, you will meet with the leaders from the team you’re applying for –data, product, or engineering. The leaders will have a brief technical discussion before deeply delving into your career aspirations. This stage is also a space for you to ask as many questions as you have about the organization and working culture within, so use it wisely :)

5. Offering

Yay, you are 1 step closer to becoming a Katalis! If our hiring managers are keen to get you on board, they will tell the TA team, and all you have to do is wait for them to reach out with an offering package.

Areas of Focus

During the process, just like what other recruiters and hiring panels do, we will assess you based on the following:

Product understanding

Do you know the products DKatalis is developing? While you might have been aware of our major involvement in developing the Jago App, DKatalis also builds a human resources management solution called PX. Hence, experience within these fields will be advantageous.

Familiarity with the stacks

DKatalis tech team is well-versed with [stacks]. However, our engineers maintain a keen eye on emerging tools and technologies. When these tools promise to enhance productivity and efficiency, our team eagerly incorporates them into our expanding toolkit. If you are an expert in specific tools, consider it a valuable asset when joining our team!

Culture fit

As mentioned, creating pioneering products often requires unconventional approaches. That’s why, starting in early 2022, the DKatalis tech team adopted the Large-Scale Scrum (LeSS) framework. You can dive into the details of LeSS by exploring our [LeSS series link]. Furthermore, we don’t separate the engineering team into frontend and backend teams; they are encouraged to master both ends instead.

The Common Pitfalls

According to our data, most candidates struggle during the take-home test and technical interview, and for various reasons. Let’s comb through each of them carefully and discover how to overcome them.

Cheating

While checking the assignment, sometimes our hiring team notices that the candidate is cheating. Some areas can give away their sneakiness, such as the naming of the assignment, some codes that contain someone else’s name, similarity with another candidate’s submissions, and others. The subsequent interview will also reveal whether your submission comes from an honest work or a copy of someone else’s. Sometimes, we asked the candidate to do code pairing, and they could not explain their own code. Please be sure that you submit your honest work.

Rushing while working on the assignment

We usually give candidates 3 to 5 days to finish their take-home assignments. However, if you need more time to design a better solution for the assignment, don’t hesitate to ask for an extension so you don’t have to work in a rush.

Be passive during the interview

When talking with our engineering hiring panel, you might find them rich with unusual questions or statements. Don’t be afraid, they are just very eager to challenge your point of view! For us, an interview is not a mere step to cross in a hiring process –we treat it as an opportunity to learn new perspectives.

So, don’t just passively agree and say ‘yes’ to their statements. If you have a different opinion, raise it to them or challenge them back!

Acing The Stages

Now that you know what pitfalls to avoid, let’s explore some preparations to help you. Marudi Subakti, one of our senior engineers who is also part of the hiring panel, breaks down practical tips for each stage and thoroughly explains how they are useful.

Assignment stage

Good points if the assignment focuses on these points:

1. Have good documentation of your code. Most of the time, candidates don’t have proper documentation of the code they submitted, or when they do, it doesn’t properly explain how their code works. It might be insignificant, but it has a big impact.
2. Test your code. One thing that our Chief Product and Engineering Officer emphasizes all the time is that codes must be testable. Unit test is the strongest gatekeeper for any behavioral change in the code. However, not all candidates from both junior and senior levels have this mindset instilled. Ensure that you conduct end-to-end testing for your code, even though it’s only for an assignment test.
3. Pay attention to code readability. Ensure that the assessors can understand your code easily. Aside from syntax, pay attention to the project structure.

Technical interview

1. Be honest. Assessors will dig deeper into the code you’ve submitted, and don’t think you can fool them easily. We usually check on how candidates accommodate the request, whether they can complete it on the spot, and if the structure is as clean and structured as seen in the assignment stage. We often find candidates whose take-home assignment passes with flying colors but can’t perform well in this stage.
2. Explain your work. In a pair coding session, the ability to articulate your code’s logic and function is a strong plus point.
3. Embrace feedback. As we review your assignment together, the hiring panelists may provide some feedback. At DKatalis, we value the culture of constructive feedback among team members, with the aim of pushing everyone towards growth. Candidates who welcome and respond positively to feedback signal a potential cultural fit within the organization.

Bar Raiser

In this stage, you will get the opportunity to directly discuss things with the leaders. Of course, you have to remember that this is still part of the hiring process, so they will look out and expect you to possess certain qualities, skills, and potential.

1. You will face many questions about your personality, aiming to assess your fit within the organization’s culture. Candidates often go above and beyond to present themselves exceptionally well, but our leaders, with around 15 years of experience in their respective fields, will know when a candidate is not being honest. So, just be genuine with your answers.
2. Expect some technical discussion, though less intricate than in the technical interview, so remain at ease.
3. Take the initiative and ask questions. The opportunity to have a deep and extensive discussion with the leaders is rare due to their busy schedules. So, don’t hesitate to inquire about anything that will help you better understand the organization. You would want to understand what you are getting into before deciding to join.

Want more helpful tips to thrive in the tech industry? Follow our blog and stay updated!

Navigating the Journey to Becoming A Katalis was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

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!

Principally Speaking: Elevating Perspectives with the Architecture Elevator was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

Hailing from the heart of West Java, Bandung, Wira has always been tinkering with mechanical toys. Growing up, this love for tinkering was translated into building software and applications.

The very first brush he had with “programming” was when he created some batch scripts in ms-dos. This leads to him eventually becoming the go-to “computer tech support” for his school friends (this is in Windows 3.1 era).

Leaving his hometown to study abroad, Wira learns quickly that he loves the feeling of achievement that comes from building something from the ground up. Initially, he wanted to pursue a career as a game developer and never once thought about joining a bank, let alone building a digital banking app.

But, after years of building a career in Singapore as an engineer, he eventually landed in DKatalis as a Principal Engineer, helping to build the partnership ecosystem for Bank Jago. Not only leading teams to engineer integration between Bank Jago and its external partners, Wira is also heavily involved in pushing all members to grow.

Beyond his engineering management role, Wira collaborates with other engineers and PAC to pioneer a development program aimed at elevating DKatalis engineers’ capabilities to the next level.

Hello! Could you tell us what the Partnership Clan does?

Wira Siwananda (WR): The clan plays a vital role in ensuring smooth integration with our funding partners and streamlining the cross-platform customer acquisition process.

What does being a Principal Engineer at the Partnership Clan entail?

WR: Since the role of the principal engineer in DKatalis is quite versatile, I am mixing the definition of the role and my own understanding of the position. My primary responsibility involves defining the strategic direction and vision for the development of the system that builds up partnership products. As a “clan”, I am helping the engineers to look at the quality, stability, maintainability, and performance aspects of the system as well. Simultaneously, I collaborate closely with the clan to foster a supportive environment conducive to the professional growth and flourishing of our engineers. This extends beyond my immediate area, as I aim to nurture potential leaders and oversee their performance management, eventually passing the baton of leadership to them.

When I initially joined the Partnership Clan, several issues needed attention. The team size was too large, and the team model required each team to have its own Product Owner and they were dedicated to a single partner. With this arrangement, multiple teams are busy stepping on each other’s toes since they work exclusively on one component. In the long term, the large team size affected our performance management. It was challenging to ensure everyone, especially junior-level engineers, to deliver quality and consistent growth. Generally, the seniors and mid-level engineers ended up carrying all issues and requirements.

Moreover, the mindset at the time was that DKatalis and Bank Jago were vendors for our partners, a perspective that needed to be corrected. We are, in fact, the bank and the enabler for integration. We have to establish an API integration standard with our partners and clarify our capabilities and service availability when integrating them with our ecosystem.

Upon joining, we initiated a restructure of the teams, dividing it into manageable units with a more balanced mix of senior and junior engineers. I also identified potential leaders among the seniors and guided them in developing the necessary skills. We also established standardized “open banking”, aligning with Bank Indonesia’s Standar Nasional Open API (SNAP). For the long run, we are aligning our vision to ensure that partnership can be treated as an open banking product that is scalable.

Were you assigned to the Partnership Clan right from the start?

WR: Not really, when I first joined, our Chief Engineering Officer invited me to attend every meeting and asked me to identify the most pressing issues to fix. If I recall correctly, during that time, the main problem that the bank had was that a lot of users couldn’t even log into the application, let alone execute transactions. Organizationally, the onboarding process was chaotic, and within the organization itself, there were significant problems with work allocation; we couldn’t determine which team was responsible for which task.

For a couple of months, I carefully observed how the organization works while trying to douse the fire on login issues that are ongoing. Working closely with people who are aware of the root cause of this problem, we set up a roadmap for tactical and, subsequently, strategic fixes. Only after we had the plan to fix this burning issue was I asked to look at the next burning area in the bank, which happens to be in the partnership area. This is where my work with the partnership clan started.

You’ve frequently mentioned the importance of shifting mindset, such as viewing DKatalis-Jago as a bank rather than just a vendor. Could you elaborate on other mindset flipping that you’ve attempted?

WR: When it comes to the practices in the engineering team; although it is clear that the systems are increasingly becoming unstable and unmaintainable, teams used not to want to change the functionalities that are “already working”. In some cases, teams do not even recognize that the issue lies in the fundamental understanding of how a particular capability should work.

Another hurdle was the silo mentality, where each team in the partnership clan was focusing only on requirements coming in from their “assigned partner” to the point that team A would not understand what team B was building although the functionality requested was actually one and the same; this resulted in a lot of duplication of work. Breaking down these silos was a demanding task, but over time, we’ve made significant progress. I believe that now, all teams possess a solid understanding of the integration points with every partner.

There was also a tendency to adhere to traditional hierarchical ways of thinking. The engineers typically worked on assigned tasks, completed them, and moved on to the next. Since early 2022, I’ve been encouraging them to engage in experimentation more frequently, refining their creativity, intelligence, and problem-solving abilities. Here, there’s no spoon-feeding; you often receive a substantial challenge and must determine which team to collaborate with, who to consult for clarity, and how to break down those uncertainties into manageable tasks.

“Here, there’s no spoon-feeding; you often receive a substantial challenge and must determine which team to collaborate with, who to consult for clarity, and how to break down those uncertainties into manageable tasks.”

However, instilling this mindset has been challenging, as some members still prefer clear direction instead of taking initiative and problem-solving independently.

One of your responsibilities includes fostering growth for the engineering team. How do you approach that?

WR: The approach has evolved over time. Initially, we developed a growth path and identified the key qualities we wanted to instill in our engineers. In early 2022, I and other principal engineers formulated the necessary individual skill sets and profile capabilities, which we put into the engineers’ Individual Development Program (IDP).

However, when we introduced the program, many engineers prioritized quantitative skills and overlooked qualitative ones, such as software craftsmanship, leadership, and other soft skills. They viewed these skills as something difficult, mainly because they were not easily measurable. This approach seemed effective for junior to mid-level engineers but proved limiting for senior engineers, especially in our dynamic working environment, where engineers have exposure to multiple clans and teams.

We then decided to adjust the IDP’s metrics to be more experience-based. This involved defining the required skill sets for each level and evaluating each engineer’s performance and skills. We then benchmarked their progress, and determined how we could help them meet the expectations. Our focus shifted toward outlining the capability journey, aligning with benchmarking, and closely monitoring growth and progression.

The teams in the partnership clan were the first to embrace this new approach. Once everyone became familiar with the system, I challenged the senior engineers to assess where each of their team members stood in terms of competency and consistency. We then devised strategies to support them in reaching the next level.

Is it challenging?

WR: As an engineer, continuous learning and growth are essential. Technology is always advancing, and your relevance depends on staying up to date. If you stagnate, technology will outpace your skills, and you might become obsolete. When this happens, you face a choice: keep evolving or consider alternative paths.

It works for some, but not for others. Perhaps you aren’t content with coding because there’s a chance you didn’t choose this career path entirely on your own.

Drawing from your years of experience, witnessing changes and trends come and go, what is your best tip for those aiming to pursue a similar career?

WR: For me, it would be to start with the right mindset. Coding and engineering are more akin to craftsmanship, rather than strict hard science. You’ll find that you improve as you invest more time, learn from others, and collaborate with different people. Surprisingly, the coding part is often the easiest aspect. The real challenge lies in understanding what you want to achieve, what already exists, considering others’ perspectives and the overall vision and direction. These activities will consume more of your time compared to the actual act of coding.

Tell us a fun fact about yourself!

WR: Despite being born and raised in Indonesia, I never worked there. I’ve been working in Singapore for more than 15 years now. I never experienced the professional culture or the working environment in Indonesia, and to be frank, I had quite a culture shock when I first started at DKatalis. There was this one time when I attended a meeting with external parties, and what shocked me the most was that the meeting started with prayers. Moreover, every handoff from one speaker to another was treated like an Emmy Award. Each speaker would give a short speech, thanking attendees for their time and place, resulting in so many fillers in one meeting.

As for the meeting content itself, they just read off the presentation slides! I really thought, “This meeting could’ve been an email. Just send me the slides, and I’m going to read them on my own.” However, I also realized that many people here don’t read. I assumed that the stakeholders were worried that no one read the email; hence, they still needed to host the meeting.

Are you up to more software engineering nuggets of wisdom? Follow us!

Principally Speaking: The Craftsmanship of Software Engineering was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

The rule of life is that it doesn’t always follow a linear path. There are moments when the journey takes sharp turns and deviates from the supposedly established route, yet it still leads to a fulfilling life.

It’s common to assume that anyone graduating with a computer science degree naturally pursues a career in a related field, such as software engineering. However, Priyanka Mahajan, Senior Human Resources Manager at DKatalis Pune Hub, has a different story.

Upon completing her Computer Science degree, Priyanka embarked on her professional journey in tech companies across India. However, her roles were never that of a software engineer or anything tech-related. Instead, she specializes in Human Resources, focusing on building and managing teams that unlock their respective companies’ fullest potential. Her unique blend of strong interpersonal skills and a solid technical background brings a different color to the teams she is in.

We sat down with Priyanka to chat about being on the HR team in a tech company, how she leverages her technical knowledge to enhance her work, and her experience as part of the DKatalis team.

You have a Computer Science degree but always take on HR roles. Is that your passion? And does having technical knowledge help?

Priyanka Mahajan (PM): I have always been passionate about HR. I love talking to people, learning about their experiences, interacting with and understanding their viewpoints, and hearing their expectations from the organization. And when it has been fulfilled, I love to see the happiness on their faces.

And having technical knowledge really helps a lot, especially in finding the right talent with the right technical skills. I can, at least, help the talents in their first initial stages to see whether they are the right fit for the technology capabilities we are looking at.

What’s the exciting thing about being HR in a tech company?

PM: In tech companies, the talents are intelligent and behave differently. They think differently, and attracting them is incredibly challenging. Moreover, at that time, the tech industry was booming, and various companies in the market offered lots of tempting benefits. So attracting talented individuals was really challenging work for us.

You had experience working in various companies before finally joining DKatalis in 2019. What motivated that decision?

PM: All the companies I joined were already well-established. At DKatalis, I started the company right from scratch. I got the chance to work more on the operation side, such as having discussions with various kinds of partners, ensuring the organization complies with the regulations, and having discussions with different government officials. Those were all great experiences that I had with DKatalis.

There must have been many uncertainties back in 2019. There were also periods in 2022 when you had to manage the Pune Hub on your own. Could you share how you navigated through all these challenges?

PM: In 2019, the biggest challenges were registering the organization while onboarding new engineers to help us build the product. I got a lot of mentoring from the Pune Hub Head and our external partner at that time.

In June 2022, the Pune Hub didn’t have a Head of Tech Hub, and all the responsibilities fell on my shoulders. I was pretty tense for the first two months as I couldn’t understand what was happening. But I received a lot of help from other leaders to settle everything down. Some even came down to visit us, which was a good booster for me. With that help, I was able to hold on. But then, for the next few months, everything went very well. Today, I’m proud of myself that I did a good job.

That was impressive! And how is the current situation in the Pune Hub? Any new challenges?

PM: I can say that people are currently very pleased with the management. They engage us well and bring up all the issues or problems they face. It’s an extremely well-connected hub. You could say that we have a lot of fun here. We always go on an outing during each quarter; there’s always something planned, and we have a lot of fun with people.

However, people are hesitant to go to work because the majority of them have returned to their hometown and work from there. Some can even travel quite far from our Pune office. And since they are frequently preoccupied with work, connecting with them remotely can be difficult. If I call an engineer, they tell me, “Wait, I’m working on something.” So, I must reserve their time slot even for a five-minute conversation.

Nonetheless, we are well-connected remotely through weekly or monthly meetings with all team members.

Then, there are difficulties in acquiring talent. Finding the right talent has become more difficult as we have raised our standards. However, we have different strategies in place to meet this challenge. Then there’s the team’s diversity. It’s great that I manage a team of 20 men, but I do think we should hire more female talents. So whenever we start screening profiles, I make sure we have at least two or three women included.

With nearly 5 years of experience at DKatalis and all the challenges, do you feel a sense of personal growth? Could you share your favorite aspects of being a part of the team?

PM: The best part is that we prioritize our work rather than simply working on deadlines. The organization is employee-centric rather than management-centric. DKatalis also offers excellent benefits and opportunities for individuals to enjoy their personal lives. That makes them very happy at work, and as a result, they do an excellent job. So that’s something I really appreciate about DKatalis. It’s an enjoyable place where I can enjoy my work and be free to do things my way while learning new things and growing personally.

I learned a lot during my 5 years. If I look back at where I was, I have exponentially grown up, even personally. I am more exposed globally and can connect with and discuss with people from all over Singapore and Jakarta. They’re extremely helpful, and every conversation expands my knowledge.

Share with us a day in your life as a Senior HR Manager at DKatalis Pune Hub!

PM: My days usually begin with follow-ups for pending payments or compliance matters. Then, I proceed with the HR team daily, connecting with my team at around 11, discussing where to go and what strategies to employ. Then, in the afternoon, I deal with recruitment and continue processing more financial matters. I close the day by, catching up with my team members and engineers in the office.

Congratulations on reaching the finish line! If you’re as hungry for knowledge and stories as we are, satisfy your curiosity with more insightful tales from the amazing people at DKatalis here. Also, don’t forget to give that follow button a click!

Tech’s Hidden Heroine: Stories from the HR Superwoman was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a market saturated with analogous digital products, the key factor that sets one apart from another is user experience. From the initial process of acquiring the product, usability, support, service, and upkeep, a smooth ride across these stages will put the product ahead of its competitors.

Shaping users’ experience and interaction with a product has always been a huge passion of Cipta Pratama, the Product Designer Chapter Lead at DKatalis. For him, the art of designing interaction holds more excitement than merely interpreting a client’s briefs. Just like his first name translates “to create” in English, Cipta undeniably stands as one of the driving creative forces behind the conception of groundbreaking digital financial solution designs at DKatalis.

As he looks back on his riveting journey, he shares with us what he has learned and glimpses of what lies ahead.

Why are you interested in UI/UX design?

Cipta Pratama (CP): During my university years, I attended an interactive new media class that truly captivated me. That was my entry point into making a product with two-way customer interactions, starkly different from graphic design's one-way nature. Usually, your role concludes after completing a design. But designing interaction involves envisioning how the users will engage with your design, essentially designing the interaction itself.

And now, to answer why the interest in UI/UX design. This is just my musings, but consider this: When you create a product, who decides whether it is good or not?

If you’re already acquainted with UX design, you may be able to answer correctly. However, in the past, your answer might be varied. Perhaps your lecturer during your university days or your supervisors or clients in a professional environment. But the answer is actually much deeper. You have to find out what your clients want. Of course, the answer will be for their products to be used widely. Then the next question is “how”? To answer this question, I did a lot of research and eventually learned about UX.

The more I know about the subject, the more I realize that it aligns with my belief: that we need to focus on the users instead of the client’s brief.

You learn autodidactically about UX. How was the process?

CP: Hahaha, yes I did. In my previous role, I spent hours learning through articles and online courses. Luckily, (Stanford’s) d.school already had a specific UX course back then, which I found interesting and enrolled in. Alongside this course, I also got the opportunity to work with seasoned UX practitioners in Singapore, which already had a more advanced UX culture. This hands-on experience not only gave me a deeper understanding of the development process but also introduced me to the necessary tools.

Another thing, I’m also a pretty proactive person. So, I stalked and approached a lot of UX people on LinkedIn. It was pretty fruitful, I even co-founded the UX.id community with one of the individuals I approached!

This community was formed as a dedicated learning space for anyone interested in UI/UX, and also to answer the lack of local UX learning sources at that time. Not everyone has the privilege to learn abroad, which can be very expensive. I could organize an event with this community and invite cool speakers from other countries. It was more cost-effective.

The community is still pretty active today.

Was the learning process challenging, especially considering your background in graphic design?

CP: Well, it was undeniably a steep learning curve. The realm of UX design is multifaceted. To be a great UX designer, you must not only possess design skills but also understand how to engineer interaction, which requires programming skills. Yet, what is more important than the two is a solid research skill because you have to understand your users, right? Proficiency in research enables you to break down the project and accurately pinpoint objectives. A bit of knowledge of human psychology can be a valuable asset, too.

Back then, the more knowledge I had, the more I realized that I had to narrow down my focus of study. I delved into the psychology theories related to UX, polishing my research skills, and dabbed a bit into programming. My knowledge of Java Flash helped a lot. I read a lot of books, too.

Due to my passion for interaction design, I took a lot of related side jobs, such as developing games, so I already covered the first two skills. After that, I searched and learned about the necessary psychology studies and research skills. When I assembled the pioneering UX team in my previous workplace, I also hired those with IT and psychology, even though they didn’t have a design background.

Your career journey was mostly in the creative industry. How did you get into fintech, more specifically, digital banking?

CP: Right, banking was never on my radar at that time. However, when I attended a conference in Singapore, there was a speaker from banking. Despite having a different background from all other designers, the speaker could elaborate on how design can affect the bottom line of a bank. For example, digitizing the form submission experience and making it more user-centric can save billions of dollars. Customers no longer have to make a call or visit the bank, which significantly reduces the cost on both sides. It opened my eyes to the many possibilities it would bring. Digital banking was rising in other regions, and I was looking forward to the same thing happening in Indonesia.

Coincidentally, I was approached by a digital bank at that time, and the rest is history.

Can you recall your experience upon joining DKatalis? How was it?

CP: I “joined” in January 2019, and at that time, DKatalis hadn’t even officially formed yet. We didn’t even have an office, and I also had to build the team from scratch. During that time, I was responsible for planning our value proposition. I had to translate our leaders' and stakeholders’ strategies into practical design briefs and, from there, formulate action plans outlining the products we were about to develop and how. It led to the conception of many intriguing concepts, such as the Jago Pocket.

I was also aiding in recruitment efforts, where I stalked and contacted many potential candidates, so much that my LinkedIn account got temporarily suspended. The process was undoubtedly challenging because, at that time, we really had nothing to offer except sweet promises of the product we planned to build.

What’s the secret? Honestly, it’s the “just do it” mentality. As long as we can break down the necessary steps to achieve this, then it’s possible.

Regarding Product Design, one of your responsibilities is translating leaders’ visions into products. Can you break down the process and what are the results? Furthermore, how do you guide your team to execute the strategy effectively?

CP: Through discussions with our stakeholders, our goal was to create something different from what was already in the market then: a digital bank that plays along well with partners. The product must be characterized by flexibility and easy integration with ecosystem partners. Pretty similar to the open banking concept but tailored to the unique situation of the Indonesian market. Well, I eventually conceptualized two approaches.

Firstly, treat the platform as a versatile container, much like a bento box. How can it expand or condense as required while maintaining a coherent system?

Secondly, think about the use cases. In essence, banking products revolve around money storage and transactions, that’s it. We are trying to turn the core banking product into a second layer and focus on the customer-facing layer instead, where we make it flexible enough to answer the customer’s needs. This is where rigorous research comes into play. For instance, let’s take a look at joint accounts. If you’re a married couple seeking a better, more transparent way to manage your household finances, we translate it into a Jago feature called Shared Pocket. But, if you’re a group of friends wanting to pool money for “arisan” there’s the Arisan Pocket.

Most often, others try to change the core product, like a bank account. But, I found the approach impractical because of the product’s standardized nature. So, the trick is to play with the other elements you can tinker with and shape them into products. It’s crucial to grasp the fundamental aspects that make a product.

With that in mind, what qualities do you want to build in a team? What makes a product designer in DKatalis?

CP: The most important skill to have is definitely design. Because we aim for smooth interfaces, and other skills can be learned as we go. Nobody starts off perfect, after all.

It’s also important to detach them from the usual design workflow. From my experience, designers get stuck on a client’s brief, searching for references, compiling them into a moodboard, and start visualizing them. However, in UX or broad design, the process is quite different. It’s more about researching to understand your users, not just merely creating visuals.

That’s why I’m heavily invested in my chapter’s learning program, from arranging online and on-the-job training to establishing initiative projects for them to execute. They might lack confidence at first, but the most important thing is for them to try. If the project is successful, that’s a bonus. These projects are designed to help them grow and what we’ll need in the future.

Additionally, now I’m trying to establish a book club, where I purchase good UX design books for my team members, aligning with their annual self-development goals.

How about your personal and professional growth during your tenure with DKatalis?

CP: I’m the type of person who will stay long in one workplace if I can create challenging and exciting things. These opportunities will push me to expand my knowledge, enhance my thinking process, and keep learning. You’re always pushed to learn and learn. Some projects in this category are data-related products, such as Jago Spend Analysis and Plan Ahead recommendation. And there’s also another exciting project on the horizon, so keep an eye out!

DKatalis is also a multicultural company that brings together diverse viewpoints, making collaboration pretty exciting. The teams here are incredibly passionate about their work and a true pleasure to work with. Their deep investment in data, a trait I rarely encountered in my previous roles, has enabled the birth of many unique features.

Are there any memorable moments at DKatalis?

CP: For me, perhaps, it was the Jago App launch. The process went incredibly smoothly as if it was just another day in the office. The tech support team might have felt a touch of nerves, but at least the anxiety didn’t spread to other departments. And also, being able to launch groundbreaking products, such as our Shared Pocket, was another proud accomplishment.

Lastly, how would you describe DKatalis in 3 words?

CP: Diverse, fun, and challenging.

Birds of a feather flock together! Read more stories from the boundaries-breaking and inspiring people at DKatalis here (and don’t forget to follow us).

The UX Factor: Weaving Interactive Design for Impactful Products was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.