The most common conversation I’ve had during the last three start-ups was the growth conversation.
Some version of: “Rands. I am here. How do I get there?”
For leadership-minded engineers, there are four career paths available to you. I will describe three briefly, and then I’ll talk about the fourth one a lot.
The first three career paths for leadership-minded engineers are CEO, CTO, or VP of Engineering.
If it strikes you a little saccharine or aggressively optimistic about showcasing these executive’s roles to an engineer who just graduated from the University of Waterloo with barely a year of experience under their belt, remember two things. First, the amount of career opportunities at a rapidly growing start-up is a lot. Double-digit hiring for multiple years means there are monthly new leadership opportunities. Second, unlike other large companies, the CEO, CTO, and VP are visible actual humans instead of “Person Who Keynotes from A Far.” This makes substantive discussion regarding these working humans aspirational and informational, as you can see with your own eyeballs how these leaders work.
The common response to my initial explanation of the three roles is silence which is expected. The person sitting across the table probably wasn’t thinking about becoming the CEO, but now they are. They are still wondering about tangible and actionable next steps for their career, but they are, more importantly, lacking a helpful framework to think about their growth. Good news, I’ve just introduced the beginnings of this framework.
CEO. Her job is the whole gosh-darned company, whether that’s product, engineering, people, real estate, legal… I could go on because the list is everything. A CEO is accountable for every single moving part, and if the human sitting across from me wants to head in this direction (the vast majority do not), then my advice is to get out of engineering. You’ve already spent at least five years of your life becoming a qualified engineer. If you aspire to run the whole show, you need to get real experience in other parts of the organization. A small leap is product management; a larger leap is running a non-engineering function like customer support.1
CTO / VP of Engineering. I can’t describe the role of CTO2 without describing the role of VP of Engineering. At a start-up, the CTO is responsible for building the machine. The product. The service. Whatever this particular company brought into being and is now selling. This could have easily been the founding VP of Engineering, but in my experience, the early engineers with leadership aspirations gravitate more towards the CTO title because it’s… shinier.3
At less than 50 engineers and without many managers, the CTO quickly realizes she needs to scale the leadership strata at the company. Still, she also knows she loves building and doesn’t aspire to lead the process, product, and people stuff that has suddenly become all that she does.
Enter the VP of Engineering. The CTO built the machine. The VP of Engineering’s job is to run the machine. Whether they are peers or the VP works for the CTO, the division of labor is roughly the same: the CTO is accountable for the technology (current and future), and the VP of Engineering is accountable for the humans who build the product, the process they develop to get that job done, and the politics (good and bad) with other teams who all significantly contribute to delivering the product.
My brief career advice for each role matches these responsibilities: if CTO lights you up, then the opportunities we’ll find for you are deeply technical and increasingly complex. We need you to stay profoundly technical and in touch with the engineers (regardless of title) who deliver bleeding-edge relevant work. If VP is the role, the opportunities we’re looking for are still engineering-focused, but we’re looking to use the other side of the brain. Work with growing the humans, the signing of process accords with other teams, defining culture, and building useful communication bridges across the company with essential partners.
The above framing is intended to start a career conversation, and after having several hundred of these, I can confirm the framing works to get a conversation started. How that conversation twists and turns is a function of the human across the table, the company’s culture, and the current leadership opportunities at the company. It is the first of multiple conversations, with each one finishing with a clear spoken-out-loud commitment to “This is what we are going to do next.”
You’re right. I said four roles. Thanks for paying attention.
The fourth role is by far the most important. It’s the role the vast majority of engineers will follow in their careers, and I’m going to call it “This. Forever.” The role you have right now is the thing you are going to do be doing forever.
Yup. You read that right.
Facts. The vast majority of engineers will not become engineering managers. It sure hasn’t felt that way for me for the past two decades, where I’ve spent my time building the leadership detritus to mint new managers out of necessity.
Unsurprisingly, engineers begin to believe the only path is that of management in these start-up scenarios. It’s the only way to maintain relevance in a rapidly evolving situation from everything they’re seeing. As a primary contributor to this erroneous perception, I apologize. We managers shine so much light on management’s necessity that we forget that leadership comes from everywhere.
And chances are you going to be doing this… forever. The name of the company might change, you’ll have a new manager now and then, and the product will have a different name, but the work you’re doing now is the class of work that will dominate your work life for years.
A depressing thought? Not when you remember you’re on a quest.
Poetry, Not Tasks
I just had a birthday. My wife wrote a very nice birthday card where she listed things she liked about me. Item number four on that list read, “How you are always on a quest.”
She’s right. At any point in my life, you could ask me, “What quest are you on?” and I’d instantly have an answer:
- Growing an American Chestnut.
- Making sure I don’t miss out on this Internet thing.
- Figuring out how humans make decisions.
- Explaining leadership to engineers in a helpful way.
- Getting the hell out of a no-win job scenario.
- Writing and publishing a book
Some of those quests were finite and understandable. Others were subjectively hilarious, but, again, if you stop me in the hallway and ask me, “Rands, what’s your quest?” I will tell you.
Notice. None of those quests read “Become a VP.” I indeed spent a lot of time thinking about what it’d take to become a VP, but the quest wasn’t the title. The quest was a cascading series of quests of advancement that gave me the confidence to believe I was qualified or that helped me build a network of humans over the years, so leadership opportunities appeared. When the interview request finally landed years later, it was an important event that resulted from a variety of quests.
Quests are actionable. They are understandable. They aren’t tasks. They are work with a bit of poetry. They are always front-of-mind, and if I’m not on a quest, my wife can confirm that my only goal at the point is, “Find a quest.”
A title is a sign-post. It tells you where you are. A title is a comforting reminder of where you are, but what is more interesting is where you are going next and how you will get there. This will involve a quest. I stand firmly behind my career title opener because it begins a vital conversation; it’s starting a story with the human across the table, not about what title they want, but what quest they need to begin.
- I’ve done this before. I was accountable for the people team, marketing, and the cafeteria. I was horrifically bad at all three.
- There are companies where the CTO title has been a parking lot for valuable engineering leaders who we can’t let go of and aren’t doing anything.
- There’s a variant to CTO, which I’ll call “Chief Architect.” Both of these roles aspire to keep banging on keyboards and inventing more products and technology. The difference between the two roles is that the CTO is willing to wade into some politics and is willing to do some people work, but the Chief Architect wants absolutely nothing to do with this work. That’s cool. Keep inventing.