“Soft” Skills

This week, Drew Conry-Murray wrote an timely and important piece in the Human Infrastructure newsletter on Hard and Soft Skills, and prompted me to make a decision.

You see, I had been sitting on this subject for a long time – well over a month – in a prolonged bout of indecisiveness. Drew’s insightful piece, though, made me realize that if I didn’t get it “out there,” it would simply rattle around in my head like a BB in a metal garbage can: loud, obnoxious, and distracting me from everything else that’s important.

First, you should read Drew’s excellent piece. Then, if you’re up for more punishment, come back here.

Drew’s message couldn’t have come at more appropriate time for me. A little over a month ago, I had a conversation with a Cisco colleague, who happens to be a Distinguished Engineer (DE). He also happens to be someone that I like and respect a great deal. So what he said stung quite a bit.

We were talking about a possible project, when he casually threw out there that while it was good to have my marketing talent, we needed to get some “technical” people on board as well.

Wait, what?

Now, Suzie, if you don’t have 10 years of, and a PhD in, ASIC development, you must be in marketing

“Well, J,” he said, as if explaining the way of the world to a child. “The people on my team have Ph.Ds in Computer Science, and have been studying ASIC design for 10 years.” This, despite the fact, that we were not discussing designing ASICs. It was just a general benchmark for what was “technical,” and I didn’t qualify.

I confess, I was – and am still – offended by his nonchalant, off-the-cuff comment. All at once, I got caught up in a whirlwind of emotion. Was… was this how he has thought of me all along? Is this how everyone thinks of me? Am I just merely someone trying to “sell” something?

On the other hand, if I’m just a “marketing guy,” why does he have to ask me how stuff works in storage and storage networking?

What precisely is the criteria, here?

I started to think of friends who I consider to be very technical, some of which have no bachelors degrees, and even a few who have never been to college at all. No one in their right mind would accuse them of merely being “marketing” because they don’t have Ph.Ds in CS.

What about me? Where do I fit into this?

I have always admitted that I am not a programmer. I have done some DIY self-taught C courses, some python courses, but I have always been far more interested in systems. I really don’t have the patience or the temperament to be a programmer. I admit this freely, and fully.

I can, and have, screwed up “Hello, World.”

However, it seems to me that there is a far cry from being a programmer and ASIC developer to being someone who “Bullshits” for a living.

A Note On Marketing

I want to be clear, here. For all those people who are in Sales and who are in Marketing, I am not claiming that either skill set is about “bullshitting.” On the contrary: as I’ll point out below, my point here is to illustrate the dismissive nature from those who are “technical.”

That is to say, the attitude displayed and embodied by my colleague is pervasive. “You go out and talk about the hard work that we are doing,” is what he was saying. What’s more, it was not intended to be insulting (even though it was) or offensive (even though it was). It was, to him, “what it was.” It’s just the way things work.

At best, the attitude is that “technical” people are grateful for the marketers and sales people because it frees them from having to do stuff they don’t like. That, of course, means they can get on with the “real work.”

The Tyranny of “Enough”

It seems to me that those who dismiss the ability to communicate (i.e., “soft skills”) do so because – ironically – it is hard to do.

I should know. In the past 3 years alone, I have done over 100 presentations, webinars, podcasts and seminars. In the past 10 years I have written over 500k words on storage-related topics (that’s about 2/3rds the length of the King James Bible).

I have written, presented, and recorded on topics such as Block, File and Object storage. iSCSI. Fibre Channel. FCoE. NVMe. NVMe-oF. iSER. Erasure and Network Codes. Storage Virtualization. Backup and Recovery. Security and Privacy. Regulation. RDMA. Congestion Notification. RoCE. iWARP. Hyperconvergence.

I read and reference IETF RFCs and Fibre Channel specification docs. I keep up to speed on the more than 60 ongoing Technical Proposals (TPs) in NVMe. I contribute to the T11 Fibre Channel standards.

Through it all, though, I confess I have suffered tremendously from Imposter Syndrome. Is this too broad? Am I not going deep enough? Am I a Jack-of-All-Trades, Master-of-None? I only have two patent applications, and neither have been granted (yet).

There is so much I don’t know. It’s the truism to end all truisms – the more I learn, the more I have left to learn.  I am constantly reminded, at every turn, about how much I do not know.

I am in absolute awe with the people that I work and interact with. Brilliant minds who inspire me to stay outside my comfort zone. I will never, ever be as mathematically-minded as Landon Curt Noll or Dr. Rachel Traylor, both of whom have incredible contributions while at a young age. I’ll never know as much about Flash storage as James Candelaria, the brilliant (and erroneously and unfairly maligned) founder of Whiptail. I’ll never be as prolific and technically intuitive as David Black or Fred Knight – two people who have contributed more to storage than anyone will ever know. I’ll never be as versatile as Claudio DeSanti, who was able to intuit how to make general-purpose Ethernet be reliable as a transport for Fibre Channel and (now, as a result), RoCEv2 and NVMe-oF. I will never be as accomplished and staggeringly efficient as Sagi Grimberg, the key author behind NVMe/TCP.

These are just the proverbial tip of the genius icebergs.

I fully understand that they know I’m nowhere near as “good” as they are, but they tolerate my presence and know that if I get something wrong, I’m completely happy to be corrected. I’d like to think we are friends, too, even if my specific skill set for each of these disciplines is wanting to a large degree.

