Between high and low level plans

Context

My team is about to start a new project, and I'm trying to figure out how to create and convey plans around it. We're a small team and most folks are still relatively new to the company. The project isn't really *technically* complicated, but there are lots of subtleties and business complications since our work sits between internal and external processes.

My challenge

About 3 hours before a planning meeting yesterday I had a 1:1 with my manager. I had previously shared a design document with the entire team. It contained some diagrams (written with Mermaid JS, which is great) and a high-level breakdown of the work. I'm happy with all of those. But the part I didn't like was the work under those high level tasks. It was *way* too prescriptive. It talked about class names, file layout, that kind of thing. The sorts of planning that turns into tickets that are stifling. But I was struggling to find the in-between I needed: my high level explanation was solid, and if I were doing the work my low level tactics were good, but I was striking out on that middle ground I needed to provide folks so they could do meaningful work.

A solution?

My manager asked a fairly obvious question when we looked at the first high level task: is the pattern to follow here documented somewhere? It wasn't, of course. Since there was no documentation, no list of bits that must be done to have a the type of X that we need, the only way to communicate about the work was by getting deep into the weeds. But this is a place where we *do* have a pattern. It just isn't made clear and is instead sort of emergent out of the other Xs we have built. Could a bit of documentation be that middle layer I was missing? At least for the first chunk of work we are doing that follows existing patterns?

I'm trying it and I'll find out soon enough if the docs I've written help me solve this problem. If they don't, maybe the solution is still good and I just need different docs. Or maybe the solution is wrong. It'll take time to really find out if this level of documentation can solve at least some of these 'mid-level' planning problems I'm running into. But even if it doesn't work, it has shifted my thinking about the types of work I can do to help my team understand their work. That's going to pay off for sure.