2026-08-06
Who I Am, Beneath the Job Title
My resume answers 'what have you worked on.' This essay answers the question interviews rarely ask but that matters more: why I'm still at the same company after 7 years, and what I actually put on the line every time I hit deploy.
- personal
- career
- introduction
Scan the numbers and here's the shape of it: 7 years at one company. 3 promotions. 1 payroll system that determines whether more than 800 people get paid correctly every month. That's the version my résumé answers — the "what have you built" version.
There's a different question that almost never comes up in an interview, even though I think it matters more: why does someone stay seven years in the same place, and what actually changes between one title and the next, besides the number on the paycheck.
My name is Muhammad Royhan, and this is my attempt at an honest answer.
I Didn't Plan Any of This
I got into software engineering for a fairly unromantic reason: the field looked crowded already, and I had no interest in competing with people who'd fallen in love with it long before I showed up. Moving Bytes Digital opened the door anyway, back in 2019 — not because I walked in with some grand vision, but because the opportunity existed and I took it.
What I didn't expect: once I was in, the real question stopped being "do I enjoy writing code" and became "can I actually carry the weight of something other people's livelihoods depend on." That turned out to be a far more interesting question, and a much harder one to answer.
The Route: Junior to Tech Lead, Same Building the Whole Way
From June 2019 to now, my title has changed four times at the same company: Junior Software Engineer, then Software Engineer, then Senior Software Engineer, and since 2023, Tech Lead.
What actually separated each stage wasn't the salary bump or the new line on a business card. As a junior, I was handed running code and told not to break it. As a senior, I started getting trusted with projects from zero to handover — with no more senior engineer standing behind me as a safety net. As Tech Lead, the question shifted again: no longer "can I finish this," but "can I get two other people to finish this correctly, without me having to step in every time something wobbles."
All three shifts happened in the same office, at more or less the same desk. What changed was how far the consequences of my mistakes could actually travel.
The Domain I Chose: Numbers That Aren't Allowed to Drift
Look at the tech list — React, Next.js, Node.js, Express, NestJS, PostgreSQL, MySQL, occasionally Flutter for mobile — and it reads like thousands of other fullstack engineers' stacks. What sets the work apart isn't the tools; it's the category of problem I kept choosing to point those tools at.
I built a payroll system for a company with 800+ employees. I owned an employee credit system for a rural credit bank from the first line of code through the day it was handed off. Before that, I worked on an ERP project and a rental marketplace that were both already running before I ever touched them.
One thread runs through all of it: these aren't systems where a cosmetic bug is the worst-case outcome. A wrong number here means a paycheck that lands late, or a loan balance recorded incorrectly against someone's name. A miscalculation isn't a bug report — it's a consequence someone feels in the real world, usually before you do.
What Keeps Me Here Isn't Love for the Code
I'll say this plainly because it's less inspiring but more honest: I haven't stayed seven years because I'm passionate about writing code. I've stayed because the longer I'm in this field, the more people end up depending on my output being correct — and strangely, that weight makes me more serious about the work, not more eager to leave it.
The moment that stuck with me most: working on the employee credit system in 2022, it hit me that a wrong figure on my screen wasn't an edge case to patch quietly. It was someone's actual debt, recorded wrong, and that person would find out before I did.
As Tech Lead, the Job Is Somehow Less About Code
Since 2023, most of my working hours aren't spent staring at an editor. I run 2 projects at once with 2 software engineers, from planning through production release. I've designed backend architecture patterns that later got reused across client projects — measurably cutting the setup time for new work.
Clients also come to me first when something technical goes sideways, and part of my job is translating what they're asking for into tasks the team can actually execute. Outside that routine, between March and June 2025, the company handed me a cross-country initiative — a chance to see whether the way I work still holds up against engineering standards from other countries.
My favorite part of this role isn't the authority — it's the field of view. As an individual contributor, I only ever saw one slice of the system. As a lead, I watch how one small decision on project A quietly determines how fast project B can move six months later.
Working Principles, Not Wall Art
There are two ways of thinking I rely on daily, and I'm deliberately not calling them a "life philosophy" — that sounds far too grand for something that grew out of practical habit.
The first: I try to see a system as a web of things pulling on each other, not a stack of modules that each stand alone. A small change to a tax rule can ripple into a report that looks completely unrelated — and if I'm only staring at one module while debugging, I'll miss it entirely.
The second: before I let myself get frustrated about something, I've trained myself to ask, "can I actually change this, or can I only design my response to it?" A client's deadline, a decision a previous team already locked in, whether some third-party API happens to be down right now — I rarely have any control over those. What I control is how prepared my system is to absorb them anyway.
Why I'm Writing Any of This Down
This site isn't a résumé dressed up to look more interesting. It's where I unpack the reasoning behind decisions — why I picked a particular architecture for the payroll system, why this website itself was built the way I describe in a separate essay, and ultimately, what makes me confident that the systems I build deserve trust from people who've never even met me.
But all of it starts from the same place: seven years, one company, and a conviction that the most valuable thing I can leave behind in anything I build isn't speed or cleverness — it's clarity that survives long after I've stopped watching over it.