Never be the smartest person in the room, the Turtle perspective

It has long been said that you never want to be the smartest person in the room, and I have done my best to live my life like that.

The unfortunate corollary to that is, however, that the room will always see you as the stupidest person present. Hey, someone has to be at the bottom.

It’s a risk I’ve always been willing to accept, and perhaps this is just the consequences of accepting that risk. I’ve always known that there would be people who thought I was an idiot because I didn’t know what they knew. This may very well be one of those times.

Getting it Backwards

The reason why “you’re just a marketer” is an insult to a technical person actually has nothing to do with any marketing skill. It’s has to do with the insinuation that someone is just play-acting, simply reciting lines as if it were a play.

It’s as if one were to say, “You don’t actually know what’s going on; you’re not creating anything – at best, you’re reporting it. At worst, you’re saying words you don’t actually understand.”

The reason people get away with this is because, sadly, in a lot of cases it’s true. We have all met people who have been hired to spout the company line, create pretty graphics, regurgitate the script. Marketing people can’t answer questions. They often don’tknow how things work; they only know what they’ve been told.

I, myself, have had a number of run-ins with salespeople and marketers who don’t want to know how something works – they just want to know what are the magic words to get customers to buy their stuff.

So, I get it. It’s also why it strikes a nerve when it appears I’m seen in that light. I have worked very, very hard to build up my technical chops and to think that I’ve failed in that endeavor, well, it’s soul-crushing.

What this DE fails to grasp is just how much work is required to make technology understandable. Drew covers this in his piece, but one of the things that he doesn’t say explicitly (but I will) is that there is a reason why Communication is actually so hard.

Unlike programming, where you can debug a problem and resolve it with relative predictability, human beings are not quite so accommodating. Imagine running a compiler where the output may or may not work, even if you’ve not changed a line of code.

That’s people. Unpredictable. Variable. Inconsistent. That makes coming up with an approach really difficult, when something can work less than 50% of the time, and each successive attempt reduces that percentage (because people lose patience with you really fast).

Now, try to take a concept that is not well understood, like NVMe in 2014. Try to figure out a way to explain it to a variety of people – including technical people – in a way that doesn’t simply regurgitate the outline of the specification.

Then – and here’s the key thing – you have to make sure they understood and remembered it. After all, if they didn’t hear it, you didn’t say it.

Worse, you have to be right a lot more often than you are wrong. You have to understand what’s going on to a much deeper level than the one at which you’re speaking/writing. If you can’t, or don’t, you will lose all credibility. If that happens, all of your hard work goes out the window and you might as well not even have bothered.

It’s All Relative

It is true that I do not have either a PhD in Computer Science, nor do I have 10 years of ASIC development. If that is the criteria for ‘being technical,’ then I will always fail. Miserably. Fortunately, I do not claim (and have never claimed) to have such talents. Frankly, I do not want to.

At the same time, I challenge anyone – anyone– to go through anything I’ve written or presented and find “marketing spin” on my material, especially in the last 6 or 7 years. Even the material that I’ve done specifically for Cisco is remarkably sparse on that regard.

Of course, with the sheer volume of information I have produced, there are bound to be mistakes and errors, and for that I take full responsibility. Even with diligent proof-reading, it would be impossible to have errors and inaccuracies – especially when trying to simplify technical content for a mass (or at least, broad) audience.

I honestly don’t know how much will be “enough,” to be honest. In my “free” time I am a sponge. I learn everything I can about the related technologies, because I know that everything is related to everything else.

How does GPU pipelining integrate efficiently with NVMe storage? I have no idea. Need to understand GPU pipelining better first. So, I’m reading up on that. Then I can figure out how to optimize for parallel I/O.

What’s this newfangled L4S Congestion Notification stuff? David Black put me on to it. Will it practically replace ECN? Looks interesting, but look at all the dependencies I have to pick up on. How will it affect storage? How does it interact with NVMe-oF with RoCEv2 and NVMe/TCP? Nope, nothing on the search engines about that yet. I’ll probably have to be the one to write something up.

You can’t be technical. You wear a hat.

Speed mismatches are a problem with NVMe over Fabrics, and no one is getting off easy. Not RoCE, not TCP, and not Fibre Channel. Each has its own way of handling it. The question that comes up (and is intuitive) is: Which one is “better?” Which one will “win?”

Well, what do you need to know about that answer? You need to know how RoCE works. You need to know how the (and which) TCP stack works. You need to know how Fibre Channel works. Then you need to know what happens with congestion in each of these. THEN you need to be able to evaluate each on its own merits and in which circumstances.

Finally, you need to know what kind of environments and workloads are going to be using each of these different solutions. Then, and only then (or maybe not even then), can you get a grasp on what the best practices can and should be.

But that’s not all. The next step to all of this is not just understanding it, but being able to explain all of those interdependencies in such a way that’s brief, to-the-point, understandable, and memorable.

That’s the kind of stuff I have to do, because I get asked these questions all the time.

By the DE himself, no less.

And that is why I was offended by his comment. If you still believe that this is not a “hard” skill, then I suppose the only thing to suggest to you is that you might not quite be as good at what you do as you thought.

It’s all well and good to grok something yourself, but if you can’t exchange that value in some fashion, then you have no value at all. It must be produced into something useful, and if you find it difficult to show someone why what you know is useful, well… that’s because doing so is a hard skill.