Are engineers in meetings a waste of time?

My default approach to meetings is to shield engineers from them. Engineers hate interruptions that break their flow. However, having engineers present in one type of meeting can save development time.

In smaller teams I work with, we write feature passports with the client to keep meetings minimal. The idea was simple: document what we’re building up front, hand it off to engineers, and let them build. Repeatedly, the feature would require multiple iterations before it met expectations.

The typical response to this? More process. More QA, more reminders for engineers to test thoroughly, and more upfront analysis to catch every edge case and question before development begins. The problem? More process slows everything down.

Slower processes lead to slower delivery. Slower delivery means slower feedback. Slower feedback delays the validation of whether we have built the right thing. Ultimately, this extends the time before we see a return on the investment made in that feature.

So, instead of adding more processes, we experimented with a different approach: having the engineers present when the feature passport is refined and finalised.

This way, developers gain valuable context on why we’re building a feature and the reasoning behind key decisions. On top of that, they often even suggest improvements that make the feature more straightforward to implement. And during development, they can make better decisions.

Are these the most exciting meetings? Not always. More people means more opinions and more back-and-forth discussion. But the result is better. Even less vocal engineers understand better what we're trying to achieve.

How do we keep the meetings productive?

• We set a one-hour limit.
• We schedule another session if there are still open questions.
• If there are no more open questions and we have been debating two options, it's time to decide and finalize the feature passport.

It resulted in better alignment, fewer iterations and faster delivery.