Constructive confrontation: a real-life example

I was recently sent the following situation and email exchange by an intern and reader of this blog, whom we'll call T. What happened to him, how he handled it, and how it turned out was interesting and professional.

Our intern, along with a licensed architect and job captain, had performed some field verification of an existing area to be remodeled and was using the field dimensions along with an old CAD plan and some paper drawings of the building's original construction documents to build the existing conditions in Revit. After drawing everything in, he found some busts between existing conditions and the dimensions shown on the existing drawings. He and the job captain discussed the difference (about 10" over a 120'-0" span!) and decided to bring the situtation up with their project manager. However, the problem never came up until about three hours before a meeting with the job's contractor, in which T. would be giving them a copy of the Revit model to use in pricing the remodeling project. The job captain's other projects had distracted her, and T.'s work on the model was constantly interrupted by people asking for help with Revit. T's office switched over to Revit in the past year, and there were only a few people who knew how to use it well enough to provide tech support, and T. was one of those few. Because of his expertise, he had been roped into helping work the bugs out of the new computer images and installation of Revit 2010 in his office.

So there T was, with three hours before a big meeting and a 10" bust in dimensions. Needless to say, his project manager was furious and he and his job captain were embarrassed. His manager made the two recheck their math on the asbuilt dimensions and criticized the way they had taken the dimensions in the first place. Their boss was visibly angry but trying to stay calm (to his credit), but the damage was done--neither T. nor his job captain could think clearly, they were so rattled. They barely got out the door on time to the meeting.

While the meeting went well and was productive, and the car ride to the contractor's office proved to calm T.'s boss down quite a bit, T. knew the score--he'd missed checking a basic detail. "I should have rechecked my asbuilt dimensions before that moment, it's so obvious," he emailed me. "But my workday is spent so frickin' distracted and I keep getting interrupted, that it gets easy to miss stuff like that!" T. sat down that evening and wrote the following email to his project manager and copied his job captain. The email is below, and T. has graciously given me permission to reprint it here:

[Project Manager] -

I wanted to first off apologize for the mistake on the as-built model today - you were right and the match-up should’ve been caught prior to this morning. I take full responsibility for the mistake, as I should’ve been more meticulous about the dimensions when laying everything out. In the future I’ll make sure to, as they say “measure twice, cut once,” and catch these things to avoid the last-minute fixes.

I also wanted to bring to your attention the distractions during a typical day at work that I fear can lead to mistakes if people aren’t careful, including myself. Before [the recent layoffs, in which many overhead people were let go], we had a “cad-manager” person that would take care of any CAD problems we had during a project, and he could drop what he was doing to help out. With this, our office had a good knowledge base among the actual users (architects, interns, landscape) that could answer questions and fix problems through the [old peer-to-peer support group] CAD Helpline. As the office has moved more towards Revit only, this knowledge base hasn’t kept pace. There are very few people in the office that know Revit really well, and as a member of the CAD Helpline I can’t remember the last time that email address received a question or a request for help. This leads into the few people around the office that know Revit well to field questions and fix problems. To my knowledge these people are primarily [one intern in the office], who is the “king of Revit;” after him it falls off to a few others including myself to answer Revit questions. To make a long story short - I fear that these distractions during a course of a day, ranging from requests to fix something to “can you teach me this,” can lead to mistakes because of the interruptions. Only speaking for myself here - but I really enjoy helping and teaching others how to use Revit and how to make it work for them, and I wouldn’t want to drop that task. I simply need to find a way to make these requests for help work around my tasks and avoid mistakes at the same time.

In the past few weeks I’ve also been helping [the guys in the IT department] roll out a new image to the design staff. Along with a few others we’ve been testing the new software to catch any problems before the image gets sent out to the rest of the staff. I feel this is an important task; as IT doesn’t use these programs on a daily basis, we can more easily find the problems.

I don’t want to only point out a problem but also provide a potential way to solve it. If we could re-configure the CAD Helpline by adding more people to it that know Revit, I think that would really help. These additional people could lead to a larger knowledge base, so more people in the office know they can go to different people to solve problems. It could spread the help out so to speak, give the current helpers a huge relief, and allow them to concentrate on their tasks more easily.


Thanks for the time in this email and for allowing me to accompany [the job captain] and you today to the BIM meeting. It was a great learning experience, and after the talk with [the contractor], our model is on the right track. I also discussed with [the contractor's Revit experts] some ways to make the model work even better for them, and allow us to get accurate material take offs from the model.

Thanks again,
T.

T.'s email got this response from the project manager:

No worries on the mistake T., we all share in the responsibility. I understand the distractions and appreciate your helping others in the office. Many of us are all pulled from our efforts in many ways all day long every day. Those that can come back after this distraction and re-focus on the detail and the thoroughness are in short supply. It is very difficult to do. I know you are one of the greats that will master this ability.

Keep up your good work T.

Thanks,

T's email, while lengthy, was a good one to send. He first took ownership of the part of the problem that was his responsibility--it was indeed part of his job to check his math on the as-built measurements--but he also described a part of his daily work environment that, if fixed or alleviated in some way, would help him to do his job better. He explained the situation well and without blaming or name-calling, and he refrained from whining about the fact that he's helping people. He wants to help, as it helps him learn as well, but not at the cost of his own job tasks. He frames his request in the service of the job. He also ends on a positive note, thanking the manager for the chance to meet with contractors (which for many interns is a rare occurrence) and assuring him that "the model is on the right track": the problem is being solved if not completely solved already.

T.'s manager's response is reassuring and yet a bit unnerving. On the one hand, he acknowledges that T. is being pulled away, and he understands if not empathizes. He thanks T. for helping folks and appreciates his good work and doesn't ask that he turn their backs on those who need help, which is also good )what kind of "team player" would that make T. if he did?). Overall, the manager doesn't seem to think unfavorably of T. after this incident. Where I become concerned is that the response seems to end with a polite "getting distracted is part of the workday, so you'll just have to learn to get used to it and be able to refocus."

Fair enough, Captain Obvious: distractions are part of everyday worklife, if not everyday life in general. But in light of mounds of evidence that task-switching (which is the actual word for what we've been calling "multitasking") is counterproductive, there's nothing wrong with being able to set limits and close an office door, turn off your phone, or put up a sign in your cubicle saying that you're working on something and won't be available for an hour. It disturbs me that T.'s project manager didn't offer to make that suggestion about the "CAD Helpline" at the next manager's meeting, but perhaps he didn't go there because T. wasn't direct about it. T. could have taken his problem-solving to the next level by writing, "Is a rearrangement of the CAD Helpine something you can bring up at the next Monday manager's meeting? I'd be glad to write something up for you or speak to the other managers regarding this, if you like." Regardless, it was overall a good exchange that acknowledged responsibility, described a problem, presented a solution, and then thanked everyone involved for their time. There's so rarely enough of either of those--time or thanks--so it's nice to acknowledge both.

If you have a question, need some advice, or would like to see a topic discussed here, drop me a line in the comments or send me an email from this site. Thanks!