Hiring a human
By: Alexandra Gifuni
Tags: Leadership, Recruiting, Communication, Hiring, Management

Last year I was given a huge opportunity by my manager. He offered me the chance to evolve from my Technical Writing role to that of a Technical Content Manager. The new role came with the promise of a small but growing team to lead. The plan was this; we’d start off with hiring one full-time Technical Writer, then an intern in Web Development (our help centers are online), and eventually we’d expand from there. As someone who’s flown solo most her career, I jumped at this opportunity. I had years of experience as a Technical Writer, and I had already been doing the role of Technical Content Manager without the title. I couldn’t wait to mentor a new Technical Writer. Bring it on.

As per company policy, we opened the hiring for the full time Technical Writing position internally first. Within one week we had three applicants.

Now something that’s worth mentioning here is that GSoft is a medium-sized company at roughly two-hundred-and-sixty individuals. What this means is that people know each other. I mean, even if I didn’t work directly with the applicants (which I did), I would have almost certainly had crossed them in the hallway at least once or had a chat in lunchroom.

This made it all feel, needless to say, a bit awkward.

I still remember speaking to my manager about it. Our conversation went something like this;

Me: “Hey, so I’m a bit worried”

Manager: “Why?”

Me: “Well X, Y, and Z applied to the position.”

Manager: “Yes, I saw. Do you think they could be good candidates?”

Me: “Yes, I think so. They’ve all expressed interest in Technical Writing and I think any of them could be good with enough mentorship.”

Manager: “So what’s on your mind?”

Me: “I’m worried about my bias. I know all the candidates pretty well. I don’t want that to impact how I evaluate them.”

Manager: “Do you think that’s a good enough reason not to consider them, and to consider an external candidate instead?”

Me: “No, of course not.”

Manager: “So let’s figure this out.”

Fast forward to the end of a brainstorm session that lasted almost an entire workday, and we had finally developed a plan.

Step 1: The Worksample

The worksample is a classic evaluation of skill, and it is where many candidatures begin and end. I’ve heard it from other hiring managers; all you need is a solid worksample followed by an interview to see if they’d be a good fit for the team. But I’m stubborn, and my need to ensure I was hiring without bias far outweighed my desire for a simple process. So thus, the worksample was just the beginning.

A bit of an unpopular opinion I hold as a Technical Writer turned Technical Content manager is that anyone can write, but not everyone can write technical documentation. Not only do you need to understand some pretty complex subjects, but you need to write about them in a way the audience can understand. Brevity, simplicity, empathy, and being devoid of personality are what champions your writing style in this field. It’s these factors that make it a challenging career for many writers.

A simple [writing] style is the result of very hard work. — William Zinsser

So my worksample did not focus on grammar or syntax. My candidates all had experience in writing in some form, so that sort of test wouldn’t tell me what I needed to know. My worksample focused on technical writing itself.

What I did was took real, messy, overly-technical, barely understandable release notes written by developers in the company, and told the candidates to reformulate them into release notes you’d publish externally for a real version release. There was no use pretending the candidates were not already familiar with our product, so this was a great way to see if they could use their understanding to decipher the notes and translate them into a list our customers could understand.

In consideration for their time, all candidates were given forty-eight hours to complete the worksample at home, then send it back to me via email.

Step 2: The Meeting with SMEs

GSoft runs an innovation lab that we call the GLab. This is a space where teams can develop new products. The lab functions like a Research and Development department, so it has its own office space behind closed doors. The products being developed aren’t necessarily a secret, but the rest of the company still has little exposure to them until they are released. This offered us a unique opportunity to have our candidates test out their skills on another important part of being a Technical Writer; interviewing SMEs (Subject Matter Experts).

We met with each candidate and explained to them that they would be meeting with a Project Manager and Developer from the GLab team. This meeting would last half an hour. Fifteen of those minutes would be spent by the Project Manager and Developer explaining a single feature from the product they are developing, and fifteen would be allotted to the candidate to ask questions. At the end of it, the candidate would be given another half-hour to write a short instructional document explaining the feature. On our side, we instructed the Project Manager to never give enough details, while Developer was instructed to give too many.

It was a play, yes, but one in which art would very much imitate life, as they say. The whole process would remain bias-free since none of the candidates had ever seen the GLab team’s product before (my manager gets full credit for thinking of that part).

So in each meeting, when it was the candidate’s turn to ask questions, I evaluated three key points.

Customer empathy

Did they have the customer in mind? For this meeting, we were waiting to see if the candidates would ask about the security of the feature. It’s something customers deeply care about, and would want more information on.

Information filtering

The candidates all knew they were writing a short instructional document after the meeting was completed. So I was evaluating to see if they stayed on point. Technical Writers often deal with deadlines, so you need to get the information you need, and get out. If a candidate began a tangent about a separate topic, or asked about a feature that wasn’t being discussed in the meeting, it was sign they might not have the mindset needed for the role.

A curious mind

Asking the wrong questions can be detrimental to getting the job done. Think of it this way, if you gather the wrong information, you’ll need to return to the SME and waste more time getting the info you missed. However, asking no questions is worse. We wanted our candidates to ask questions, be curious. If they asked no questions and tried to end the meeting after the Project Manager and Developer were done their fifteen-minute presentation, it was a bad sign.

Final Step: The In-Person Review

This step was the most difficult. I don’t say that lightly.

Imagine this, the candidates — these people with whom I have a professional working relationship with already — had now given me hours of their time and effort. To reiterate, they had written an in-home worksample, met with SMEs on a product they’ve never seen before, and wrote a short instructional document on said product.

And now my job was to meet with them one-by-one to review and possibly criticize their work, live and to their faces.

How the heck did we come up with that one, you ask? Good question! That conversation went something like this;

Manager: “So what’s one of your main concerns about hiring internally?”

Me: “I know all the candidates, they are used to working with me, will they be OK being led by me?”

Manager: “How do you mean?”

Me: “Well one of the most important aspects of this job is being able to receive constructive criticism gracefully. You get it all the time. You need to be able to realize it isn’t personal, and use it to fuel better work.”

Manager: “OK so let’s figure out a way you can criticize them to their face — it will be maniacal!”

OK, so that last part didn’t happen. But it sure did feel like that when he first suggested the plan for an in-person review. I ultimately realized that as a Technical Content Manager I’d be offering the future Technical Writer a lot of constructive criticism. And if I wasn’t able to sit in front of these candidates and do so professionally and respectfully, it would as much reflect on my ability to do my role as their ability to receive the criticism would reflect on them for their role.

So on we went. The first review was the hardest. Not because of the candidate. Believe me, they were professional. As I reviewed their work and suggested improvements, they nodded their head, showed interest, and gave no indication they viewed any of this as a personal attack. However the process of a face-to-face review felt foreign to me, and was exhausting all the same.

Once the review was finished, I thanked the candidate sincerely for their time, took notes, discussed the results with my manager, put my laptop on my desk, went to our office’s “quiet zone”, lay down, and took a nap at work for the first time in my life.

The next two reviews were easier for me. Maybe it was the nap, or maybe it’s how the brain magically post-processes information in just the right way, but I felt more confident and got into the flow of it — without the nerves.

Ultimately, seeing how the candidates reacted to me giving them feedback and constructive criticism on their work was a valuable piece of the puzzle. This new role would shift our working dynamic, so this was a crucial step in hiring without bias.

In case you are wondering how I avoided the bias of my own perception on the situation, I had invited my manager to sit-in on all the reviews to observe our interactions. I would then measure my observations against his to ensure that we both had perceived things the same way.