Every once in a while, I’ll see enterprise folks mentioning that startup roles are becoming nebulous. Front-end ninja, JS guru, or supreme leader of customer success hegemony to name a few. Ok maybe that last one I just thought would be cool and doesn’t show up ever, but the sense tends to be that these amorphous titles do a disservice to those who hold them.
Roles at startups are different than those in a much larger organization. They are different. Not superior or inferior. Just different. The management experience of a Director of Engineering at Facebook is vastly greater than that of CTO or Tech Founder at a startup. Whereas the technical architecture flexibility and responsibility of that early stage CTO is infinitely greater. The jobs don’t even really compare. Why is it so different? Let’s look at a couple of factors:
- Organizational Support
- Mission definition
- Establishment of processes
We could break this apart any number of ways, but for simplicity above is a simple framework. Startups have very little organizational support. At a big company a success manager who is trying to better understand how to deal with a challenging problem might check in with other success managers, their boss, the Account Executive, the Solutions Consultant on the deal, the Product Marketing manager of the challenging functionality, or some other avenue. In a startup that same customer success manager may have been the AE, SC and no PMM is employed at the company. That individual will need to figure it out. And figure it out from first principals as this may be the first time this problem has ever come up.
Larger organizations often have more well-defined missions. These missions are normally articulated at all-hands meetings. Managers then align their measurable business objectives to those set by the executive staff. Individual contributors then align below their management team’s. Cohesivity of mission is attempted to be enforced by administrative vehicles as well as emails crafted by internal communications public relations experts. Large organizations don’t pivot as much, so it’s easier to put your head down and push forward in the specified direction. At startups nothing can just be assumed to be the right direction. From how the product is sold, to how it is supported, to how it is built. Everything is subject to change based on careful curation of limited data points.
Enterprise companies have established processes for most things. Hiring. Firing. Promoting. Evaluating. Most of the processes are well documented. When I was a government employee, I’d have a well-established process for how I would produce work, present it to my colleagues, and then submit for external action. I may do everything perfectly, get all the promotion wickets, and never really create true value for my organization. I didn’t need to. It was neither required or really desired. I was a cog in a machine that may or may not even be useful to the function of the greater machine. These inefficiencies cannot exist at a startup. Process can never impede production. It can regulate it to prevent bad code, negative customer interactions, or anything else undesirable. But no employee is safe saying, “I know this had a negative outcome, but the manual said to do it that way.”
So back to the topic of titles. Titles need to be different. The scope of work is different. The level of autonomy and responsibility for covering organizational holes is different. The nature of employment is different. The work is different. And life is different. The most information dense way of capturing all of that differential experience and communicating it to others is through that person’s title. Therefore, it stands to reason that professional titles would be nebulous or even non-existent. That said, professional titles should serve the business need and that could be different for start-up and enterprise companies.