Final Drawings: Why the Best Teams Share Before They’re Ready 

11-09-2026
photo of Michael Grogan for the Final Drawings: Why the Best Engineers Share Before They’re Ready blog

A conversation with Michael Grogan, Director at Birzulis.

A recent report found that 41% of AEC teams cite poor communication and coordination as a leading cause of rework. Does that match what you’re seeing? 

It doesn’t surprise me at all. You see it on project after project. Every discipline goes away, does their work, and nobody shares anything until the drawings are ready to issue. By that point everyone’s committed to a direction. If there’s a clash, someone’s redoing weeks of work. It’s not a technology problem; most teams have the tools. It’s a habit problem. People don’t share early enough because they think their sketches aren’t ready to be seen.

Why do you think engineers default to holding work back? 

There’s this belief that sketches are markups for the draftsperson, and that proper drawings are the thing that should be sent out. Most of us were trained that way. You work through the design, and when it’s polished, you hand it over to be drawn up. Nobody wants to put something rough in front of a client or another consultant. 

The effect that has is that every discipline ends up designing in their own lane, and the first time anyone sees what the other teams have been doing is at a coordination meeting. By then it’s already expensive to change. Everyone’s sitting on information they could be putting in front of other people right from the start. 

Can you give an example of what it looks like when someone does share early? 

We had a project where the civil engineer circulated sketches showing the location of the on-site detention (OSD) tank, well before any formal drawings were issued. Four weeks later, the electrical engineer came back wanting to put a substation in that exact spot. But because civil had already shared their sketch early, the whole team already knew that space was taken. The response was simple: “No, that’s where the OSD is — find a new spot.” Sorted, before either side had sunk serious hours into a layout that was only going to clash anyway. 

Without that early share, the two teams would have kept designing independently for weeks, turned up to a coordination meeting with incompatible plans, and one of them would have had to start again from scratch. 

What happens in a meeting when people share on the spot versus holding back? 

I encourage our engineers to throw out a guess in meetings rather than saying “I’ll get back to you” — even if the guess isn’t perfect. Because once you commit to a number in the room, other people can react to it straight away. 

For example, I was in a meeting and said we’d probably need 500mm deep beams. The mechanical engineer asked what the ceiling void was — 900mm — and their ducts needed 450mm of that. Straight away, the numbers didn’t work: 500mm of beam plus 450mm of duct doesn’t fit into a 900mm void. 

But because that came out in the room, the mechanical engineer could immediately say the ducts needed 450mm, meaning the beams had to come down to 450mm deep too. I went back to the office already knowing that constraint and widened the beam to compensate for the reduced depth. Everyone left the meeting with clear direction — instead of finding out about the clash weeks later. 

Compare that to what happens if I’d just said, “I’ll get back to you.” I go away, come back later, and maybe I still say 500mm — because nothing in the room forced me to test that number against the ceiling void. Now the mechanical engineer tells me the ducts won’t fit, and by this point it’s too late to just adjust the beam — someone has to lift the entire building 50mm instead. A wider beam might cost a bit more, but lifting the building 50mm means paying for extra cladding around the whole building, just to fix one pinch point. That’s the kind of cost that comes from not sharing early enough. 

What about when work stays hidden and the client doesn’t see progress? 

That’s the other side of it. You get situations where an engineer has done solid work, weeks of sketches and markups, and it’s all sitting on the server. Nobody outside the team has seen any of it. Then an invoice goes out and the client says, “We haven’t seen anything. What have we been paying for?” The work was there. But without a process that triggers sharing along the way, the client has no visibility on what they’re getting, and the other disciplines have no idea where the design is heading. 

It comes back to the same thing. The sketches are no good sitting on the server. Send them out. 

What is Birzulis doing to build this into how the team works? 

We’ve introduced hold points into project delivery. Built-in milestones where a senior engineer reviews the design before the team goes too far down one path. Stop, check, adjust while changes are still cheap. 

We’re also moving sketch circulation into the standard workflow. Not just for complex jobs, but for every job. The expectation is that you get your work in front of other disciplines early, even when it’s rough. When you do that, other people spot things you haven’t seen because they’re looking at the project from a different angle. That’s free quality assurance. But it only works when the work is visible. 

What would you say to firms that haven’t built early sharing into their process? 

You don’t need new software or a bigger team. You need to accept that unfinished work shared early is worth more than finished work shared late. Most coordination problems aren’t caused by bad engineering. They’re caused by good engineering that nobody else could see until it was too late to change cheaply.