Reflection

Reflection

Monday, May 11, 2015

The Reluctant Code Guru

When I was hired here at RLPS a mere 18 years ago, my position was to assist one of the partners, Gregg Scott, on his particular projects.  His position included leading projects as partner-in-charge for several clients, but he was/is also the main business development person for the firm, doing interviews for more work, lecturing at conferences and keeping clients happy and coming back.  As opposed to developing the same strengths Gregg had by the bushel: as his underling, my job evolved into a role that augmented the skills Gregg didn't have time for.  I became a very young project manager/project architect on day one.

On my first day on the job with him, he told me we were running up to visit three projects in Northeastern PA, and to "wear a blazer".  Each of the projects was in a different state of completeness - one in early design, one in construction, and one post construction.  After a couple of months and a few meetings with these Clients, Gregg eventually left me on my own, without the life vest of having him attend all the meetings with me.  Gregg was out of town very often, so in place of his direct guidance back at the office, he encouraged me to utilize the office resources, which included not only code and technical books, but the people in our office who had the knowledge to help me.  I had only been in the field nine months prior to starting with RLPS, I had very little experience with Codes, especially in the Department of Health arena.


My part of the library.


Of those three first jobs were included a very messy skilled care facility addition and renovation starting in the design phase, a personal care provider in a mansion from the 1800's currently under construction, and a large retirement community that had just been completed.  I had to very quickly learn the ins and outs of building codes, health codes, constructability, construction management, and the coordination with our engineers and the in-house drafting team.  All of whom had many decades more experience than I did.  I was lucky that Dave the Contractor was (mostly) gentle with me and helped lead me to the proper decisions sometimes, Tom the Structural Engineer didn't laugh at me when I thought it was his job to fire proof the steel, Bill the Drafter I had on the job with me was able to draw the sections based on his vast experience, and we had an in-house resource for code support, Paul.  All that and I was making the transition from MicroStation to AutoCAD.

After a few years’ time, I eventually became a more traditional project manager, leading a variety of projects for any of the partners-in-charge at our firm.  But having been left to sink or swim in my early days, I had developed an ability to find things out for myself, whether calling on Code Officials or Plan Reviewers for guidance or consistently bugging our in house Code Expert.  When I did bug Paul, I always gave my best effort to read and understand the Code before I interrupted him, which he appreciated.  I used Paul as a resource to verify my interpretations, not as a substitute for reading the books.

Fast forward to 2014 and my annual review with the Partnership at the firm…this review is an opportunity to discuss how things are going and perhaps how things in the office can improve.  All suggestions are considered (I was the one to suggest sparkling water to be added as an option to the soda fridge – score!).  We had been operating without the benefit of Paul's guidance for a few years at this point, so I happened to mention that, based on the upswing in new projects at that time; a lot of designs were progressing without a seasoned project architect on board to review for fundamental code analysis.  It is always better to head off an issue early, I said, because I had been on the receiving end of some very difficult positions once the project got into Design Development with me at the helm. Some examples: bathrooms or kitchens far too small to be accessible, fire walls separating buildings that would be extremely hard to build or would require rated adjacent windows, occupant loads too large not to be separated or needed additional exits - just to name a few.  It would be great, I said, if someone could look at these plans before we have the Owners super excited about a building that will be too difficult to build without various changes.


Some of the literature at my desk.

Well, be careful what you wish for.  That guy is now me.  I was not suggesting that we get one person do this job more or less full time, let alone it being me.  I wasn't sure I was qualified me to do it, really.  I had been an unofficial resource for codes in the office for some time.  I had a lot of experience (as much as anyone in the office I suppose) with Department of Health work that included NFPA reviews. I had a pretty good grasp on the International Code Council (ICC) codes as well.  Everyone from partners to drafters were already stopping by with questions.  But I had no formal training in code compliance or quality control.  I also wasn't sure I would be able to give up working on one job for months or years at a time, as I was accustomed to do.

Turns out I can still work for the Clients I have a relationship with, just in a more managerial way.  I have to adjust my thinking sometimes, but I can still be a team member.  And I started to really like seeing more projects our office is working on, where I may have never seen them prior to the finished product photos.  Analytically I am able to look at early plans and try to sort out construction types and area/height limitations, building separations, occupant loads, etc.  As I understand it, others don't find this as interesting as I do.  I describe it as "reading the Matrix".  I try to look at any limitation or hurdle with a problem solving eye, very much the same as I do when I am laying out building programs and adjacencies in floor plans.  It is just another type of problem to solve - split the building this way, provide sprinkler coverage to get height increase, perhaps change the construction type...and not knowing everything there is to know about the project or client just means that I need to think in terms of options.  You can do this or that and get to five stories - you choose.

The Matrix - Isn't this how everyone sees buildings?  I see clearances and ratings as readily as doors and windows.

