Sharing is Caring

Did you just figure out a problem that has been bugging you for awhile now? Did you develop a new tool that is saving some time?

Let everyone know about it.

This is a surprisingly small “community” of design technology support folks. I see the same people over and over again all over the world.

Communities need to grow and evolve. And the people in the community that I respect the most are the ones who share all the cool stuff they figure out with everyone else.

Many business owners are concerned about proprietary information, or getting a leg up on the competition. If you are in that environment, I certainly am not endorsing you to break any kind of company rule. But frankly, any company that feels they are going to beat other firms by having a better way to add views to a sheet probably has their priorities a little skewed.

Don’t worry if you think someone else might have already figured your new solution out already. Go ahead and share it. Chances are it will be new to someone.

And those who already know it will fall into two camps: the first camp are the people who will quickly let you know that they already knew about it, and you can start avoiding those people; the second camp will be happy that their solution has been confirmed and will be excited that there is one more person trying to find fixes.

Get yourself a Twitter account, start a blog, etc. Find a way to share what you are doing.

The Problem With “I Was Going to Do That”

We all get busy… very busy. We all have many things thrown at us at once. I, and I wager many of you, sometimes just plain forget things.

And sometimes, someone else picks up what we dropped and takes care of it for us.

This, is totally fine, assuming it doesn’t become a habit. We are part of a team, and everyone should have everyone’s back.

What is not fine, and what I hear from a high number of design technology support folks is the immediate reply of “I was going to do that.”

We find it as a personal challenge to be the best and brightest in the room. When someone does our job, we sometimes take it as an attack and the immediate response is to defend.

The phrase “I was going to do that,” should be removed from your bank of phrases. It immediately is followed, whether out-loud or not, with “Well, why didn’t you?” It diminishes the efforts of the person that did do it. It’s a negative reaction and creates nothing, it simply takes away.

We are here to build a team, and to fix problems. It seems little, but expressions like this can be very detrimental to this effort.

The Next Generation

This is really more of an observation than anything.

AutoCAD has been around for almost forty years now. And while the birth of ACAD wasn’t the beginning of “CAD(D)”, it certainly was the start of accessibility and more wide spread adoption. It was also the beginning of the new role in organization’s that became the CAD Manager.

Many of those CAD Managers became BIM Managers, or kept working hard in their CAD Manager roles. Whatever path they took, they were pioneers. And we are starting to see many of that first generation getting ready to retire.

I encourage anyone in up and coming groups of CAD and BIM Managers to learn what you can from these pioneers before they do one last sync with central.

And to those of you getting ready for a well deserved break, be sure to share your knowledge; document, teach, and mentor. That’s something I would encourage all the time, but especially now.

Easier Said Than Done

Try not to take it personally.

You poured your heart and soul and sweat into it. It’s something you created and a little part of you is now in it. But nobody seems to really like it.

That’s OK.

This is a great opportunity to figure out why people aren’t using it.

I will bet any amount of money that it has nothing to do with you.

Maybe it does’t really solve the problem. Maybe it solves one problem but introduces another. Maybe it was too hard to understand.

But it’s not you. It almost never is.

Throw Them a Rope

Sometimes in our work, we come across someone who knows everything (hopefully, we are not that person). You may find yourself in a situation where they claim to know something, something that they swear to, something that they will die defending… but you know it’s not true.

There’s an expression:

Give them enough rope to hang themselves.

The idea is that you share out just enough information to force them to keep talking and paint themselves into a corner and look foolish. This is great to do to your enemies and makes you feel good.

The problem is, the people you work with aren’t your enemies. This isn’t Game of Thrones. This is designing and building with the help of computers. I wish there were dragons.

We’re going to update that idiom:

Give them enough rope to pull themselves out of the pit.

Ask some probing but delicate questions about the topic. “Oh I didn’t know xyz did that…” “How did you make it do abc…”

This lets them backtrack without losing face and doesn’t put them on the defensive.

It’s not about winning, it’s simply about working.

Empathy

No matter who I talk to about support or consulting, it always seems to come down to the idea of empathy.

