Defect/Bug Management

who doesn’t love bugs? they are small yet beautiful…ly ruining our life 🙂. Bug is inevitable, choosing 0 Bug as your OKR/KPI is an insane choice, it’s not impossible but it will astronomically hit your productivity & cost, your best bet is to manage it properly. So how are you organizing and managing these bugs? Assigning the right priority(by assessing its severity) is the key, inspired by a couple of references, here is how I typically categorize them.

Continue reading

Software Fragmentation – The Golden Path

There is a direct correlation between teams that give their engineers autonomy to own their technical decisions and the team’s ability to hire and retain A-class or Senior talent. There is a tradeoff, but an acceptable level of chaos in exchange for a stronger sense of individual/team ownership is usually the right one and leads to higher performing teams in the long run – at least this is what I’ve been seeing if a couple of companies in Indonesia.

So, how to make sure these “chaotic” things are manageable and actually give the benefit to the team?

Continue reading

Engineering Growth Framework

Growth Framework, Career Guideline, Career Ladder, whatever you call it, is essentially general expectations of each of the grade, sometimes people call it as career ladder, but we at Mekari wanted to take it further down into its philosophy: Framework. In general, a framework is a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.

Continue reading

Manager Manifesto

Manifesto

  • Giving critical feedback or having difficult conversations
  • Assessing whether a product is ready for launch
  • Designing and executing a realistic roadmap
  • Setting good goals with accountability
  • Building viable new products
  • Managing a team during “war time” versus “peace time”
  • Defining quality
  • Determining who to hire
  • Understanding people’s skills, strengths, and growth trajectories
Continue reading

Engineering Initiative, where to start?

Performance improvement we must do, but where to identify it? Sometimes this kind of things might not obvious as they are, as experience and frame of reference from each of the individual engineer within your team might vary.

This post intended to share questions and framework that I’ve been using (and pushing) to my team to give cue and where to start on finding room for engineering improvements.

Continue reading

Excerpt on Regulated Data : Amount, Duration Data Holding, and Archiving

Data subjects are entitled to request the ESO delete their PII, and the ESO must do so accordingly. If the data subject does not request such deletion, under MoCI Regulation 20, an ESO shall comply with a five-year minimum statutory retention period or as otherwise required by the relevant supervisory authority. This retention period is calculated from the moment the data subject terminates the use of services of the ESO. 

Continue reading

On Establishing Technical Documentation at Mekari


We all hate time wasters. Documentation often is seen as one of these time wasters, mostly because it is boring to do. Planning is often seen as kind documentation, so there is a natural tendency to just skip this step for efficiency. However, people forget the hidden cost of skipping this documentation step: no agreement on shared understanding may cause the project will take a lot longer than people think, and this is only the beginning of other disadvantages of not having proper documentation.

Continue reading

Engineering North Star Metrics

In the world where all of the metrics are available to be fetch and tracked, we end up on too many things being measured or worst, too little things that are being measured. It is impractical to make smart decisions based upon all available data and impossible to make any decision without data, and virtually impossible to make every metric as a priority worthy of improvement. The first challenge is deciding on what to measure, this article is intended to propose following metrics as the de jure metrics that being tracked and constantly improved going forward within tech team that I led so far.

The 4 Layers of A Team
Continue reading