Soft Skills are Hard Requirements

Today I had a call with one of our vendors who helps find developers and other technically-skilled contractors that we’ve employed in the past. It wasn’t with Marlene, who’s been my contact with this particular agency for many years, this was someone whom I vaguely remember having a chat a while back about potential contract work. As in, I would be the contractor.

So it quickly turned out that this was more about getting my file with them up to date, in case they find the perfect job for me and would immediately put me out as a recommended contractor. Which, slightly awkward given that I’m only five months into my current company and this isn’t exactly the sort of thing I want to be dealing with when I’m actually quite happy with what I’m doing.

As I tried to wrap up the conversation, the question dropped: What are your three principle hard skills? It’s a fairly standard thing for this particular agency, as they require you to choose three (no more and no less, which I think is a bit dumb, but I understand why they do it that way). But here’s the catch – it’s more about things like knowing Active Directory or building Java apps or managing a network infrastructure. And those are things that I know how to do, but I would never put them down as “principle” skills because, frankly, I’m not good enough to be used as a trusted resource.

I didn’t know this then, but the day I started into management was the day my ability to be a trusted technical resource started to wane. Knowing the deep, inside knowledge of how something worked wasn’t going to be on my roster of skills because I had to worry about other things: how other people were getting work done. That’s not to say I didn’t do actual hard work – I did still contribute to delivery – but my job was to help others do their jobs better.

I know, sounds utterly vaccuous, right? A “life coach” sort of thing? That’s the real trick of management, especially with technology teams: you’re not there to do the work, you’re there to ensure the work is done correctly, to standard, and delivered without issue. And that’s not to suggest anything like a “supervisor” or even a “babysitter”, though those images do come to mind, it’s really about ensuring that you’ve got someone with enough skill, knowledge, and experience to catch problems before they become big ones.

This is where we stray in the poorly-named “soft skills”, which is where people usually go when you can’t define “hard” skills – if you don’t have one, you only have the other, right? This is where my meeting took a left turn and went down the road of “this is where we have a bigger problem”.

I have a friend who works for a (unnamed) software development company that is experiencing what I can only describe as “hell”. They have a really great product that would do a lot of genuine good. But due to extremely rapid growth and the demands from some very large, very expensive customers, the company has had extreme difficulties in nailing down direction. I cannot explain where it’s coming from (even if I knew, I couldn’t say), but there are a litany of organizational issues that keep cropping up: HR not checking potential candidates and wasting hiring managers’ time, individual teams not coordinating deliveries, support teams believing that they’re more important than those actually delivering revenue stream products, Director-level people who insist on being hands-on and not seeing the problems inherit to their teams, and so on.

These are the sorts of problems that I now solve. Sure, I understand what it takes to provide an ecommerce solution for an SMB, I’ve done those a few times. But can I also dig into that SMB and discover the internal challenges they have, identify solutions, and give them a phased plan to fix them? Yeah, I can do that. Does that make me a “management consultant”? Heck, no. It makes me useful. Because not everyone sees that.

But more importantly, it’s what I do for my teams, something I’ve been doing since the mid-2000s: make them better. I look for the conflict, the difficulty, the inefficiencies, the miscommunication that exists within and without a given team, the processes that drive the organization. I’ve yet to work anywhere where those problems didn’t exist, because they always will exist: any time you have a human, you will have differences. The trick is to try and smooth them out as much as possible.

But to do that, you need to understand the work: what does (in my case, anyway) a technology team need in order to deliver work in the most efficient manner possible? And, for them to deliver, what do other teams need to do? And how does all that work together? Now we’re looking at:

And yet, I can still code enough PHP to fix problems. So do I have one hard skill? That makes no sense. But they’re not “soft” skills, either.

In short, I think I’ve graduated out of simple technical agencies. I don’t do pure technology work. I know how to do the work, but you call on me because you have bigger, harder problems that won’t be solved with some elegent React or a well-formed SQL query.

And, maybe, that’s a good thing. ‘Cuz I’m getting too old for the same shit. (With apologies to Danny Glover and Sgt. Murtaugh.)