The day job
Business Development Director, technology staffing & solutions, Minneapolis.
I help technology leaders build their teams: contract, contract-to-hire, and direct hire across IT. The rest of this site is what I do at night. This page is what I do all day, and honestly, the two have more to do with each other than you'd think.
I'm not a "send me a req and I'll flood your inbox" recruiter. That model wastes everyone's time, yours most of all. The way I work is slower at the start and faster everywhere after: I want to understand your team first. What you're building, where it's straining, what a great hire actually changes for you. Sometimes the honest answer is that you don't need what I sell yet. I'd rather tell you that and be useful in the meantime.
What that looks like in practice: I pay attention to the local market and share what I'm seeing (comp, availability, which skills are genuinely scarce versus just trendy), whether or not there's a deal in it. When there is a search, you get a short list of people I can vouch for, not a stack of keyword matches. And when the search is done, I stay interested, because the relationship was the point.
Take a look around this site: I run a small private cloud, ship my own applications, and put AI to work in production, as a builder, not a bystander. I'm not an engineer and don't pretend to be one. But when we talk about your stack, your team, or what an AI-era role really requires, I'm not reciting vocabulary. I've wrestled with a version of it myself, probably at 11pm, probably with a dog supervising.
That changes the conversations I can have. I can hear the difference between a role that's really about systems thinking and one that's really about tooling. I can talk to your engineers without making them translate. And I have real respect for the craft, because I know just enough to know how hard it actually is.
Designing systems and reasoning about tradeoffs. Running infrastructure that has to stay up, and finding out the hard way what a tested backup actually means. Directing AI agents as a team: delegating, verifying, and governing what they're allowed to do on their own. Reading a security finding and deciding whether it's real. And writing all of it down so it survives me forgetting it. None of that makes me an engineer. All of it makes me better at the conversation you and I are actually going to have.
If any of that sounds like your world, or you just want to compare notes on the market, hiring, or what I've learned building all this, reach out. Worst case, you get a good conversation and a picture of two very good dogs.