Personal User Manual
This page saves us six months of figuring out how to work together.
High trust. Radical candor. Clear boundaries. Here's the operating manual — read it before our first 1:1.
Operating Rhythm
I'm the lighthouse, not the tugboat
My job is making the right path obvious — not doing the rowing for everyone. Good writing, trade-off maps, and visible decision logs beat another status meeting.
Async by Default
- Decision logs and 1-pagers over meetings about meetings
- Notion/Linear/Slack for structured updates — not surprise DMs
- Written proposals before calendar invites
- If it can be a Loom, it shouldn't be a meeting
High-Bandwidth When It Counts
- Architectural decisions that affect multiple teams
- Incident response and crisis triage
- Stakeholder alignment when written context isn't enough
- 1:1s — never skipped, never status updates
How to Communicate With Me
Structured communication helps me work faster
I have ADHD. Bullet points, numbered lists, and clear headings help me give you my best thinking quickly. This isn't a demand — it's a cheat code for getting better output from me.
Bottom Line Up Front
BLUF
Lead with the conclusion. Then explain how you got there. I'll read the whole thing — but I'll read it faster if I know where it's going.
In both directions
Direct Feedback
If something isn't working, I'd rather hear it straight so we can fix it together. I'll give you the same respect. No compliment sandwiches, no passive-aggressive Slack reactions.
Show me the query
Data Over Debate
When we disagree, I'd rather look at the data together than debate from assumptions. I'll pull the query — you bring the context. Best argument wins, regardless of title.
When Things Go Sideways
The Kobayashi Maru Protocol
I don't accept the premise that the constraint is real until I've pulled it apart myself.
Panic doesn't help. When things break, I stay calm, rewrite the constraints, and find the path forward. During incidents, I handle stakeholder communication so engineers can focus on the fix. I'll translate the technical reality into business terms and manage expectations upward — that's the job.
Named after the Star Trek training exercise designed to be unwinnable. The lesson: the best response to an impossible constraint is to reject the setup entirely and find a third option.
Energy
What drains me vs what lights me up
Sharing this upfront means we can design our collaboration around where I do my best work.
Drains Me
- Meetings without agendas or clear outcomes
- Process that exists for its own sake
- Manual work that should be automated
- Decisions made by committee that could be made by one owner
- Performative urgency on things that aren't actually urgent
Energizes Me
- Ambiguous data systems with no owner yet
- Deleting code, features, or process that isn't earning its keep
- Removing blockers for engineers so they can ship
- Turning a messy domain into clear bounded contexts
- Shipping something real and watching actual humans use it
The Toolkit
Three frameworks I actually use
Not because they're trendy — because they solve real problems I've hit in production.
DDD
Domain-Driven Design
Clear ownership boundaries, ubiquitous language, and architecture that reflects how the business actually works — not how it looks in slides.
Domain bugs →Prioritisation
RICE / DRICE
Standard RICE for consumer-facing features. DRICE (with a domain-weight modifier) for internal platforms where reach math breaks down.
Why RICE fails →KCS
Knowledge-Centered Service
Documentation is a product surface. Every decision, workaround, and incident gets captured in the same loop: fix it, document it, close the gap.
Docs as product →Working FAQ
The questions that come up most often
These are the plain answers I end up giving in interviews, diligence calls, and first-week handoffs.
- How does Ryan Winkler prefer to communicate?
Start with the conclusion, then the context. Written updates beat surprise meetings for anything that needs a trail. I default to async, but I switch to live conversation when the stakes are high or the room is confused.
- What is Ryan Winkler's approach to decision-making?
I want the decision, the trade-offs, and the owner written down. Frameworks like RICE or DRICE can help, but the real test is whether the team can explain why this matters now and what we are not doing instead.
- How does Ryan Winkler handle crises?
Stay calm, work the blast radius first, and keep engineers focused on the fix. I handle the status updates, translate the technical reality for stakeholders, and make sure we capture the lesson afterward so the same failure does not repeat.
- What tools and frameworks does Ryan Winkler actually use?
Domain-driven design for boundaries and language, RICE or DRICE for prioritization, and KCS for turning fixes into reusable knowledge. The specific tool matters less than keeping context visible and decisions traceable.
Sound like someone you'd work well with?
I'm always open to conversations with teams building complex, trust-sensitive, or high-ambiguity products.
This page changes when I do. Last updated 2026-04-20.