Close the technical/non-technical divide

[kcwatkins]

I was surprised to see that "non-technical" employees are paid substantially less than employees who are considered technical. In my experience this creates and perpetuates cultures that devalue and discriminate against the contributions of employees who are not pushing code, when in fact, companies succeed or fail because of their work. Code becomes a product that people want to use, learn to love, and gain loyalty toward because of the work of marketing, support, docs, design, research, and other teams beyond engineering.

As someone who works in marketing (but can also code), I have faced many situations where I was considered "less than" due to organizational policies that validated the work of engineers over mine. Your pay hierarchy may seem minor at first glance, but I've found that even small signals about who is important factor into larger perceptions around influence and power in ways that make it hard to get anything done when you are not among the chosen few...e.g., engineers.

It's also unclear here and more generally what facts inform the technical/non-technical divide. A finance employee is technical in their domain, as are other employees focused on key parts of your business beyond engineering. Without more clarity into how a technical vs. non-technical assessment is performed, salaries based on this divide seem to not be grounded in the equality goals that inform the rest of the handbook.

I hope that Clef can consider being more of a beacon here - valuing all employees more equally and encouraging our industry to move past the technical/non-technical divide as it's not ultimately helpful for anyone.

[iamb55]

Hey @kcshearon, this is definitely something we thought really hard about as we were making the rubric, and not something I've reconciled with myself ideologically. The reality is that the market salary for different positions are different, and that technical skills command much higher salaries in this industry. We intentionally made the gap smaller than our market research indicated we should, but we didn't close it completely. If we did, we would be paying some folks drastically more than they would be making elsewhere, while paying others about what they expect.

All of that said, I'm not sure that market dynamics accurately reflect the value a company gets from an employee, and perhaps even pay would make our non-technical positions more competitive, so we would end up with candidates who's value matched their compensation.

Or maybe we shouldn't expect employee value to match compensation. Companies make profit from the fact that they pay employees less than they make, so perhaps that line of thinking is deceptive itself. I'm not sure, but I know that picking a rubric and publishing it is the first step. We should definitely add more clarity about what "technical" means and think about how salaries play into perceived importance within the company no matter what else we decide. Thanks for bringing this up!

[kcwatkins]

@brennenbyrne thanks for responding. A few things in return:

The reality is that the market salary for different positions are different, and that technical skills command much higher salaries in this industry.

While this is perfectly valid motivation for your rubric, I find myself struggling with how lines are being drawn here vs the rest of the handbook. In many other cases you are actively saying that industry standards are bankrupt and should be challenged. Can you shed more light on why this particular case is different and why are you willing to roll with what the industry deems as valid here?

If we did, we would be paying some folks drastically more than they would be making elsewhere, while paying others about what they expect.

I'm not sure where salary benchmarks were pulled, but based on my experiences you are currently paying below market for all positions. Might be worth more investigation.

[ghost]

As a software engineer, :+1:

I care much more for a flat pay hierarchy (which is possible) than for a flat responsibility hierarchy (which can't exist when your company size grows above a handful of employees). I'd be very content with making less if it'd mean that everyone's employment is treated equally, including its remuneration.

[troy]

Regarding @rhymoid's comment, as a prospective employee, I want the opposite of what he described. Namely, I don't care about a flat pay hierarchy. I do want some people to be paid more than others and I'm not content making less so that everyone can be paid the same. In the best case, others make more than me -- hopefully because they contribute more. They give me examples to grow into.

I don't pretend to know which goal is right for Clef -- that's up to Brennen, Jesse, and the team to decide. Just know you'll have some supporters and some detractors regardless.

[jessepollak]

Thanks for your thoughts @kcshearon, @rhymoid, and @troy!

One note that I do want to add is that while the cash compensation is variable based on role, the equity compensation is flat for all employees, regardless of when they join (within the first 10) and their role.

I think when we looked at this problem, we faced the reality that as a small startup, we have very limited resources to work with. Following market rate salaries for roles, while asserting equality in long term impact on the company by making equity grants equal, was the compromise we came to and it let's us keep operating costs lower, while still making a statement. I'm not sure this compromise in it's current form is right, and I'm swayed by much of the discussion by @kcshearon, but I do think it's an important perspective to share.

[troy]

That seems like a totally logical compromise given, as you put it, the reality of being a small startup. When I created a bonus plan for my company, I made distributions equal not because I favored equal pay, but because, with the information available to me, I couldn't see enough difference to reward people differently. I think "Everyone is making pretty much the same contribution and taking pretty much the same risk" is a fantastic reason to reward people the same.

[kcwatkins]

I think when we looked at this problem, we faced the reality that as a small startup, we have very limited resources to work with

Given this reality, have you considered a rubric based solely on experience rather than assumptions around technical vs non-technical contributions? If you pursued this route, you could come up with some leveling docs around responsibilities and skills based on experience and equate pay ranges with those.

To be clear on what my point is here, for me this is not about binaries around flat pay vs a pay scale wit hierachy. It's that a pay scale with hierchy grounded in the technical/non-technical divide seems off base.

[isicalynn]

Interesting discussion. I don't have solutions but I have thought about the fact that as it stands now, if Clef hires a junior engineer to join the marketing team, they will be offered the same salary as I have, with ten years experience. I'm unsure if that were to become reality, that my team would respect me. Additionally, I think its interesting to think about my situation in particular. I can code. (not well) I have a technical background. But my position, as Dir. of Marketing, doesn't require that I code as a critical part of my role. I would go even further in saying that even if I was an excellent developer, I wouldnt be able to do my job one bit better, but I would have more "value." That doesn't feel great. I guess I could go and take a Python course or something.