Quality with ownership
QA sign-off, structured regression cycles, and stronger automated testing.
Head of Solutions Engineering · PMC
I lead 30+ engineers across development, QA, and automation, with responsibility for engineering excellence, delivery, and release ownership.
Engineering leadership · Vadodara, Gujarat, and across India

30+ engineers
Development · QA · Automation
PMC · 2025 – Present
Current focus
QA sign-off, structured regression cycles, and stronger automated testing.
A shared, spec-driven playbook with people accountable for decisions and approvals.
Developing technical leads, QA leads, and release management to make evidence-based decisions.
A delivery decision
When a feature arrived late in planning, we moved it to a separate release. The main release shipped on schedule, and the feature followed after QA sign-off.

Leadership in practice

AI in the SDLC
How I guided AI adoption across requirements, architecture, development, QA, and review, with people accountable for decisions and release quality.
Read the case study: From ad hoc AI use to spec-driven delivery
Engineering excellence
How mandatory QA sign-off, structured regression testing, and a deliberate scope decision protected release commitments and strengthened team ownership.
Read the case study: Making quality ownership part of every releaseAbout
I have spent more than a decade building and leading engineering teams. What I keep learning is that great products come from teams that trust each other, understand the real problem, and feel ownership over the outcome. My job is to create the conditions for that to happen more often.
I started as an individual contributor, moved into mobile architecture, then engineering management, and now lead solutions engineering at PMC. That path matters because I have been the person receiving unclear direction, and I have been the person giving it. Both perspectives shape how I lead now.
I am happiest in the messy middle: business pressure, technical debt, team dynamics, and delivery risk all colliding at once. Those moments force the best conversations. I try to turn what we learn from them into habits the team can repeat.
The themes that keep showing up in my work are simple: make the work visible, have honest conversations early, mentor people into decision-makers, and use new tools only when they actually help. Nothing fancy — just consistency applied with care.
How I mentor
The best engineers I know are not the ones who memorize the most patterns. They are the ones who can look at a messy situation, ask the right questions, and choose a sensible path. That is what I try to grow in people.
I do not want people waiting on my answer. I want them to understand the context, weigh trade-offs, and decide. My role is to make that safer to try.
Ownership is not about blame. It is about caring whether the thing actually works. I push people to look past their ticket and see the customer, the team, and the business.
A great idea nobody understands is not a great idea yet. I coach engineers to write, speak, and reason in ways that other people can follow.
Leadership areas
Aligning people, priorities, and technical decisions so the team knows what matters and why. Less noise, more forward motion.
Coaching engineers to move beyond tasks and become people who can own decisions, explain their thinking, and lift others.
Focusing on what actually changes for the customer and the business, not just what ships. Progress over motion.
Asking why we do things this way, and whether there is a better way. Then proving it with execution, not just opinions.
Connecting architecture and product choices to real constraints. I like decisions that hold up six months later.
Protecting quality before it becomes a crisis and building habits that do not fall apart when deadlines get tight.
AI-assisted delivery
I am interested in AI where it actually makes engineering better: clearer discovery, less repetitive documentation, sharper reviews, earlier quality signals, and delivery health you can see without digging.
The goal is not to replace engineers. It is to remove friction so they can spend more time thinking. That means starting small, measuring honestly, and never handing off accountability.
AI should help people reason, review, test, document, and unblock work. If it creates noise or hides decisions, it is not helping.
I want to see it in release confidence, fewer escaped defects, faster reviews, or clearer specs. Good stories are fine; proof is better.
Before scaling, be clear about what AI can touch, where a human must review, and what should never be delegated.
Find the repeated friction: slow reviews, missing docs, unclear requirements, quality gaps, or reporting that takes too long.
Run a small experiment with one team or workflow. Learn what works and what breaks before telling anyone else to adopt it.
Measure what changed: predictability, defects, review time, or how quickly the team learns. Be honest if the answer is 'not much'.
Only expand once there are clear guardrails and someone owns the outcome. Adoption without ownership creates mess.
Experience
I lead 30+ engineers across development, QA, and automation, with responsibility for engineering excellence, delivery, and release ownership. My remit includes engineering practices, hiring decisions, budget allocation, mentorship, and AI adoption.
My focus is building an organization that delivers reliably and makes sound decisions at every level. I established QA sign-off as a release requirement, strengthened sprint and release regression testing, and increased investment in automation. When delivery commitments and quality requirements compete, I work with the team to make deliberate scope and sequencing decisions. In one example, we protected a scheduled release by moving a late-added feature into a separate release, allowing both to ship with completed QA.
I’m also leading the adoption of AI across the software development lifecycle. We progressed from individual developer experimentation to a shared, spec-driven delivery playbook covering requirements, architecture, implementation, testing, and review. I set the direction, guide adoption, and establish expectations for measurement, while teams retain responsibility for decisions and approvals.
Developing leaders is central to this work. I coach technical leads, QA leads, and release management to own outcomes, resolve blockers, and make decisions using evidence. By combining clear expectations with trust and constructive learning from mistakes, I’m helping the organization operate with greater independence and accountability.
At Bounteous I sat between architecture, clients, and delivery. I translated business goals into technical direction, helped teams keep quality under pressure, and stayed close enough to the code to make practical calls. With clients like Shake Shack, Texas Roadhouse, AirMiles, and University of Phoenix, the challenge was always the same: understand what the customer actually needs, then build something real around real constraints.
I joined Onlia while the company was shifting from heavy offshore reliance to stronger in-house ownership. I learned the architecture, understood the delivery model, and helped build a cross-functional team of developers, QA, and designers. The role grew from mobile architecture into broader solution thinking, Azure improvements, and the management habits needed to keep quality and velocity as the team scaled.
West is where I started to think of myself as a leader, not just a strong engineer. I owned technical direction for large-scale iOS and Android products, modernized platforms, and improved engineering health. When I moved into management, I realized the product is only as strong as the people building it. Trust, coaching, accountability, and team well-being became just as important as code quality.
My first PMC chapter took me from writing code to leading teams. I worked on Store Enabler and retail POS SDKs, where technical decisions connected directly to customer workflows in stores. It taught me an early lesson: your work is not done when the code is written. It is done when the solution works reliably for the person using it.
This phase was about breadth. Encrypted financial apps with NFC, Mac desktop software tied to BlackBerry devices, cross-platform mobile work across iOS, Android, and Flash. It gave me the technical foundation I still use: respect platform constraints, care about security, and never ignore performance on real devices.
Sardar Patel University, Vallabh Vidyanagar
Sardar Patel University, Vallabh Vidyanagar
In their words
Engineering Leadership
“Valay is both highly knowledgeable and skilled as a developer and a leader. He works collaboratively across QA and product teams, stays calm under pressure, and consistently provides multiple options to resolve complex issues. I would highly recommend him.”
Problem Solving & Outcome Focus
“Valay never shies away from a problem. He is always the first to suggest a solution and works collaboratively to get it resolved. He is goal-oriented, forward-thinking, and a strong problem solver.”
Clarity & Thinking
“Valay has a rare ability to bring the words in documents and the thoughts in people's heads to life. He is a tech enthusiast, problem solver, and the go-to person when clarity is needed.”
Root-Cause Mindset & Mentorship
“Valay focuses on understanding the root cause of problems and brings solutions, not just issues. He is a supportive team lead who motivates and helps teams move forward.”
Skills & technologies