I also do a lot of reviews of projects near the end of Construction Documents as part of our quality assurance procedures.  This way I get to see the (almost) finished product and see which options they went with.  I try to go through the code sheets as if I am seeing it cold, however.  I try to take on the persona of the Plan Reviewer.  I try to take out any of the questions I feel may be asked with the help of a red pen.

Codes change of course, as we experienced from the SBC,  BOCA and the UBC to the ICC family of codes.  We work all over the country and, in my opinion; there is really no unified building code.  Every jurisdiction has multiple amendments and approves the more recent codes at their own pace.  Various State agencies require conformance to the NFPA Life Safety Code while local jurisdictions review under the International Building Code. And why is it International when only US States and Territories use it?  And depending on the State, there is potentially a 12 year difference in the Code edition enforced - 2003 vs. 2015 Editions.  So one of the more challenging parts of my position is figuring out what we have to comply with.  This is not always so easy to find on the State and Local websites.  In one case I found one department did not yet know that a legislative change revised the way townhomes were reviewed, essentially taking out of the State’s purview and putting it solely into the local review.   Anytime there is an overlap of responsibility between the State and Local, it is just an opportunity for potential conflict. It is all part of the fun!

So, a couple of years later, I am primarily the office "Code Guy".  There are still several jobs in construction that I had run, and am still involved with projects where I had been the primary contact for several years.  But now I am integrated into the front ends of many projects, assist project managers with issues, attend preliminary code reviews with them at the Authority Having Jurisdiction (AHJ), assist in the QC/QA process, as well as assist any client having code issues with existing facilities, etc.

It is challenging work, but there is a variety and overview that I find refreshing.  I had just recently worked on three projects with extremely long timelines, each taking 5 or more years to design and build.  I felt a little pigeon holed in those projects and felt like I didn’t get to see anything else we were doing as a firm.  While I have to broaden my depth of understand of code issues as I look at up to a dozen projects in a week sometimes, I see more projects, I work with a wider range of people in the office and I even correspond with a broader cross section of Clients in my new position.

The one area that I am still getting used to is the interruptions.   I have come to realize that my work days are now a series of disruptions with some intermittent scheduled work in between.  When I am working on any of my projects, I am often doing complex calculations or I have my head in the Code book(s), reading and rereading sections of code.  This is not an ideal task to interrupt, at least not for me.  I never claimed to have any Codes memorized.  In fact, Codes have a tendency to change with each edition, so it is not wise to rely on memory alone.  Certain tasks can take me into a section I have never really read before and the Code is not always particularly black and white for every situation.  I don’t carry code books to the coffee pot or the rest room.  That doesn't seem particularly sanitary in either case.

Read, interpret and retain, right?
Everyone has their strengths, though, and where one has strengths where many others are unsure, you're bound to be popular.  Maybe I need a take-a-number dispenser like at the deli.  I’ve always liked those paper hats they wear, too.


Now serving:  Number 32.

The position I am in now all relates to whom I started working with and how I was able to fill in and learn a set of skills that were needed to round out those first three projects I started working on with Gregg.  Had Gregg been the technical guy, I may have never become the Code Guru.  I really don’t like that name though – sounds like I teach yoga on the side.  Other considerations are:  Code Sage, Code Shaman, Code Illusionist, Code Whisperer, Code Soothsayer or Code Clairvoyant.  Whatever you call it, I never, not in a million years, suspected I would be in this position.  If you would have asked me when I was 22 if would ever want to do this day in and out, I am sure I would have said no way.  But that is a dumb kid talking, one who doesn’t have twenty years of experience and doesn’t see the inherent value in staying out of trouble.


3 comments:

  1. James, I love this, somewhat describes my early career. A comment and a thought, if I may:

    Comment: becoming the "go-to-guy" for an area of expertise such as "code", "building envelope", etc., never hurts, especially in the earlier years of a career. I survived through several recessions at various employers because, like you, I became a resource to others in the firm, and when partners had to make hard decisions in hard times, it was harder to lay off a resource than a project architect. That was not my intention when developing expertise, but definitely a side benefit;

    Thought: Having been exposed to many more projects than most project architects, you have undoubtedly been exposed to many "tales", i.e., stories about design and construction that constitute teaching moments for younger (and in many cases older) architects. I am starting work on "An Architect's Guide to Quality - Tales from the Trenches Book Two", in which, as editor, I hope to capture tales of importance to architects, interns and students in these days of reduced mentoring. Let me know if you are interested. Regards and thanks for a great tale, Brian

    ReplyDelete
    Replies
    1. Code Breaker!

      Thanks for sharing your story, James. Fascinating.

      Delete
    2. Thanks for the comments - I always thought I would manage jobs, in the traditional sense - and in lean times I suppose I would always be able to fall back on that experience. I do try to mentor those less experienced with the codes - we do a lot of health care, so there is always something. I would surely be interested in contributing a story or two. Thanks for reading.

      Delete