Skip to content

Latest commit

 

History

History
37 lines (33 loc) · 3.65 KB

README.md

File metadata and controls

37 lines (33 loc) · 3.65 KB

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.