Early in my career, I described my work the way most engineers do: "I built a mobile app." "I managed a team of 5." "I led the migration project." Those statements are not wrong. But they are incomplete. They describe activity, not impact.
The difference between a strong senior engineer and a forgettable one is often not skill. It is the ability to connect technical decisions to business outcomes. To say not just what you did, but what changed because of it.
Over 20+ years, across startups, enterprise projects, fintech scale-ups, and freelance work, I went through a shift in how I think about my own contributions. The trigger was the Google XYZ framework — a deceptively simple template that forces engineers to stop describing work and start describing results.
The Google XYZ formula was popularized by Laszlo Bock, former Senior VP of People Operations at Google. It is designed to help engineers write better resumes, but its real value is deeper than that: it teaches you to think in outcomes.
X Accomplished [X] — Y as measured by [Y] — Z by doing [Z]
| Part | Question it answers | Example |
|---|---|---|
| X — The result | What improved? What changed? | Reduced production incidents |
| Y — The measure | By how much? How do we know? | War-rooms dropped by 80% |
| Z — The action | How did you do it? What was your specific contribution? | Introduced TDD + SonarQube CI/CD with 80% code coverage |
Notice that Y is the hardest part to fill. Most engineers skip it. But without Y, your statement is just an assertion. With Y, it becomes evidence. The stories below are built entirely around this structure, drawn from real situations across my career.
X Led a seamless credit card processor migration for 100,000 active customers — Y with zero noticeable downtime and zero refused transactions — Z by engineering a custom data migration application that resolved complex data discrepancies between FIS and Pismo, completing the transition within Q2.
At alt.bank, the decision to migrate our credit card processor from FIS to Pismo was a business imperative. The new provider offered better economics and a more flexible integration model. But the technical reality was brutal: two systems with fundamentally different data schemas, 100,000 live customers, and a hard deadline tied to a business partnership agreement.
Processor migrations are rarely about moving data from A to B. They are about reconciling the world-view of two systems that represent the same financial reality in completely different ways. Transaction states that mapped cleanly in FIS had no direct equivalent in Pismo. Customer identifiers overlapped in some edge cases and diverged in others. A simple ETL script was never going to be enough.
We built a purpose-built migration application, not a generic tool. It included:
The migration completed inside Q2. Not one customer had a refused transaction during the switchover. Not one customer noticed the change. The gains from the more favorable processor economics started appearing in the P&L in the second half of the same year. The business team had expected a 3-month risk window. We closed it in weeks.
X Reduced critical production incidents — Y decreasing unplanned war-rooms by 80% — Z by establishing TDD practices, implementing SonarQube CI/CD pipelines with 80% code coverage enforcement, and integrating AI-assisted code review across frontend and backend.
If you have worked in a fast-growing fintech startup, you know what a war-room feels like. It is 2 AM, 8 people are on a call, production is down, and nobody knows exactly why. The immediate pain is obvious. The hidden cost is not: developer morale erodes, sprint commitments slip, and engineers start to fear deployments instead of looking forward to them.
When I moved into the Tech Manager role at alt.bank, this was the environment I inherited. The team was skilled. The product was complex. But the testing culture was weak and the tooling was reactive.
Layer 1 — TDD as a team discipline, not a solo practice. Test-Driven Development only works if the whole team does it, because the moment one person skips it, the test suite starts to lie. We introduced TDD in planning sessions — not just in code. Before writing a line, the team had to define the expected behavior and the failure conditions. This changed how people thought about features, not just how they coded them.
Layer 2 — SonarQube as a gate, not a report. Too many teams use SonarQube as a dashboard they look at after the fact. We wired it into the CI/CD pipeline on GitLab so that a pull request with coverage below 80% or with critical security findings could not be merged. The gate is what makes the number real.
Layer 3 — AI-assisted code review. Using tools like Code Rabbit in the review cycle meant that common code smells, missing edge cases, and architectural misalignments were caught before a human reviewer even opened the PR. This freed senior engineers to focus code review on design and business logic, not syntax and boilerplate.
Over the following months, unplanned war-rooms dropped by 80%. Deployments became something the team looked forward to, not feared. The 20% of remaining incidents shifted from "unknown production failures" to "known edge cases we are actively improving," which is a completely different, manageable category.
X Achieved a 3x revenue increase on the collections product — Y scaling from a B2C model to a B2B launch scheduled for Q1 2026 — Z by leading end-to-end development of the Wolfe platform, implementing AI-assisted automated testing pipelines, and designing a scalable microservices architecture that handled 400,000+ daily records.
Building a collections platform that can scale from a handful of internal users to dozens of B2B partners with different data requirements is not a feature delivery problem. It is an architecture problem. The wrong foundation will collapse under the weight of the second client.
The stack we built was deliberate:
Moving a B2C product to B2B is rarely a matter of adding a new user role. The data isolation model, the access control layer, the API contract structure, the reporting granularity — all of these need to be rebuilt with multi-tenancy in mind. We had anticipated this during the original design, which meant the B2B onboarding process was an evolution, not a rewrite.
X Delivered an 80% productivity boost across engineering cycles — Y measured by delivery velocity and reduced cycle time across sprints — Z by pioneering AI-native workflows using Cursor, Code Rabbit, and LLM Agents as first-class tools in the engineering process.
Productivity in software is notoriously hard to measure. Lines of code is a terrible metric. Story points are a proxy, not a truth. What I measured was simpler and more honest: how long did it take from a feature being defined to it being in production? And how often did that feature need a hotfix within 30 days of release?
AI-native does not mean asking an AI to write all the code. It means redesigning the engineering workflow so that AI tools amplify each stage, not just the typing stage:
The cumulative effect across the full cycle was significant. Engineers stopped switching context to look up documentation. Code reviews became faster because AI had already caught the obvious issues. Test suites became more comprehensive because they started from requirements, not from post-hoc coverage analysis.
X Delivered a high-quality banking application MVP — Y in just 3 months as a core startup developer — Z by leveraging telemetry and data-driven prioritization to focus development effort on features with the highest user impact, and by applying Flutter with clean architecture (Bloc/MVC) to maximize mobile delivery speed without accumulating technical debt.
The word "MVP" is often used as a license to cut quality. I have seen too many MVPs that were rushed into production carrying hidden structural debt that took 12 months to untangle. The real challenge of an MVP is not speed. It is choosing what to build fast and what to build right, simultaneously.
In the early days of alt.bank, we had no historical user data. We could not A/B test because there were no users yet. So we instrumented the app from day one — not to analyze behavior, but to prepare to analyze behavior. Every screen, every user flow, every error state was telemetered from the very first commit. This meant that the moment we had users, we had data. We were not waiting weeks to instrument. We were waiting weeks to have enough sample size for statistical confidence.
That telemetry informed every prioritization decision from the first sprint after launch. Features that users were actually engaging with got more investment. Features that were being ignored were cut or deprioritized before they accumulated more debt.
Using Flutter with Clean Architecture (Bloc pattern) was a deliberate choice to preserve optionality. Clean Architecture's separation of concerns meant that when we needed to swap out a backend integration — and we did, multiple times — we changed the data layer without touching the business logic or the UI. In a startup, that flexibility is not a luxury. It is survival.
You do not need to wait for a job search to start thinking in XYZ. The most powerful use of this framework is as a real-time habit — a filter you apply to every project and every decision as it happens.
"We will accomplish [X — the business outcome], which we will confirm by measuring [Y — the metric or signal], by doing [Z — the specific technical work]."
This is also how you write sprint goals that actually mean something. And it is how you retrospective a sprint with honesty — did the thing we shipped move the number we said it would move?
Sometimes the impact is real but not yet measurable. The migration is complete but the cost savings show up in next quarter's AWS bill. The architecture improvement pays off when you hire the next engineer and they onboard in 2 weeks instead of 6. In these cases:
The Google XYZ framework is not a resume trick. It is a way of thinking about your work that forces you to close the loop between technical decisions and real-world outcomes. It is also, in my experience, one of the clearest ways to distinguish engineers who grow into leaders from engineers who stay in execution mode.
The five stories in this article are not exceptional. They are the kind of work that senior engineers do every day in startups and scale-ups. What makes them visible is not the work itself — it is the habit of measuring what changed, and being able to articulate why.
If I had to distill 20+ years into a single professional habit, it would be this: always know what number your work is trying to move, and always go back to see if it moved. The rest — the architecture choices, the tools, the frameworks — is just the means to that end.
Write the XYZ statement before you build the feature. You will build a better feature.