Principally Speaking: The Craftsmanship of Software Engineering

With Wira Siwananda, Principal Engineer for Partnership Clan

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!