Product Development: II. Meetings

Engineering, product, design and security are core to any team building AI-native products. I prefer small, tight-knit teams within the same timezone, if not the same office space. I feel that efficiently running in-person standups and weekly meetings is better than Geekbot. I don’t do 1:1s with engineers b/c it is a tax on all our future time without a view of where the world will be. My alternative is also detailed below.

Normally, I run the following meetings:

  1. Standup
    • Daily
    • 1 meeting per workstream/pod
    • Format:
      1. 1 min each person
      2. What did you do, what will you do, where are you blocked
  2. Demo
    • Friday / Weekly; Thursday if short week
    • Each pod/workstream presents objective and results from the past week
    • Compulsory for EPDS
    • Anyone else in the company can join / open invite
  3. Planning
    • Friday / Weekly; Thursday if short week
    • Each pod/workstream will work with PM
    • Format:
      1. Figjam Retro
      2. Outline the objective for the week
      3. Task breakdown/allocation
      4. Bug owner (round-robin) / Bug Prioritization
      5. OOO notices

1:1s

Now, the elephant in the room, one-on-one. We tax our future selves when we block recurring time on our calendars. Two things end up happening:

  1. Critical discussions and feedback are delayed till the meeting
  2. We are forced to have a meeting even when we don’t need one

Feedback should be actionable, direct, kind and real-time. If you have a culture of recurring 1:1s, people sit with feedback till the next meeting. The same happens with critical decisions that can impact the company/career.

The second bullet is self-explanatory. I have seen enough teams sit through these meetings or have aimless ones just to fill the calendar with this one meeting they think they should have.

My alternate is simple:

  1. The onus is on the senior/manager to ensure they build/grow the relationship with their team. It is also their responsibility to help the individual figure out the unknown unknowns.

  2. The individual is expected to reach out to the senior/manager when they need help/feedback/clarification. They should also reach out when they have feedback/ideas/concerns.

  3. When a gap is identified, a plan is put in place with milestones and check-ins. This has a definite end date and does not go into perpetuity.

You can read more about how I approach product development cycles and principles here and here respectively.

Find me elsewhere on Twitter/X, Farcaster, and Github. I don't use LinkedIn much and emailing the hello@ alias on this domain is the best way to get in touch.