Make Phone Meetings Great Again!

20 Oct

Remote teams live and die by the phone meeting. So, how can we prevent death? Channel Rumsfeld. Begin with known knowns. Have a clear agenda, have a discussion leader, and end with a summary. Do those well. Then try out some ideas to address well-known challenges: disengagement, social friction, exclusion, time wastage, and inability to follow what’s going on.

  1. People on the phone can’t always tell between the two uses of brief silence—a brief pause, and signaling opening the floor for discussion. The speaker can address the issue by signaling the end of speech with a phrase. A speaker may start the speech by noting: ‘at the end of what I have to say, I will formally open up the floor and go around alphabetically among those whose speakers are unmuted.’
  2. Having ‘too many’ people = wasting people’s time + disinterested participants. How many is too many? Max. number of people that can productively engage where everyone is expected to contribute is probably as low as 4–5. Ask people to discuss independently within their own teams and share notes.
  3. Prevent or Cure Rambling as side effects are the same as above—time wastage and disinterest. The discussion leader should take on the responsibility to energetically understand the point people are trying to get at if people are having trouble articulating. The discussion leader may also refer the person to the shared document to sketch out the idea and try again.
  4. Slides/stuff in advance that everyone actually reads is important. Just tell people if you didn’t find time to read + independently think, just opt out (semi-private opt-outs with emails to meeting organizers should be allowed). The job of a meeting is not spoon feeding.
  5. Keeping people on the same page:
    • Visual aids, e.g. slides, are useful in bringing people on the same page.
    • Taking notes on a shared screen can also help see people that progress is being made. The document can be shared and that allows others to contribute and organize simultaneously.

Most importantly, avoid meetings when you can. If the aim of meeting = transferring information, it only makes sense to have a meeting < 10% of the times. Alternatives = write out a document, or create a slideshow or a video and send it along.

(Software) Product Development Cycle

6 Mar
  1. Solicit Ideas
    Talk to customers, analyze usage data, talk to peers, managers, think, hold competitions, raffles,…
    For each idea:
  2. Define the idea
    Write out the idea for clarity — at least 5–10 sentences. Do some due diligence to see what else is there. Learn and revise (including abandon).
  3. Does the idea make business sense? Does it make sense to the developers (if the idea is mechanistic or implementation related)?
    Ideally, peer review. But at the minimum: Talk about your idea with the manager(s) and the developers. If both manager(s) and developer(s) agree (for some mechanistic things, only developers need to agree), move to the next step.
  4. Prototype
    This is optional, and for major, complex innovations that can be easily prototyped only. Write code. Produce Results. Does it make sense? Peer review, if needed. If not, abandon. If it does, move to the next step
  5. Write the specifications
    Spend no less than 20% of the entire development time on writing the specs, including proposed functions, options, unit tests, concerns, implications. Run the specifications by developers, get this peer reviewed, improve, and finalize.
  6. Set Priority and Release Target
    Talk to the manager about the priority order of the change, and assign it to a particular release cycle.

  7. Who Does What by When?
    Create JIRA ticket(s)
  8. Code
    General cycle = code, test -> peer review -> code, test -> peer review …
    MVP of Expected Code or Aspects of good code: ‘Code your documentation’ (well-documented), modular, organized, tested, nice style, profiled. Do it once, do it well.