Research and Engineering Culture

KDU and KDL priority is to improve core competencies and capability to innovate in digital technology domain. KDU will be the main source of knowledge and skill in developing Software+AI products and services, while KDL will serve as R&D and innovation arm to explore State of the Art (SOTA) in healthcare industry. Both KDU and KDL will produce corporate wide inclusive-services in Kalbe. 

KDU reflects Digital Employee Experience (DEE) as part of modern Research and Engineering culture with tools and practices focused on developing high-quality, secure, and feature-rich Software+AI services to enable digital transformation across Kalbe companies. KDU research and engineering initiatives designed to help all Kalbe SBUs to achieve customer-centric digital services and improve engineering productivity with Software+AI standardizations (KMSP, KUIF, KLCP, KMLOps, KKB, KDLS).  

What is Software+AI Engineering

There is clear separation between programming as a code construction activity and Software+AI (SEAI) engineering as designing, developing and maintaining software during its lifespan, in a way that it remains both modifiable and scalable. So, time, scale and trade-offs differentiated programming from SEAI. 
The main goal of SEAI is to develop sustainable intelligence software solutions. It is sustainable if during its lifespan we can change it in response to changes in the technologies or for business reasons. Based on industry experience, if the software is going to live for more than a few days (or if it's not for fun, not a college project and not to show your friends that you are smart!), we should prepare for the changes. For this reason, Kalbe software and policies must be scalable. Some initial principles in CDT to build SEAI are: 
- AI-First: Software is designed to prepare AI features
- Cloud-First: Distributed and multi-cloud platform and tools/
- Mobile-First: Modern web and mobile experiences 

Vision of Modern Engineering

Kalbe digital transformation requires us to deliver capabilities and solutions at a faster pace and with high quality, reliability, and security. To achieve this, we should be able to modernizing how we build, deploy, and manage digital products and services to get new functionality in Kalbe users’ hands as rapidly as possible. We’re re-examining every part of engineering process and instituting modern engineering practices with cloud-first, mobile-first and AI-first principles in order to deliver the best experiences for Kalbe customers, partners and employees. Those principles will modernize Kalbe research and engineering processes to be customer-obsessed, data-driven, speed-oriented and quality focused.
We want to ensure Kalbe engineers keep users front and center in their thoughts, so we have to capture feedback in a common tool, thereby providing engineers with a deep understanding of the customer experience. We will surface and view this feedback in conjunction with telemetry measures that will help us build an understanding of how users are utilizing digital products and the features that are causing them issues. Telemetric data availability is also very important for automation with AI-first principle. 
We want to implement a higher fidelity SEAI service and business-process monitoring so that we’re alert to problems and fix them before users are even aware of them. We want to enable Kalbe engineers to develop reliable and secure services, and reduce deployment lead times by streamlining the process from committing of code to deployment while integrating compliance checks seamlessly in the build and release pipeline. We are the first customers of any Kalbe commercial offerings, which enables us to identify and address the engineering needs of the Kalbe operating in a cloud-centric architecture.

While increased velocity is critical to digital transformation, it must not negatively affect reliability. Continuous data collection, monitoring of health signals, moving toward proactive detection, and quick remediation are also critical in ensuring reduced downtime and creating a high-quality user experience. Implementing modern SEAI practices is a long-term journey that requires fundamental changes to mindset, culture, and tooling, including:
  • Shifting to a modern cloud architecture; building Microservices by componentizing monolithic applications; publishing APIs with KMSP or KLCP; developing modern frontend with KUIF; ensuring greater than 90 percent automated test coverage; and partnering with other SBU engineering teams by taking dependencies and integrating with their service rather than attempting to duplicate it.
  • Implementing intelligence services using machine learning or deep learning requires standard technologies for collecting, curating and modeling of the data. We have to define our standard tools and practices in utilizing state of the art machine learning models in productions. In CDT, we will develop KMLOps as patterns and practices to utilize fragmented machine learning platforms. With KMLOps standards we will explore various AI use cases in healthcare and medical like Medical Imaging, Medical Language Model, Graph Knowledge Based and Genomic/Life Science (KKB and KDLS).
  • Continuously integrating tested SEAI codes and only deploying from a master branch of the code.
  • Shifting from fixed cadence releases to continuous integration/continuous delivery by keeping the product in a releasable state, allowing fast release and rapid response to failures supported by an automated deployment pipeline.
  • Conducting experimentation in production using a ring-deployment model instead of having user acceptance testing (UAT) and relying on dedicated UAT environments.
  • A Live Site culture that comprehensively monitors service health, proactive identification of issues, introduction of self-healing mechanisms, fast remediation of major incidents, direct contact with end users, laser focused on root cause to ensure sustained improvements in service quality and by extending focus from service health to business process health.
  • Proactively managing acknowledged technical debt and reserving engineering resources so that we can address it before it generates unplanned work or impacts the quality of service.

How to Work as Team

SEAI engineering is teamwork. To be successful in SEAI engineering we should first focus on ourselves by applying core principles of humility, respect, and trust as guided by Panca Sradha!. People are afraid of being judged based on their unfinished or unperfect code and try to find a way to hide their code because of insecurity. This insecurity comes from the Genius Myth which is a tendency to ascribe the success of a team to a person and idolize him/her. The heroic picture of a genius programmer staying in the basement of his/her parents' house, for just three months, and coming out with a masterpiece of working and precious software, that stuns everybody and shakes the industry, comes from this myth.
Other than the Genius Myth and the insecurity coming from it, software engineers like to keep their ideas a secret before finishing work on it because they fear their idea be copied by others. But this hiding is harmful because you can be on the wrong track. Hiding is dangerous and we should encourage knowledge-sharing, early and frequent feedback, and teamwork.
To apply humility, respect, and trust in practice, we should lose our ego and not behave like we are always the most important person in the room. In other words, we should be humble at the same time that we have self-confidence. One solution is to work on the team's identity and pride instead of personal identity. Furthermore, we should learn to give and take criticism and keep in mind that "we are not our code" when faced with criticism from others. The choice of language is also important when giving someone our criticism.
Furthermore, we should note that "failure is an option" and we must try to fail fast and iterate to reach success. To support this, a blameless culture is necessary. We should work hard to create such a culture by having a well-defined postmortem process to document in Confluence what we learn from each mistake. To embrace failure, being patient and open to influence is necessary. We defines FAST SEAI culture, as a set of attributes and behaviors that we look for in candidates, which represent strong leadership and exemplify humility, respect, and trust, as below:SEAI engineering is teamwork. To be successful in SEAI engineering we should first focus on ourselves by applying core principles of humility, respect, and trust as guided by Panca Sradha!. People are afraid of being judged based on their unfinished codes and try to find a way to hide their code because of insecurity. This insecurity comes from the Genius Myth which is a tendency to ascribe the success of a team to a person and idolize him/her. The heroic picture of a genius programmer staying in the basement of his/her parents' house, for just three months, and coming out with a masterpiece of working and precious software, that stuns everybody and shakes the industry, comes from this myth.
Other than the Genius Myth and the insecurity coming from it, software engineers like to keep their ideas a secret before finishing work on it because they fear their idea be copied by others. But this hiding is harmful because you can be on the wrong track. Hiding is dangerous and we should encourage knowledge-sharing, early and frequent feedback, and teamwork.
To apply humility, respect, and trust in practice, we should lose our ego and not behave like we are always the most important person in the room. In other words, we should be humble at the same time that we have self-confidence. One solution is to work on the team's identity and pride instead of personal identity. Furthermore, we should learn to give and take criticism and keep in mind that "we are not our code" when faced with criticism from others. The choice of language is also important when giving someone our criticism. 

Furthermore, we should note that "failure is an option" and we must try to fail fast and iterate to reach success. To support this, a blameless culture is necessary. CDT should work hard to create such a culture by having a well-defined postmortem process to document in Confluence what we learn from each mistake. To embrace failure, being patient and open to influence is necessary. CDT defines FAST SEAI culture, as a set of attributes and behaviors that we look for in candidates, which represent strong leadership and exemplify humility, respect, and trust, as below:
  • Focus. Do the right thing for Kalbe: Has a strong sense of ethics about everything we do; willing to make difficult or inconvenient decisions to protect the integrity of the team and product. Execute what is planned: Has achievable and measurable plans for all initiatives with clear Goal, Signals and Metrics (GSM). Learn to say no on distraction and noise. 
  • Alignment. Values feedback: Has humility to both receive and give feedback gracefully and understands how valuable feedback is for personal (and team) development. Communicate intention upfront: Always communicate the intention of initiative and willing to adjust strategies with consensus to achieve common goals.  Open and honest: Never hide main intention and always open and honest without hidden agenda.
  • Scientific. Experiment to gain knowledge: Apply scientific principles in all of our action by making hypothesis, design and run experiments to gain knowledge. Don't bias with other people opinions. Thrives in ambiguity: Can deal with conflicting messages or directions, build consensus, and make progress against a problem, even when the environment is constantly shifting. Challenges status quo: Is able to set ambitious goals for Kalbe business and pursue them even when there might be resistance or inertia from others.
  • Talent. Learn, unlearn and relearn: Maintain curiosity to explore state of the art of technologies in KDU. Cares about the team: Has empathy and respect for coworkers and actively works to help them without being asked, improving team cohesion. Puts the user first: Has empathy and respect for users. Always educate users with technical documentation and socialize in KDU. 

Learning Organization

Any organization has to understand problem domain better than some random person on the Internet and should be able to answer most of its own questions. To achieve that, we need both experts that know the answers to those questions and mechanisms to distribute their knowledge. These mechanisms range from direct questioning to talks, courses, and written documents in any form (technical papers, code documentation, tutorials, manuals, HowTo, and so on).
Code is an important output but only a small part of building products. Our success depends on growing and investing in its people. In other words, investing in engineers' learning and knowledge sharing. Personalized one-to-one advice is invaluable but documented knowledge in Sharepoint is more scalable.

We will implement a culture of learning in Kalbe and these are the challenges to learning we found so far:
  • Lack of psychological safety
  • Information islands, which shows itself in different forms: fragmentation, duplication, and skew
  • Single points of failure, "all or nothing" expertise
  • Parroting or mindlessly copying patterns or code without understanding
  • Haunted graveyards, which are parts of code that nobody dares to touch
One side of knowledge sharing is learning from others. The first way of learning is by asking questions. Also, we should understand the context of any decision made to be able to understand and use it. Consider the principle of "Chesterson’s fence": before removing or changing something, first understand why it’s there. Asking direct questions can be followed by asking the peers, writing down the answers if not documented, and sharing them with others. Also, our group chats in Slack and documentation in Sharepoint platforms play an important role in learning. We should make Slack and Sharepoint more structured and easy to use. 
On the other side, we should share our knowledge to be used by others. Having KDU courses, tech-talks, and written documentation are great ways to scale our knowledge sharing. The first time we learn something is the best time to see ways that the existing documentation and training materials can be improved. Everybody must be able to read any document in Sharepoint and contribute to them and fix them if necessary. As team we must recognize the value and incentivize documentation because the writer often has no direct benefit of writing the document.
Code and its documentation is another medium for knowledge sharing. It can be completed with the code review process and another CDT-specific process named "code readability process".
Documentation is tough for software engineers so they must learn how to do that and CDT must facilitate the process as much as possible. CDT must treat the documentation like code by putting them on version control systems (markup languages made it possible), reporting their errors like bugs and fixing them, and reviewing important ones. CDT will make sure that there is just one canonical source of information for each topic and prevents wasting time finding answers or duplicating documentation.
Technical writing skills very important and rewarding for CDT engineers. A good piece of well-structured and maintained documentation is as valuable as a piece of code, if not more. Lack of overall vision in the documentation process is a big problem. We should determine the scope of documentation including the audience, plan for it, structure it perfectly, and maintain it just like code. 
Designing and developing software for a diverse user base in Kalbe is challenging. CDT must focus on users of different geographies, ethnicities, races, genders, ages, socioeconomic statuses, abilities, and belief systems. Because of the hidden biases, even the most talented engineers will fail to design and develop for everybody and it can lead to dissatisfaction or harm.
One way to address this problem is to help the CDT organization itself looks like the populations for whom it builds products, by hiring people with different backgrounds and from diverse groups. Every individual engineer in CDT needs to learn how to build for related Kalbe users. Being an exceptional engineer requires us to focus on bringing diverse perspectives into product design and implementation. It means that CDT engineer involved at hiring must try to build a more representative workforce and the organization itself must provide a truly supportive work environment for all people.

Measuring Productivity

CDT aims to setup Kalbe as a data-driven company and tries to make most of the decisions in an objective way rather than a subjective way. When human factors involved, however, analyzing data is difficult. In CDT, we have a team of engineering productivity specialists from Software and AI Labs. We are not relying on each team to do productivity measurement, analysis, and decision making. Before measuring productivity, the engineering productivity specialists team asks questions from the stakeholders to be sure that the effort worth it. They ask whether the result is actionable, regardless of the result is positive or negative. If you can’t do anything with the result, it is likely not worth measuring. They also ask people to describe what they want to measure in the form of a concrete question. They found that the more concrete people can make this question, the more likely they are to derive benefit from the process. Note that when we are successful at measuring our software process, we aren’t setting out to prove a hypothesis correct or incorrect. Here, success means giving a stakeholder the data they need to make a decision.
To measure productivity, we will use GSM (Goal/Signals/Metrics) framework. A goal is one desired end result like objective in OKR. It’s phrased in terms of what we want to understand at a high level and should not contain references to specific ways to measure it. A signal is how we might know that we’ve achieved the end result. Signals are things we would like to measure, but we might not be measurable ourselves. A metric is a proxy for a signal. It is the thing we actually can measure. Some signals don't have any measurable metric (we should ignore them) and some have multiple. A good metric is a reasonable proxy to the signal we’re trying to measure, and it is traceable back to our original goals.
Select metrics that cover all parts of productivity. By doing this, we ensure that we aren’t improving one aspect of productivity (like developer velocity) and the cost of another (like code quality). CDT team divides productivity into five core components named QUANTS: quality of the code, attention from engineers, intellectual complexity, tempo and velocity, and satisfaction.
Some of these signals might be measurable by analyzing tools and code logs. Others are measurable only by directly asking engineers. Qualitative metrics are also metrics. Consider having a survey mechanism for tracking metrics about engineers’ beliefs. Qualitative metrics should also align with the quantitative metrics; if they do not, it is likely the quantitative metrics that are incorrect.
After the analysis, aim to create recommendations that are built into the SEAI engineering workflow and incentive structures. Even though it is sometimes necessary to recommend additional training or documentation, change is more likely to occur if it is built into the engineer’s daily habits. The engineering productivity specialist team always prepares a list of recommendations for how they can continue to improve. CDT believes that the engineers will make the appropriate trade-offs if they have the proper data available and the suitable tools at their disposal. Doing engineering productivity measure in small team is hard and costly. CDT should trust engineers and researchers and setup the engineering productivity as virtual team with members assigned from from each division in CDT - Software Center and AI Center Labs.
Created with