Nothing changes in a vacuum.
A website looks like a marketing property right up until it stops working, and then the calls come from operations, from the contact center, from the people whose daily job quietly depends on it. Almost every expensive digital mistake I’ve seen started with someone changing one thing without knowing who else was standing on it. This page is how I work so that doesn’t happen.
Five positions, held before you hire me
Not values. Positions — each one has something at stake, each one costs me work when a prospect disagrees, and each one changes what I would recommend to you. You should know them before we’re in a room together, not after.
01 · A website is not a marketing tool. It’s the operational face of the business.
Marketing usually owns the budget and the roadmap, which makes it easy to assume marketing owns the purpose. It doesn’t. Scheduling, service information, hours, results, documents, forms that route into somebody’s queue — a large share of what a corporate site does is operations wearing a marketing badge. The proof arrives the day it goes down: the people who call are almost never the people who own it.
02 · Accessibility conformance is a state you hold, not a certificate you earn.
It’s true on the day it’s measured and untrue the first time somebody publishes a page without alt text. Anything that treats it as a one-time project is describing a snapshot and selling it as a condition. What holds it is the same thing that holds any standard — a decision that’s been made, a person accountable for it, and a scheduled moment when it gets re-checked. Most organizations have written the first, assumed the second, and never scheduled the third.
03 · Lifecycle work is the cost of doing business, not a nice to have.
End of support is not a surprise. It’s a date the vendor publishes ahead of time — Drupal names end-of-life dates for each major version in its public core release schedule, and Adobe commits to at least twelve months’ notice before an enterprise product leaves core support. Notice periods vary by vendor, so the honest version is that the date is knowable long before it arrives, not that it always arrives years out.
Which makes the timing a choice rather than an accident. Raised a cycle early, it’s a budget line somebody planned for. Raised late, it’s an emergency at the worst possible price, out of money already committed to something else — and the bill grows the longer it’s deferred, because the property gets larger and more connected while you wait. This is a conversation I’ve had with executives, in their terms, about their P&L. It’s winnable. It has to be started early enough to win.
Sources: Drupal core release schedule, drupal.org. Adobe Enterprise Support Lifecycle Policy — core support typically three to five years from general availability, minimum twelve months’ notice of end of support. Both are vendor-published policies and can change; they describe those two vendors, not every platform.
04 · A solid foundation is what makes the new thing effective.
Leadership wants the visible win, and that’s not a character flaw — visible wins are how funding gets defended. But a redesign on top of a weak foundation buys a year of workarounds, and workarounds are where the next three problems come from. The good news is that this is a false choice more often than it looks: sequencing can usually deliver the visible change first and move the foundation underneath it, which is a planning decision rather than a compromise.
05 · A team held accountable for something it doesn’t control is set up to fail.
This is the one I’ll raise with your leadership if I see it, and I’d rather tell you that now than surprise you with it later. A date committed before anyone asked how long the work takes, a dependency nobody owns, an approval sitting in a queue with no escalation path — none of those are the delivery team’s failures, and all of them will be recorded as such unless somebody says otherwise. Naming that is uncomfortable and it is the job.
For the length of an engagement, that team is mine. What that comes with, I’ve written down — twenty-one years of Army leadership, and the standard I did not leave behind.
Four stages, and what each one is really for
Every engagement moves through these in order, whether it takes six weeks or eighteen months. Each stage exists to stop a specific, expensive mistake in the one after it — skip one and you’re choosing to absorb that mistake.
Discovery — finding what’s true, including what nobody wrote down
Most digital work gets scoped from symptoms, and symptoms mislead with impressive consistency. A conversion problem is frequently a data problem. A content backlog is frequently a missing owner. Nobody is being careless — the symptom is simply the only part that’s visible from where the budget sits.
So discovery closes the ownership map across every function that touches the customer, not just marketing, and asks all of them the same plain question about what they expect the website to do and what they need it to accomplish. What comes back is rarely a disagreement. It’s a dependency nobody had counted — the number of operational workflows that terminate on a property one department is assumed to own.
Then the same finding gets measured independently, in analytics you already pay for, because a claim that survives both an interview and a number is a finding and a claim that survives only one is a hypothesis.
What it produces
- An ownership map with names, not departments
- The real dependency list, including the ones outside marketing
- Findings verified twice — stated, and measured
- The questions the organization can’t currently answer, which is itself a finding
Planning — turning findings into decisions with names and dates on them
The most expensive outcome of a strategy engagement isn’t a wrong plan. It’s a correct one that never became a decision — filed, agreed with, and quietly not funded.
So every finding gets a disposition: fix it, plan it, accept it, or investigate it further. Obligations get separated from opportunities before anything is ranked, because if security and lifecycle work competes against campaigns on the same list it loses every cycle, forever, and everyone involved can see it happening. Each item gets one accountable name and a funding path routed to the right budget in the right planning cycle — which is a different question from what it costs.
And the timeline goes through everyone who could block it before it’s a timeline, including the periods when work can’t happen at all. A date nobody was asked about isn’t a plan. It’s a liability with a deadline.
What it produces
- Every finding dispositioned, none left as an observation
- Obligations ranked separately from opportunities
- One accountable name per item
- A funding path per item, in the cycle it can actually be funded
- A dependency register — who provides what, and whether it’s requested or required
Data and integration — where roadmaps quietly die
APIs are easy to build. It’s the data part that’s difficult, and it’s the part almost nobody scopes honestly.
The first questions are never technical: what information exists, what of it is actually exposed, and does it come back usable. I’ve watched a build discover in week six that four required fields were never in the source — which is a data problem wearing an integration problem’s clothes, and it’s why I query a source and read what comes back before anyone estimates the work.
The failure that costs the most isn’t dirty data, though. It’s data that is entirely correct for a purpose that isn’t yours — a field maintained accurately for years by a team using it for something else, that becomes wrong the moment you publish it. The fix isn’t cleaning the data. It’s understanding what the field is for, and adding one that’s for your thing instead.
What it produces
- Feasibility confirmed against the source, before estimates
- One authoritative record per thing, and many presentation destinations
- Specifications a developer can build from without a translation call
- Governance for who updates it, and how it stays true at scale
Implementation — where I’m most hands-on, and deep in the weeds
A great strategy and a solid roadmap both go belly up if delivery doesn’t land on time and on budget. You can’t hand a roadmap to a development team and call it a project — that’s the single most common way a capable team gets set up to fail.
So I’m in the board, in the stand-ups, and in the backlog. Not for status: for the ticket that quietly stopped moving, which is visible about three weeks before anyone reports it as a problem. Most of what I then clear is not technical at all — an unmade decision, an unanswered stakeholder, an approval sitting in someone’s queue.
The part I’d point at if you only read one line: nobody has to translate for me. Your developers can describe a problem in the terms it actually exists in, and I’ll understand what it implies — which means the conversation is about the problem rather than about explaining the problem, and it takes a fraction of the time.
What it produces
- Releases in slices that each deliver something usable
- Blockers cleared on the business side before they become schedule failures
- Reversible steps instead of one irreversible event
- A team that can carry it after I’ve gone — which is the actual measure
I’ve held the job. I wasn’t advising the person who held it.
Almost everything worth knowing about working with me comes downstream of one fact: I was the person accountable for a flagship digital property at a large regulated organization — the roadmap, the architecture, the governance, the development team, the budget, the compliance posture, and the availability calls at the point of heaviest demand in that platform’s history.
My specifications are buildable
Because I wrote them, handed them to developers, and lived with what came back when they weren’t good enough. That’s not a claim about care. It’s a claim about having been corrected.
My plans survive budget season
Because I’ve been the person who had to find the money — inside a real operating budget, against real competing priorities, on a real planning calendar, arguing to the person who actually decides.
I’ll tell you what I can’t do
I specify and evaluate integrations, analytics and data layers; I don’t build them. I’m not a scrum master and I’m not an AI engineer. I know where my limits are because I found them by hitting them.
And the one that costs me something to publish: I’ve made the right recommendation, made it plainly, made it more than once — and been overruled. The consequence arrived on the schedule I had named in advance, which removes the comfortable explanation that I could have been clearer.
I don’t think that’s a flaw in the arrangement. It is the arrangement. It is always your decision, and you hold all the options — the trade-offs, the budget, the risk you’re willing to carry, and a hundred things about your organization I will never know as well as you do. What I owe you is the best available answer and the reasoning behind it, said plainly, and said more than once when it matters. Anyone who implies they can give you more than that is selling you something they don’t own.
I’m not here to replace anybody
The people you already have know your systems and your constraints better than any outsider will in eight weeks. They are not an obstacle to route around — they’re the reason the work holds once I’ve gone. My job is to lead them through it and to sit in the seat nobody is currently sitting in.
I treat the team I’m given the way I treated the ones who reported to me, and that isn’t a sentiment — it’s an operating method, and it shows up as three specific things you can hold me to:
- When something goes wrong, the complaint comes to me. Not to the person who did the work. I’m the wall, and that is most of what the role is for.
- I ask for level of effort in hours, and I take the answer. I don’t argue with an estimate from the person who has to deliver it. If the number is a problem, the scope is the thing that moves.
- Ideas keep their owner. If your developer’s workaround is better than the plan I brought — which happens — I’ll say so out loud, and it stays their idea.
I want to leave every team and organization better than it was when the engagement started.
Where this page stops and the other two start
This page is the method. It deliberately doesn’t sell anything, and it deliberately doesn’t give you the instruments — the interview set, the disposition framework, the validation sequence and the sequencing model are how I do the work, and they’re what you’re hiring rather than reading.
If you want to know what’s deliverable
Five fixed engagements with deliverables and turnarounds, the longer arrangements, what things cost to find out, and the list of work I don’t take at all.
If you’re an agency
A client-side counterpart who doesn’t need translating, specialist capacity you can put in front of a client, and the terms — including the non-solicit commitment.
If any of that described your organization, the next step is a conversation
My first question is what problem we’re trying to solve, and how you want me to help. Not a pitch, not a discovery call with a deck behind it. If the answer turns out to be that you should hire someone permanently, I’ll tell you that — I’d rather be right than retained.
