A related aspect of organization and making decisions is meetings.
Meetings, other than 1 on 1 meetings/collaborations, are best for making decisions, NOT for sharing information.
Information sharing relevant to the decisions to be made should happen before the meeting via group emails (or possibly through a software tool like Jira) with questions and responses. Written information is easier to reference, quicker to search through, and can be multiprocessed in that multiple people can share information or ask questions simultaneously. If additional information is needed after the fact, you can email after the meeting.
Going into a meeting about building a feature or product for example, you should know the constraints on that, and be able to weigh them in making the decision. When is it due? Who is available to work on it, who will test it, who will maintain it, and who is it for? What aspects/functions are necessary, and what are merely desirable? What resources are available? Why is the feature being added? How might it be constructed?
Finally, be ruthless about moving forward in meetings to get to decisions. If a couple of people agree on something, and begin to quibble over the details? Ask if anybody is opposed to that general idea or has a better one to offer. If not you have made that decision, and can decide on the details, but if so, the detail discussion is premature. It's quite probably also premature if you haven't decided who is going to work on it; the point is you want to nail down the higher level decisions, not get lost in the weeds.
Amazon just assumes that nobody will read the prep material and reserves a block of time at the beginning (as long as 90m IME) for silent reading and markup. Seemed to work pretty well.
Meetings, other than 1 on 1 meetings/collaborations, are best for making decisions, NOT for sharing information.
Information sharing relevant to the decisions to be made should happen before the meeting via group emails (or possibly through a software tool like Jira) with questions and responses. Written information is easier to reference, quicker to search through, and can be multiprocessed in that multiple people can share information or ask questions simultaneously. If additional information is needed after the fact, you can email after the meeting.
Going into a meeting about building a feature or product for example, you should know the constraints on that, and be able to weigh them in making the decision. When is it due? Who is available to work on it, who will test it, who will maintain it, and who is it for? What aspects/functions are necessary, and what are merely desirable? What resources are available? Why is the feature being added? How might it be constructed?
Finally, be ruthless about moving forward in meetings to get to decisions. If a couple of people agree on something, and begin to quibble over the details? Ask if anybody is opposed to that general idea or has a better one to offer. If not you have made that decision, and can decide on the details, but if so, the detail discussion is premature. It's quite probably also premature if you haven't decided who is going to work on it; the point is you want to nail down the higher level decisions, not get lost in the weeds.