The work behind the resume line — what the situation actually was, what I did about it, and what changed as a result.
Product OwnershipInheriting the Fire: Stabilising an HRMS in Production
Shyam Steel / Shyam Future Tech · Product Owner — SFT Evolve
Feb 2026 – Present
An HRMS had reached enterprise tenants before it was stable, and escalations arrived wherever a client could find someone to tell. The fix was root causes, an escalation matrix, and a team that stopped dreading the product.
Read the full story↓
Situation
SFT Evolve, the group's multi-tenant HRMS, had reached external enterprise tenants before it was stable. The product I inherited carried functional defects in its attendance and payroll calculation logic — the two areas a workforce notices immediately — so tenants were openly frustrated, and escalations arrived unstructured, reaching whoever a client could get hold of rather than anyone accountable for resolving them.
Action
Appointed Product Owner in February 2026, I took personal ownership of every escalated account and put a stabilisation plan in front of each one, holding confidence through visible progress rather than promises. With the cross-platform teams I separated true defect classes from configuration and data issues so that fixes stopped recurring — the calculation logic behind attendance and payroll was diagnosed and corrected rather than patched per complaint — then built the machinery the product had never had: an escalation matrix, and customer support channelled through a Freshdesk ticketing system with owned queues and SLA reporting in place of scattershot escalation paths. I raised the resourcing and structural gaps with leadership rather than absorbing them quietly, and worked on the team's own relationship with a product they had come to associate with firefighting.
Result
The attendance and payroll calculation defects were remediated, the product stabilised, the escalated tenants were retained, and the escalation matrix and ticketing channel remain the operating model. The work is ongoing.
Product OwnershipEscalation ManagementCross-Team LeadershipSupport Operations
Client LeadershipClient Escalation to Technology Partnership
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
Dec 2024 – Present
Inherited an escalated high-value US client engagement without technical ownership — and turned it into a collaborative technology partnership with an expansion roadmap.
Read the full story↓
Situation
When I joined in December 2024, I inherited a portfolio that included a high-value US logistics and delivery client whose relationship was already deeply escalated. No dedicated technical manager had owned the engagement: requirements weren't translating into deliverables, ownership was unclear, and every interaction had become an escalation.
Action
I refused to treat it as a communication problem. I diagnosed the underlying system — requirements interpretation, application capabilities, delivery process, and ownership gaps — then established myself as the single technical point of ownership and deliberately reset the relationship model: from client-versus-vendor to one technology team working toward the client's business outcome. I also contributed to the platform directly: it had no proper real-time architecture, so I implemented live driver location and movement tracking on socket.io — the operational visibility the application had been missing. Once stable, I mapped the wider ecosystem, identified expansion opportunities across automation, integrations, and analytics, and proposed a predictive-AI direction to evolve the platform from transactional management toward predictive decision support.
Result
The engagement moved from escalation calls to partnership conversations — delivery matched expectation, and the client renewed and continued the relationship past its original term. Stabilization converted into a concrete expansion dialogue, with predictive AI proposed as the strategic next step.
Client RecoveryDelivery GovernanceAccount ExpansionAI Strategy
TransformationEnterprise SaaS Modernization Across 12+ Platforms
Shyam Steel / Shyam Future Tech · Platform & SaaS Transformation Lead
Dec 2024 – Present
Re-architecting legacy systems into secure multi-tenant ecosystems — with centralized authentication and governance that cut delivery cycle time by 30%.
Read the full story↓
Situation
The group's digital estate spanned 12+ internal and client-facing platforms built as disconnected legacy systems — no shared authentication, no delivery governance, unpredictable releases.
Action
I led the modernization program: engineered centralized authentication for the SFT Warehouse ecosystem (SSO, RBAC, tenant-level authorization), institutionalized product governance — gap assessments, SOP standardization, release management, risk controls — and scaled the engineering capability by enabling 15+ cross-functional resources on Scrum practices and SaaS architecture patterns.
Result
Delivery cycle time reduced by 30%, release predictability improved by 40%, and the platform suite now operates as a secure, governed multi-tenant ecosystem rather than a collection of legacy systems.
Multi-Tenant SaaSSSO & RBACDelivery GovernanceDevSecOps
Client LeadershipDefending Delivered Work With a Paper Trail
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
Dec 2024 – Present
A US client disputed payment for work that had been delivered. The defence was the delivery record itself — reconstructed, evidenced, and walked through in a conversation rather than argued through a payment platform.
Read the full story↓
Situation
A US client raised a payment dispute claiming that work had not been delivered, despite a signed statement of work and completed sprint demonstrations. At stake were both already-earned revenue and the working relationship behind it.
Action
Rather than argue inside the payment platform's formal channel, I reconstructed the entire delivery timeline into a single evidence pack — commit history, sprint demonstration recordings, chat approvals and email sign-offs — and called the client directly to walk them through it. The conversation was framed around what had been asked for, what had been shown, and when, rather than around who was at fault.
Result
The dispute resolved in our favour and the earned revenue was protected, removing a financial and reputational risk from the account. The durable lesson is structural: a delivery record kept well enough to serve as evidence is a record that ends disputes before they need defending.
Client ConflictDelivery DocumentationContractual EvidenceRevenue Protection
TransformationWinning the Architecture Argument With a Prototype
Shyam Steel / Shyam Future Tech · Platform & SaaS Transformation Lead
Dec 2024 – Present
Engineering wanted to keep per-product authentication; the platform needed centralised SSO. The disagreement was settled by measurement rather than mandate — and the team ended up championing the approach it had resisted.
Read the full story↓
Situation
Engineering wanted to keep product-specific authentication across the SaaS suite, while the platform direction called for centralised SSO with tenant-scoped RBAC. To the team, centralisation read as added complexity and slower velocity — a reasonable position, and not one that a mandate would have changed.
Action
I built a trade-off matrix across security posture, user experience, migration cost, velocity and audit readiness, then ran a workshop where engineering prototyped both approaches at skeleton level and measured the actual effort instead of estimating it. The measurement showed centralisation costing more upfront and considerably less to maintain, and producing ISO 27001 access-control evidence as a by-product rather than as a separate exercise.
Result
Engineering championed the approach it had opposed. Centralised SSO, RBAC and tenant-level authorisation shipped across the product suite, so that tenant users and admins reach every subscribed product through a single login — and the decision has not been re-litigated since.
SSO & RBACArchitecture DecisionsInfluence Without AuthorityTrade-Off Analysis
People LeadershipScrum Without a Mandate
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
Dec 2024 – Present
Structured delivery spread across 12+ platform teams without any authority to impose it — because the measured results made other teams ask to be included.
Read the full story↓
Situation
Engineering teams ran delivery ad hoc: no consistent cadence, uneven backlog hygiene, no shared definition of done. As a newly joined Senior Technical Project Manager I had no formal mandate to impose Scrum on any of them — and imposing it would have bought compliance rather than adoption.
Action
I began where adoption was voluntary rather than where the problem was worst: structured sprints with explicit commitments, stand-ups, retrospectives and a shared definition of done. Then I measured predictability instead of asserting improvement, took that data to engineering leadership review, and let adoption scale by demand-pull as other leads asked to be included.
Result
Structured delivery reached 12+ platforms, 15+ cross-functional resources were enabled on Scrum practices and SaaS architecture patterns, and release predictability improved by 40%. Adoption came from the teams themselves, which is why it held after the attention moved elsewhere.
Influence Without AuthorityScrum EnablementDelivery PredictabilityChange Adoption
SecurityMoving Tenant Boundaries Out of the Client's Hands
Shyam Steel / Shyam Future Tech · Platform & SaaS Transformation Lead
Dec 2024 – Present
In a multi-tenant platform, a tenant boundary enforced by a value the client controls is not a boundary. It was moved to where the client cannot reach it.
Read the full story↓
Situation
In multi-tenant SaaS, the boundary between one tenant's data and another's is the security model. Any part of that boundary that depends on a value the client supplies — a query parameter, a request-body field — is a boundary in name only, and it will eventually be found, either by an auditor or by an accident.
Action
I moved tenant validation off client-controlled parameters and onto server-enforced middleware applied on every read, hardened the surrounding access controls alongside token-based session architecture, and made authorisation review a standing gate for tenant-scoped endpoints rather than something done when it occurred to someone.
Result
Server-side authorisation became the default pattern across the suite and the platform's multi-tenant access controls were measurably hardened — which also produced the access-control evidence ISO 27001 asks for, without a separate exercise to generate it.
Multi-Tenant SecurityRBACServer-Side AuthorisationAccess Control
Product OwnershipHolding a Launch Date With Arithmetic
Shyam Steel / Shyam Future Tech · Product Owner — SFT Travel Desk
Dec 2024 – Present
Finance wanted a custom approval flow before launch. The arithmetic said ship — and the arithmetic, presented one to one, is what settled it.
Read the full story↓
Situation
As SFT Travel Desk approached launch, finance pushed for a custom multi-level approval flow that would have delayed it. The request was reasonable on its own terms and came from a level of the organisation that does not usually receive a counter-proposal.
Action
I ran the arithmetic both ways. Launching on time realised the full approval-turnaround improvement for the entire employee base immediately; the custom flow added marginal benefit for a far smaller group at the cost of that delay. I recommended shipping the core on schedule with the finance flow as a committed fast-follow, put the fast-follow date in writing, and walked the finance side through the numbers one to one rather than presenting them in a room.
Result
The platform launched on schedule and delivered a 40% reduction in approval turnaround. The transferable part is the method rather than the outcome: an unpopular recommendation becomes acceptable when the arithmetic is visible and the deferred work is committed in writing.
Product OwnershipStakeholder ManagementData Over RankSFT Travel Desk
Engineering GovernanceThe Gate That Caught What Review Missed
sourishmukherjee.com — personal platform · Author & Maintainer
2026
Rebuilding this site produced a governance system rigorous enough to catch a defect that source review had already passed over — and the gates were negative-tested, because a gate that has only ever passed proves nothing.
Read the full story↓
Situation
Rebuilding this site during an active job search surfaced two defects at once: the live experience section was rendering template placeholder cards, and the published metadata carried content that the résumé strategy deliberately anonymises. Fixing both would have taken an afternoon. Fixing them so that the whole class of defect became structurally impossible was the harder and more useful problem.
Action
I authored a binding project constitution covering evidence-based content, publish gates, confidentiality law and an amendment procedure; implemented a typed content layer as the single source of truth, with a loader-level gate that makes unverified entries unrenderable by construction rather than by discipline; and wired mechanical release gates — type-check, lint, build, a recursive artifact sweep including sourcemaps, and a placeholder sweep. Then I negative-tested them, proving that each gate fails loudly against a known-bad artifact and correctly distinguishes a real finding from an encoding coincidence.
Result
The system caught what source-level review had missed — a generated artifact still carrying pre-fix content, which review had passed over because review had been looking at the source. It was remediated, recorded as a decision, and then eliminated as a failure class rather than patched. Every incident since has produced a decision entry instead of a silent fix.
Governance as CodeVerification DisciplineRelease GatesAI-Assisted Engineering
GovernanceISO/IEC 27001:2022 with Zero Major Non-Conformities
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
2025 – 2026
Directed security governance alignment across the delivery lifecycle — audit-ready, with zero major non-conformities.
Read the full story↓
Situation
Aligning an active multi-platform delivery organization to ISO/IEC 27001:2022 means embedding governance into live workflows without stalling delivery.
Action
I directed the alignment across the product delivery lifecycle — mapping controls to actual delivery workflows, institutionalizing the SOPs and risk controls that make audit readiness a property of the process rather than a scramble before the audit.
Result
Audit readiness achieved with zero major non-conformities, and governance that delivery teams operate as routine rather than exception.
ISO 27001Audit ReadinessRisk Management
GovernanceThe Statement of Applicability That Failed First
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
2025 – 2026
The first pass at the ISO 27001 Statement of Applicability missed tenant-specific risk controls and failed internal pre-audit. The rework became the template every cycle after it used.
Read the full story↓
Situation
The first pass at the ISO/IEC 27001:2022 Statement of Applicability missed tenant-specific risk controls and did not survive internal pre-audit. The certification timeline did not move to accommodate that, so the rework had to happen inside the schedule the original had already consumed.
Action
I broke Annex A into domain workstreams with named owners and weekly control-evidence reviews, and brought in an external pre-audit review partway through so that gaps surfaced before the formal audit rather than during it. Each domain was then iterated against those findings rather than against the original assumptions.
Result
The formal audit was cleared with zero major non-conformities, and the reworked Statement of Applicability became the template for subsequent cycles. The honest lesson — that multi-tenant control scope was underestimated on the first pass — is now a standing point in compliance reviews rather than a thing quietly not mentioned.
ISO 27001Audit ReadinessFailure & RecoveryMulti-Tenant Controls
AI & InnovationTeaching the Toolchain to Read Regulations
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
2025 – 2026
Regulatory alignment across a 12+ platform portfolio is an interpretation workload long before it is an engineering one. LLM tooling was applied to that workload — with the verification loop kept human.
Read the full story↓
Situation
ISO/IEC 27001:2022 alignment across a portfolio of 12+ platforms generates a heavy interpretation-and-documentation load well before any control is implemented: regulatory language has to be mapped to controls, controls to policies, and policies to the evidence an auditor will eventually ask for.
Action
I led development of an AI-assisted compliance intelligence framework built on LLM tooling (Claude), applied to accelerating regulatory interpretation, policy mapping and governance documentation workflows. The verification loop stayed human by design — audit evidence that nobody reviewed is not evidence, whatever produced it.
Result
The framework is part of the governance toolchain supporting alignment across the portfolio. Its quantified effect — time saved per document, coverage achieved — is deliberately not claimed here until it has been measured.
AI-Enabled DeliveryLLM ToolingISO 27001Governance Documentation
Crisis RecoveryRecovering a Suspended Production Mobile Platform
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
2025
Resolved a Google Play publisher suspension caused by an expired developer-account registration, safeguarding platform continuity and the revenue that depended on it.
Read the full story↓
Situation
A publisher suspension on Google Play threatened the continuity of delivered React Native applications — and the revenue streams running through them. The cause was administrative rather than editorial: the developer account's registration had expired. No app policy or content issue was involved, which mattered, because a suspension notice invites everyone to assume otherwise.
Action
I led the resolution end to end: establishing the actual grounds rather than working from the assumption of a policy fault, restoring the account's registration standing, assembling the appeal evidence, and driving the reinstatement process while keeping stakeholders aligned on risk and timeline.
Result
Reinstatement came through in 10 working days. The applications returned to production distribution, and platform continuity and revenue were safeguarded.
React NativeGoogle PlayCompliancePlatform Continuity
Engineering GovernanceEngineering Governance: Bitbucket to GitLab
Shyam Steel / Shyam Future Tech · Senior Technical Project Manager
2025
Directed the enterprise repository migration that standardized CI/CD, access governance, and code quality gates across products.
Read the full story↓
Situation
Version control and delivery automation were fragmented on Bitbucket, with inconsistent access policies and no standardized quality enforcement across the product estate.
Action
I directed the migration to GitLab as a governance program, not a lift-and-shift: standardized CI/CD pipelines, access policies, structured release controls, and SonarQube-driven quality gates enforcing automated vulnerability detection and technical debt management.
Result
A single governed engineering platform — standardized pipelines, controlled access, and quality gates that made secure, predictable releases the default.
CI/CDVersion Control GovernanceDevSecOpsSonarQube
Healthcare (Regulated)Building a $3M+ US Healthcare Insurance Ecosystem
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
Architected a regulated B2B enrollment and claims ecosystem that onboarded 21+ US insurers and processed 20,000+ healthcare records weekly.
Read the full story↓
Situation
US healthcare insurance runs on precise, regulated data exchange between employers, insurers, TPAs, and claims engines — an ecosystem where integration failures have compliance consequences, not just technical ones.
Action
I architected and delivered the enrollment and claims management platform end to end: scalable enrollment, eligibility validation, and policy lifecycle frameworks; secure EDI (834/835/837) and SFTP integrations; and institutionalized PHI data governance ensuring auditability and traceability across every workflow.
Result
The ecosystem onboarded 21+ US insurance carriers, processed 20,000+ healthcare records weekly with transactional reliability, and generated over $3M in revenue across regulated environments.
US HealthcareEDI 834/835/837PHI GovernanceB2B Integration
Healthcare (Regulated)Making "Universal" Buildable
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
A client asked for a universal insurer onboarding system. Every insurer defined its fields differently — so the answer turned out to be configuration, not more code.
Read the full story↓
Situation
The ask was "a universal onboarding system for insurers". The reality underneath it was that every insurer defined eligibility and enrolment fields differently, exchanged files on its own cadence, and formatted dates its own way. Building literally to the word "universal" would have produced either an unbuildable abstraction or one bespoke parser per insurer.
Action
I interviewed the client's product lead to surface the assumptions nobody had stated, mapped the actual shape of the variation across the first insurers' specifications, and designed a configuration-driven mapper rather than hardcoded parsers — then validated that abstraction against three insurers before generalising it any further.
Result
The same architecture carried 21+ US insurance carriers onto the platform and held without redesign across a four-year engagement. What made it work was the discipline of refusing to generalise until the variation was actually understood.
Requirements DiscoveryConfiguration-Driven DesignInsurer OnboardingUS Healthcare
Healthcare (Regulated)Engineering PHI Out of the Places It Should Not Reach
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
Protected health information leaks most easily where nobody is looking — debug output, logs, the sinks those logs drain into. The controls were built so that the mistake becomes hard to make.
Read the full story↓
Situation
In a regulated healthcare platform, the controls that matter are not only the ones sitting on the data path a designer drew. Protected health information escapes most easily through incidental paths — debug output, application logs, and the sinks those logs drain into — precisely because nobody is watching them.
Action
The response was structural rather than procedural: a redaction-aware logger that strips defined PHI fields by default, an audit of the existing log sinks, an automated pre-merge scan for PHI field names appearing inside log statements, and a HIPAA technical-safeguards refresher so the team understood why the gate existed rather than merely that it did.
Result
PHI data governance — HIPAA-aligned security, auditability, traceability and regulatory compliance across healthcare workflows — became a property of the toolchain rather than of anyone's individual vigilance, and the redacting logger entered the reference architecture for later builds.
PHI GovernanceHIPAAPrevention EngineeringPre-Merge Gates
People LeadershipThe Engineer Who Wouldn't Ask
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
An engineer missing sprint commitments was not a performance problem. They had been handed unfamiliar territory and were too embarrassed to say so.
Read the full story↓
Situation
A junior engineer had missed sprint commitments three sprints running. The work was sound whenever it arrived — it simply was not arriving. Handled as a performance conversation it would have gone one way; handled as a question, it went another.
Action
I ran a 1:1 built on open questions rather than a ticket review, and the actual cause surfaced quickly: they had been assigned integration work in territory they had never touched, were teaching themselves in the evenings, and were too embarrassed to ask for help. I paired them with a senior engineer, set smaller and more explicit commitments, and made asking for help a stated expectation rather than an admission of inadequacy.
Result
Sprint commitments were met again, and the engineer went on to work confidently in the area that had blocked them. The wider pattern — diagnose before judging — is what Mentor of the Year recognised, awarded across two consecutive years, 2023 and 2024.
CoachingRoot-Cause EmpathyTeam DevelopmentMentorship
Client LeadershipSequencing More Demand Than Capacity
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
More insurer onboarding demand than the quarter could hold. The answer was an honest published sequence — and an adapter that made everything after it cheaper.
Read the full story↓
Situation
Insurer onboarding demand ran ahead of the capacity available to deliver it, with commitments already made in conversations the delivery team had not been part of. Every option that involved promising everything led to the same place.
Action
I scored each onboarding on revenue impact, technical complexity and strategic leverage, split the queue into a committed tier and a transparently deferred one, and briefed the commercial side with the scoring rather than with a refusal. Looking across the deferred tier surfaced a repeating integration pattern, which I scoped as a reusable adapter instead of letting it be rebuilt bespoke each time.
Result
The committed tier delivered on schedule, and the deferred work was sequenced openly rather than quietly missed. The platform went on to onboard 21+ US insurance carriers — a number that was reachable precisely because the repeating work had been turned into architecture.
PrioritisationSales AlignmentCapacity PlanningReusable Architecture
Client LeadershipThe No That Wasn't a No
Aeonix Research & Innovations LLP · Product Architect & Senior Software Engineer
Dec 2020 – Dec 2024
Late scope requests do not need a refusal. They need the trade-off made visible and the decision handed back to the person entitled to make it.
Read the full story↓
Situation
Late requests arrive mid-sprint in every delivery relationship: genuine needs, arriving at the wrong moment, large enough to break commitments already made. Refusing outright protects the sprint and damages the relationship; absorbing them silently protects the relationship and damages everything already committed.
Action
The pattern I settled on refuses that choice. Instead of saying no, I put the effort estimate, what the request would displace, and three clean options — defer it, descope something else, or reduce the new request's own scope — on a single page, and let the client decide with exactly the information I had.
Result
Handing back an informed choice consistently produced better decisions than defending a boundary, and the framing became the default answer to late scope asks. The client keeps their authority; the commitments keep their meaning.
Client NegotiationCommitment ProtectionTrade-Off FramingDelivery Governance
Client LeadershipMaking Accreted Scope Visible Before It Became Free
Aeonix Research & Innovations LLP · Product Architect
Dec 2020 – Dec 2024
A government monitoring platform grew one small request at a time. Naming the accumulation — rather than absorbing it — protected both the launch date and the relationship.
Read the full story↓
Situation
A government environmental-monitoring engagement grew by accretion: air-quality dashboards, then noise monitoring, then citizen grievance intake, alerting, multi-language support. Each request was small enough to say yes to on its own. Together they described a different project from the one that had been costed.
Action
I introduced a visible change-request log carrying an effort estimate against every item, and presented the cumulative picture at steering rather than the individual asks — then proposed a phased split, holding the highest-impact scope in the committed phase and bundling the remainder into a separately scoped follow-on.
Result
The committed phase launched on time, and the accumulated scope was made visible and separately scoped rather than silently absorbed. Naming the accumulation early is what stopped it becoming either a missed date or an unbilled gift.
Scope GovernanceChange RequestsCommercial AcumenGovTech
TransformationMeasure First, Then Propose
Wipro Limited · Associate Support Engineer
Aug 2019 – Sep 2020
Repetitive monitoring work was consuming engineer time and the conversation had turned to hiring. Measuring where the time actually went changed the answer.
Read the full story↓
Situation
Manual network-monitoring work on a major UK telecommunications engagement was consuming roughly 40% of engineer capacity across a network of 10,000+ enterprise devices, and the discussion had turned towards adding headcount.
Action
Before proposing anything I sampled where the time was actually being spent, by task category, across the team; identified the highest-volume repetitive tasks; and prototyped Bash automation against the worst of them so that the saving could be measured rather than argued. Only then did I put the comparison — automation against hiring — in front of anyone.
Result
The automation was rolled out, manual intervention fell by 30%, and incident-response efficiency improved with it. The work was recognised with Wipro's Operational Excellence Award, the Pragati Trophy. The habit outlasted the job: measure first, then propose.
AutomationData-Driven DecisionsNetwork OperationsEarly Career
FoundationThe Years Before the Résumé Begins
Confidential roles (pre-2018) · Confidential Secretary · Confidential Assistant
2007 – 2018
The professional record here opens in September 2018. Eleven years of working life came before it, in roles whose defining requirement was discretion — and a computer science degree earned alongside the last of them.
Read the full story↓
Situation
The professional record on this site begins in September 2018, by deliberate rule. Before it sit eleven years in roles named only by their function: Confidential Secretary from 2007 to 2014, and Confidential Assistant from 2014 to 2018 — work whose defining requirement is discretion, and which is therefore described here by title and period only.
Action
The change was made while the earlier career was still running rather than after it had ended: a B.Sc in Computer Science from the University of Calcutta, earned between 2015 and 2018, concurrent with the final years of that work. Competitive martial arts ran alongside both, recognised with international and national silver medals in 2017.
Result
The engineering career that followed — technical instruction at Aditya Group, then network operations and automation at Wipro, then the healthcare platform work at Aeonix, and now senior technical project management — began at a point when most careers are consolidating rather than restarting. The detail of the confidential years stays where it belongs; the fact of the reinvention does not.
ReinventionDisciplineCareer Change
