Approach
The same three moves, on every project.
Most hard problems start as a wall of legal, regulatory, or technical constraints nobody wants to touch. My job is turning that into a decision people can act on, then holding that decision through legal review, stakeholder pushback, and every revision after. Same three moves, regardless of industry.
The Process
01
Audit
Read what's already live and flag what's unclear, redundant, or failing an accessibility check before building anything new. At Agile Defense, this is the first phase of Pre-Discovery: sitting with federal stakeholders before prototyping anything, every time a new engagement starts.
02
Draft
Build the first real version, a prototype, a plan, a decision, before folding back in the legal, brand, or technical requirements. At Agile Defense, that's the concept-prototype stage of Pre-Discovery: a working dashboard built to react to, before anyone commits to the final build.
03
Ship
Test it with the people who'll push back (legal, dev, a real user) and hold the line through revisions. That discipline is what turned 20-plus navigation menus on a 5,000-plus page university site into one structure people could use.
What Stays Constant
Clarity over cleverness
I'll take the boring answer that's right over the clever one that needs a follow-up meeting to explain, every time. Agreement is what makes an answer stick. When the whole group defines the facts at kickoff, a later pushback gets a gentle reminder of what everyone agreed to. The decision can still change, and the group sees what else the change affects.
Prove it before you promise it
Federal agencies don't sign on a pitch deck. At Agile Defense, we build working concept prototypes, real dashboards with synthetic data, before the contract exists and before we can see the real data. Real data often sits behind access restrictions at that stage, so we've gotten good at building synthetic data with enough context to show what works and what doesn't. Clients believe what they can see. The sooner they're clicking through a working dashboard, the sooner they trust us to build the real one.
Repeatable over one-off
I help build things other people can pick up without me. Fast Plays and the Solutions Architect Jira board are both reused by people who never met me.
The last 25% is the job
A mentor of mine calls it the 75% trap: AI gets you most of the way fast, and that's exactly when it's tempting to call it done. The iteration after that is the real work. I budget for it every time.