Skip to main content

At a Glance

Your quick read for how to work with me: response times, office days, capacity, and feedback style.

Response time

Email 24–48h

Teams same-day · Urgent within 1 hour.

Preferred: written

Office days

Mon + Wed

Bristol office, 7am–4pm.

Capacity

Max 3 items

Everything else waits in triage until capacity frees up.

Feedback

Direct + kind

Tell me the issue and what good looks like.

🚫 Important: The "No" Protocols

I say no to: end-of-day asks, meetings without agendas, surprise decisions, info dumps. Truly urgent means life/death or imminent harm only. Learn more →

🙋 Personal

▼

Conversation starters

Not great at small talk? Get started with one of these conversation starters.

  • Why I took up running.
  • The time I handcuffed myself to a shopping trolley.
  • The Back to the Future Trilogy.
  • Why I became qualified as a touch-typist at age 16 (RSA I/II/III, Pitman Advanced, C&G).
  • One space or two after a full stop; discuss.

My humour

Dark. Occasionally smutty. Shaped by Bottom, Red Dwarf, Blackadder, and a childhood of British comedy where wit required reading between the lines.

My eldest daughter has decided it's a feature, not a bug. I'm inclined to agree.

Favourite quote

"

Progress over perfection

📚 Books I'm reading (January 2026)

💡 Things I'm interested in (January 2026)

  • Digital compartmentalisation: Keeping work, home, and learning separate but integrated.
  • GitHub Pages: Static sites, version control, deployment pipelines. Simple, elegant.
  • Building my home office: Navigating planning permission and creating a proper workspace.
  • Ubiquiti UniFi network: Building home infrastructure that actually works.

📖 Basic Essentials

▼

✅ Quick Facts

Superpowers & Kryptonite

✨
Superpowers
  • Creating order from chaos (structure, systems, accuracy)
  • Deep listening and understanding (the thinking, not just the words)
  • Spotting inconsistencies and gaps (fact-checking as muscle memory)
  • Winning at GIF games (yes, this is a real skill)
⚡
Kryptonite
  • Detail rabbit holes (easy to disappear down them)
  • Task switching (kills momentum and clarity)
  • My racing brain vs. my speaking speed (misalignment)
  • Being transparent about health/capacity
  • Sending things before the wife's sanity check

💬 Communication

How to reach me (in order of preference)

  • Email: For anything that needs detail, retrieval, or a record.
  • Teams: For time-sensitive things that need same-day response.
  • WhatsApp/Signal: For truly urgent matters that need immediate attention.
  • Teams call: Only if it's genuinely urgent; I'll pick up.

My communication style

  • Direct and explicit: Never intended to offend, but clarity wins over softness.
  • I read everything: I reply only when needed. Silence usually means I agree.
  • Writing beats in-person: I'm clearer in writing. In conversation, you'll hear my thinking process out loud.
  • Over-communication wins: Use bullets, use @mentions, be specific.
    Ambiguity is worse than too much detail.
  • Clear asks, not pings: "Hello" without context is noise. Specific asks are music. See nohello.net for why.
  • Names matter: Getting your name right is important. If I get it wrong, I genuinely want to know.

Email specifics

  • CC: Means "for your information". I check it less frequently than TO lines.
  • @mentions: Flag action required. I'll see these and prioritise response.
  • Structure: Lead with the ask/action/deadline, then reasoning, then supporting facts.
    See Bottom line up front for why.
  • Everything is kept: I read and archive everything. Useful for reference and follow-up.

Related

🧭 Logistics

  • Bristol office: Monday and Wednesday (7am to 4pm). I have a 2 hour commute!
  • Remote or customer sites: Other days with core hours roughly 10am to 4pm, with flexibility for life.
  • Non-negotiable: Evenings and weekends are family time.
  • Dispersed teams: I adapt for global collaboration; I take time back later.
  • Your boundaries matter: Please share yours so we can respect them together.

📅 Availability

Calendar management

  • What's on my calendar is accurate: If it's blocked, I'm not available.
  • Focus blocks: Purple blocks = deep work, do not disturb.
  • Flexible time: White space = available for meetings if you need me.
  • Book directly: You don't need to ask permission; just send the invite.

Response time expectations

  • Email: 24-48 hours for non-urgent matters
  • Teams: Same-day during working hours
  • Urgent channels: Within 1 hour if truly urgent
  • Outside hours: I won't respond until next working day

Best times to book me

  • Mondays/Wednesdays: 10am-3pm (in Bristol office, easier for in-person)
  • Other days: 11am-3pm (remote, better for focused conversations)
  • Avoid: Before 9am, after 4pm, or Friday afternoons

