Ninja Van

I started learning software engineering very early and began freelancing before finishing secondary school—over 20 years ago, when the field was much simpler than today. By the time I entered university, I was already working with three companies as a freelancer, dedicating all my free time to coding. When I transitioned to a full-time role, it was my first experience working under engineering leadership.

Since then, I have moved through various roles, companies and countries, always seeking innovative environments where I could learn and grow. These opportunities exposed me to diverse cultures and leadership styles. I invested heavily in self-development—earning certifications, reading management and communication books and expanding my technical expertise to manage broader technology scopes.

My first leadership role was at Lazada, then a two-year-old startup with rapid growth and exceptional talent. Initially leading one team, my scope expanded as I proved my capabilities, though the role remained hands-on due to tight resources and deadlines. Adjusting to the Asian cultural context was challenging but rewarding, successfully enabling me to lead multicultural teams across Southeast Asia.

Subsequent roles in companies with distributed teams further broadened my leadership approach, ultimately preparing me for my current position at Ninja Van.

Adapting Management and Improving Performance

I have developed a personal management framework that I tailor to each team, as each team has its unique challenges, processes, goals and mentalities. I spend at least 3 months directly managing new teams to assess their state firsthand, get to know everyone in the team, including stakeholders, their relationships and engineering metrics and practices. Learning all this helps me to find the right way of working.

I have developed a personal management framework that leverages metrics and observations. I apply Scrum, XP, or Agile where appropriate—or fix flawed implementations, which are often the root cause of suboptimal performance. Fortunately, these issues are typically easy to detect and address using team performance metrics.

One common problem is that as task effort estimates increase, the margin of error also grows. This impacts team commitment, adherence and delivery variance due to higher uncertainty, which ultimately hinders performance. To solve this, I recommend capping task estimates and breaking down large tasks into smaller ones. Doing so improves predictability, commitment adherence and overall team performance.

"The best engineering managers stay close to the code and design—that’s how they inspire change and spot opportunities."

Another frequent issue is inadequate communication channels. Sometimes people are excluded from meetings, too many participants are included, or the wrong individuals are talking to each other. While this can be quick to fix, it’s not always easy to detect.

For example, a product manager might primarily engage with one stakeholder, neglecting others. This limited approach can lead to scope creep or, worse, project rollout delays when missed requirements surface. Such communication issues must be addressed promptly, as they can result in costly setbacks for stakeholders and demotivation for engineering teams.

Balancing Product and Engineering Roadmaps

My usual approach is to agree with product stakeholders about a fixed capacity for the engineering roadmap. For example, the team would dedicate x percent of their effort to the engineering roadmap. Of course, we are always willing to sacrifice this x percent for a sprint/iteration or a few to deliver some very urgent feature. Still, generally we try to adhere to this, mainly as engineer KPIs or OKRs are reflecting such agreement. Stakeholders tend to understand the need for the engineering roadmap, as we always try to express our initiatives or tasks in business terms and benefits. For example, upgrading a particular library or technology would reduce the number of issues experienced by the end user, or it would improve their experience and so on.

Bridging Data and Engineering Teams

I learned about data science, which has been my most significant insight. I was familiar with data engineering before, but data science was something new to me. I have invested a considerable amount of time in understanding the latest technologies and solutions for both of those domains and put my effort into bringing us up to date. One of the collaboration efforts that I proposed was a data catalog. It seems to be a vital missing piece for a few teams: BI, data engineering, data science and product engineering. I have invested a lot of my time advertising the data catalog to all of the teams mentioned above to achieve a buy-in. In the end, everyone understood the benefits that it brings to all parties.

Besides this specific example, I introduced data engineering and data science team service offerings to product engineering teams. Previously, their services were unknown primarily to product engineering teams and were used very narrowly by a very few stakeholders, which left them underutilized. After this exercise, we had quite a few projects that had product engineering, data science and/or data engineering teams working together. For example, we had a few OCR projects, route optimization projects, etc.

Advice for Engineers Becoming Managers

I would suggest they stay involved in their team’s day-today tasks as much as possible, especially if they are at the entry manager level. They should strive to review as many code changes as possible and participate in and/or review all technical design decisions. If they have time to code themselves, they should. This should keep them technical and allow them to see their team member skill gaps, their product technical debt and process issues, which subsequently would enable them to lead impactful changes.