Thoughts on Formulaic Salaries
I helped found Quark Security in 2013, have been through two M&A’s, and have run a company with over 100 people doing $100M+ in revenue. In August of 2025, I left my last company and since then I’ve been on a sabbatical. Now that I have more time on my hands, I want to share some of my experiences with the wide and varied parts of starting and running a company. To kick things off, I want to talk about using formulas to determine salaries and bonuses.
Before I get going, a quick disclaimer: any financial figures or names are fabricated, and I’m only speaking for myself, not anyone else who was part of the leadership teams at the companies I worked at.
Background
In 2004, not too long after I finished college, I started working at Tresys Technology. I was one of the earlier employees and got to experience the growth of Tresys and the shift from pure services to a more product-focused organization. Through a ton of work and luck I became one of the key engineers and even won employee of the year in 2012.
At Tresys, most financial information, including salary information, was a black box. Once a year, we’d get a quick overview of company revenue, but there was no transparency about other financial information. At the time, that lack of openness really bothered me. Looking back, it wasn’t necessary for everyone to know all the details, but as a young, brash engineer, I wanted to understand how things worked.
In the fall of 2012, I’d been hanging out with Ed Sealing and he had talked to me about how excited he was to have just started Sealing Technologies. His excitement was infectious, and I knew that starting a company was something that I wanted to do. When the sale of Tresys happened in late 2012, it was the impetus that I needed to take the plunge. So in January 2013, I started Quark Security, Inc. with two friends.
At Quark we didn’t pay ourselves until we hired our first employee eight months after we started. Suddenly, we had to figure out how to design pay scales and benefits from scratch. We wanted to offer good pay, a bonus if we made a profit, PTO, 401k, and healthcare. For this post, I’m going to focus on salary and bonuses.
Formula System Setup
To start, we had to come up with levels for employees. We had come from the world of DoD services contracting, and in that world, pay is determined by years of experience and education. Quark would also be doing DoD services and, because that would impact what we could pay people, we had to build that into our levels. We also wanted to build in skills that we wanted our team to have. We were focused on cybersecurity software, so a lot of the skills we looked for were around programming languages, operating systems, SELinux, and other types of security knowledge.
We came up with something like this formula:
Salary = Base Salary for level in role + (Base Salary for level in role * 1% * years of service)
Bonuses were given out in two separate pools from our profit, with one given equally to all employees and one based on your time as a percentage of the total time of all non-owner employees.
Pool 1 = % of profit for pool / employees in pool
Pool 2 = % of profit for pool * time with company / all non-owner employees time with company
Let’s look at an example to make this more concrete.
Level 1 Engineer Base: $80,000
Level 2 Engineer Base $100,000
Level 3 Engineer Base $120,000
If Alice worked as a Level 2 engineer and had been with the company for two years her salary would be $100,000 + $100,000 * .01 * 2 = $102,000.00
Now let's check out what a bonus might have looked like. If we made $30K in profit in Q1, we might say 20% goes in Pool 1 and 20% goes in Pool 2. If we have four non-owner employees including Alice and the total years that all employees have worked is five years, Alice's bonus would work out to $3,900 using the formula below.
Alice Bonus = $30,000 * .2 / 4 + $30,000 * .2 * 2 / 5 = $3,900
I’m sure no one reading this is thinking about inflation (Ha? L ), but we did take that into account every year as well. We raised everyone's salaries based on the Cost-of-Living Adjustment (COLA) done by the Social Security Administration (SSA).
Why we did this and how it worked out
Why did we set it up like this? I think the biggest reason for me was around trying to be as fair as possible. If two people did the same job, they should be paid the same.
A part of determining salaries when you have pay bands is negotiating with management, and if an employee isn’t good at negotiating, they could end up with a lower salary, even if they were a better engineer. Many engineers are introverts and avoid conflict, and that could impact their pay. We wanted to take that out of our system.
If I'm honest with myself, I never enjoyed negotiating my salary, and I wanted a system where that wasn't required. I know there are plenty of leaders that enjoy salary negotiations. But trust me, plenty of bosses dread salary discussions just as much as the employees.
We also believed this approach took out the potential challenges of having one employee being upset that another employee was paid more for doing the same job. We wanted to avoid potential confrontations between employees or even with us about why Alice had a larger salary than Bob even though they both worked on the same project and were at the same level.
There are, of course, some drawbacks to our approach.
Some engineers who have the same level are just worth more than others. That might be contentious, but it's the truth. You can have two people who went to the same college, got the same degree, and have the same number of years of experience, and for a variety of reasons one of them is just better at the skills a company needs than others.
Let me give an analogy to sports to help with this. I played four years of lacrosse in high school, but even though I worked my tail off, I was probably the worst lacrosse player on the team when I graduated. I had the same experience and education as others on the team, I just wasn’t as good as other players. Some people are better at things and some are worse. Unfortunately for me, I suck at lacrosse. Some engineers, even though they go to the same college and have the same number of years of experience, are just not as good as other engineers.
Another drawback is that our system didn’t account for unique skills that a customer needed and would pay more for. If a customer said, “I know your normal rate is $100/hr, but I'll give you $120/hr if you have someone with five years of AWS experience,” the revenue would work out like below. That $20/hr more makes a big difference:
1920 Hours * $100/hr = $192,000
1920 Hours * $120/hr = $230,400
That's $38.4K more a year! Wouldn't paying someone $10K be worth that? Of course it would. But in our system, we couldn’t offer that extra $10K, and we lost out on candidates because of it.
A final drawback is that, for employees, there isn’t an incentive to perform better. If you are the key engineer on a project and do an amazing job, you get the same pay and bonus as if you are an underperforming engineer. Most people are still going to work hard, but we know money is a motivator for many people, and as a company we were not encouraging our people to perform.
Final thoughts
So what do I think of the formula system? If I were to start a company again, I would not use formulas. It makes things simpler, but to be successful you need flexibility with salaries. You are going to miss out on work and employees if you have a rigid system for pay. And in the long run, getting highly skilled employees and being able to find work will benefit everyone far more than avoiding having tough conversations about pay.