Regular time off

  • School holidays: I may have reduced availability for childcare
  • Notice: I'll flag capacity changes at least 2 weeks ahead

💬 How to Give Me Feedback

What I need from you

  • Be direct: Open and honest wins. I can handle it.
  • Tell me how to improve: Don't just tell me what I'm doing wrong. Tell me what good looks like and how I can get there.
  • Make it clear you're giving feedback: Say "I want to give you some feedback" so I know to listen differently.
  • In the moment is best: Feedback minutes or hours after something happens is useful. Days or weeks later loses context and impact.

How you'll know I've heard it

I'll play back what I've heard to you. This helps me check I understood correctly and shows I'm taking it seriously.

Don't be scared

If you're worried about giving me verbal feedback - don't be. Honestly. I'd rather hear it directly from you than wonder what you're thinking or have it come up later in a review. Direct feedback helps me improve faster and shows you care about working well together.

🚫 The "No" Protocols

  • How to ask: Written requests with context and clear ask. Not drop-in interruptions.
  • I say no to: End-of-day asks, meetings without agendas, surprise decisions, info dumps.
  • Truly urgent means: Life/death or imminent harm. Everything else can wait for a response.

See Advanced: No Protocols for full context and why I'm working on this.

📥 Work Intake Process

The "No Protocols" explain what I won't do. This explains how to give me work in a way that works for both of us. I manage capacity carefully, so clear intake helps me prioritize fairly.

How to submit work

  • Or submit directly: Email, Teams message, meeting notes. Anywhere works. I'll ingest it.

What I need to know

Include as much as possible:

  • Context: Why does this exist? What problem are we solving?
  • The ask: What specifically do you need from me? (Decide? Review? Build? Unblock?)
  • Deadline: When do you need it? "No rush" is useful too.
  • Who's asking: You, your manager, leadership team? (Helps me prioritize.)
  • Impact/Urgency: What happens if we don't do this? Business impact? Blocker for others?

My capacity model

  • I hold max 3 active work items. Everything else sits in Triage until something completes.
  • Prioritization: Urgent/Impact first, then seniority level (requests from my VP+ get higher priority), then order received.
  • Fair expectations: Work from senior leadership gets higher priority, but I'll be transparent about impact with you. ("This moves your deadline back because X is critical now.")

Track your work in Planner

  • Check the backlog: Everything I've ingested lives on my Planner board. It's your source of truth.
  • Status updates: Look for comments on your item. I update via comment, not messages.
  • Triage means "not yet assessed": Your request is logged but not prioritized yet. Don't worry, I see it.
  • In Progress means I'm working on it. Blocked means I'm waiting on something.

⚙️ Working Preferences

My tools of choice

  • LogSeq and Obsidian: My go-to tools for notes, knowledge management, and thinking through problems.
  • Bullet journaling: When I can't use digital tools, I revert to pen and paper. Still effective.

I work in the open

  • Available from day one: If I'm writing a whitepaper or document, it's accessible as soon as I write the first line. No need to wait for "done".
  • No permissions needed: I'll communicate where my open working directory is. Jump in, read along, comment, collaborate.
  • Work in progress is valuable: You'll see my thinking evolve. Early feedback is welcome and saves rework later.

Documentation is my happy place

I love writing documentation. Yes, I'm a nerd. Clear docs reduce confusion, save time, and help teams scale. If something needs documenting, I'm probably already excited about it.

🚀 Advanced Topics

▼

🧠 How I Like to Work

  • Meetings as a last resort: I prefer async communication and written updates. If we need a meeting, there should be clear preparation, a pre-read, and a specific agenda. No surprises.
  • I hate surprises: Flag blockers, delays, scope changes, or problems early so I can adjust and respond thoughtfully. Transparency before panic.
  • I need preparation time: I minimize notifications during deep work (email off, Teams on DND). During focus blocks, I'm truly focused. Come back when the time is right.
  • Capture as you go: Meeting notes and actions should be written collaboratively in real time. Clarity in the moment saves rework later.

