Posts

• When every meeting looks the same

  My calendar is full of meetings and for various reasons, I find it difficult to skip them. Some of those meetings help me build context (or keep it up to date) around an area that I care about. Others are there to build and maintain relationships. As a remote worker, I no longer have a space to talk to peers on the way to lunch or while grabbing coffee, so 1:1s fill that purpose too.

  With the amount of meetings in my calendar, I don’t have clarity about which meetings actually need my real-time presence. This is particularly troublesome when there are conflicts and I need to pick 1 of 2 (or sometimes 3) meetings to attend.

  I need a system to decide: Is this important? Do I need to be there in real time? Can I just read the notes afterward?

  Every meeting invite looks the same in my calendar. A 30-minute block with a vague title and a list of attendees. No indication of whether I’m there to make decisions, provide context, or just stay informed. This forces me to make attendance decisions with incomplete information. I end up in meetings where I contribute nothing, while missing others where my input was actually needed.

  I’ve been thinking about this for a few months now and finally wrote down some notes on what I would like to see in every calendar entry. I came up with a template and the first iteration is this:

  # Daniel's Experimental Meeting Template
  
  ## Meeting Notes
  
  *Specify the location of the meeting notes. It may be an attached document, a wiki page, a tab in a document or a shared folder.*
  
  ## Attendees
  
  *Who will find value from attending this meeting? It could be a project manager, designer, stakeholders for a project, your team or engineers working on a specific platform.*
  
  ## Pre-work
  
  *What should attendees prepare before the meeting? Should they come with a list of questions? Or read a document?*
  
  ## Type of Meeting
  
  *What is the primary purpose for this meeting? This helps set expectations for participants.*
  
  - [ ] Fact-finding - Gathering information, understanding current state, identifying unknowns
  - [ ] Decision-making - Making choices with clear authority and accountability
  - [ ] Consensus-building - Aligning on approach through discussion and agreement
  - [ ] Context sharing - Providing updates, knowledge transfer, or background information
  - [ ] Status update - Reporting progress, blockers, and next steps
  - [ ] Dry run - Practice or preparation for upcoming meeting or presentation
  - [ ] 1:1 - One-on-one discussion (career development, feedback, relationship building)
  - [ ] Other: ________________
  
  ## Agenda
  
  *Create a time-boxed agenda to keep the meeting focused. If the meeting is at risk of going over the allotted time, schedule a separate meeting or resolve the remaining issues offline.*
  
  Example:
  - 2-5 minutes: Review action items from the previous meeting 
  - 5-15 minutes: Discussion on [main topic] 
  - 5 minutes: Pulse check on [specific area - project health, blockers, team sentiment]
  
  ## Purpose
  
  *Write one to three sentences describing what this meeting is intended to accomplish. Include what is NOT in scope to prevent scope creep.*
  
  Example: The meeting is intended to discuss the development status and challenges of [project]. This is not a meeting to explore or make decisions on other projects.
  
  ## Exit Criteria
  
  *When should this recurring meeting end or evolve?*
  
  Example: This meeting will stop once Project ABC is either shipped or rolled back.
  
  ## Related Meetings
  
  *List other meetings where this topic might come up. This may be a platform sync, team meeting, or org-wide meeting.*
  

• A random thought on postmortems

  Writing a postmortem is a balance between terse and embellished. Sometimes the embellishments help set the rhythm of the document, like a sixteenth rest in a melody.

• On code style guides and incremental improvements

  In a recent code review, I suggested some changes to improve the accessibility of the feature I was reviewing. The content descriptions for several elements in the user interface were not useful for screen reader users. The author was appreciative of the comments, and they implemented the changes I requested.

• Exploring credentials in my password manager

  My history with password managers

  I’ve used password managers since 2014, from LastPass and Dashlane to the Chrome password manager and macOS’ Keychain. I’m generally a happy password manager user, appreciating the many great features and convenience. However, over time, as I notice product quality issues, I begin to worry.

• Technical Investments

  Our typical day-to-day work as engineers falls into projects, and almost all such projects start with a product goal that tends to be time-sensitive. As a result, we discover cases where we would benefit from a technical improvement to our system while attempting to move quickly to build a user-facing feature.