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 →

Incident & Post Mortem Process

This article is part of **On Managing Stability** series.

Recurring incidents are the enemy of scalability. Recurring incidents steal time away from our teams – time that could be used to create new functionality and greater value. Our past performance is the best indicator we have of our future performance and our past performance is best described by the incidents we have experienced and the underlying problems that caused those incidents.

Failing to recognize and resolve our past problems means failing to learn from our past mistakes in either architecture, engineering, process, and operations, and also communication.

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.

Continue reading →

On forming Technical Program Manager team at Mekari

As the company growing and more product verticals are coming in, and more competitors coming in not only from Indonesia but also big players from outside the country, there are needs from stakeholders and management (C/VP levels) to ensure we are delivering our initiatives more than ever. Hence, ensuring a team to be self-organized, transparent, and great visibility of ongoing and upcoming project progress are very critical. Spotting potential delays early and doing continuous improvement on how we structure the team and do communication within the team is also essential for us to achieve effective & efficient productivity.

Continue reading →

Guidance on Creating New Service

something that we definitely don’t want to happen to us 🙂

At any tech company, we work with a lot of legacy systems and monoliths. As engineers, our first instinct would be to decouple these monolithic applications into microservices architectures so we can have cleaner code and an easier system to maintain. While this is definitely a good goal to have, sometimes we focus too much on the technical side of things (architecture, scalability, implementations) and lose sight of the bigger picture. Hopefully, this document can be guidance on other aspects we should think about.

Continue reading →