It started with a tweet:
Agreed, particularly in looking for an external hire, it’s to compliment a missing piece within the current team and more often than not it’s the management piece.
— Allen Cheung (@allenmhc) January 23, 2020
If you read through the thread, I was responding to my friend @jackdanger, who was lamenting the lack of consistency in titles and responsibilities for startups looking to make a senior engineering hire, where a CTO/VP/Head of Engineering can imply any number of technical and managerial skills and can mean a whole range of things to hiring CEOs and their executive peers. In that regard, he’s not wrong; I do think senior engineering titles in our industry—particularly startups—are liberally applied, and in some cases are a form of compensation and career development.
Of course, my observation here is subject to a huge amount of selection bias, wherein my anecdotes are largely filtered through my personal interests in people management. Nonetheless, I do think there’s some validity, even accounting for the admittedly skewed perspective: the vast majority of companies aren’t looking to make a singular, senior technical hire from the outside, because the business does not hinge on securing a technical complement.
The more straightforward explanation is the generally accepted wisdom that years of engineering experience alone doesn’t automatically make for good management. In the context of small startups and groups of software engineers just looking to iterate towards a viable product, it’s easy to imagine a deemphasis on people management, until when the entire enterprise needs to scale out its team further and acknowledges the need to augment the team with a senior leader who’s done it before. Though my conversations through Plato’s mentorship sessions plus some of their networking events, I’ve met a lot of folks that fit this pattern—VPs hired into companies to up-level their management, line managers looking for help handling their founder-VP/CTO bosses who themselves are lacking in management experience.
A quick aside: I have a hypothesis—more a hunch, really—that one of the biggest risks to mid- and late-stage startups is the inability to scale the team, as fast as the product-market fit is opening up new opportunities and widening the business. Some of that scaling resides with individuals who need to grow themselves with the same velocity. But some of it also necessitates overhauling processes and systems, along with the churning of leadership and management that can drive those stages of growth. Hence, I’ve come around on the idea that exec turnover is often a good thing, even if it causes short-term instability, because it sets up the team for its upcoming challenges.
A more nuanced explanation is that most businesses do not need state-of-the-art software and technology to thrive. If there is a piece of technology that differentiates the product, that expertise needs to be already with the engineering team early on, if not as founding partners directly—an AI-driven startup should already have researchers as early, non-VP engineering hires. That said, I have seen a handful of instances where that an external CTO hire was driven primarily by their experience in that technological domain, but—getting back to the straightforward reasoning above—I only know of them because they opened a VP of Engineering role to actually manage the team.
Taking a step back, the motivation beyond this thread is salient: there’s value in standardizing titles across an industry. The software and startup diaspora is so young that, in conjunction with our cultural undercurrent of disrupting norms, that it feels like another instance of proliferating standards. On some level, this lack of consistency also drives the wide and deep range of job interview practices; some feel like they’re designed to mimic certification final exams because job titles on resumes have become less reliable signals of competency.
Yet, if the tradeoff here is the summarily rejection of formal field certifications1, such that the barrier to entry into software development stays low and accessible, then that may very well be worth the ambiguity.
As is often the comparison made between software engineering and other engineering disciplines.↩
