What is the company culture like at DKatalis Labs?

Good culture and a great place to learn

Very agile place, good to learn but you also have to be ready for any new project

Work from anywhere, nice people and good culture

None that I can think of

1. Work from anywhere. 2. Work culture are based on the community. 3. Work life balance, rarely to work overtime.

1. Still require you to go to office on certain occasion, and will be without compensation even though you are outside Jakarta area if you are based on Jakarta previously. 2. Because it is based on the community, it will be difficult if you prefer to work individually. Will depend on each team or division. 3. Backlog priority are not really transparent, usually will have multiple highest priority projects in the same time to appease multiple stakeholders requirement.

Embracing learning, blameless culture, and modern thinking leader

The benefits are okay, yearly adjustments are just average, and the HR team is unhelpful

DKatalis Lab offers a truly impressive range of benefits, including a competitive salary, Unlimited Responsible Leave, Work-from-Anywhere flexibility, comprehensive Health Insurance, coverage for frames and prescription lenses, access to continuous learning opportunities, and a highly diverse team of employees. I particularly appreciate their open-minded approach to work—employees are not confined to their job descriptions, which encourages innovation and skill-building. This culture fosters both personal and professional growth, as employees are given the space and trust to explore new areas and expand their expertise.

There are occasional challenges with communication, whether between peers or between upper management and team members. Miscommunication tends to happen frequently, especially with their independent client and sister company, Jago Bank. Although they emphasize that we are identical and share similar values, the reality is that their culture and employees are completely different. This often creates clashes whenever there’s collaboration or overlap in projects involving them. Additionally, at times, resources seem to be allocated to less impactful areas, which could be improved.

DKatalis Lab offers a truly impressive range of benefits, including a competitive salary, Unlimited Responsible Leave, Work-from-Anywhere flexibility, comprehensive Health Insurance, coverage for frames and prescription lenses, access to continuous learning opportunities, and a highly diverse team of employees. I particularly appreciate their open-minded approach to work—employees are not confined to their job descriptions, which encourages innovation and skill-building. This culture fosters both personal and professional growth, as employees are given the space and trust to explore new areas and expand their expertise.

There are occasional challenges with communication, whether between peers or between upper management and team members. Miscommunication tends to happen frequently, especially with their independent client and sister company, Jago Bank. Although they emphasize that we are identical and share similar values, the reality is that their culture and employees are completely different. This often creates clashes whenever there’s collaboration or overlap in projects involving them. Additionally, at times, resources seem to be allocated to less impactful areas, which could be improved.

Competitive salary. Some good junior engineers who haven't yet been ruined by the environment.

Where to start. Engineering leadership has no grounding in modern software engineering practices. Foundational work like CI improvements, contract testing, and automated test infrastructure is actively devalued. I was told I was doing "too much technical work" after discovering builds that had been silently broken for years and test suites that had never actually run in CI since they were created. I didn't just identify the problems, I fixed them and left the infrastructure for others to use. I introduced contract testing using industry-standard tools (Pact, Specmatic). Months after being told to stop because I "must be getting bored of it," leadership asked the team how to solve the exact problem the contract testing already addressed, completely unaware the work had been completed. The QA team, whose primary function is manual regression testing, was then directed to build a custom mock framework from scratch instead of using the proven tooling already in place. This same team also calls itself QE and writes "automation tests" in isolation from the development teams. They can't even decide what they are. If you need a dedicated team to write your tests for you, your engineering culture has already failed. They have consultants from a well-known agile consultancy embedded and even they are doing feature branching, not trunk-based development, not writing proper test automation. Their engineering contribution includes "enriching" shared JSON objects: one mutable god object full of optional nulls and empty strings representing 50+ different transaction types, where impossible states are not only possible but common. Instead of creating proper message types for each transaction, everything is crammed into one bloated payload and passed around between services with no schema constraints, no contracts, and no validation. When something breaks, nobody knows which service mutated what, or when. Two organisations that should know better, and neither does. There is no psychological safety. When I raised architectural concerns, specifically how the org structure violated Conway's Law, with ~50 people across 9 teams sharing microservices without domain boundaries, the response was a formal "expectations" message rather than any technical engagement. Process improvement proposals were dismissed as "just presentations," then leadership delivered their own presentation two days later. I explicitly told my manager that the feature factory / long-lived branch / pull request model was the reason I'd left previous companies, and that I'd likely last about a year in that environment. I was subsequently assigned to a team operating under exactly that model. Either the feedback wasn't retained, or it was deliberately ignored. A greenfield project opportunity went to an engineer whose current work had a broken build for two weeks. There was no conversation about interest or suitability with other team members who had demonstrated stronger delivery track records. The principal engineers think they're clever at attempting an old consulting trick: if you identify problems they should have caught, they load the fix onto you. It's a deflection. The problem becomes your responsibility, and their failure to spot it disappears. Raise enough problems and suddenly you're doing "too much technical work." Accurate technical assessments get reframed as attitude problems. I used the term "Distributed Monolith" to describe the architecture, a well-known industry term, and was told this was "disparaging" and "negative," and that holding that opinion would "isolate" me. That's not feedback, that's gaslighting and fearmongering that borders on bullying. Meanwhile, the majority of my peer feedback praised me as a mentor, a leader, and a go-to person for technical guidance. The message is clear: identify problems that leadership is responsible for or doesn't want to hear about, and the problem becomes you. The entire organisation has fallen into agile theatre. Pure cargo culting: ceremonies without understanding, frameworks without foundations. They went all-in on LeSS, which is the problem in itself, not just the implementation. In my department alone ("Money Management"), ~50 people divided into 9 teams all sharing the same services with no domain boundaries. And that's just one department. Large refinement sessions where stories are pre-estimated by people who won't implement them, and they call it agile. The result is a distributed monolith masquerading as microservices, operated by a framework that assumes shared codebases. Nobody questions whether any of it is working because nobody is measuring flow. When someone does measure it and presents the findings, it gets dismissed. The company values talk about being a "catalyst of change" and "willingness to break norms." In practice, challenging the status quo results in formal warnings rather than collaborative problem-solving. On a personal level, one of the more disappointing realisations is that the product enforces Sharia compliance. I regret contributing my skills to building a system that operates under a religious legal framework I fundamentally disagree with. I was on an Employment Pass in Singapore, which meant leaving wasn't as simple as handing in notice. Had I been working in my home country, I would have left within the first few weeks once the dysfunction became apparent. Instead I'm stuck with this revolting blight on my resume.

