One of the many skills that hiring managers look for in tech and pretty much every single job outside of engineering is teamwork/collaboration: how do you work with and share ideas and projects with other people? Are you able to navigate cross-functional teams, build relationships, and work to come to one solution, even when your points of view at the beginning may be starkly different? If you work in any kind of customer-facing role, during your interview process, you will likely get grilled to show examples of how you tread through murky waters with disparate personalities, opposing opinions, and undercurrents of passive aggression on a team or across teams.
A while back, I had to work on a project with someone (he will be called Daniel) who was so anti working with others that when he disagreed with you and did not want to incorporate your idea, he simply said, “Well, let’s see what Jack (pseudonym for our mutual manager) thinks.” End of discussion. No more shared ideas, no compromise. Just bring in Dad to sort this out. Got it.
The project we were working on was a user manual for the technology platform we were supporting. Our team was lean, and thus we had no team members solely focused on educating our customers on how to use the platform they bought via any type of training portal or webinar. This meant countless hours of live trainings and demos, which meant a lot of time (read: money) wasted for the company. We needed to streamline this process and enable customers to first train themselves, then be supplemented with a live, one-time training with someone on our team. The solution? A user manual complete with screen shots and a step-by-step guide of how to use the platform. Daniel was ecstatic; he could finally use his experience as an English teacher in his first job in tech! He spent the next week owning the project, completely leaving me out of it and pretending to work on other tasks when I asked him, until he proudly showcased the 110-page user manual he had come up with (he stole the formatting and style from his previous job’s templates).
I balked when I saw the document — 110 pages? Who is going to use this, much less read even the first few pages? I told him that no customer would take this manual and run with it; everyone is constantly complaining about how little time they have, so what is their incentive to read through a 110-page user manual? He argued, “Well, they bought this platform, so it’s on them to learn it.” Well, here is where his lack of experience in the tech industry truly showed; just because some stakeholder signed a SaaS contract with us did not mean the actual day-to-day users would adopt the product. He did not get this… at all. I tried to explain to him, and he kept going back to, “Well, they bought this, so they should use it.”
“Yes, but 110 pages is not a reasonable ask,” I responded. “It’s WAY too long!”
“It’s mostly just screen shots and pictures,” he fought back. He refused to make it shorter or even consider cutting specific words out of the document which I thought were just plain verbose. He wouldn’t even give me the document so that I could edit it. He was that resistant to even considering a change. Plus, there was no way in hell I was going to create a user manual from scratch if he’d already started work on one.
I went to our mutual manager Jack and told him my point of view. He agreed, saying it should be shorter (Daniel was NOT happy with this), but we could still keep the 110-page version (Daniel was thrilled with this – he wasted endless paper printing out many copies of these and placing them all over the office. For the record, no one ever opened a single copy). So, now I was tasked with taking Daniel’s guide and condensing it. Within a few days, I got it down to just 15 pages – yes, with the screen shots and pictures. We eventually shared this with every new customer who was onboarded. To be frank, there weren’t that many new customers, but hey, I got my point across that 110 pages wasn’t going to fly!