The Myth that Technical Skills Alone Will Make You Great
Recently, The New York Times featured The Effective Engineer in a piece about how skills like empathy, collaboration, and communication play critical roles in software engineering. These interpersonal skills often get overlooked — in favor of technical skills — and it’s not difficult to see why.
The emphasis on the “hard” technical skills over the “soft” interpersonal skills in engineering starts as early as in school.
Nearly all of my computer science classes at MIT focused on the technical skills — ones like algorithms, systems, abstractions, design patterns. Very little instruction was provided on how to work effectively in teams, despite there being many opportunities for group projects.
I remember in one group project, a friend and project member consistently wasn’t pulling his own weight. Rather than confronting him on the issue, the rest of us just worked longer hours to cover for him. We lacked the maturity to approach the difficult issue, the tools for having uncomfortable conversations, and the context for how dialogue might have offered an important learning experience
And we all still ended up getting an A in the project and in the class. That only served to reinforce the wrong lesson, that perhaps interpersonal skills weren’t that necessary after all.
Our choice to overlook the situation was not healthy — how long can we sustain relationships where we always have to put in 120%? — nor was it the type of behavior we’d want to instill in new engineers entering the industry. It was a missed opportunity to learn more about what effective teamwork looked like and the conversations necessary to bring it about.
And here’s the thing.
The more time I’ve spent in engineering and in coaching conversations, the more it’s become painfully apparent that strong technical skills will only get you so far. You might even get an “A” like I did, for some definition of success. But you’ll plateau. Because ultimately, it’s the strength in the interpersonal skills that distinguishes the most effective teams and leaders.
Climb Beyond the Plateau
At Google, the expectation is that every engineer the company hires should eventually level up to at least a “senior engineer” — two promotions above an entry-level position. Googlers sometimes even describe that level as a “terminal” level, in that many people would be content with staying there for the rest of their careers.
Of course, at many tech companies, five or six more levels often exist above the position of senior software engineer. So why is stopping so early in the ladder the norm? What is upper limiting our careers and stopping us from achieving more?
One key observation is that people can often become senior engineers purely through strong technical execution on individual projects. In fact, Google engineering interviews often only assess the technical element. So if you define your “A” as becoming a senior engineer, then just as with my class project, you can likely get there just by powering through on technical execution alone.
But we’re all capable of so much more.
Breaking past that limit – and your personal limit of what you can achieve from purely technical execution may be higher or lower, but it’s there – requires leveraging a separate set of interpersonal skills. You need to be able to effectively communicate your ideas to reduce wasted energy from misinterpretations. You need to clear mistaken assumptions to build trust. You need to explicitly design your work relationships so that each side understands what the other wants and needs. You need to ask for and give feedback so that the team continually grows more effective.
The bottom line is that there’s a limit to how much impact you can create by effectively executing on your own. Shipping higher-impact and bigger projects involves working effectively with other engineers, product managers, designers, and people on your team.
Break old patterns, and replace them with new ones
The hard part about breaking past our limits is that it often requires letting go of old patterns of behavior — ones that might have served us so well in the past — and replacing them with new patterns that open up higher levels of performance.
Marshall Goldsmith, an executive coach who’s worked with over 150 major CEOs and management teams, wrote an entire book, What Got You Here Won’t Get You There, on the theme of how the early habits we develop often aren’t sufficient for us to reach our full potential.
We see the same theme everywhere, including sports as well.
Tiger Woods unlearned and reinvented his golf swing three times over his career. 1 Roger Federer reinvented his backhand after his injury. 2 Michael Jordan mastered his bump and fadeaway jump shot when he could no longer rely on his youth to physically power through the defense. 3
Had each of these athletes relied on the skills that got them where they were, they would still have been great athletes — but they wouldn’t have dominated their fields for such a long time. The patterns and skills that got each of these athletes into the world’s spotlight were powerful, but they weren’t enough to make them — and keep them at — the best in their game.
To do that, they needed to replace old patterns with new, better patterns — often with the help of their coaches.
The same’s true for software engineering. The patterns and technical skills that get us to a level of senior engineer — strong abstractions, clean code, fast iteration speed — are all important, but they’re not sufficient to help us create the impact we’re capable of. To become the best versions of the engineers and leaders we can be, we need new patterns.
Exploring these new patterns is the work I do in the engineering circles mentioned in the New York Times article. I lead groups of engineers and leaders to have open dialogue how to explicitly design work relationships, how to understand their concerns around asking for help, how to ask powerful questions to discover what other people value, and other meaningful topics.
It’s what I taught in a leadership workshop last week in Vancouver. We covered fun tools for connecting more deeply at work. We discussed how to create relationships where each side can productively ask for and get what they want and need — so that instead of being frustrated from pitching in 120% all the time, everyone’s putting in their 100%.
Breaking old patterns and teaching new ones are also what I do when I coach engineers and engineering leaders. They’re already successful by many measures, but they’re wanting more. Their teams continue to grow, and they know that they’ll need to grow along with them if they’re to continue leading fulfilling careers and creating the impact they want. (By the way, if you’re already an excellent engineer or leader and you’re excited and ready to take your leadership and impact in the world to the next level, sign up for a coaching session.)
And this is the work I’m excited to continue sharing with you: the high-leverage, interpersonal skills that will enable you to break through the limits of your career and open up what’s possible.
If you’re not already on my mailing list, where I’ll be breaking down these new patterns into powerful frameworks you can use for effective technical leadership, add yourself now. You’ll immediately get the single, most valuable lesson I’ve learned in my professional life, and we’ll continue to build on that going forward.
Scott Eden, “Stroke of Madness,”, ESPN, January 22nd, 2013. ↩
Chris Almeida, “Roger Federer Is Unassailable Again”, The Ringer, July 17th, 2017. ↩
Kelly Scaletta, “How Michael Jordan Re-Defined His Game to Extend Legendary Career”, Bleacher Report, August 21st, 2013. ↩
“A comprehensive tour of our industry's collective wisdom written with clarity.”
— Jack Heart, Engineering Manager at Asana
“Edmond managed to distill his decade of engineering experience into crystal-clear best practices.”
— Daniel Peng, Senior Staff Engineer at Google
“A comprehensive tour of our industry's collective wisdom written with clarity.”
— Jack Heart, Engineering Manager at Asana
“Edmond managed to distill his decade of engineering experience into crystal-clear best practices.”
— Daniel Peng, Senior Staff Engineer at Google
Leave a Comment