Engineers and Meetings

Good engineers like to be productive. Every minute they spend not getting the problem solved (with the Right Answer) is an irritant. This is why Google tried to go completely without managers (as have other engineer-driven companies). But your bad engineers laze around on reddit and have to be prodded to get them to do any real work. As a manager you need to be able to keep both types engaged and productive, which seems like an impossible task.

To your good engineers, almost any type of meeting will be seen as a waste of time. They don't care what the other members of your team are doing, they just want to get back to solving their problems. The bad engineers will be equally annoyed, but because they have to excuse their lack of performance. However, there is one kind of meeting which I've found almost all engineers enjoy. Engineers love big picture brainstorming design meetings, where you get the brains trust around a table and they get to compete with their technical abilities to come up with the best solution. Its like a kind of mating ritual to see who comes out on top of the engineers social hierarchy. So when you can schedule your catchup meetings around these, the engineers will be happy to contribute some status updates beforehand.

But there aren't normally enough brainstorming meetings to use these for all your meetings. So here are a few pointers on how to make those status meetings work.

1. Minimise them. If you need to know what Jane, Tom and Bob are doing, go and ask Jane, Tom and Bob separately and informally. If you've got half-decent engineers they'll talk informally between each other to make sure they don't overlap anyway. 
2. Invite the bare minimum number of people. I find meetings are most effective with 5 or less people, beyond that you'll just be wasting your engineers time. Split it up into smaller, more precise meetings where necessary. 
3. Your engineers will love it if you can get them out of meetings with the client or other stakeholders. Have informal discussions with the team members whose information you need beforehand and represent them wherever possible. They want to be left to do the problem solving, so this can earn you brownie points to spent on commercial solutions, crunch time or changes to working practices. However, there are still times where you'll need to have the subject expert present.
4. Formality is death. Engineers with their own social hierarchy and poor social skills don't see the need for formality - this is why Silicon Valley dresses in hoodies and sneakers. This should apply to your meetings too, keep them free flowing and informal. Nothing kills creativity and interest more than running through a handed out sheet of talking points. 
5. Minutes are for recording what happened last time, not deciding what happens this time. Keep last week's minutes out of this week's meeting. I've sat in more deathly meetings where managers droned through the last minutes and asked the person responsible for each item for progress on it in turn than I care to list. Nothing useful happened at any of them. Keep the floor open, the discussion organic and raise your talking points throughout the discussion as required to keep things flowing and get the information required
6. Segueing into technical discussion is good, but only if the whole team in the meeting needs to be a part of that discussion. If your two electrical guys are arguing over details the mechanical and fire guy don't need to know, then invite them to take it outside later (see item 2 as well, did those other guys need to be in this meeting?). On the contrary, if you've got an organic team brainstorming session going on, then let it flow - only good can come out of these.

Make sure your engineers can see the meetings as productive and you'll get them more engaged rather than hiding away in a cubicle.