Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Unlike me, 56 and yet to be wrong once.
  • That's what it took to finally support Agents.md I guess. Boris had to blog about having made a mistake.

    How about you stop taking things so personal instead and let others steer more.

  • It’s often struck me how many “leaders” basically jump to step 6, and come up with an urgent set of superficial actions without even clarifying what they’re trying to do. There’s probably some value in “bias for action” as you might call it. But it’s been one of the difficult adjustments for me, how little people want to think.
  • Steps 1–5 of his framework are increasingly formal ways of saying “figure out what’s going on before doing something,” followed by step 6: “then do it fast”
  • I am confused by step 5.

    A. Why define the goal after identifying the solution? Or does define the goal mean identify a stopping point for step 4, in which case you must first define the solution?

    B. Isn't the goal explicit in a clear problem definition?

    1) Ambiguous problem definition with no implied goal: We need more money.

    2) Clearer problem definition with implied goal: We need $500K by Monday.

  • > 3. Define the problem

    If you do this step well, in my experience, the next steps fall into place quickly.

    My version: accurately naming the problem is the essence of problem solving. There are things you usually need to do before you can accurately name the problem, because most problems aren’t presented to you in textbook form.

    Once properly defined and framed, it’s obvious how to solve most problems, most of the time.

    If you’ve ever worked with someone amazingly good at accurately naming the problem, it’s hard to unsee it. This is one of the hidden talents of the most effective people I’ve met.

  • This seems strongly aligned with the Amazon doc-writing and decision making process. I found it to be unusually effective as a business process, and took it with me when I left to my current role.

    Making thoroughly informed decisions and iterating on a decision doc before committing to a direction and plan is better than every alternative I’ve ever observed in my career.

    The criticism I’ve read thus far on this thread seems unwarranted. I give the same kind of feedback to my mentees when their work product or process could use improvement.

  • I have worked in GTM/PM consultancy for some time now. This is the patterns I often observe:

      - Have a vague understanding of the problem
      - Architect an overcomplicated solution thinking of all possible contingencies
      - Pitching the overcomplicated solution to someone else
      - Ask them to come up with a simple solution. Ask questions to "birth" to the solution.
      - Not providing any feedback as that would mean need you to be accountable for the work
      - Trying to convince them they should work out the solution because they are the expert and much smarter then you
      - Taking credit for solving the problem
    by wqtz

Explore Birbla archives