Hi, I'm Yoshiori

I wrote this document to share how I think, what I value, and how I work. This isn't meant to be "this is who I am, so fall in line" — it's written so we can understand each other and build a good working relationship. I want to be clear: this is not meant to impose anything on you.

日本語版は README.ja.md をご覧ください。

My role as a manager

I see my job as a manager as two things:

1. Raise your salary
2. Make your resume Instagram-worthy

You might be thinking — "what about shipping the product, or delivering business value?" Fair question. I see those as means to the two goals above, not ends in themselves.

Without meaningful work to show the company, I can't make the case to raise your pay. And if the company isn't doing well, there's no budget to raise salaries in the first place. So yes, I take product and project work seriously.

But here's the thing: what if we shipped a great product, and the team was burned out, and none of the members got recognized? I'd consider that my failure.

If I make "project success" the primary goal, it becomes tempting to treat people as disposable in service of the deadline. And maybe my own performance rating goes up. But that's not what I want.

If the product is thriving but your salary isn't going up, that's on me.

Goal: raise your salary
Means: make the product succeed

I keep this distinction in mind so I don't confuse the two.

Raising your salary

Each monthly cycle (MBO, etc.), I design your tasks with these questions in mind:

• What are your strengths? Which tasks right now let you build on them?
• Where do you need to grow? Is there a task that gives you a real challenge?

When I assign work, I try to be explicit about why:

• "This is something I know you can handle. It's important for the company, so I need you to deliver it reliably."
• "This is a stretch. It might not go smoothly at first, but I want you to take it on because it'll help you grow."

My feedback follows the same logic:

• "You did exactly what I expected. 100%."
• "I think you could have done better here — the update on xxx should have come earlier. 90%."
• "This was a hard task and you recovered when things went sideways. 110%."

Making your resume Instagram-worthy

If I focus only on your current salary and company performance, there's a risk you become highly specialized for this company but less valuable on the open market. To avoid that, I intentionally try to give you roles and responsibilities that make for compelling resume entries.

For example:

• "Led and owned the front-end architecture for the team"
• "Served as the primary engineering owner for the xxx enterprise rollout and drove it to success"

Having built hiring criteria before, I know how much weight "owned and led something meaningful" carries in the evaluation process.

How I assign tasks

In practice, tasks come from PM-driven product work and engineering-owned work (security, DevInfra, etc.). When I assign them, I'm thinking through:

1. Who is the best fit to make this successful for the product?
2. Is this a "must deliver by deadline" task, or an exploratory one where trying different things matters?
3. Is this in their area of strength?
4. Will this help them grow?

I try to optimize across all of these for every member.

For example:

• "This is a customer requirement that needs to land by xxx. I think it's well within your abilities — I'm counting on you to deliver it solidly."
• "This is early-stage work for a new feature. Part of the goal is learning what works and what data we can gather, so please explore freely."

One-on-ones

1–2 times a month, around 15 minutes. I combine two purposes:

1. MBO / task feedback — I follow up on the tasks I assigned, referencing the expectations I set upfront.
2. Casual chat — Mostly hobbies and everyday life, but sometimes we'll get into work, team dynamics, career, or the future.

When we're remote, I prefer video (Google Meet, etc.) — face to face matters. When we can meet in person, I'd rather go to a café or take a walk than sit across from each other in a conference room.

MBO

As described in the section above, I review how your tasks went — not just whether they're done, but how the outcome compared to the expectation I communicated upfront.

If you ever feel you're not being evaluated fairly, don't wait for a formal review cycle — tell me right away.

Casual chat

The real goal of having casual conversations is to build the kind of relationship where you actually feel comfortable bringing things up. Saying "feel free to come to me anytime!" doesn't make that happen.

I believe the foundation for that is knowing each other as people — what you enjoy, what's going on in your life. That's why I prioritize just talking.

Work topics are of course welcome too. I'd much rather hear "I've been feeling like my work isn't aligning with where I want to take my career" than get a surprise "I'm leaving" six months later.

And things change. "I wasn't interested in management, but I'm kind of curious now" followed by "actually, never mind" the next month — that's totally fine. I want us to have a relationship where those shifts can be said out loud.

Feedback for me

Please tell me what you think — the things I should improve, and (if you're willing) the things that are working well. Knowing what's working helps me keep those things when I'm making changes.

Slack, email, whatever works. Anytime you notice something.

Schedule

I work with a remote, global team, so time zone differences are a given. I'm generally on JST, though I sometimes have evening meetings, which means I start later the next morning.

I've shifted to a more conventional schedule lately to align with my kids' routines — I used to be a complete night owl.

Even when I'm not officially online, I often check Slack out of habit. Feel free to message me anytime — I just can't promise a quick reply.

This is not a hint that you should match my schedule. Let's find a rhythm that works sustainably for both of us.

When I'm not feeling it, I don't work. I'll go see a movie or take the day off. I know the "real pros perform regardless of motivation" argument — I just genuinely believe I produce better results when I rest than when I push through.

I learned early on at a startup that work is a marathon, not a sprint. There are moments where you have to push hard, but I fundamentally believe in keeping a pace you can sustain.

Work–life balance

I understand the concept of work-life balance, but honestly, it doesn't quite map onto my own experience. I love what I do, and I don't feel like I become a different person when I'm "off the clock." I'll think about work while waiting for a game to load, and catch myself thinking about travel plans in the middle of the workday.

That said, there's something I want to say clearly: I strongly believe you should never sacrifice the things that matter to you — your family, your health, your values, your faith — for work.

If you ever feel like that's happening, tell me immediately.

Other things I care about

• I don't stop writing code. There's too much I can only learn by doing it myself. I'm careful not to take on scheduled deliverable tasks given my role, but I keep my hands in the work. Lately I think it's especially important to have firsthand experience working alongside AI agents, so I use them actively.
• I move fast when cross-team negotiations stall. By the time you need to escalate to me, things are already complicated. I'll gather context, act appropriately, and always report back with what happened.
• I default to transparency. I share what I know, unless it involves someone's performance review or compensation. I prefer open conversations over DMs — public Slack channels over private ones.
• I care about technical correctness, but not at the expense of people. When I push for the technically right answer, I try to bring people along with reasoning they can actually buy into.
• I care deeply about trust within the team. That means being honest, being sincere, and treating each other with respect.

I'm far from perfect, and I don't always live up to everything above. But it's what I'm aiming for.

Notes

This document is neither final nor definitive. It will change as I change. Thanks for reading all the way through.