A practical manual for working with me.
Nobody has to adapt to me. This is just a description of when I do good work, and when I get harder to deal with. Take what's useful.
- TL;DR
- How my attention works
- Where I'm strongest
- Where I'm weak
- Communication
- Where things have to land
- Meetings
- Estimates and time
- Detail and quality
- Feedback
- Disagreement
- Environment
- How I hand work out
- How I review code
- If I'm stuck
- What I'm responsible for
- Best defaults
I work best when the goal is clear, the problem is interesting, and the next action is concrete.
- Be direct. Say the actual thing.
- Say what you want from me. "Can you look at this?" means six different things.
- If it matters, write it down. Once, in one place.
- Tell me why, not just what.
- Real deadlines only.
- If I'm intense about an idea, I'm not angry at you.
My attention is interest-driven. I don't only do things I enjoy, but novelty, difficulty, real stakes and a clear outcome get my brain going in a way that routine and vague obligation never do.
When something clicks I go deep and fast, and I stay with it well past the point where it stops being fun. I can hold a big system in my head and find the shape of it. When work is underspecified or procedural, starting is the hard part. The work itself is usually fine once I'm in it.
If I've gone quiet on something, it's rarely because I stopped caring. It's the gap between deciding to do it and doing it.
- Hard, unfamiliar problems. No known answer. This is where I'm worth the most.
- Real deadlines with real stakes. Incidents, launches, anything with a countdown. Urgency helps me.
- Debugging. A concrete broken thing with a findable cause and fast feedback.
- Designing systems. Working out the boundaries, then writing the plan.
Point me at one of those and give me room.
You'll find these out anyway, so here they are.
Starting boring work. Status updates, forms, admin. I know exactly what to do and the doing doesn't start. A checklist, a short deadline, or somebody expecting it works better than reminders.
Small dropped details. I'll see the architecture and miss the typo. I'll understand the plan and forget the one-line follow-up.
Estimates. My sense of elapsed time is bad. Any number I give off the top of my head is worse than one I give after breaking the work down.
Rabbit holes. I can go deep on something adjacent and interesting while the actual priority sits still. Ask me "is this the thing?" and you'll get an honest answer.
Things that work:
Direct language. I prefer clarity to cushioning. If something is wrong, blocked, late or annoying, say so. I won't take it badly and I will take it seriously.
An explicit ask. "Review this for correctness by Thursday" or "I need a yes or no" is much easier to act on than "can you take a look?".
Separating fact from opinion from request. When I can tell which part is evidence, which is your read on it, and which needs me to do something, I respond to the right one.
The reason. I engage a lot harder when I know what we're optimizing for. "The customer is blocked" works. "That's the process" mostly doesn't.
Things that don't:
Hints. If the real issue has to be inferred from tone, there's a good chance I miss it or fix the wrong part. Say the actual thing.
Long verbal instructions. I'll follow them in the moment and lose details later. That's how my memory works, and hearing it twice doesn't fix it. Writing it down does.
Ambiguous ownership. If something is owned by everyone, I might not treat it as mine until somebody says out loud that it is.
I run on external systems because my memory isn't one. One place per kind of thing:
- Work goes in a ticket. If it isn't written down somewhere durable, it's a conversation, not a commitment.
- Anything with a time goes in a calendar invite. Not a message, not "let's sync Thursday".
- Decisions and commitments go in writing. A doc, an email, a comment on the ticket. Something we can both find in a month.
- Chat is fine for talking. It's a bad delivery mechanism. A request buried in a thread at 4pm on a Friday can evaporate.
Please don't treat "I mentioned it once" as reliable delivery. That's about the channel, not about you.
I'm useful in meetings that solve a problem, make a decision, review something concrete or surface a risk. I'm much less useful in meetings that exist to keep everyone loosely synchronized.
Agenda, or at least the decision needed. No agenda, no meeting.
Async first. If it can be a doc or a thread, it's better as a doc or a thread.
Batch them. Meetings clustered into blocks cost me a fraction of what the same meetings scattered across a day cost. Three half-hour calls spread over eight hours can take the whole day.
Decisions, owners and dates written down before the meeting ends.
If the topic changes suddenly I might need a second. I'm switching models, still listening.
Ask in a way that gets you a usable number:
- Ask for a range and how confident I am, rather than a date. "Two to five days, low confidence" is honest. "Wednesday" often isn't.
- Ask what would change it. I can usually name the unknown that dominates the estimate.
- On long work, ask for a checkpoint. "Show me where you are on Tuesday" catches drift early.
- Make me break it down until the pieces are a day or less. My estimates get much better on the other side of that.
If a date is real, say so and say why. I treat a real constraint very differently from an invented one.
I reason well about systems and unevenly about details, especially on repetitive work. So I'd rather work in a setup that catches mistakes than rely on anyone's attention holding out, mine included.
Checklists, written acceptance criteria, a clear definition of done, and a second pass for details once the main thinking is finished. Automate the check wherever we can.
If you catch a small mistake in my work, just tell me. It's useful and I won't be wounded.
Direct, specific, actionable, and early rather than saved up.
Useful:
- "This section is too abstract. Add a concrete example."
- "You interrupted twice in that meeting. Let people finish."
- "This works, but the maintenance cost is too high because of X."
Not useful:
- "Be more mindful."
- "This feels off."
- "You should know what I mean."
If I'm being too blunt, too persistent or too detailed, say it at the time. When I'm focused on the content I don't always clock the social effect fast enough, and I'd much rather be told than have someone quietly write me off.
I get attached to a line of reasoning when I think the logic matters. From the outside that can look like stubbornness. Usually I'm trying to get the tradeoff stated out loud.
Bring it back to the goal. Name the tradeoff we're actually choosing between. Ask what evidence would change my mind, because I'll answer that honestly. And timebox it: if we're stuck, we're stuck, so decide and move.
I don't need people to agree with me. I do need to understand what we're optimizing for. "We're choosing a different constraint" lands very differently from "you're wrong".
I also talk too long about things I find interesting, and I jump in before people have finished, usually because I'll lose the thought otherwise. That's mine to manage. It's completely fine to cut me off: "short version?", "let me finish", "I need a decision, not the whole model".
Noise costs me more attention than I'd like. In a room with competing conversations I often can't follow what's being said. I'm not being distant.
Headphones on usually means deep work. Interrupt me if you need to, but that's the signal.
For anything complex or important, a quiet room beats an open floor.
Camera off, or a walking call, often makes me a better listener.
Same things, from the other side.
- You'll get the problem and the outcome, not a list of chores.
- I'll tell you what done looks like and which constraints are real.
- I'll tell you why. If I haven't, ask, because I've probably skipped something I assumed was obvious.
- I don't hold hidden expectations. If I haven't said it, you're not being measured on it.
- Ask me the obvious question rather than guessing. Guessing costs more.
- I care about correctness, failure modes, interfaces, and what this costs to run in a year. I'll push hard there.
- I don't care about style a formatter can settle. If we're arguing about it we should be automating it.
- I mark comments blocking or not. If I didn't say blocking, it's a suggestion and you can ignore it.
- My comments are short because I'm moving fast. If one reads as sharp, tell me.
- If a review is urgent, say so. Otherwise assume a day, and chase me if it slips. Chasing me is fine and it works.
If I'm circling, delaying or quietly avoiding something:
- Ask me what the next physical action is.
- Pair with me for twenty minutes. It works, and I won't find it patronizing.
- Cut the scope, or ask for a rough first pass instead of a finished one.
- Give me a short deadline with a person waiting at the end of it.
- Ask which part feels unclear, pointless or risky. It's usually one of those three.
None of this hands the work of dealing with me to somebody else. You can expect me to own what I commit to and say early when I can't, ask when I spot ambiguity instead of guessing, apologize properly when I've been too blunt or too absent, and keep maintaining the systems that make me reliable.
- Write it down.
- Be direct.
- Make the next action concrete.
- Say why.
- Use real deadlines.
- Give feedback early.
- Assume intensity is focus.
- Ask for the short version whenever you want it.
Fewer hidden expectations, fewer dropped details, better work, less friction.