A User Guide to Working With Sean
I came across Julie Zhuo’s user guide concept a while back and it stuck with me. The idea is simple: when you buy a new piece of equipment, it comes with a manual explaining what each button does, what the operating conditions are, and what not to do if you want it to keep working. People should come with something similar.
I finally decided to write this because too much collaborative friction comes from people having to reverse-engineer each other’s operating conditions in real time. The things that actually matter—how I handle ambiguity, what kind of check-ins help me stay on track, what makes me trust the work, and what kind of communication spikes my stress—rarely show up in job descriptions or project charters, but they shape the work anyway.
This is mine.
Working With Me in 30 Seconds
- Give me the ask, the deadline, the decision at stake, and what “done” means.
- Bring me real ownership or a clearly bounded role. Ambiguous responsibility is where work starts to rot.
- Surface problems early and concretely: what happened, what is off-spec, and what decision you need from me.
- Push back when you understand the tradeoff. Vague skepticism lands badly; informed challenge usually makes the work better.
- If I start rebuilding the universe, tell me. The magic words are: “that is not in spec; solve the task in front of us first.”
How I View Success
When a project goes well for me, the center of gravity is that the work is durable, defensible, and deterministic. Durable work survives the weather around it: political pressure, brittle infrastructure, shifting priorities, or my own need to put it down for six months and come back without having to rediscover the whole thing. Defensible work stands on its own; it can be inspected, reproduced, and justified without me having to personally intercede on its behalf. And when I call something deterministic, I mean it does not depend on memory, mood, luck, or hidden state. Given the same inputs and conditions, it should produce the same result — or a bounded, expected variation you can explain in advance.
That standard shapes how I think about done. I care whether the result is useful, obviously, but usefulness that depends on heroics or institutional memory does not feel finished to me. I also care whether the work makes future work easier, because a good pipeline, analysis, or framework should lower the cost of the next decision rather than recreate the same ambiguity. In a federal science context, that probably makes me more process-conscious than some people. I distrust good outcomes that came from opaque methods, because someone eventually has to defend the result, rerun the analysis, or maintain the system after the original author is gone.
How I Communicate
I don’t operate at maximum output every hour of every day, and I think that’s just a human reality. Sometimes I need time to think and let a problem percolate. I am usually scanning for the long-term cost of temporary solutions; if I seem slower at the front end of a project, it is often because I’m trying to avoid backtracking and reimplementation later.
In day-to-day interactions, I prefer brevity and substance over decorative status. If something is blocked, I want to know exactly what the friction is and what you think the next move should be. Knowing what is blocking a project or the recommended next action is far more useful to me than a chronological narrative of past progress. What is least helpful to me is vague hand-waving—updates that imply motion without conveying technical or operational substance.
I also work best when expectations are explicit: due dates, victory conditions, and a clear sense of what done looks like. In practice, I tend to do well with a roughly two-week review rhythm—frequent enough that work does not drift out of focus, but not so frequent that every update turns into churn. If something is sticky, a dedicated working session with no distractions can be more effective than another vague status meeting.
Software and Tools I Use
Most of my technical work happens in R. I usually reach for the tidyverse for data wrangling, ggplot2 for visualization, Shiny and bslib for interactive tools, Quarto for writing and reporting, and package structure when a workflow needs to survive beyond one analysis. I use DuckDB and SQL when the data or reproducibility problem needs a local analytical database instead of another pile of CSVs.
I use Python when it is the right glue: automation, scraping, API work, document parsing, and agent/tooling integration. I am comfortable moving between R, SQL, Python, the shell, Git, GitHub, and GitHub Actions, but I care more about whether the workflow is reproducible than which language got used to make it happen.
My day-to-day operating layer is deliberately boring: Git for version control, GitHub for collaboration and issue tracking, Obsidian for durable notes, Quarto for public artifacts, and AI coding agents when they can accelerate bounded work without making the process less inspectable. If a tool creates hidden state, magic configuration, or results that cannot be replayed, I get suspicious fast.
Things I Do That May Annoy You
One thing to know about me is that I can drift from solving the immediate problem into stabilizing the whole system around it. If a dependency is broken or underspecified, I sometimes start rebuilding the surrounding machinery so the work can rest on firmer ground. At one point, rather than keep wrestling with a website that had a bad API, I recreated the database locally and folded the logic into my R package so the package could silently redirect to a faster, more current local source. That instinct can produce something genuinely useful, but it can also pull me out of scope. If you see me doing that, the most helpful intervention is early and direct: let’s solve the task in front of us first, then decide whether the larger fix is actually worth taking on.
While I care deeply about how the final product looks—visual form affects clarity and usability—I do not have formal graphic design training, and I lean heavily on existing examples when I need inspiration. My default visual choices are usually safe, accessible, and color-blind friendly, but they can also be a little flat. I often benefit from a collaborator with stronger design taste who can say, plainly, when the palette or visual complexity is burying the message and help me simplify without losing the thread.
I also struggle with administrative anxiety. Ominous or vague signaling—like a random meeting invite titled “Discuss progress” or “Employee performance review”—will reliably crank my baseline stress. If something is wrong, the better pattern is simple: tell me what is being observed, what is off-spec or unexpected, and ask whether that is intended behavior. That gives me something I can actually triage: whether the answer is dedicated time, a quick meeting, or a small patch.
What Gains and Loses My Trust
I gain trust in people who give real ownership and mean it. Early in my current role, my former boss made it clear that I had been hired for my judgment, not just to execute someone else’s plan. He trusted me to manage the work, the deadlines, and the approach even when the path forward was unclear. My trust deepens even more when someone advocates for me when I am not in the room — recommending me for projects, speaking highly of my work, and using their institutional credibility to open doors or remove friction.
I also pay attention to signals of character and ownership. Sometimes that looks as simple as hearing someone described as “good people.” That kind of reputational shorthand carries weight with me. In the work itself, I trust people more when they bring a clear, actionable problem: what they have tried, what is and is not working, and what success looks like. That tells me they are not fobbing something off on me; they are actually trying to solve it and are asking for help in good faith.
What loses my trust is less about human limitation than about unmanaged limitation. Everyone has uneven edges. I do too. What erodes trust is passivity, flakiness, and drift — especially when those patterns force other people to compensate. I distinguish between trusting someone’s intentions and trusting their execution. If I cannot rely on someone for time-sensitive work, I start building guardrails: earlier internal deadlines, repeated check-ins, and explicit structure. One early warning sign for me is when someone becomes hard to reach or hard to read in the coordination loop. Once that starts, I stop assuming drift will self-correct and move from passive guardrails to active ones. That does not mean I think they are a bad person; it means I no longer trust the work to stay on track without intervention.
In technical and scientific work, my trust can erode much faster. P-hacking, weak or absent QA/QC, and refusal to document process or pinch points are all immediate red flags. Those behaviors signal that the work is not meant to be inspected, reproduced, or defended. I am much more persuaded by rigor, transparency, and intellectual honesty than by polish or schmoozing, even though I know institutional life often rewards the latter.
My Strengths
One of my clearest strengths is that I can take work that is vague, fragile, or under-maintained and make it legible enough for other people to trust and continue. I tend to stay with a problem long enough to expose the hidden assumptions, stabilize the pipeline, and make the logic explicit. In practice, that often means I am the person who notices where an ETL or analysis workflow will break when an upstream file changes, then keeps pulling on the thread until the result is reproducible and maintainable.
I do not think of that as brilliance so much as persistence in service of continuity. I care a lot about making work survivable by other people. If a project depends too heavily on memory, personal heroics, or one person’s private understanding of the system, I usually feel compelled to keep working until the structure is clear enough that someone else can pick it up and keep going.
My Growth Areas
One recurring growth area for me is managing scope without converting every rough edge into a systems problem. I can often see the durable fix quickly, but that strength has an obvious shadow side: I sometimes start solving adjacent infrastructure before the present task is actually complete. If left unchecked, that can turn one real problem into three impressive side quests.
Relatedly, my ADHD can make prioritization harder than it looks from the outside. I do best with clear victory conditions, explicit due dates, and a review cadence tight enough that work stays live in my head without becoming constant interruption. Monthly reviews are too loose for me and weekly can feel too chatty; roughly every two weeks tends to be the sweet spot, with occasional distraction-free working sessions when something needs to be hammered out in real time.
How I Give and Receive Feedback
I prefer feedback as soon as possible. If something is off, I’d rather hear it close to the event, while it’s still actionable, than have it stored up for a formal review months later. I always disliked how interpersonal feedback in previous roles would be deferred into six-month increments; by that point, the signal is stale and the trust required for behavior change has often eroded.
I also tend to respond best to challenge when it is informed rather than performative. If someone questions a technical choice in a way that shows they understand the tradeoff, the scope, or the constraint I was working under, I usually find that energizing. I like being pushed. What lands badly is the hindsight version of skepticism that treats every untested path as an obvious omission rather than a function of scope, money, time, or simple human limits.
I’ve had both private and public praise, and they land differently. Increasingly, public recognition matters to me. It helps my peers understand what I’m contributing, confirms that I’m being a team player, and ensures management actually understands my value. I’ve learned that while hard work is the baseline, people skills and organizational politics have real dividends. Autonomy and trust are rewards in their own right, but at a certain level they stop feeling like special praise and start feeling like the baseline expectation of the role.
What I Expect From Collaborators
The best collaborators for me are usually people who complement my skill set rather than mirroring it. I do well with people who bring strong taste, perspective, or definitive judgment where I might be over-indexing on caution. I also work best when I don’t have to originate every vector; I am often happy to be “along for the ride” as a strong second or a sharp finisher for someone else who knows what they want and is willing to drive.
One of the fastest ways to get my attention is to make clear why you are coming to me specifically. A vague “any thoughts?” ask is hard for me to engage with. A much better opening is one that names the subject, the deadline, the decision at stake, and the reason my judgment matters here. What really motivates me is not flattery for its own sake; it is knowing that my work might materially help decide what happens next.
That also means I respond well when someone treats my unfinished work as usable judgment rather than waiting for everything to be formally blessed. In my world, draft and deliberative work is often the best available picture of reality. If a collaborator can say, in effect, “this is not fully settled yet, but it is our best chance at understanding what is going on,” I am likely to lean in hard.
What makes collaboration easier for me is clear expectations: due dates, victory conditions, and regular review points. I tend to do best with a roughly two-week rhythm—enough time to get real work done, but not so much that the work disappears into the background. If something is sticky, I often benefit from a dedicated working session with no distractions, just enough time to hammer it out with another person in the room.
What makes collaboration harder for me is opacity and drift. Endless meetings with no clear decision or resolution in sight are a fast way to lose momentum. I also find it difficult to work with collaborators whose contribution is hard to read or who remain largely absent from the coordination loop. I value legibility and engagement: I want to know where you’re stuck, what you’re working on, and that we’re moving the work forward together.
Inspired by Julie Zhuo’s user guide framework. If you work with people, consider writing your own — the template is here.