The paper version of this fits on a page and leaves out why any of it happened. This is the longer version.
TrebleHook builds a CRM and project pursuit platform for architecture, engineering, and construction firms, delivered as a Salesforce managed package. I lead a delivery team of four consultants across more than sixty client accounts, own solution architecture for our implementations, and still build.
That last part is deliberate. I don't think you can set technical standards for work you've stopped doing, and I've watched enough architects drift into diagram production to want to avoid it. So I write Apex and Lightning components alongside the team, mostly on the harder or stranger problems, and the standards I set are ones I've had to live with.
The work splits roughly three ways. Architecture: data model design on a managed package, feature specification, integration patterns, and the technical standards the delivery team builds against. Delivery: implementations and managed services for construction firms, which means requirements, build, deployment, and the long tail after go-live. And enablement: mentoring consultants, establishing practice standards, and lately building out how we use AI-assisted development without letting volume replace judgment.
Two things from this period I'd point at. I drove the consolidation of two merged consulting organizations onto a unified delivery system, which was mostly a change management problem wearing a tooling costume. And I led an enterprise namespace migration across 454 field references, 45 reports, and 2 dashboards, where the interesting part wasn't the rewrite but defining the verification approach that proved zero residual references before anyone's Monday reporting depended on it.
I started here as Associate Director and moved into the current role in 2024.
I went in-house on purpose.
Consulting teaches you breadth quickly. What it doesn't teach you is what happens to a system in year three, after the consultants have gone and the org has absorbed four rounds of well-intentioned changes from people who each solved their own problem. I wanted to be the person who lived with the consequences.
I led a team of administrators, owned platform strategy, and built automation with Flow and Apex triggers. The most useful thing I learned had nothing to do with the platform: I saw how requests actually arrive inside a business, pre-shaped as solutions, carrying a political history that nobody explains to you. "We need a field for this" almost never means what it says. That's an easy thing to be told and a hard thing to internalize until you've been on the receiving end of it every week.
I also did a lot of training and documentation here, which is where I stopped believing that adoption problems are training problems.
Lead consultant across multiple implementations, planning through deployment. Workshops, requirements sessions, testing, end user training, Sales Cloud and Service Cloud.
A short stop, and the one that made me want to go in-house. Project-based consulting hands you an org at kickoff and takes it away at go-live, and you rarely find out what happened next. I wanted to find out what happened next.
Three and a half years supporting 450+ users across two Salesforce instances, at a healthcare technology company growing fast enough that the platform was permanently slightly behind the business.
Scale changes the job. With 450 users you cannot personally know every workflow, which means you stop designing from your own mental model and start having to go find out. I built Salesforce-to-Salesforce connections to align data across partner business units, which sounds like an integration project and was mostly a negotiation about whose definition of a record was correct.
This is also where I did the most sustained work on adoption specifically: training, documentation, support, and watching which of it actually changed behavior. Mostly it was the documentation nobody asked for and the small interface changes nobody noticed.
My first Salesforce role and my introduction to the ecosystem. Requirements, configuration, QA testing, user training, user stories, backlog management, daily standups.
I was the junior person in the room on most of these engagements, which is the right way to start. I watched senior consultants run discovery sessions and learned more from how they asked questions than from anything technical.
Forecasting and inventory planning for 2,000+ SKUs across major retail accounts including Petco and PetSmart.
This is the job that shaped everything after it, and it's the one that looks least relevant on paper.
Partway through, we implemented forecasting software, and I ended up being the person who trained the sales planners on it. The software worked correctly. It also asked people to enter data in an order that didn't match how they thought about their accounts, and buried the screen they needed six clicks deep. So they kept their real numbers in spreadsheets and typed things into the system afterward.
That was the first time I saw a system be completely right and completely useless at the same time. I've been arguing about it ever since.
Inventory and sales planning for private label programs at national retailers. Reporting and analysis for account managers.
I was the end user of somebody else's CRM here, which is a perspective I've never quite lost.
Salesforce Administrator · Sales Cloud Consultant · Service Cloud Consultant · Experience Cloud Consultant · Platform App Builder
Worth naming the gap: these are all functional certifications, and a good part of my work is Apex, Lightning Web Components, and managed package architecture. That's a mismatch between what my certifications say and what I actually do, and I'd rather point at it than hope nobody notices. Platform Developer I is on the list.
B.A., Business Administration · Thiel College · 2011
I don't have a computer science degree. I came at this from the business side and learned the technical half on the job, which I think shows up in how I work more than any credential does.
Not an availability notice. A description of the problems I want to be working on, which is more useful to both of us.
I'm most valuable where the technical work and the business context can't be cleanly separated: vertical products, complex domains, implementations where getting the requirement right is harder than building it. I like managed packages and the particular constraints they impose. I like industries with real vocabulary that takes time to learn.
I want to keep building. Any role that ends with me only reviewing other people's designs is one I'd be worse at and less useful in.
And I care about whether the thing gets used. If adoption is treated as someone else's problem after go-live, we probably won't enjoy working together.