The Myth of the Anti-social Engineer
Engineers have long been typecast as poor communicators. This myth allows bad engineers to thrive, and stops us all from developing our own tech fluency.
I got my product management job at McKinsey because I was a designer who could read a balance sheet. I was 19, painfully mediocre at both finance and design, but blessed to have both skills in tandem. Shortly after joining, I was leading teams and managing clients.
I didn’t have the expertise to guide/mentor the very skilled ICs on my team, so I focused on supporting them. I got really good at selling and explaining technical decisions to “the business.”
In meetings, the senior architect would speak, but the client would look to me to translate. This gave me a misplaced sense of superiority - these brilliant engineers were doing things I couldn’t, but it didn’t matter. I’d always have the upper hand because I could communicate, and they couldn’t.
Then, one day, McKinsey held a summit for its developers. There was a series of highly technical talks and demos. Non-technical product managers like me were also invited, alongside traditional McKinsey partners and consultants.
One of my colleagues gave an excellent talk on microservices, still relatively new at the time. The crowd was engaged and began asking a series of very technical questions about his experience, potential applications, and risks.
The non-technical folks in the room - myself included - could barely follow.
Suddenly, one of the partners jumped out of his seat, grabbed the mic from the speaker, and took the stage. “Let me help,” he said smugly, “I’ll explain this in English.”
He proceeded to draw a box on the whiteboard. “See guys, a microservice is like this box….”
He then drew another box.
“You can connect it to other boxes - in other words, other microservices….”
And then another box.
And another.
“You could connect them endlessly.”
He drew box after box after box on the whiteboard. You could hear a pin drop. Imagine if someone interrupted a medical symposium to do a dramatic reading of their kid’s science report.
It dawned on me that I had it all wrong. Engineers didn’t need “help” communicating; everyone else needed to learn their language.
I had spent the week in the company of congenial, charming engineers who had no issue communicating with one another. In fact, they thrived on collaboration and craved feedback. One of the most popular talks that year was an impassioned call to action to contribute to open source.
They were the furthest thing from the Silicon Valley trope of socially awkward dudes in hoodies coding in a dark basement. In fact, in the very excellent company I had the privilege to be in, this trope simply didn’t exist.
It turned out that my “powerful communication skills” boiled down to a bare-bones grasp of how engineering worked at all. It was only an advantage because most people - like Mr. Boxyboxbox - don’t think to develop their technical fluency at all.
The myth’s origin:
This picture of engineers as socially awkward hermits comes from Silicon Valley in the ‘90s and ‘00s. At that time, the work of software engineering looked very different. There was no open source. There was barely internet. When you bought software, you went to Best Buy and bought a box with a CD-ROM.
Software engineering looked a lot like manufacturing. You built your own thing from scratch on your own island, and that software lived independently from everything else. You didn’t have many dependencies to worry about because software servicing models didn’t exist yet. You also had no way of rolling back mistakes because you couldn’t push an update once something shipped.
The people writing software also looked different. Tech wasn’t exactly a sexy, sought-after career that every undergrad wanted to break into. Culturally, it was a fringe movement—one that only a minority of early adopters had access to.
So you had contrarians writing code alone on islands. They didn’t need to worry about maintenance because once it was shipped, it was done. They didn’t need to think about how updates to a library might impact the longevity of what they had built. They rarely had expansive enterprise teams.
By virtue of being the only ones building, they reaped outsized financial rewards as the internet burgeoned. They became the faces of successful engineering. They weren’t necessarily objectively awkward, but relative to other leaders at their level - leaders who were polished, media-trained, and charming - they couldn’t help but look dorky.
Over time, the very nature of engineering changed. It was no longer possible to develop features in isolation. Modern software engineering is, by nature, interdependent. You are building a system out of smaller systems, all while those smaller systems change.
Good software engineering is no longer just about what you’re building, but also about how users and other engineers will interact with it. The work is an odd blend of art (inherently social, collaborative, and open-ended) and science (there are best practices, and, at the end of the day, it works or it doesn’t).
No lone wolves
That’s why the stereotype of the lone wolf engineer is so harmful. It not only ignores the extraordinary collaboration skills that engineering inherently requires, but it biases us toward - frankly - shitty engineers.
An engineer that can’t play well with others, has low empathy, and generally fails to accept that they live in a society will suck at their job. How well they can write code doesn’t matter because their mindset inherently creates business continuity risk. If you believe you’re making a standalone work of art, you will hoard information, build unsustainably, and be more than willing to sacrifice time/resourcing/money (that isn’t yours!) on the altar of Your Most Important Work.
What sucks further is that these engineers are often rewarded by our systems today. In Jira, they tend to get the most story points completed. They sit in very senior roles as the “rockstars” who can fix anything, fast.
What Jira won’t tell you is that these rockstars created unnecessarily complex systems to begin with. They purposely hoard information from other engineers to protect their territory, and their high speed often comes at the expense of other engineers who are left to clean up after them.
It’s kind of brilliant in a twisted way: you build something convoluted, explain things poorly, shame others for not “getting it”, and then play hero for being the only one who knows the convoluted thing you made and refused to explain in the first place!.
All in all, it’s not surprising to me that more people don’t go out of their way to learn the language of engineering. For a very long time, shitty engineers - put on a pedestal by history - went out of their way to keep people out. And this behavior went largely unchecked, because our engineering management systems rewarded their behavior.
I was lucky to have worked with exceptional engineers so early on. Despite being way out of my league, never once did I feel stupid. They encouraged my questions and gave me the courage to ask more. When I said silly things (which was often), they gently corrected me and explained.
At the time, this care and coaching made me feel shame. After all that work, I still was far from truly being technical. I didn’t like that it took so much work just to be passable.
But looking back, I’m filled with pride and gratitude. My finance and design skills were mediocre on their own, but together they became a superpower that landed me my dream job. In the same way, my passable technical skills were enough to give me the foundation to later run a startup, launch a consultancy, navigate two exits, and start Godfrey.
Interdisciplinary mastery is a force multiplier - with each incremental skill adding multiplicative value. The harder and less intuitive the new skill is to you, the stronger the multiplier is.
So if you haven’t already, take time and learn the language of engineering. Start by talking to your engineers, and do so with an open mind.
If they’re any good, they’ll want to talk to you.
Godfrey is the ally of great engineers and the worst nightmare of bad ones. By mapping maintenance, resourcing, and architecture clearly and transparently, it helps you identify your best engineers and root out bad actors.