Rasel Mridha at Exprovia: Technical Project Manager Experience

My remit is delivery across teams rather than a single project. I hold the scope, the dates, and the tradeoff between them, and I am the person who names which of the three moves when something slips.

The week is built around sprint planning and the conversations that feed it. I turn business goals into sprint scope and milestone dates, size the work with the engineers who will do it, and keep acceptance criteria specific enough that a ticket cannot be reinterpreted at review. Client and stakeholder management runs alongside that, conducted directly in English: status that is honest about a risk while it is still a risk, and scope conversations held early enough that there are still options on the table.

Hiring and mentoring are mine as well. I run hiring, the onboarding path a new engineer follows, and technical mentoring on architecture and code review for the developers on my teams.

I own production incidents. When a service goes down I run the response: owners assigned, a communication cadence set with the client, and the change that stops the repeat written up afterward rather than promised.

The rest is commercial: budget allocation across teams, effort and cost estimates, and the technical proposals that turn a prospect into a signed scope.

Every engagement starts with an onboarding conversation I run directly, in English: requirements clarification, scope agreement, and the risk conversation, from the first call to a signed scope. I have run more than 50 of these at Exprovia.

The same discipline carries into delivery. 100% on-time milestone delivery on the programs I led traces back to the onboarding call rather than to anything downstream: a risk named while the scope is still being agreed is one that gets designed around, and a scope change gets priced in front of the client instead of absorbed quietly partway through a sprint.

8 delivery incidents are documented as case studies. One of them, and the option it ruled out first:

During a Vercel-to-AWS migration for a client site, the engineer running it got sick partway through and a second developer took over mid-project. A missed environment variable crashed the live site while the client's campaign was already driving traffic to it. I have an email alert on every deployment, sent to myself directly, and it woke me at two in the morning. I ruled out rolling back, because by the time I was looking at the failure the missing variable was already identified rather than still unknown. A rollback would have cost the migration progress for nothing. I put visitors on a maintenance page first, then fixed the missing variable directly and redeployed. Service was restored in 35 minutes.

Project intake ran through a form, a hand-typed ClickUp task, a hand-written project document, and a manual developer handoff on every new project. I automated the mechanical steps: a form submission creates the ClickUp task and a project document from my own template automatically, and assigning a developer from Telegram creates the ClickUp assignment and notifies them. I still review every project and record a video brief myself before anything gets assigned. The automation moves data between tools, it does not decide what a project needs. Roughly 30 minutes saved per intake, by estimate, with dependency-related delays down roughly 20%.

The Exprovia engineering team went from 7 to 20 under my hiring and onboarding ownership. A team of 7 coordinates by proximity: everyone hears everything, and process reads as overhead. That stops working somewhere in the teens, and the failure mode is invisible until delivery quality has already slipped. So I built the structure in the order the company's size actually called for: onboarding first, an onboarding flow that hands a new engineer their environment, their first scoped piece of work, and a named person to ask, then a mentoring cadence that puts architecture and code review feedback in front of developers from someone who reads their code. A formal hiring pipeline was not part of it: the company was not hiring at the volume that would make a repeatable pipeline process worth building. Growth at that multiple is a systems problem before it is a recruiting problem.

The on-time figure is a scoping outcome rather than a heroics outcome. Dates hold when the estimate came from the engineers doing the work, when a scope change is priced in front of the client instead of absorbed quietly, and when the risk conversation happens in the sprint the risk appears rather than in the week of the deadline, which starts in the onboarding call, not after it.

Project Manager at Exprovia Rajshahi, Bangladesh. On-site, with remote delivery for clients inside and outside the country. Jan 2026 to Present

Associate Project Manager at Exprovia Rajshahi, Bangladesh. On-site. Aug 2025 to Feb 2026

Full Stack Web Developer at Exprovia Rajshahi, Bangladesh. On-site. May 2025 to Aug 2025

Web Developer, Internship at Exprovia Remote. Mar 2025 to May 2025

Total tenure at Exprovia: 1 yr 5 mos. Four roles, one company, seventeen months from first day as an intern to Project Manager. Exprovia is also the first job: there is no earlier employer, and no gap before it.

Education Diploma in Engineering, Computer Science, from Satkhira Government Polytechnic Institute Jan 2021 to Dec 2025. Grade 3.46.

The full-stack engineering background this role rests on (MERN, Next.js, PHP and WordPress, SQL and PostgreSQL, AWS and Linux server administration) was built in the two engineering roles that came before the PM ones, at the same company and on the same teams I now run delivery for.

That is the reason the delivery work runs without a translation layer. The architecture calls I review, the estimates I size, and the incident bridges I take are in stacks I shipped in myself, recently enough that the details have not gone stale.