WORK STORY / 02
Clarify delivery boundaries amid complex processes and shifting standards
Context
BTSE’s development process involved PD, PJ, designers, backend, QA, and frontend, as well as multiple environments, code review, QA acceptance, release, and other checkpoints. The process did have standards; the real difficulty was that many exceptions, preconditions, and responsibility boundaries still depended on human experience and memory. Different roles could understand the requirements, implementation scope, and completion criteria of the same ticket differently, and some standards surfaced only near delivery. For the implementing engineer, the challenge was not merely completing the feature, but confirming whether everyone meant the same thing by “complete.”
My Decision & Action
I changed how I worked. Before development, I identified the roles and systems involved, proactively confirmed expected behavior, frontend and backend responsibilities, and possible impact. Where a ticket alone was insufficient, I cross-checked existing behavior, relevant documentation, and different roles. For shared-module changes, I also organized potentially affected brands, pages, and features for QA to use as test scope. My goal was not to add more process, but to place the answers held by different roles onto the same plane while the information could still be confirmed.
Outcome
This did not change BTSE’s entire development system, but it changed how I handled complex collaboration. I no longer treated finishing the feature as completion; I also confirmed the shared understanding of requirements, change impact, responsibility boundaries, and acceptance scope. This helped me identify real delivery risks earlier, including the possibility that the version QA verified differed from the version prepared for release after code review, and that completion criteria might be redefined late in development.
Reflection
This experience made me highly alert to engineering processes that operate through human memory. When a system requires engineers to remember many implicit rules and they may learn of a different standard only near delivery, the issue is no longer whether an individual asked the right question. Engineers should not have to guess the answer in someone else’s head to prove they did the work correctly. I came to care more about preserving sufficiently clear facts for requirements, technical impact, and acceptance criteria, so that information gaps would not ultimately become blame assigned to the implementer.