Answering predictable questions

Description

  • Most time spent answering questions is lost, especially if those questions are repeated

Disproof

  • Dashboards and docs that people actually use first

Consequences

  • When engineers are DM'd for delivery status, engineers start losing 20% of their day from interruption and context switching
    • Surprise surprise, delivery takes 20% longer and anyone whose work is scheduled on the original delivery time, proceeds to get rekt
  • When PMs are treated as living product/marketing documentation, other teams learn helplessness, creating a reinforcement loop
    • Suddenly PMs don’t add value anymore because time that could be spent on real product work is burnt
  • Status questions thankfully go away, but 'how to use' and 'how to sell' questions represent an evergreen time sink
  • Eventually, organisational fitness is lost to the point where it is outcompeted, and dies

Causes

  • When nobody has explicitly thought about what information is needed by who
  • When it’s been normalised to ask people questions that a transparent and easily locatable document/tracker/dashboard could answer
  • When a product team has developed an allergy to ‘feeling watched’, and doesn't propagate status outwards
    • Usually due to bad relationships with the rest of the company, or historical micromanagement, and as a result, under-reports status
    • Ironically, the only way the rest of the company has for understanding what’s going on is to interrupt by polling for status, making product people feel more watched
  • Things further slow down if there’s no standardised way of reporting status and you’re making things up every time someone asks a similar thing
  • In the case of 'how to use/sell' questions, can be when product teams are too busy or not taking responsibility for the end result of actually getting documentation used by making them relevant/readible/findable

Approaches

  • If a company’s culture has evolved in such a way that it’s OK to do this, it’s going to take a lot of butt-hurt and boundary-setting to claw people back to it
  • Design something truly appropriate for the work you do and for who needs to know
    • Any solution that has not properly anticipated the information needs of its consumers (i.e. everyone else in the company) will fail because it won’t tell them what they need to know
    • Any solution that doesn’t build a habit in its consumers will fail because they won’t remember to use it
    • Any solution that has not properly anticipated the need for the product team to not do pointless paperwork will fail because they won’t fill it out