Rasel Mridha — Technical Project Manager with a Full-Stack Engineering Background

A project manager who cannot read the codebase runs on a translation layer. Every estimate arrives pre-interpreted, every risk arrives pre-summarized, and every "this needs two more weeks" has to be accepted or challenged on trust, because there is no independent way to check it. That dependency is invisible while a project is healthy and expensive the moment it is not.

The opposite gap is as common and gets discussed less. An engineer who can read every line in the repository often has no mechanism for holding scope when a client asks for a block of new features late in a program, no hiring pipeline when the team has to double, and no habit of telling a stakeholder that a date is at risk before the date is missed.

I work across that gap, and the difference shows up during a bad week. When a production VPS started dropping requests under load, I did not file a ticket describing symptoms and wait for it to be translated back to me. I profiled the server myself and tuned the Nginx, PHP-FPM and Redis layers until the numbers moved: average response time went from 4.2s to 0.6s, and the same server carried 3x its previous peak load. The client got a cause and a number rather than an apology and a new timeline. [NEEDS INPUT: the specific misconfiguration behind the VPS slowdown, and what was ruled out before tuning the existing server rather than scaling it]

That is the argument of this page. The engineering background is not a second service on offer. It is the reason the delivery decisions get made against evidence instead of relayed opinion.

The progression is documented rather than claimed. Web developer, internship, remote, March 2025 to May 2025. Full stack web developer, on-site, May 2025 to August 2025. Associate project manager, on-site, August 2025 to February 2026. Project manager, on-site, since January 2026. One company, Exprovia, in Rajshahi. Total tenure 1 year 5 months.

Four roles in 17 months is fast, and the fair question is whether the practice is deep or only quick. The answer I can evidence is the record those roles produced: 50+ client onboardings run directly in English, an engineering team taken from 7 to 20, and 11 delivery incidents documented end to end, each one carrying the decision made, the option ruled out, and what the choice cost.

The engineering work is not a parallel offer. It is the reason the project management is not run on translation. I wrote the kind of code I now schedule, and the estimates I hold teams to are the kind I have had to make myself.

An ECS container deployment failed silently in production during business hours and took the service down with it. CloudWatch pointed at the task definition, so the instinct is to fix the definition and redeploy. I rolled back to the last stable task revision first.

That cost something. The rollback discarded the work in the failed revision and the team had to run the deploy again. I ruled out fixing forward because a forward fix has an unknown duration — you learn how long it takes only once it works — and an unknown-length outage during business hours is worse than a known-cost rollback. Service was restored in 35 minutes. The task definition and IAM permissions were corrected afterwards on a normal deploy path, with health check validation and a deployment checklist so the same silent failure could not repeat. [NEEDS INPUT: exact root cause of the ECS failure as stated in the case study]

The same reasoning applied when the Stripe integration broke mid-launch and blocked every transaction. I restored the ability to take payments before pursuing a clean fix, because an hour of clean-fix time costs more than a temporary path does. Two hours to resolution, zero lost transactions. [NEEDS INPUT: the root cause of the Stripe failure and the specific preventive control added afterwards]

Day to day, reading the code changes four things. I weigh architecture decisions instead of ratifying them — a database change under peak load that took query performance up 80% was a decision I could evaluate rather than approve on faith. I size effort against the actual repository, which is most of why milestone dates hold. I mentor developers directly instead of routing coaching through a lead. And I can call feasibility in the room, with the reason attached, which lands better than "the team says no". [NEEDS INPUT: the specific change behind the 80% query performance improvement]

Turn the business goal into scope and dates. Every program begins by converting what the client is trying to achieve into sprint scope and milestone dates, so every ticket traces back to the outcome it serves. That mapping is also what makes scope defensible later. When a client asked for a block of new features late in a program, I ran a scope review with the original agreement and the new requests side by side, each carrying its impact on the committed dates, and negotiated a phased plan rather than refusing it or absorbing it quietly. [NEEDS INPUT: the outcome of that scope negotiation — whether the phased plan was accepted and delivered]

