Hi, I'm James!

This is intended to be a relatively quick introduction to me, how I work, how I prefer to collaborate, and how I can often be best utilized in a work environment.

A little about me

• I tend to focus in extreme detail if it's something that is important to me or the team/project.
• I can be easily distracted (and context-switching is expensive), so I often look for ways to minimize distractions (including working from home, finding "alternative" spaces within a given office space, setting "do not disturb" periods on my calendar, etc).
• I can pay attention to many information streams simultaneously, but often at the cost of being unable to perform complicated tasks.
• I communicate extremely well, but I often prefer to reference documentation wherever possible.

How I like to work

• I like tasks and projects that are clear, concise, and that have a clear Definition Of Done.
• I tend to work more effectively in spaces that are fairly quiet, don't have a lot of visual distractions (flashing lights, other screens, people walking around in my sight-lines, etc.), and where amenities (like drinks, snacks, and bathrooms) are a short distance away.
• I like being able to communicate changes, releases, and documentation through some form of centralized mechanism such as a team Slack channel, Confluence documentation, or Live Demos during a stand-up meeting.
• I prefer short meetings for stand-up (ideally less than 20 minutes), topic- or task-specific meetings with other team members where some amount of detail or focus is required, and if I don't explicitly need to be in a meeting I prefer to just get an email about it with a summary afterward.

How I prefer to communicate

• If it's non-critical, emails are great.
• If it's something really quick that doesn't need to be codified anywhere (like a Confluence document or something), Slack tends to work well.
• If discussing something is going to be complicated or detailed, a one-time meeting (with a summary afterward) is great.
• If it's an emergency, Slack works really well (but then again if it's an emergency, referencing documentation around How To Get Help and What Is An Emergency would probably be better).

What I prefer to avoid

• Repetitive tasks
  • Automation, remediation, or fixing bugs should ideally eliminate toil
• Escalations and emergencies
  • These should ideally NEVER happen (monitoring, metrics, and alerting should notify us before this response becomes necessary)
  • If they happen, they should ALWAYS have a post-mortem and action items to resolve (aka "CAPAs" or "Corrective Actions/Preventative Actions")
• Useless meetings/training sessions
  • If a meeting/training session doesn't have any of the below items, there's no point to me being there:
    • Clear objectives ("what you should know by the end of this session", "what we intend to address", etc.)
    • A clear list of take-aways
    • A clear indication of impact to my job function/project/tasks/etc.
• Ambiguity
  • If there isn't a Definition Of Done, finding that is imperative.
  • If there's no overall direction, visible Milestones, or articulated Vision of the product or service, then that's a big problem.
• Over- or under-communication
  • Constant emails, meetings, and Slack notifications are just as bad as radio silence. Finding the right balance and notification mechanisms is key.