During the last five years at Opal BPM, I provided technical leadership and mentoring to a team of 5–7 developers, establishing code-quality and system-design practices.
Opal BPM India Pvt Ltd — technical leadership, last ~5 years of tenure.
Technical Leadership & Engineering Philosophy
I spent nearly 10 years at Opal BPM, where I started as a Senior Java Developer and progressively took on technical leadership responsibilities. During the last five years of my tenure, I led a team of 5–7 developers while continuing to contribute hands-on to architecture and backend development.
5+ years in a technical leadership role · 5–7 developers led
Started as
Senior Java Developer → Lead Java Developer
Team led
5–7 developers (last ~5 years)
Opal BPM tenure
Sep 2015 – Apr 2025 · 9y 7m
The same verified roles as the Engineering Journey’s Career Timeline, isolated to one question: which of them carried verified leadership scope, and which didn’t. For the full role-by-role breakdown, see Engineering Journey.
Dec 2007 — Dec 2010
3 years
Software Programmer
Comnet Innovations Pvt. Ltd
Individual contributor role — no leadership scope on record for this position.
Dec 2010 — Mar 2014
3 years, 4 months
Programmer
PC Solutions Pvt. Ltd
Individual contributor role — no leadership scope on record for this position.
Apr 2014 — Aug 2015
1 year, 4 months
Senior Java Developer
TeamLease Services Pvt. Ltd
Individual contributor role — no leadership scope on record for this position.
Sep 2015 — Apr 2025
5+ years in a technical leadership role (last ~5 years of tenure)
Senior Java Developer → Lead Java Developer
Opal BPM India Pvt Ltd
Five maxims — each already paired with the one verified decision that put it into practice on the Architecture Gallery, not repeated here a second time. Titles only, so this reads as a summary of what’s demonstrated in depth elsewhere, not a duplicate of that page.
Direct mentoring and code-review-based standards are verified for the 5–7 developer team I led during the last five years at Opal BPM; the onboarding process and design-discussion format aren’t documented in my own words yet.
I established code-quality and system-design practices for the team as it scaled, rather than relying on ad hoc review.
I set code-quality standards for a 5–7 developer team as part of technical leadership during the last five years of my Opal BPM tenure.
During the last five years at Opal BPM, I provided technical leadership and mentoring to a team of 5–7 developers, establishing code-quality and system-design practices.
Opal BPM India Pvt Ltd — technical leadership, last ~5 years of tenure.
Incremental delivery and direct ownership of release/deployment are verified; the specific release-planning cadence, QA methodology, and risk-management process aren’t documented yet.
I delivered incrementally across nine-plus years at Opal BPM and through a distinct onshore/offshore delivery model at InterGlobe.
See it applied in a case study →I reduced mean time to resolution for production issues by 30% through direct ownership of triage.
TeamLease Services Pvt. Ltd, Apr 2014–Aug 2015.
Verified for business stakeholders (translating requirements into architecture), engineering (onshore/offshore delivery alignment), and clients (standardizing security across multiple independent deployments) — not yet documented for product or QA specifically.
I collaborated directly with cross-functional teams and stakeholders to translate business requirements into technical architecture at Opal BPM, and aligned onshore/offshore delivery with finance-domain needs at InterGlobe.
See it applied in a case study →Every architectural decision on record follows the same shape — a problem the system actually had, the options weighed, the trade-off accepted, and the decision made. The Architecture Decision Record fields below map onto that framework: Context is the problem, Alternatives considered are the options, and Consequences is the trade-off accepted.
I owned the architectural decisions behind the Enterprise Exchange Platform's 16-service decomposition and the Beckn Protocol Verification Adapter's state-machine design — decisions made and defended, not just implemented from a spec.
See it applied in a case study →What’s verified about how the team actually worked, day to day — not a values statement.