Why (I think) Tech Needs the Humanities
And why dismissing tech-adjacent roles and people is a mistake
In 2017 Bluewolf CEO and author Eric Berridge took to the TED stage to talk about why tech needs the humanities.
He argued that it would be dangerous to overvalue STEM careers at the expense of dismissing other key parts of the industry like marketing, design, product management and human resources. His talk centres on “how people with backgrounds in the arts and humanities can bring creativity and insight to technical workplaces.”
My main takeaway? To paraphrase Eric: science tells us how to build, but the humanities tell us what to build and why. At least half of the problem that any given tech company exists to solve relies on skills that have nothing to do with writing code but everything to do with working together as humans. And that requires “real-world experience and judgment and historical context.”
Enter the humanities.
On being tech-adjacent
I’ve been working alongside engineers for the past 5 years. I was lucky enough to have generous colleagues who were willing to indulge my curiosity and answer endless questions about the nature of DDoS attacks and the virtues of one language over another.
“Do you know what an ARM machine is Alison?” Our CTO and Sqreen’s co-founder Jb asked me, not unkindly, in a sprint kickoff meeting last week.
“A computer with a different type of processor?” I guessed.
“Does it run on 32 or 64 bits?”
“Both?” This time I was less sure.
Two from two.
It’s a nice party trick to be able to talk confidently about dockerization and extol the virtues of Postgres over MongoDB. Or to contrast Python’s garbage collection approach with the necessity for constant memory vigilance that Java implies. But the reason I know about ‘tech things’ is because it helps me do my job.
What DO you do anyway?
As the Head of Talent in a technical company, I hire engineers, and sales people, and marketers and product managers. I also design organisations, culture and people processes. I spend a lot of time thinking about how to architect these systems — to predict how they’ll behave in ideal world and also what edge cases we might encounter.
Not dissimilar to how you might architect software perhaps, except that with people it’s arguably trickier. AWS virtual machines don’t usually bring their own wants / needs / agenda to the table.
Machines tend to do what they’re told. Humans, less so.
If you’re so good at tech why don’t you just learn how to code and shut up about it already?
Indeed, this is a real question I’ve been asked more than once on the inter-webs.
Could I learn to code? Probably.
Could I have a greater impact by doing what I do in a HR role in the tech industry? Yep. Would the tech industry as a whole benefit from it? Also, yep.
How many of you have been frustrated with recruiters spamming you with poorly targeted job offers? Or hit walls with internal promotion tracks that seem poorly adapted to tech roles?
Wait a second Alison, are you saying it’s an individual engineer’s job to patiently and kindly educate each misinformed recruiter about the difference between Java and JavaScript?
Or to spend hours explaining how expertise in software engineering is a delicate combination of ‘time spent solving problems with tech’ and ‘language-specific knowledge’ but also ‘lack of dogma about one specific framework or tool’?
Maybe not.
But what about rewarding genuine curiosity or ‘not quite on target but not ridiculous either’ inMails with a swift, educative response. Or an invite to the next Meetup of your community?
What about inviting your HR person or your internal recruiter into your engineering meetings? Extending some technical onboarding to all members of your team?
Wouldn’t we all benefit from HR and recruitment professionals who inherently understand the nuances of the tech world?
The strategic potential of tech-adjacent roles in technical companies today is drastically undervalued. There is a big gap between these roles and the tech industry but the only way we close that is by encouraging our tech-adjacent colleagues to learn about the tech world through the prism of their own area of expertise.
By inviting them in, and encouraging them to stay.
And here’s how you lose us…
I had a goal for 2019 to speak at more non-HR conferences. Tech and SaaS conferences seemed like a good place to start. It’s a step towards one day taking the stage at TED, a long held dream of mine.
I was lucky enough to speak at a Point Nine Capital event just before SaaStr in San Francisco in February of this year.
Boosted by this, I recently applied to speak at a couple of Paris-based technical conferences with clearly stated management tracks focused on hiring and then developing engineers’ careers. Something that falls pretty squarely into my wheelhouse. The response?
“We don’t accept speakers who aren’t C-level or cofounders at this event”.
The other (rather more diplomatically) enlisted an account manager to give me a quick call and explain that they don’t think engineers really want to hear from HR people.
Cool, cool, cool, cool.
BUT.
If we agree with Eric that engineering requires ‘skills that are not only about writing code’; that are more about interacting with others, about effectively making parts function as a whole — then surely tech should at the very least be curious about what human resources can add to the conversation?
In addition, how do you expect to attract and keep the best tech-adjacent people if you keep telling us we’re not welcome?
Okay, okay, you’ve convinced me! What now?
Seek out the great tech-adjacent people in your organisations, your networks, your communities and make sure they know you value them.
Give them opportunities to be heard, to be seen — it’s the only way we can encourage others to join us and do great tech-adjacent work.
As for conference organisers , if you recognise yourself in the section above — do better!
Otherwise, you’ll lose us.
We’ll end up moving to pure tech roles, or founding our own companies out of pure frustration. And whilst neither of those are bad choices for us, the industry will be worse off for it.
