How I Lead

Stay Technical — Because the Best Decisions Happen Close to the Code

I've watched engineering leaders gradually disconnect from the systems they're responsible for. It starts small — skipping design reviews, delegating architecture decisions, trusting dashboards over direct observation. And then one day, you're making organizational decisions about systems you no longer understand.

I refuse to let that happen.

At Acko, I remain hands-on across architecture reviews, critical backend components, and system design decisions. When we migrated our highest-traffic partner to a new core platform, I wasn't watching from the sidelines. I was in the architecture reviews, challenging assumptions, and reviewing rollback plans.

When we integrated AI-based fraud detection, I worked closely with the team to design it as a pluggable platform — architected so we could swap providers or integrate multiple systems in the future. The integration took time to mature; we ran weekly reviews to track progress and iterate. Understanding how the fraud detection layer worked was essential to making good decisions about where it fit in our platform architecture.

The principle: Technical depth isn't optional for engineering leaders — it's the foundation of good judgment. I participate in design reviews not to micromanage, but because understanding systems deeply is the only way to make sound organizational decisions about them.

Build for Predictability — Because Heroics Are a Symptom, Not a Solution

Early in my leadership journey, I mistook urgency for impact. A team pulling all-nighters to hit a deadline felt like commitment. A last-minute save during a production incident felt like heroism.

It took me time to recognize the pattern: heroic efforts are a symptom of broken systems, not a sign of a strong team.

At Acko, I've built delivery practices designed to eliminate the need for heroics:

• Implemented a Jira automation framework with multiple rules that improved SDLC compliance, enforced code review discipline, and standardized sprint hygiene across teams
• Established an incident governance framework that reduced escalation resolution time — not through faster firefighting, but through better prevention
• Promoted data-driven retrospectives with actionable tracking, so the same problems don't recur

When we delivered a major multi-category product launch in under 3 weeks, it wasn't because the team worked around the clock. It was because our delivery infrastructure, partner onboarding frameworks, and engineering practices were already in place. The sprint felt fast, but it was predictable.

The principle: Sustainable pace is a feature, not a compromise. I build teams and processes that deliver reliably — sprint after sprint — without burning people out. When you invest in predictability, speed becomes a natural byproduct.

Invest in the Craft — Because the Tools Are Changing and Curiosity Isn't Optional

Engineering leadership isn't just about managing people and processes. It's about staying curious about how we build software — and being willing to challenge established practices when better approaches emerge.

I've been exploring AI-assisted development workflows with my teams, and we've seen measurable reduction in development cycle time. But the number isn't the point. The point is creating a culture where engineers are encouraged to experiment with new tools and approaches rather than defaulting to what's familiar.

When we integrated AI-based fraud detection, we brought a new capability into a team that had never worked with such systems before. We learned new patterns, iterated through weekly reviews, and built something that significantly improved detection accuracy while reducing manual reviews. The team grew technically because we chose to lean into unfamiliar territory instead of staying in our comfort zone.

I also standardized SDLC process documentation across teams and established automated deployment pipelines — not because process is glamorous, but because craft includes the discipline of how you ship, not just what you ship.

The principle: The best engineering teams are learning organizations. I encourage experimentation, invest in tooling, and create environments where trying new approaches is celebrated — even when they don't work. Staying curious about the craft is what keeps teams sharp.

Teams Compound — Because Individual Heroics Don't Scale

The most important thing I build isn't software. It's the team that builds the software.

At Acko, I've scaled engineering teams from small squads to a 15+ person organization spanning multiple business lines. But scaling isn't just about headcount. It's about building the conditions where people grow into the best version of their engineering selves.

Here's what that looks like in practice:

• Mentored engineering manager candidates and senior engineers for promotion readiness — investing in their growth trajectories, not just their current output
• Restructured teams for higher delivery accountability — sometimes the right team design decision is restructuring, not just hiring
• Ran hackathons to encourage experimentation and process automation — giving engineers space to explore ideas outside sprint commitments
• Active in hiring panels and reviewer for cross-team design proposals — extending influence beyond my direct org

When you invest in the right people and give them the right context, the results compound over time. Major product launches, platform migrations — none of these were the work of any one person. They were the output of a team that had been deliberately built to handle exactly this kind of complexity.

The principle: Individual heroics don't scale. I spend significant time thinking about team design, hiring, mentorship, and creating environments where engineers can do their best work. The compounding effect of a well-built team is the most powerful force in engineering.

Own the Outcome — Because Accountability Is the Foundation of Trust

I believe engineering leaders should own outcomes end-to-end — not just the technical delivery, but the business impact, the stakeholder alignment, and the operational follow-through.

At Acko, this has meant:

• Full accountability for multiple major launches — from architecture to production to business metrics
• Owning system stabilization efforts — resolving historical data issues and achieving reporting accuracy alignment with Finance and Compliance teams
• Handling partner escalations independently — with proactive root cause analysis and closure
• Shifting the engineering culture from dependency-based to accountability-driven delivery

I've learned that accountability isn't about being responsible when things go right. It's about being the person who steps up when things go wrong — the partner escalation at midnight, the compliance issue that needs immediate attention, the production incident that requires judgment calls under pressure.

The principle: Trust is built through consistent ownership. When your team, your stakeholders, and your partners know that you own the outcome — not just the sprint ticket — everything else becomes easier. Accountability is the foundation that makes predictability, technical depth, and team growth possible.