That's the thing, these meetings are B.S. Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues. There are tools for such communications that do not require talking and immediate responses. Being reactive (which is what meetings enforce you to do) costs more, as reactive and forced responses will be far more technically unsound.
Feature development is rarely so cut and dry that you can hand a developer a task and let them run with it.
To get there, you need a confluence of context and expertise from several domains:
- what problem needs to be solved (user story)
- what options are available (interaction design, technical capabilities)
- what the cost of implementing each option is, and the opportunity cost of each level of implementation / each option (technical capability, resource management, sales, user research)
- managing group consensus on the path forward (communication to technical and non-technical audiences)
- break down of any large chunks of work into smaller tasks that can be done and planning the work to be done in series or parallel (resource management, technical capabilities)
Finally, after all of that, you have a task (or several) that can be handed off.
There's really no way to get here without at least some thought into the implementation details, as the business can't make the decision on which options without knowing rough timelines.
> Engineers need a task, time to think, and write about the solution and its cost. Period. Talking in a room full of people who love to hear their own voices and love to stroke their egos does not actually help engineers do their job. When engineers need to communicate, they communicate with their colleagues.
Seems like when you say "engineers", you mean "people with my exact personality"
