Empathy as the Hiring Filter — Building the AI Operations Secretary Tasukiba With Me
Why empathy as filter
The usual hiring filter is “technical skill” or “experience.”
Tasukiba’s is different. Technical skill isn’t required. Whether empathy is possible is what matters.
The reason is plain. Tasukiba is a “thin and long” kind of project. Over one, three, ten years, a project without values alignment runs into conflict.
Skills can be caught up to. Values aren’t easily changed.
So the first filter is values. This post opens Chapter K (community, hiring, culture). I’m writing it as the person doing the recruiting — honestly.
Three axes I want alignment on
1. Purpose — provide community to developers and users
Tasukiba aims to be a useful business tool, and through that, build a third place — neither home nor work. Seriously.
“Business SaaS — with a community?” Probably won’t resonate with you. “A place where business utility and community coexist sounds interesting” — that probably will.
Direct continuation of A-6’s “graduation culture” post.
2. Target — make the service known, liked, used long-term
This isn’t “explode sales” or “short-cycle IPO.” It’s thin and long.
“I want fast growth” / “I admire hyper-growth companies” — probably misaligned with this target. Better to say this honestly upfront; it saves both sides time.
3. Method — a simple UI, with decision authority in every user
The math of subtraction. No gatekeeper UI. Don’t trap users.
This conflicts with “I want to build a feature-rich, multi-purpose tool” or “I want mechanisms that retain users.”
Empathy weighted differently: people I know vs external applicants
I wrote “empathy as the starting point,” but the weight differs by context.
People I already trust
For these, what matters more than current empathy is whether their personal aspiration matches what this project is. Empathy can grow through discussion.
For example:
- A junior who wants scratch-build experience their current job doesn’t offer
- A friend interested in founding, on small scale first
For people like that, even with empathy still under construction, I reach out based on the aspiration-project fit.
External applicants
For these, empathy itself is the filter. Joining without empathy makes the basis for discussion missing, which creates conflict and burnout.
The reason for the split is simple: with external applicants, I’m not in a position to invest the time and cost to build a trust relationship from zero. Empathy fills the gap.
”Motivation is up to you”
Why you’d join doesn’t matter, as long as empathy is there.
- Want scratch-build experience as a step toward something next
- Want infrastructure experience
- Want PM exposure
- Want practice for a service you want to build later
All of these — “I want to use this place as growth ground for me” — are welcome.
If empathy is in place, neither skill nor motivation is a gate. That’s the line I want to hold.
People who probably won’t fit
Honestly: the following profiles probably won’t fit. And not joining is probably best for that person too.
1. People who already have a clear thing they want to build
If you have a clear personal vision, building solo will likely serve you better. Working inside this project means moving along its direction, and that often feels constraining to someone with their own vision.
2. People who don’t resonate with Tasukiba’s vision
Joining without resonance creates conflict with other members. Not joining is genuinely better for that person too.
3. People oriented to profit maximization
This service isn’t oriented to profit maximization. We secure the minimum profit required for continuation, and prioritize community growth. A profit-maximizing orientation simply doesn’t share the goal.
The courage to decline
Naming “people who probably won’t fit” takes some nerve.
But:
- A member without shared values means discussions don’t get traction
- Values mismatch produces conflict and mutual exhaustion
- Not naming “this is the kind of place we are” misleads both fit and non-fit applicants
The best outcome is for both sides to recognize misalignment early. Same as The Courage to Be Disliked — the courage not to try to be liked by everyone.
Out of respect for applicants’ time, I decline honestly when needed. That’s my stance.
Commitment shape and pay
I want both of these stated upfront.
Alongside your day job
The base assumption is participation alongside your day job.
That said, a ghost developer (no progress at all) is, in my experience, a burden for the person themselves. If you join, the assumption is that you make some amount of consistent progress at your own pace.
Once revenue exists — because paying customers exist — the expectation shifts toward clearer development progress.
Pay
- Before profitability: framed as growth ground; volunteer participation
- After profitability: share of proceeds proportional to contribution (the actual split design is TBD)
Saying “volunteer” upfront prevents a mismatch in expectations about revenue. Honesty here also avoids fighting later.
What I’d love members to embody
A picture of what membership looks like, also stated upfront.
Use the service yourself (not required)
I personally plan to use it heavily. I won’t force teammates to, but I’d love it if they did.
Building a service you don’t use yourself is hard to sustain motivation for long-term.
Stack discussion
On top of vision resonance, express your opinions and stack discussion, so we add better features over time.
My idea generation is weak alone. There’s a limit to what one person sees, which is exactly why I want teammates to bring their angles.
A culture that doesn’t fear failure
| Kind | Description |
|---|---|
| Acceptable failures | Thought-through, with care taken to avoid user impact |
| Unacceptable failures | Thoughtless failures (these we don’t accept) |
If you handle failure honestly, engage with the service seriously, and trust and respect the team, that’s the only ask.
Recruiting timing
- Open: June 1, 2026 (same day as release)
- Initial setup: me + Claude Code, on operations and maintenance
- How to apply: details on the homepage, but the shortest path is to say hi on Discord
Recruiting by values, not by skill. That’s Tasukiba’s hiring philosophy.
Tomorrow: the philosophy of how the team is run — the equal-founders model and a three-layer discussion process.
Related posts
- Return autonomy to the user — a UI with no gatekeeper — series part 10, Chapter B close
- I want to call it graduation, not leaving — why Tasukiba chose Discord — the prior for community design
- The Courage to Be Disliked, Part 1 — drop the trauma view, live by teleology — “courage not to be liked by everyone”
About Tasukiba
Details on co-developer recruiting are on the product page. Discord invite goes live in stages around release.
