Stories
As of this year, I’ll have been at RMW for 30 years. I still remember the first project I was assigned: the renovation of the Joseph Magnin building in San Francisco, built in 1914. Previously, I’d worked in healthcare architecture, so I didn’t know anything about the building code issues involved with such an old structure. I attended a lot of seminars to get up to speed, and the project came out well—the client gave us another project. Now I’m the go-to person in the office when it comes to codes.
I imagine putting on the contractor’s hat and thinking, if I were building this, what would I need?
My title is Director of Technical Quality. I like helping people out with their code issues and technical constructability considerations. (Of course, that’s not all I do—I also play a role as project architect on some of RMW’s projects.) And although I know a lot about code and technical stuff, I always find I can learn from other people in the firm. It’s not a one-way street. There are always new things to pick up from other people and new ways of seeing. If there’s anything I’ve learned in the field, it’s that listening respectfully and communicating well with others—whether fellow architects, contractors, or clients—is the most valuable skill and the most effective way to solve problems. 
Incorporating Code and QA in the Project Process
I usually get assigned a project when design development has already started, which is when code evaluation or code research is required. You want to address those issues or at least start thinking about how the building code and ADA requirements will constrain and shape the design.
Usually, the designer starts by telling me something like this: “I want the building to look like this, and these are my materials.” Then I figure out how to get to that end product in a way that is practical and meets the code requirements. I imagine putting on the contractor’s hat and thinking, if I were building this, what would I need? That way, once you actually start working with the contractor, there will be fewer problems, fewer change orders, and fewer requests for information.
The traditional design-bid-build approach puts the architect and the contractor in a bit of an adversarial relationship. You can’t totally avoid that, because of the liability issues at stake, but you can minimize it. You have to establish a working relationship with the contractor and build trust by listening and taking a team-oriented attitude: “Let’s work together, roll up our sleeves and solve this problem together. I’m not here to tell you what to do.” You establish early on that we’re all in this together, so when issues arise, they call you. This works a lot better than finger pointing.
Contractors are smart—they can tell if you know what you’re talking about. I come prepared, and if there’s something I don’t know, I’m honest with them, and I tell them I’ll get back to them.
The same kind of honesty and collaborative approach is essential in the architect-client relationship, too. On one project, we ended up having issues with the exterior metal panels. We had specified a steel panel that we trusted, which was not laminated. The general contractor proposed substituting a less expensive alternative, which was laminated. We had concerns about the lamination failing, so we told the client that we recommended they stick with our original choice. However, after listening to our concerns and weighing the advantages and disadvantages, the client ultimately decided to risk going with the alternative anyway, because it was significantly less expensive. We understood—and they understood—that it was their call.
Once the alternative panels were installed, imperfections appeared on the surface of some of the panels, so they didn’t look smooth. Of course, the product was under warranty, so the manufacturer had to replace the problematic panels—sometimes twice, because a few of the replacements also developed the same issue. Eventually, all the problematic panels were replaced.
There was clear communication all around—everyone understood the risks and the benefits involved. Obviously, the client wasn’t happy that the problem arose, but because the panels were under warranty, everything worked out in the end. And the client saved a lot of money.
So it all comes down to listening and building relationships. I think that’s one of the reasons a lot of people in this office have been here a long time—that valuing of the relationships, the give-and-take of knowledge and ideas. So although my job title is ostensibly about technical quality, like everything in architecture, it’s really not about that. It’s about people.