Tried this many times, never got it to work properly.
I’m not sure if it’s because my teams are too small, or I’m bad at communicating.
When discussing technical specifications the most efficient way in my experience is to throw people into a room with a whiteboard and a few laptops and don’t let them come out until they’ve ironed out each other’s concerns; while this is uncomfortable, the alignment is unmatched by anything else I’ve tried.
In my current role we write detailed technical specifications in google docs; but the end result is similar, an ocean of tech specs that may be defunct or relevant or in draft status, dense reading and/or infinite questions once the document is produced (or worse: no questions at all! Which means either people didn’t understand it or they think it’s fine).
I also have this experience and I've gone as far as to build this understanding into how I improve teams.
I wrote myself a short alternative to the agile manifesto which includes the phrase "Build context; not documents". The documents are relatively worthless if you cannot get context across, so I also prefer these big sessions where everyone is in the room.
But I take it a step further. Instead of just having meetings where we discuss I start to drive in structure and formats. The team knows by the 3rd iteration what the process will look like: we do some customer empathy discussions, identify requirements, break down into something that looks a bit like a C4 architecture, and then break down into task dependencies. In each of those sessions I create the structure and coach the team in the workshop but also 1:1s to start using structured processes and less ad-hoc ways to communicate. For example, if we enter a requirements conversation about the customer and someone talks about MongoDB I tell them we need to defer the DB conversation. If we open a Miro board I enforce that we all use the same types of diagrams to discuss the same thing at the same level of abstraction (increase team discipline).
After the team learns the supporting structure for the process, the process takes less time each round. Lots of waste generated by confusion or off-topic discussions or non-critical points are removed or deferred to the right time. I did this with multiple teams in the same company, usually the first round takes 1-2 months, but the 2nd round takes 1 month, the 3rd can take 2 weeks, by the 4th round they can do everything without me (on average). They end up creating documents, but the difference is: now they have context, and they are "fully literate in a new language" which lets them move faster.
I’m not sure if it’s because my teams are too small, or I’m bad at communicating.
When discussing technical specifications the most efficient way in my experience is to throw people into a room with a whiteboard and a few laptops and don’t let them come out until they’ve ironed out each other’s concerns; while this is uncomfortable, the alignment is unmatched by anything else I’ve tried.
In my current role we write detailed technical specifications in google docs; but the end result is similar, an ocean of tech specs that may be defunct or relevant or in draft status, dense reading and/or infinite questions once the document is produced (or worse: no questions at all! Which means either people didn’t understand it or they think it’s fine).