How I structure 1:1s

  • Shared working doc: We keep running notes in Teams, Confluence, or SharePoint. Agenda is yours. Raise concerns, development topics, blockers, anything that matters.
  • Pastoral, not status: 1:1s are for relationship-building and development, not project status (that's async). If you need something, I'm here for it.
  • Your agenda: You own what we discuss. I'm here to listen, coach, unblock, and support your growth.

🧩 Decision Frameworks

I use a few core principles to make calls clearly. Here's how I think about decisions:

The four signals I need before deciding

If I'm missing any of these, I'm gambling, not deciding. I need:

  • Root cause signal: Is this a symptom or the disease? Example: "Sales are down" is a symptom; "the checkout button is broken" is the disease.
  • Reversibility signal: How hard is it to undo this decision?
    • Type 1 (one-way door): Very difficult to reverse. Slow down. Seek 90% confidence and multiple expert opinions.
    • Type 2 (two-way door): Can be undone easily. Move fast. Seek 60-70% confidence. Progress beats perfection.
  • Counter-evidence signal: What's the strongest argument against this choice? If I can't find one, I probably have confirmation bias.
  • Opportunity cost signal: If I spend time and resources on Option A, what am I explicitly choosing NOT to do?

The WRAP process

I use this to prevent short-term emotion from affecting outcomes:

  • Widen my options: I never choose between "yes or no". I force myself to find at least three viable alternatives.
  • Reality test: I find someone who disagrees with me and understand why. This challenges my thinking.
  • Attain distance: What would I tell a friend to do in this situation? This removes my immediate fear or ego.
  • Prepare to be wrong: Set a tripwire: "If X hasn't happened by Y, we stop and reassess."

Resources I rely on

📊 Measurement of Success

I don't care where you do your work. It's about outputs and impact. Here's how I measure whether work is actually successful:

What "done" actually means

  • Feature shipped to users: Code merged is nice; users benefiting is better. It needs to be working and production-ready.
  • Code quality checked: If you're rushing code through the pipeline ignoring quality issues flagged in review, it's not "done". Get it right the first time.
  • Decision made and documented: We might find it's wrong later. That's fine. But if you made it using available information and can explain why, that's success. Document your reasoning so we learn from it.
  • Deliverables completed: Even if not perfect. Progress over perfection. Completed, not abandoned.

How I measure impact

  • Move your objectives forward: And help move others' forward too. Don't be selfish. Think about company impact.
  • Use data to prove it: Saved cloud costs? Made something more efficient? Faster resolution on tickets? Spread knowledge? Show me the metrics.
  • Customer validation matters: Faster ticket resolution is great, unless the customer doesn't think the ticket is closed. They're the judge. Check that they're happy it's closed; then it's closed.
  • Open documentation: Don't hoard knowledge. Write it down so others can benefit and learn from what you did.

Quality philosophy: The rework test

Quality threshold: "Will this require someone else to fix it or rework it?"

  • YES: Slow down and get it right first. The further code moves up the pipeline, the more expensive rework becomes.
  • NO: Ship it. Iterate if you need to. Done is better than perfect.
  • No 2am wake-ups: If you broke something downstream and someone has to run a manual process at 2am, that's not done. That's leaving a mess.

The metrics that actually matter

  • Deployment frequency of working features: How often are you shipping things users can use?
  • Test coverage and quality: Does this need testing? Are the pipelines passing?
  • Decisions made vs delayed, and accepted: Did you make the call? Does it stick?
  • People unblocked: How many colleagues can now move forward because of your work?
  • Time spent mentoring: Are you growing others?
  • Documentation written: Did you leave good records?

What's NOT success

  • Constant rework: Delivering something, then having to fix it repeatedly wastes everyone's time.
  • Breaking things downstream: Your feature works, but it cascades failures to other teams. That's a problem.
  • Shipping without user validation: You built it. Does anyone actually use it? Does it solve their problem?
  • GitHub commit history as a proxy for work: Lots of commits ≠ good work. Deployment frequency of working features is better.

🎓 How I Learn Best

I learn by doing, not by watching. Give me solid pre-read time first so I can immerse myself and prepare, then let me get hands-on with feedback as I go. I'll ask questions to validate my understanding.

Pre-read essentials

  • High-level overviews and diagrams: Diagrams are more useful than people think.
  • Skip the code: I don't read much code; focus on the architecture and the why, not the implementation details.
  • Give me time: Let me immerse myself in the material before we start.

The hands-on part

  • I'll watch what you're doing: Not necessarily have it explained step-by-step.
  • I'll ask questions: To validate my understanding as I go.
  • Feedback in the moment: Helps me learn faster.

The clarity test

  • When explanation requires effort: That's a signal the concept is over-complicated. Simplify it.
  • When something's unclear: Simplify the language, add examples, or break it into smaller pieces.
  • If it needs work to explain, others will struggle too.

What doesn't work

  • Click-click-click e-learning modules: I switch off. Dull, monotonous training loses me.
  • Passive watching: Without the chance to engage, I'm not learning.

What I need from you

  • Show me passion and energy. I feed off it. Engagement matters more than perfection.
  • Be excited about what you're teaching. That energy is contagious.

👥 Collaboration

Whiteboarding is my thinking tool

  • In-person: Shared drawing and whiteboards.
  • Online: Shared whiteboard tools or MS Paint if needed; tablets are great for quick sketches.
  • A picture paints a thousand words: I use drawing for all problem types: architecture decisions, process flows, problem decomposition.
  • Everyone draws simultaneously: This is collaborative thinking, not passive watching.

Brainstorming

  • Free-form and expansive: Build on ideas; don't sit in your own bubble waiting to create something new.
  • Building on an idea is as valuable as creating one. I'll say "that's interesting, what if we..." as much as I'll propose something from scratch.
  • After we brainstorm: We share the sketches to broaden knowledge and document thinking.

Documentation & write-ups

  • Work in the open: Share sketches and thinking as we go.
  • Sometimes I own the write-up: The act of writing helps me figure things out. I tend to want it to be perfect, so I may iterate.
  • The goal is shared knowledge: Not gatekeeping. Get it documented so others can learn and build on it.

🚫 The "No" Protocols (Full Context)

I struggle with saying no. I want to help, and I worry that setting boundaries means letting people down. But unfiltered access to my time means I can't do deep work, and "yes" without process means commitments I can't keep. Here's how I'm trying to protect focus without being a blocker:

How to ask for my time (the pipeline)

  • Written requests win: Email or Teams message with context, the ask, and why it matters. This lets me assess impact, urgency, and fit with current work.
  • Not drop-in asks: "Can you check this?" or "Can you read this?" interrupts focus and ignores my existing pipeline. Use the written request process instead.
  • Lead time matters: Same-day asks are gambling on my availability. I need time to review, think, and prepare; especially for decisions.
  • My counter-offer: "Yes, but later" or "Yes, but let me read it first". I'm happy to help, just not instantly.

When I automatically say no

  • End-of-day asks: My brain is checked out. If you catch me at 3:45pm, I'm not ready for new information. Come back tomorrow.
  • Surprise AOB items: Last-minute "any other business" that requires decisions or commitment. If it's not on the agenda, it waits.
  • Meetings without agendas: No prep, no clarity, no attendance. See How I Like to Work for why.
  • Information dumps followed by "decide now": I can't process a wall of verbal information and make good calls. Write it down, then I'll engage.

What counts as truly urgent

If you need me right now, it should be one of these:

  • Life or death: Literal safety risk to people.
  • Imminent harm: We're about to destroy something critical (data, systems, relationships, reputation).
  • Everything else can wait: Even "urgent" work benefits from time to think. Write it down, flag it clearly, and I'll respond.

What I'm working on (honestly)

I'm trying to stop trading my time now for theoretical future reciprocity. Saying yes doesn't bank goodwill, it just means I'm overcommitted and underdelivering. I need better boundaries, but I'm not there yet. If you see me slipping, call it out.

🐛 Known Defects

▼

Welcome to the Production Environment. While every effort has been made to ship a stable version of myself, please be advised that this build contains several legacy features and unpatched vulnerabilities.

Below you'll find open issues in the backlog. These are documented features, not system failures. Please review before submitting a bug report.

#DEF-001 Migraine Trigger Under Load
Critical health Open

Description: Stress, tiredness, poor eating/drinking habits can trigger system instability. Early warning signs include difficulty concentrating and possible emesis.

Workaround: Sleep in a dark room; coffee, painkillers, sumatriptan can stabilize the system. Preventive measures include regular breaks and adequate hydration.

#DEF-002 Context Assumption Bug
Minor communication Wontfix

Description: May assume shared context and skip explanatory details. This optimization reduces communication overhead but can cause confusion for new collaborators.

Workaround: Simply ask for additional context. I'm happy to expand on details and will recalibrate my assumption levels based on feedback.

#DEF-003 Misophonia Audio Processing Error
Major sensory Open

Description: Certain repetitive sounds (loud eating, tea slurping) trigger unexpected system responses. Audio processing filter appears to be overly sensitive to specific frequency patterns.

Workaround: If I'm also eating, the effect diminishes significantly. May need to step away briefly to reset audio processing. Generally manageable with awareness.

#DEF-004 Loud Keyboard Typing
Minor sensory Open

Description: I type with considerable force on my laptop keyboard, producing noticeable noise. Affects cohabitation comfort (wife's annoyance is a key metric). Danger escalates significantly if mechanical keyboard ever introduced.

Workaround: Remote work in separate office, headphones on spouse, or acceptance. Thank goodness for laptop keyboards. Mechanical would be catastrophic.