Why is this a problem? You can replace meeting time with time reading specs / requirement if you’d like. Point is you need some constant amount of time to understand the problem domain. If 2 people need to do that then that’s twice the time needed.
Having a meeting involves more than 1 person spending time. Reading a spec involved only one person investing time (only those that need to know it anyway).
Doing it in a meeting where everyone has different questions, tangents and other cruft that you have to sit through is extremely inefficient.
If you have 2 part time devs with a manager giving them the info in the meeting, that's 3 people spending time, and the two part-time devs won't have 100% overlap of information needed and questions asked and answered (and if you have two separate meetings with each PT, then they won't have access to the questions/answers discussed with the other dev _in case_ they need it).
Additionally, everyone can focus on producing and consuming information in the downtime between focus-work sessions, without interrupting flow at someone else's convenience.
In all cases, quality documentation is more likely to produce accurate information transfer with less time wasted by everyone involved.
I dunno. I for one wouldn't want to work at a place where I'm just handed a bunch of docs to implement. I want to be able to ask questions for clarification, suggest alternatives etc. All of which takes time.
We run a 5-person dev team (1 designer, 2 technical founders, 1 dev full-time, +1 part-time dev) with 30 minutes of sync-time per week for non-founders. Our part-time dev can perfectly run with those specs thanks to our encouragement of daily documentation and written specs rather than waiting for a big meeting to ask and be asked questions.
Heavily depends on the nature of the work in question and size of team. Larger the team, and more foreign the domain the more time is needed to coordinate work.
Broadly, I disagree, at least when talking about any team or sub-team focused on software development.
It depends more on the personalities, values and organization of the workplace and the team — for any size, if more than 20% of people involved need to spend more than 2 hrs/week in meetings — it is an organizational/ops issue, not an inherent feature of the work.
> more foreign the domain the more time is needed to coordinate work
More foreign to who? If it is foreign to individual team members, then it is a problem of insufficient onboarding/training material and process, poor documentation, or under-qualified hire.
Foreign to the engineers. Onboarding still takes time, regardless of documentation. There is a reason why CPAs takes a year to complete, even though there are lots of high quality written material that have been used for decades. Ever tried getting productive yourself quickly when working with some domain specific software like accounting? There is a lot of context that needs to be learned.
Yea this has been my experience as well. You either have meetings, or spend hours reading specs and a sync talking back and forth to ensure the requirements are correct.
The only way I see real value is if you’re the sold dev/architect or if you can come in and confidently pick up tickets and they’re properly scoped and documented.
What are you building that requires an individual dev to read hours and hours of spec? I’d like to think my company builds some pretty cool shit, and even then, I can explain an issue in less than 2 paragraphs.
If you need developers to spend so much time ideating and figuring out how and what to build, you’re mismanaging those developers imo.
The time require by devs for non coding work is inversely proportional to how relatable the domain is and how specific the problem is. Tell me to build a clone of twitter and I can make a lot of autonomous decisions. Tell me to be an ERP and I'll be spending most of my time not coding. Most of software development are in domains that most people don't intuitively understand.