- Flat hierarchy in the organization - Lots of learning opportunities (trainings, workshops, online courses, etc) - Lots of senior people here, can have opportunities to learn new things from their background - Diversity in terms of technology, people, also culture

- Working tools that quite delay to be replaced - Quite hard to be promoted to another seniority level - Office that is not reachable through public transport

Where, when, and how you work is pretty flexible. Up to you and your team to come-up with a shared agreement. Culture revolves around problem solving. As you long as you solve problems and show accountability for your solution, the company care less about the hours you spend on work.

Too many initiatives running at once, it's disorienting. Need to choose your battle and ignore everything else, otherwise it's impossible to get anything done.

Competitive salary. Some good junior engineers who haven't yet been ruined by the environment.

Where to start. Engineering leadership has no grounding in modern software engineering practices. Foundational work like CI improvements, contract testing, and automated test infrastructure is actively devalued. I was told I was doing "too much technical work" after discovering builds that had been silently broken for years and test suites that had never actually run in CI since they were created. I didn't just identify the problems, I fixed them and left the infrastructure for others to use. I introduced contract testing using industry-standard tools (Pact, Specmatic). Months after being told to stop because I "must be getting bored of it," leadership asked the team how to solve the exact problem the contract testing already addressed, completely unaware the work had been completed. The QA team, whose primary function is manual regression testing, was then directed to build a custom mock framework from scratch instead of using the proven tooling already in place. This same team also calls itself QE and writes "automation tests" in isolation from the development teams. They can't even decide what they are. If you need a dedicated team to write your tests for you, your engineering culture has already failed. They have consultants from a well-known agile consultancy embedded and even they are doing feature branching, not trunk-based development, not writing proper test automation. Their engineering contribution includes "enriching" shared JSON objects: one mutable god object full of optional nulls and empty strings representing 50+ different transaction types, where impossible states are not only possible but common. Instead of creating proper message types for each transaction, everything is crammed into one bloated payload and passed around between services with no schema constraints, no contracts, and no validation. When something breaks, nobody knows which service mutated what, or when. Two organisations that should know better, and neither does. There is no psychological safety. When I raised architectural concerns, specifically how the org structure violated Conway's Law, with ~50 people across 9 teams sharing microservices without domain boundaries, the response was a formal "expectations" message rather than any technical engagement. Process improvement proposals were dismissed as "just presentations," then leadership delivered their own presentation two days later. I explicitly told my manager that the feature factory / long-lived branch / pull request model was the reason I'd left previous companies, and that I'd likely last about a year in that environment. I was subsequently assigned to a team operating under exactly that model. Either the feedback wasn't retained, or it was deliberately ignored. A greenfield project opportunity went to an engineer whose current work had a broken build for two weeks. There was no conversation about interest or suitability with other team members who had demonstrated stronger delivery track records. The principal engineers think they're clever at attempting an old consulting trick: if you identify problems they should have caught, they load the fix onto you. It's a deflection. The problem becomes your responsibility, and their failure to spot it disappears. Raise enough problems and suddenly you're doing "too much technical work." Accurate technical assessments get reframed as attitude problems. I used the term "Distributed Monolith" to describe the architecture, a well-known industry term, and was told this was "disparaging" and "negative," and that holding that opinion would "isolate" me. That's not feedback, that's gaslighting and fearmongering that borders on bullying. Meanwhile, the majority of my peer feedback praised me as a mentor, a leader, and a go-to person for technical guidance. The message is clear: identify problems that leadership is responsible for or doesn't want to hear about, and the problem becomes you. The entire organisation has fallen into agile theatre. Pure cargo culting: ceremonies without understanding, frameworks without foundations. They went all-in on LeSS, which is the problem in itself, not just the implementation. In my department alone ("Money Management"), ~50 people divided into 9 teams all sharing the same services with no domain boundaries. And that's just one department. Large refinement sessions where stories are pre-estimated by people who won't implement them, and they call it agile. The result is a distributed monolith masquerading as microservices, operated by a framework that assumes shared codebases. Nobody questions whether any of it is working because nobody is measuring flow. When someone does measure it and presents the findings, it gets dismissed. The company values talk about being a "catalyst of change" and "willingness to break norms." In practice, challenging the status quo results in formal warnings rather than collaborative problem-solving. On a personal level, one of the more disappointing realisations is that the product enforces Sharia compliance. I regret contributing my skills to building a system that operates under a religious legal framework I fundamentally disagree with. I was on an Employment Pass in Singapore, which meant leaving wasn't as simple as handing in notice. Had I been working in my home country, I would have left within the first few weeks once the dysfunction became apparent. Instead I'm stuck with this revolting blight on my resume.