This might be through my lens, but it is essential to do what we do effectively.

Many times we are approached when people are already at the end of their rope; there are deadlines, things are broken, they are spinning their wheels.

Nothing is more important that genuinely letting them know that you are on their side, and that you have their back.

You might not have it just that second, but being able to let them know that you are on their team will go a very long way to starting to solve the problem.

Know the Whole Plan – But Be Ready to Change It

We discussed the importance of listening already, and I wanted to pull out a note from that post and expand on it a little.

You will often find that when a user or new client comes to you with a problem or a workflow that they need to work on, your brain immediately finds a pathway to a solution. As design technology support people, it is baked into our DNA to want to fix things. It triggers something in the brain with happy feelings. Probably. The science isn’t done yet…

This is a great skill to nurture. Find those pathways, recognize obstacles, build solutions. Do it in the blink of an eye.

But don’t share it until it’s the right time.

Make sure you have collected all the data from all the parties before you lay out your master plan. There might be something critical that you have missed.

And the most important thing to remember – be ready to change it. You never know what hurdles you will run into: personnel, money, time, etc. Anything can impact your plan.

The fix is what’s important. Not how you get there.

The Customer Isn’t Always Right – But They Think They Are

“No, you’re wrong,” is a phrase that you should never use.

Ever.

Even though you are right.

It’s important to find some ways to convey that important message in a delicate way. I find that that making it not personal helps a lot.

“That’s really weird. That’s not how that usually works. Why don’t you show me.”

Empathize, explain, put the onus on them to prove it.

And if they can’t prove it, don’t point it out, just let it die and move on. Remember, you are on their side. And even if you aren’t literally laughing and pointing at them, it can feel like it to the user if you handle this situation in the wrong way.

None of this is a competition. There is no scantron form that you fill out and get more points for having more right answers than the other people taking the test. All that matters is we get the job done as quickly and effectively as possible.

You Don’t Need to Know Everything

For BIM and CAD manager “types”, it’s usually baked into our DNA to want to know everything. That’s a great motivator.

But it shouldn’t be a limiter.

Nobody likes a know-it-all. We’ve all learned this through the years. More importantly, there is a sense of incredulity when you work with that person that ALWAYS knows everything.

It’s 100% OK to say “I don’t know” or “I’m not sure.”

The skill you need to have and to constantly refine is your ability to learn something new. Because “I’m not sure,” should typically be followed up with “but I’m going to try to find out.”

How to Listen

I’m not going to rewrite the list of skills that you can find in literally hundreds of other (and better) resources, but I do want to point out some tactics that I have found help me the most, and were hardest for me to work on.

Some listening strategies

Look your user in the eye

This seems simple, but it’s overlooked a lot. Look directly at them. Not past them. Not around them, at them.

Don’t use your laptop as a crutch

If you take notes on your laptop, be sure you let them know that’s what you are doing. Drop a casual “Sorry, I’m just jotting down some notes,” and be sure that you are only jotting down some notes. This is not the time to check email or the Teams channel. This is time to be present.

Rephrase

This one gets a little clinical, but it’s important. Maybe don’t be as generic as “What I hear you saying is…” but find something that sounds natural to you. I default to “Wait. It’s doing XYZ?! That’s crazy.” or “OK, so I want to make sure I have this right….” It lets you confirm you are on the same page as the user and clear up any vague points.

Be patient

We tend to put out a lot of fires. But, they are not actual fires. I would not be working in this industry if that was the case. You have some time to breathe.

So many times, a user comes up with a question or a problem and my brain immediately starts building a solution. I have talked with enough people in the design technology support industry to know that most of us do the same thing. And our instinct is to solve the problem right away (and show how smart we are).

Wait. Don’t speak.

Let the user say what they need to say. There are so many reasons this is important to do. First of all, it’s not a literal fire. It can wait the 20 seconds it takes to get the whole story. Also, you might miss something. It’s rare (wink) but we could be wrong with our immediate knee jerk reaction.

Find your own way

The key is to force yourself to be there with the user. Not somewhere else, not 20 steps ahead of them. You have the time, and it will build better rapport and better fixes.