Recommendations are evidence of the working relationship
I have added two public client recommendations to this site: one from Mary Skuse, Marketing Operations Director at OnlineMedEd / Archer Review, and one from Adam Finch, Sr. Digital Marketing Manager at DataSpring, powered by CAQH. I am grateful for both because they describe the part of engineering work that is hardest to represent with a technology list.
Projects are visible through their interfaces, repositories, launches, and case studies. The working relationship is harder to show. Did the engineer understand the actual goal? Could they make an ambiguous request concrete without pretending the ambiguity was not there? Did they make the team more dependent on a specialist, or leave behind a system that people could understand and operate?
Those are the questions I care about in client work. The recommendations give me a chance to reflect on the practices behind them, while linking to the complete letters rather than asking a short excerpt to carry the whole story: read Mary Skuse’s recommendation and read Adam Finch’s recommendation.
Listening is an engineering skill
Good implementation starts before an architecture diagram or a ticket estimate. It starts with listening closely enough to separate the immediate request from the outcome the team is trying to protect.
At OnlineMedEd, the public work included a HubSpot migration, custom modules, and custom objects for a B2C business. Those are concrete implementation details, but they only make sense in the context of the people who needed to publish, report, and keep the site functioning after the migration. Mary’s letter describes that I took time to understand the team’s goals and cared about the outcome, not only the next task. That is the standard I try to bring to delivery.
Listening is not passive. It means asking what has already been tried, who owns the underlying data, which user journey cannot break, what a successful handoff looks like, and which constraints are technical versus organizational. Sometimes the best outcome is a smaller solution because it is easier for the client team to operate. Sometimes the requirement needs to be translated into a few possible paths so stakeholders can make an informed decision. In both cases, the work is more useful when the reasoning is visible.
Ownership means looking beyond the immediate request
The easiest version of client work is to close the ticket that arrived. The more valuable version is to notice when the ticket is exposing a weakness in the underlying system.
Adam’s recommendation describes that tendency directly: looking for ways to improve the underlying solution rather than simply close the immediate request. His letter reflects work across complex web and AI initiatives at CAQH and DataSpring, including dashboards, membership and registration workflows, custom AI assistants, retrieval improvements, guardrails, administrative tools, telemetry, and documentation.
Those details have a common shape. An interface issue may point to unclear data ownership. A slow assistant response may be a retrieval problem rather than a prompt-writing problem. A security finding may require a decision about staging, domains, or TLS rather than a one-line configuration fix. A delivery request may reveal that the team lacks the documentation or visibility needed to manage the system after launch.
Ownership does not mean expanding scope without consent or acting as if the engineer alone knows what matters. It means making the risk legible, explaining the available options, and helping the client decide what should happen next. The immediate request still deserves a practical answer. The surrounding system deserves the same attention.
Translation is how ambiguity becomes a workable plan
Client-facing technical work often sits between people with different kinds of expertise. A marketing or operations lead may know exactly where a workflow is failing without having a useful name for the technical cause. A developer may understand a system boundary without knowing which business constraint changes the decision. Information security, subject-matter experts, and leadership may each need different evidence before a change can move forward.
My job in that setting is not to make every person become a specialist in the same stack. It is to create a shared enough understanding for a decision to be made responsibly. Adam’s letter notes careful listening, implementation questions, and practical technical solutions as requirements changed. It also describes clear communication across marketing, development, information security, and subject-matter stakeholders.
That is why I prefer concrete artifacts: a brief data map, a decision record, a demo of the actual flow, a small set of options with consequences, and documentation that says who owns the next step. They give the client something more durable than a verbal update. They also expose uncertainty early, while it can still be managed rather than hidden inside a late surprise.
Maintainability is part of the result
The work is not finished when a launch succeeds. A client inherits the system, its controls, its reporting, its publishing model, and the consequences of every invisible shortcut. A maintainable result gives the team a way to understand what they have, make normal changes, and investigate an issue without reconstructing the project from memory.
That is visible in both recommendations. Mary describes work that paired a HubSpot migration with structure for organizing and reporting a B2C business. Adam describes unified telemetry and documentation that made AI systems easier for the team to understand and manage after delivery. Those are not add-ons. They are part of whether a solution remains useful.
Maintainability is also why I distinguish client work from my independent products on this site. An independent product can be a place to explore a new interaction model or release gate. Client work carries a different obligation: respect the organization’s context, work within its operating model, and leave behind an implementation the team can own. The relevant technology may overlap, but the responsibility is not identical.
The pattern I want to keep practicing
I do not think strong client work depends on having a perfectly complete brief. Most meaningful projects do not start that way. It depends on being willing to listen carefully, take responsibility for the real system around the request, translate technical choices without hiding their tradeoffs, and deliver something the client can maintain.
The two letters are generous evidence that those practices mattered to the people I worked with. I am thankful to Mary and Adam for taking the time to write them, and I will keep treating that trust as a delivery standard rather than a credential to display.