When I was a developer, I hated meetings, and just wanted to work on my feature as much as I could. Tell me what you need to have built, and let me build it. W

When I was a developer, I hated meetings, and just wanted to work on my feature as much as I could. Tell me what you need to have built, and let me build it. When I switched to product design, I tried to respect the engineers' time by not scheduling synchronous meetings very often. I would write documents that nobody read (or at least did not comment on) and record video demos that I know for a fact only about 25% of people watched. What I said to them was: "here are the designs, and here's why I did it this way, and if that makes sense to you go for it, otherwise let's meet to answer questions". A couple engineers would reach out to me, most would never say a word. At retro, the feedback I got was "design is not communicating, we want to be involved earlier in the process". Okay, great! Maybe I went too far in trying to free up their time. So, I continued documenting my work, but also scheduled a 30 minute recurring meeting once per week, to synchronously update the engineers on where the design was headed: here's what we heard from customers, here's what I'm thinking we need, are there any constraints I should be aware of, and do you have any ideas on how we could approach this differently? Keep in mind that I'm still doing IC work on the design itself, and I'm putting in a lot of time documenting things for the engineers, and I'm attending way more meetings than them (this is the nature of design). I thought these design syncs were going great, but the feedback at a later retro was "gah! too many meetings, we don't need a recurring meeting with design every week". Since documenting things and scheduling meetings on an ad hoc basis was not enough communication, and 30 minutes a week was too much of a burden, and most of the team would not voluntarily engage in asynchronous communication anyway, I was sort of at a loss about how to make them happy. My conclusion was that every engineer is different, and there is no magic bullet that results in perfect communication but does not "break flow". And since they are being paid for their time, I'm not going to try to tiptoe around scheduling meetings when I need to, to do my part of the job.