Approach
How an engagement actually works.
Most consultancies describe their process in slides — phases, gates, methodologies. What follows is the lived experience: the rhythm of the work, who drives what, how decisions get made, and what mutual success looks like in practice. The goal isn’t to sound impressive. It’s to tell you exactly what to expect before you ever sign anything.
The first conversation.
Almost every engagement starts the same way: we zoom out to thirty-five thousand feet and ask what we’re actually trying to do. Before any code is written or hardware is ordered, the first hour of conversation is about understanding the problem honestly — what’s broken, what’s at risk, and what success has to look like.
The work begins with a written summary or proposal — my read of what you’re trying to accomplish, what’s standing in the way, and what the shape of a solution might look like. We pass that document back and forth until we’re both looking at the same problem, in the same language, with the same constraints visible.
This step isn’t bureaucratic. It’s the cheapest insurance against the most expensive failure mode in engineering: building the right thing for the wrong problem. By the time we agree on the proposal, the engagement is already half done in the most important sense — the part where we’re both clear on success.
The conversation also surfaces what physics will and won’t allow. Every system, regardless of domain, gets analyzed against four budgets that don’t negotiate.
The four fundamentals that physics won’t negotiate. Every system gets analyzed against them before any clever solution is considered. The first conversation usually surfaces which one is actually the binding constraint — and that determines the shape of everything else.
Read more in the North Star →Once we agree on the proposal — the problem, the constraints, the rough shape of a solution, the working agreement — the engagement starts. From there, the work moves quickly.
The customer drives. The engineer engineers.
Clean division of authority is the foundation of every working relationship that holds up under pressure. You own the goal. We own the path.
The customer sets what success looks like, what trade-offs are acceptable, what the budget is, what the timeline allows, and what features matter most. The engineer translates that into a system that meets the goal, raises issues honestly when reality and goals diverge, and proposes alternatives when something isn’t feasible.
This division isn’t adversarial — it’s collaborative. The customer doesn’t need to understand every technical decision; the engineer doesn’t need to second-guess every business priority. But the customer should always know what’s being built, why it’s being built that way, and what the tradeoffs were. Status emails go out multiple times a week, with what changed, what’s next, and what risks are surfacing. Whether they’re read closely or skimmed is up to the customer — but they’re always there, in writing, on the record.
When something needs to pivot — new requirements, shifting priorities, surprises in the field — the conversation happens openly. Pivots have cost and schedule implications, and those get discussed before commitments change. The customer is in charge of the project. The engineer is in charge of the engineering. When that boundary is clear, every other decision becomes easier.
Quick to a prototype. Honest about what it shows.
A working prototype tells you more than fifty pages of design documentation. The point of getting there fast is not to skip the rigor. It’s to put the rigor in front of something real, sooner.
Once the proposal is settled, the work moves fast toward something the customer can see, run, or hold. That might be a software prototype demonstrating the core algorithm, an FPGA build showing the data path is real, an Arduino-class breadboard with the right interfaces in the right places, or an architecture document with enough specificity that the implementation is obvious. Whatever the form, it exists to test assumptions against reality before those assumptions become expensive.
Hardware is never on time. That’s a structural truth of complex projects, not a complaint — the right response is engineering around it. Tier testing makes the software work without the final hardware in hand: simulators stand in for sensors, mock interfaces stand in for vendor systems, software-in-the-loop runs the algorithms against synthetic data. By the time real hardware arrives, the software has already been exercised at every layer that didn’t require it to be physically present. The integration phase becomes faster and less risky because most of the surprises have already been found.
The other rule of thumb at this stage: the right tool for the job, not the latest tool. Every technology choice is a maintenance commitment. A clever framework that nobody on your team can read in five years is a liability disguised as a feature. Code that a first-year intern could understand on a Monday morning is what gets handed off cleanly when the engagement ends. Boring technology is usually the right choice. Innovation belongs where the problem actually requires it.
Leverage. Not just hours.
A senior engineer’s value isn’t the time they bill. It’s everything they’ve already built, debugged, and learned that gets brought to your problem on day one.
Twenty-five years across defense, aerospace, industrial, embedded, and RF work means a substantial library of patterns, tools, scaffolding, and reference designs that don’t need to be invented from scratch for your engagement. Project skeletons that handle the boring infrastructure so the work can focus on what’s actually unique. Internal tools for scaffolding new builds, tracking dependencies, managing releases. Test rigs and harnesses adapted from past projects. A catalog of recurring patterns, recognized across hundreds of engagements, ready to apply.
This is the structural reason a small senior consultancy can compete on substance with much larger firms: you’re not paying for someone to learn your problem from zero. You’re paying for someone who’s seen your problem’s shape before, in another domain, and knows which patterns transfer. The research and innovation work that happens under the Artisan Technologies banner exists specifically to feed this library forward — new tools and techniques validated in research become available to the next client without them paying for the experimentation phase that proved them out.
The result is engagements that move faster, cost less, and ship cleaner than they would from a team starting fresh. You don’t just get a senior engineer’s hours. You get the accumulated leverage of every problem they’ve solved before yours.
Mutual success. All ships rise.
An engagement is worth doing only if both parties leave better off. That’s not a slogan. It’s a structural commitment that shapes how every part of the work runs.
The customer leaves with a working system, documentation their team can actually use, operators who understand what they’re running, and a clear picture of how to maintain and extend the work without further help. The engineer leaves with another reference engagement, another set of patterns for the library, and another professional relationship worth maintaining. Both ships rise — or the engagement wasn’t structured well in the first place.
This orientation shows up in small ways throughout: in flexible licensing terms when client circumstances call for them, in handing off knowledge instead of guarding it, in willingness to stay available for follow-up questions long after the formal engagement ends. The best client relationships I’ve had have come back for second, third, and fourth engagements over many years — not because they were locked in, but because the foundation built during the first one made everything that came after easier.
When done well, an engagement isn’t a transaction. It’s the start of a working relationship that compounds over time. That’s the goal of every engagement: leave the client stronger, leave a relationship worth maintaining, and let the work speak for itself.
A note on confidentiality
Discretion is assumed, not advertised.
NDAs are welcome upfront. Engagements involving sensitive technical information, classified work, or proprietary processes are handled with the rigor that defense and aerospace clients expect. The standard does not relax for commercial work.
Start a conversation
Bring the hard problem.
The first conversation is short, focused, and free. We’ll tell you whether your problem is a fit, what we’d propose if it is, and who to call if it isn’t.