I'm curious about your industry - are you in a compliance heavy environment like automotive, aerospace, finance, etc? What are you working on? It matters - a si

I'm curious about your industry - are you in a compliance heavy environment like automotive, aerospace, finance, etc? What are you working on? It matters - a simple CRUD app probably doesn't justify a design session: the problems are well known and understood and the solutions are usually straightforward to implement and to change. However, let's assume for a moment that you have these meetings regularly, that everyone fully engages, and that the meetings don't get sidetracked: what problem are you trying to solve? Just that you have a spec to use during implementation? That you get a say in how things are built? That you don't paint yourself into a corner architecturally? Counterpoints: 1. An implementation spec might not be that useful. If the person working on the task understands it thoroughly, it might be more work to spec out the task and communicate the impact/rationale to others than it would be to just do the thing. Additionally, given that business requirements will change, your spec document will no longer be useful in the future (it will be an outdated specification for a system that solves a problem that no longer exists). If you want a spec for your own purposes, write one. You could even go so far as to solicit feedback on it before you start writing code. Personally, I find that writing this kind of detailed spec up front takes the joy out of programming. "All of the problems are already solved and now I just have to translate prose into code" does not make for a very fulfilling career. 2. If you want a say in how things are built, talk to people. I suggest doing it through the lens of helpfulness (e.g. "I know a lot about this component that you're changing, there are lots of sharp edges and moving pieces, and I'd like to help you navigate them if you're open to it"). A spec is not the only way to accomplish collaboration. 3. If you don't want to paint yourself into a corner architecturally, get the team to agree on longer term, big picture technical/architectural goals. You (presumably) hire skilled engineers. Build a shared vision for the thing you're working on and let the skilled people on your team carry the system toward that goal. You don't have to be personally involved with every architectural decision. Personally, I only find design sessions useful when talking about the big picture: tell me about the system as a whole and how it interacts with other external systems. Anything more granular than that, my eyes start to glaze over and I rapidly lose interest. Discussing a hypothetical software system in depth is not something that I find productive. Give me an IDE and some code to read and I'll build a much better understanding of what needs to happen than a meeting will ever give me. All of that said: if you work in automotive, aerospace, or other compliance-heavy industries, design sessions that involve a compliance SME are a must. You don't need to get so granular as to start specifying classes and stuff like that, but establishing clear requirements that must be met to remain in compliance is just something you have to do. Not doing so is professional negligence. Design sessions are useful here because the compliance requirements (generally) change much slower than typical business requirements.