I recently attended a conference for engineering leaders based in San Francisco. It was a 2-day affair, and along with the usual talks and networking, the organizers smartly set up their venue for roundtables, 1:1s, and other peer-to-peer conversations that served as a direct contrast to the virtual Zoom conferences these past few years. They correctly predicted that there would be pent-up energy for in-person interactions, and smartly addressed the demand.
Of course, this being a gathering of engineering managers, many of the topics revolved around software development, AI, plus the usual subjects of business and people management. The former is unique to tech: there are software methodologies, existing and bleeding edge technologies, and dynamics of our industry that only make sense to those paid to work in it day-to-day. Conferences serve as an expedient way to keep up-to-date on best practices and current trends.
But the mechanics of management don’t change that much from year to year, and most of the material here is less revolutionary—or even evolutionary—and more of a rehash of anecdotal experiences. And while you’d think that we would study and understand how other industries have tackled analogous problems, that’s not quite what happens.
Rather than seeking to apply prior art, much like the problem of engineers not wanting to read others’ code, we engineering managers have our version of engineering exceptionalism. With brand-name companies serving as reputational validation, talks often revolve around personal stories spiced up with a tech angle. A session on communications would include tips on how to use Slack and Github over email; that’s how most of the companies here operate. Another session would talk about productivity and motivation but with a narrow focus on coding methodologies that appeal to developers. There is an entire subgenre of management books written by, and for, engineering managers1.
As an industry, we seem to lack the imagination to take lessons from other industries and apply them effectively in ours. I read The Phoenix Project on a recommendation from one of our staff engineers, and a part of its charm is appreciating the processes and mental frameworks used within the manufacturing industry. The main plot of the book, though, is about turning around a software development shop whose main character—and thus the reader—has to be shoved onto the factory floor to really, truly get the analogy. A couple of times, I’d recommend The Leadership Pipeline to folks looking to make the jump from manager → director or director → VP, but have to explain that the book draws its research from P&G to energy to traditional automobile companies. That is, it’s not an engineering leader giving specific tips to other engineering leaders on how to lead their engineers.
Harkening back to the title of this post, tech is in the adolescent phase of maturity: been around long enough to know some things, haven’t been around long enough to appreciate others’ trials and tribulations through their similar stages of pubescence. Tech has indeed been a shining bright spot in the economy for the past 3 decades—ever since the dot-com boom in the ’90s—but we sometimes assume that the profit margins enabled by software translate to revolutionary business management. Sure, engineers can be a quirky bunch, but managing them is not fundamentally different than managing other functions or folks in other industries.
A previous boss told me that they had stopped reading management books, as the advice all started to blend, but instead took inspiration and lessons from biographies of interesting people. In a similar vein, I appreciated this post that celebrates craftsmanship and strives to recognize it regardless of discipline. To chart a path beyond teenagehood, we should stay humble and curious—outside of our tech bubble.
