Start-Up Titles are Dangerous

 

Titles are always tricky, but particularly dangerous in the startup environment. It’s the much more pedestrian titles that create equal if not bigger problems (e.g. “Engineer”, “Manager”, “Director”, Vice President”, “CxO”, etc.). Their danger comes in two forms:

Titles become Entitlement

Like salary, titles are extremely hard to adjust downward. Unlikely salary, your titles are directly tied to roles and those will change quickly. The resulting mismatch can cause havoc in a nascent organisation. Who doesn’t know a start-up where the first technical hire assumed the most senior technical title (e.g. VP Engineering, CTO, etc.). That sounds nice but usually isn’t the best idea. Your early employees will usually be developers or small team leaders. That’s what they do well, what the company needs and what you should base your hiring decision on. As your company grows you will eventually need those senior CxO/VP skill sets such as larger team management, strategic vision and process experience. Maybe your early developer can grow into that role but the curve will likely be too steep or the interest simply not there. At that point you are stuck. Downgrading titles will create discontent and possible the lost of a core developer. Patching or ignoring the problem will rob you of one of the most important assets of a company: good leadership.

Titles create Expectations

With the exception of the odd walk-in star, most hires start within the company as a vision of a role to be filled. After a while that vision gets converted into a job description and assigned a title. That title then becomes the connection point between employee and employer. The employee will aspire to achieve the results implied by the title. That’s why so many new management hires immediately trigger the creation of a department around the title — whether the company needs one or not. Part of this might be turf creation but I actually think that most of it arises from the expectactions set by the title. Call somebody a Vice President of Operations and you create the impression that “Operations” is a major aspect of your company — requiring strategic vision and a direct line to the CEO. Usually it doesn’t. In my experience, most early stage start-up VP Ops’s have a work day consistent with the title of “Office Admin” or “IT Support”. The alternative is somebody who functions like a Fortune 500 VP Ops in a 3-person start-up. Both are bad, the pain just hits at different times.

The inverse of this expectation problem is that companies often consider functional areas “dealt with” if they assign a title to it. Hired a VP of Marketing? All that business stuff shouldn’t be a problem then… This only really works if your hire’s skills, the requirements of the role and the title actually all match up (at that point in time, since the requirements are also often changing every few months). If your business needs an experienced marketing strategist then you better hire an experienced marketing person and call him a VP. Just giving your first sales guy the VP title won’t do the job.

We have made pretty much all of these mistakes at some point or another in the past. What makes them so hard to avoid is that everybody involved is often a good person and strong performer. Weeding out low performers is a cakewalk compared to recognising that a strong performer is matched with either the wrong role or one that isn’t right for the company at that level of capacity. The problem also existing across all levels of seniority and company sizes (at least based on my limited experience).

We recommend that you try to offer titles at a level appropriate to the actual function of the person in your company at that time rather than the “experience” of the person. In other words, set titles that describe your employees activities, not your employees capacities. This very likely means that your first few hires (or even co-founders) won’t be called VP or CxO. Somebody who likes to write good code and wants to continue to write code probably should be called a Code Developer (maybe Lead or Senior Code Developer, but not VP Engineering). Even if they are a co-founder of the venture. That’s a hard dialog to have early on but it is infinitely harder later in the venture.

Also try to seperate roles that contribute primarily through their individual effort or skills versus those that contribute by leveraging the activities of others. Only the latter is strictly speaking a management function. This doesn’t necessarily mean that every manager should have people reports, but rather that their impact on the company should be multiplicative rather than additive. Adding an individual contributor to any company will add one unit of impact. Adding a leveraging manager will create an impact proportional to the size of the company or business. When you hire your next VP of Anything, consider carefully whether the person will make a multiplicative contribution in terms of skill set and role.

Finally, try to tackle these issues as early as possible. It only get’s worse over time.