Build the system the team runs on, not the ticket queue. Taking a team from 7 to 20 is a systems problem before it is a hiring problem: the pipeline, the onboarding path, the delivery process and the mentoring structure have to exist before the people arrive, or each new hire slows the existing team down. The same instinct applies under pressure. When team velocity dropped 40%, rapid one-on-ones surfaced the blockers, I redistributed work to cut cross-team dependencies, and moved standups to a daily async format with acceptance criteria specific enough to work against. The recovered velocity was still holding 6+ months later. [NEEDS INPUT: what the velocity recovery cost — which work was cut, deferred or reassigned, and what was ruled out]

Stay in the code the team ships. In practice that means reviewing pull requests, holding an opinion in architecture discussions, and being able to tell whether a number is a people problem or a process problem. After 3 consecutive sprints of rising defect rate, the root-cause review pointed at test coverage gaps and acceptance criteria too loose to test against — not at developer capability. A stricter Definition of Done, pre-merge quality gates, and focused mentoring on the recurring patterns. [NEEDS INPUT: defect rate before and after the pre-merge quality gates]

Manual reporting and client updates were consuming 12+ hrs/week. I built an agent on the OpenAI API that pulls project data from ClickUp, summarizes it, and delivers formatted stakeholder reports through Slack, with a feedback loop so team corrections improve the next report. Weekly reporting time dropped by 80% and the team reclaimed 10+ hrs/week for delivery work.

The rules matter more than the model. The agent drafts; a person signs. It reports on data it can access and does not infer status it was never given. Corrections go back into the loop rather than into a private workaround. I ruled out letting it send unreviewed reports to clients, and that was not a technical limitation — a report that is confidently wrong costs more trust than ten manual reports cost hours.

The same rule governs AI-assisted code review and research synthesis during planning: the tooling shortens the distance to a draft, and accountability for what ships does not move. I measure AI the way I measure anything else in delivery — hours returned, defects caught, dates held. A tool that cannot show one of those does not stay in the process.

I am based in Rajshahi, Bangladesh, and I work remotely with clients inside and outside the country. [NEEDS INPUT: working-hours overlap offered to clients in other time zones]

Distributed delivery fails in predictable ways, so I run it against those failures. Decisions are written where the team and the client can both find them, which removes the class of problem where two people remember the same scope conversation differently. Status is visible rather than requested — shared dashboards for scope, risk and delivery state, so a stakeholder never has to ask in order to know. Standups are async and daily, because a team spread across schedules cannot afford a meeting that only works for one time zone.

During incidents the communication cadence tightens instead of going quiet. In a production outage, I opened an incident channel with named owners, ran engineering and client updates in parallel on a fixed cadence, and service was restored in 55 minutes. Clients rarely escalate over a problem. They escalate over silence during one. [NEEDS INPUT: what triggered the outage, if it can be described without identifying the client]

For an account that had already escalated over repeated delays and a communication breakdown, the repair was structural rather than apologetic: transparent milestone tracking, a weekly executive sync, shared dashboards for scope and risk, and a written ownership matrix across teams. [NEEDS INPUT: the outcome of that account after the communication repair — renewal, expansion, or neither — and what was ruled out in favour of the structural fix]

This one is a target, not a result. The engineering team at Exprovia went from 7 to 20. What I am actively working toward is a team of 100+ members by 2027, and I am stating it as a goal so it is not read as something already done.

I know where it gets hard, because the systems that carried the team to 20 will not carry it to 100. At 20 one person can still hold the delivery process in their head and know what every developer is good at. At 100 that arithmetic stops working, and the binding constraint moves from hiring throughput to the mentoring layer: you need leads who can run what I currently run, which means growing them deliberately rather than promoting the strongest individual contributors and hoping it transfers. Onboarding has to get shorter as the team gets larger, or every new hire costs the existing team more time than the last one did.

The on-time delivery record is the thing I am not willing to trade for headcount. If the choice comes down to hitting the number of people or holding the standard the work is delivered to, the standard wins. [NEEDS INPUT: the year-by-year growth plan toward 100+ by 2027]