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
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
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 readingIn 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.
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