Fusionary · Mar–Oct 2021
The technology was primarily WordPress, with Craft CMS and custom platforms in the mix. The more important career shift was stepping into technical project and delivery work: turning client needs and defects into work engineering and QA could execute.
Environment
The job
I diagnosed plugin conflicts, rendering defects, middleware problems, API and form failures, analytics issues, and post-deployment defects across client-facing web properties. But the work did not stop at identifying a likely cause.
I also worked across clients, engineering, QA, and systems teams to clarify requirements, write functional specifications, move bugs through handoff, and support implementation. That is where I began operating more explicitly as a technical project/delivery person rather than only the person making the code change.
Selected engagements
The delivery context included a large ecommerce rebuild and direct work with senior client technical leadership.
Detroit Axle
I worked on the rebuild through Fusionary as part of the delivery team, contributing to a recognizable production ecommerce project with real client, implementation, and handoff constraints.
Jet's Pizza
I worked directly with the CTO through the Fusionary engagement, keeping technical concerns and delivery work in the same conversation rather than several handoffs apart.
The progression
Fusionary made the coordination layer explicit. I was still close to application behavior and implementation, but I was also responsible for making work legible to other people: clients, QA, engineers, and technical stakeholders.
I learned to keep a client problem intact as it moved from conversation to specification to implementation to QA, instead of treating each handoff as somebody else's boundary.
What Fusionary added
It showed me that the same diagnostic habits used in support also make project delivery better: define the problem, preserve context, make the next handoff actionable, and stay close enough to verify the result.
