Last updated: February 2026 GitHub: himerus LinkedIn: jakestrawn
This is not a resume. You can find the career summary elsewhere. This is a document about how I actually work — what I expect, what I value, what will make us a good team, and what will make us a bad one. If you're considering working with me in a senior architecture or technical leadership capacity, read this first.
If something in here doesn't fit, that's useful information for both of us. I'd rather know now.
25+ years building production software and leading engineering teams. Shipped code that millions of people have used. Built design systems. Built AI orchestration platforms. Built legal technology under circumstances that would have stopped most people cold. I write the code. I make the architectural calls. I lead the teams. I don't separate those things.
I am direct, technically rigorous, and have a finely calibrated bullshit detector. If you deal with me honestly, you'll have an engaged, committed collaborator who will work his ass off and fight for the right outcome. If you manage my perception instead of informing me, you will lose that entirely. More on that below.
For years I've been in the middle of a legal situation that isn't close to over. The stakes are as high as personal stakes get.
While that was happening, I built production software. Not a diary. Not a weekend side project. A real system — multi-agent orchestration, document analysis pipelines, complex search and visualization UI, and specialized AI coordination across thousands of pages of source material.
I am telling you this not because I want your sympathy. I'm telling you because it answers the question that matters in senior technical leadership: what do you actually do when the pressure is at maximum and the stakes are real?
I build. I ship. I solve the problem in front of me with the best tools available. That's who I am under pressure.
On the side — genuinely on the side, not the headline — I founded a publishing platform for narcissistic abuse recovery resources. Currently 11 book projects in production. The tech I built for it:
- 350+ specialized AI agents organized across engineering, clinical, legal, marketing, and operations functions. Agent management dashboard tracking specializations, performance, and deployment status.
- Full Turborepo monorepo managing multiple apps and shared packages.
- Multi-format book production pipeline — manuscript through LaTeX through print-ready PDF.
- Business management infrastructure — revenue modeling, market analysis, cost tracking, strategic planning tools.
I also wrote one of the books: Surviving the Storm: When the Court Takes Your Children — Managing CPTSD.
The platform is impressive. It's not the point. The point is that I built substantial, production-grade infrastructure as a side project, while managing a high-stakes personal situation and raising my son. This is just how I operate.
The through-line is independent consulting. I've worked as a contractor or independent operator for most of my 25+ years in this industry. I go deep with clients when the work warrants it. The longest of those engagements was Phase2 Technology, where I spent 13 years — starting as a contractor and eventually becoming a full-time employee. That detail matters: I'm not a job-hopper and I'm not a dilettante. When something is worth committing to, I commit.
Phase2 Technology (2011–2024)
Thirteen years. Enterprise clients, healthcare systems, government work. I ran frontend architecture and led engineering teams across multiple concurrent client engagements. The work that defined that era:
Omega Theme (himerus on drupal.org) — I was the lead maintainer and architect of one of the most widely-used responsive base themes in Drupal 7 and 8. Downloaded millions of times. Built on Sass, responsive grids, and mobile-first methodology before any of that was standard. If you built a Drupal site between roughly 2011 and 2016, there's a reasonable chance you used it or worked alongside someone who did.
"The Definitive Guide to Drupal 7" (Apress, 2011) — I co-authored the theming and frontend chapters. Thousands of developers learned to build Drupal from those pages.
Outline Design System — I created and architected one of the earliest production design systems built entirely on native Web Components. Lit 2, Storybook, monorepo architecture, fully open source at phase2/outline. This was before Web Components were fashionable. The patterns we established there are still relevant.
Currently: Independent
Building the platforms described above — AI orchestration, legal technology, publishing infrastructure. Same mode I've operated in for most of my career: architect, engineer, and decision-maker on the same work.
This section matters. Read it carefully.
Over the years I've developed precise pattern recognition for when a story doesn't hold together — when the version of events I'm being given doesn't match the data in front of me, when someone is managing my perception instead of informing me, when "everything is fine" is being said in a context where everything is clearly not fine.
I am not describing a chip on my shoulder. I'm describing a working style.
What this means practically:
- If you come to me with bad news, told honestly, I will work the problem with you. I won't shoot the messenger.
- If you tell me something is fine when it isn't, I will notice. The pattern recognition doesn't turn off.
- If your story changes between meetings and you don't acknowledge that it changed, I will notice.
- If you're managing my perception of a situation rather than informing me about it, I will notice — and it will affect our working relationship.
- I will not call you a liar in a meeting. But I will ask questions until the inconsistency surfaces, and I will remember.
The upside is significant: if you are honest with me — especially when the news is bad, especially when the answer is "I don't know yet" — you will have my full engagement and genuine loyalty. I don't need you to be perfect. I need you to be straight with me.
That's the whole thing, really. The rest of this document is details.
You're good at what you do. You wouldn't be in this role if you weren't. When I ask questions, I'm building context or thinking out loud — not auditing your competence.
You might know something I don't. I've been doing this for 25 years but that doesn't mean I've seen everything. If you have expertise I lack, I want to hear it. I'll push back, but not to win — to make sure the idea holds up.
You'll tell me when something is wrong. I cannot fix what I don't know about. If there's a problem, surface it. The only thing I can't work with is silence.
You can hold your ideas loosely. Good debate makes ideas better. If I challenge your approach, I'm trying to find the failure mode before we're in production. Do the same to me.
Do excellent work. That's the baseline. If something is preventing you from doing excellent work, that's a conversation we need to have.
Challenge my thinking. I am wrong sometimes. I have blind spots. Tell me directly, bring your reasoning, and we'll figure it out. Being wrong in a meeting is better than being wrong in production.
Own your work end to end. Ship it. Document it. Make sure the person after you in the pipeline can succeed. Ownership isn't just writing the code — it's the whole thing, start to finish.
Come to me with problems and options, not just problems. "Here's the issue, here are three approaches, here's what I recommend" is what I want to hear. Do the thinking before you bring it to me.
Tell me when I screw up. I will screw up. I might not notice. Tell me.
I generally work 9am–6pm Eastern. You may see a message from me at night — that's on me, not an expectation of you.
One more thing: I have a son. I pick him up from school some days. Occasionally I will drop off a conversation mid-afternoon and pick it up an hour later. I'm reachable when it matters, and I'll let you know if something comes up that affects my availability. I'm not apologizing for it.
Urgent: Slack or direct message. I respond within hours during working hours.
Non-urgent: Email is fine. Give it a day or two.
Complex: Schedule a call. Some conversations need real-time back and forth.
Meetings: Accept the invite or tell me early if you can't make it. Come with an agenda if the topic warrants it — meetings without a clear purpose are usually expensive conversations about nothing.
I use a three-status system because people deserve to know where they stand.
| Status | What It Means |
|---|---|
| Green | We're good. There are always things to improve, but if nothing changed, there's no problem. |
| Orange | There's a behavior or pattern that isn't sustainable and needs to change. It is fixable. |
| Red | There is a real problem with a real timeline. We have explicitly talked about both. |
Orange is not a crisis. Coming back from Orange builds more trust than never needing correction in the first place.
If you want to know where you stand, ask me directly. I will tell you.
Honesty over comfort. An uncomfortable truth will always win over a comfortable lie. Every time.
Results over activity. I care about what ships. Hours logged and meetings attended are not the measure.
Ownership over blame. When something breaks, I want to fix it and prevent it from breaking again.
Clarity over consensus. I'll gather input. I'll debate. But when a decision needs to be made, someone makes it and owns it.
Teams over heroes. The person who saves the day alone is also the person who created the dependency. A team that functions well doesn't need saving.
If you got to this point and thought "ok, this is someone I can work with" — let's talk.
If you got to this point and thought "this guy sounds like a handful" — that's also useful information, and I'd rather know now.