Paying Engineers like Salespeople

[upbeat electronic music] How's everybody feeling?

It's been, uh, seven and a half hours. We doing w- We doing okay? Yeah. Awesome. I'm Arman. Uh, like the voice of God. Apparently that's what they're called, voice of God, apparently.

Uh, so my name's Arman. I'm one of the co-founders and managing partners at a company called Tenex. Uh, my co-founder is Alex, who's been, uh, kindly announcing everybody all day.

We do a lot of cool work. We, uh, we help companies with their AI transformation. We have incredible clients all over the world, but I'm not gonna talk about any of that today.

I'm gonna talk about something much more niche. I'm gonna talk about how we pay engineers, and we pay engineers like salespeople. Earlier, I was just in the green room with a bunch of distinguished engineers that I've grown to, uh, respect for my entire career, and we were talking, and I was telling them that we pay engineers based

on the story points that they complete. And we had a lot of people roll their eyes and, and laugh. And they asked, "What do you mean?" And I said, "Clients pay us for the number of story points that we deliver, and we pay engineers based on the number of story points that they complete."

And similar to the looks that I'm getting from some of you, there was skepticism. And I know this sounds crazy, but it's working. We've been able to hire incredible engineers, many of whom have started and exited, uh, companies before this.

We have been able to hire world-class machine learning and AI researchers. We've hired rocket scientists from NASA. We are shipping code incredibly quickly, and it's maintainable and high-quality code.

Of course, that is everyone's dream. Everybody wants to hire great people. Everyone wants to deliver really sh- uh, fast code.

So my goal here is not to convince you all to adopt our model. My goal is to show you what compensation looks like in AI, and hopefully provide a new perspective on the fact that things might change as we introduce this technology.

Before I jump in, though, I want to talk about, uh, how we got here. So I'm a software engineer by training. I went to Carnegie Mellon, and then I taught there in their School of Computer Science.

After that, I went to Google and I helped them scale their AI, cloud, and mobile practices internationally before starting a few venture-backed startups. And in my last startup, I would work out of a WeWork, and I was sitting in this, uh, 33 Irving WeWork.

If any of you are from New York, you, you might have worked out of that WeWork. And they have these big tables, and there were 12 of, 12 of us kind of sitting around.

No one's talking. Everyone has their headphones in. And I look to my left, and I see, I see somebody with Visual Studio Code open. Right? I'm like, "Okay, I have a fellow engineer to my left."

And I see that he was typing, but I didn't see a chat window. This person was typing into the code editor. They were typing F-O-R, like a caveman. This, this poor person was typing, like, with their little chopstick fingers, individual characters.

I, I, I couldn't believe it. On my computer, I had 45 agents. Three were ordering me lunch. Two were writing code. One was doing research. Uh, just different worlds were happening on my computer versus this person's computer, and I felt bad.

I thought maybe we should do a GoFundMe or something. But I, I, I tried to look deeply at what is actually causing this difference. Why am I using AI in the way that I am, and why is this person not?

There are different ways that, that people try AI, and there are different reasons why people don't use it. We've all heard people who have tried it and have said, "It's not as good as me."

We've all heard people who have not tried it because they don't want to. But regardless, my belief is that this is an incentive issue. For me, I was a founder, and I wanted to squeak out every bit of incremental value and, and efficiency that I could.

And so I would sit on Twitter and LinkedIn and read blog posts and try to understand what is the cutting edge in software engineering, and what's going to give me the ability to output more code, higher quality, faster.

And because of that, I was using all these, all these different agents. But this person probably worked at a startup, probably had a base salary with an annual bonus and some equity, and that was supposed to be the model that incentivized people to be innovated-- to be innovative and to work smarter and faster and harder, but it

wasn't working. And so in order to understand how we got to where we are, I'm going to do a brief, uh, history of compensation. And this is by no means accurate.

I'm making a lot of things up here. It's all illustrative, okay? [laughs] So back in the day, we had some cavemen who were writing code. We were, were, uh, probably inscribing C in a, in a tablet somewhere, and we were paying people hourly, right?

This makes sense. I look at somebody sitting in a chair, and I'm going to pay them some amount of dollars for some amount of time. That makes sense for me, and it makes sense for the, for the engineer.

But why is that broken? I actually, I want to hear from people. Why is hourly broken?

It's slow. The output. It's slow. Output. No upside. There's no upside. There's no reason to work faster, right? In, in fact, there's a disincentive to work faster. And so what if I, I notice this as the buyer of this technology and I say, "Okay, how long is it gonna take you?

It's gonna take you five hours? Okay, so I'll pay you 500 bucks." Right? Hourly at $100, multiply that by five. And then you as the engineer, if you work faster, great.

You get to keep the $500, and if you work slower, that's on you. As engineers, we're really, really bad at estimating how long things are going to take. And so because of that, I'm not gonna say it's gonna take five hours.

I'm gonna say it's gonna take 15 hours, 20 hours, so that I have no downside. And so again, as the buyer, I don't want to pay you based on the project.

So what if we hire people on salary and give them a bonus, right? Well, we in the startup community know what happens in that, uh, uh, when, when this is the case.

People punch in at five leave... or, uh, nine, leave at five. And so I'm Larry Page. I notice this and I see why am I working so hard at Google?

Why am I putting my blood, sweat, and tears into this? It's because I have some of the upside. I own the company, right? And so when we exit for, for many, many dollars, I'm going to see that.

So what if I can share that with my employees? And that's when equity comes in. And, and this has worked. This has worked for many, many years to incentivize employees.

This is, this is the foundation of the startup community that we all know and are a part of. It's incredible.

But the... not every company is Google. In fact, for every one Google, there are many, many failures, and software engineers know this, right? For those who want to take the risk, many will just go to YC or, or start their own company.

And for the ones who don't want the risk, they're opting for cash over equity. Many of us who've hired engineers know that the cash is non-negotiable. Equity, yeah, sure, I'll take some upside.

And so my contention is that this model needs to be reinvented in the age of AI. We need to directly incentivize people to use these tools and to use them well, and to still maintain really high-quality standards of code.

And so here's how it works for us. So we basically, just to take a step back, we do two types of work at Tenex. One is road mapping and one is execution.

So companies come to us and they say, "Hey, we want AI." That's generally the request. Sometimes it's more specific. It's like, "Hey, I want my customer service team to have ten percent more, uh, output using AI," right?

But, but generally they come to us with a request. We do a bunch of studying and learning, and then we output a roadmap. And based on that roadmap, they can take it and work it, on it on their own, or we can do it.

For a lot of things, we're taking off-the-shelf tools, but a lot of what we do is custom builds, and that's where the story point model comes in. So we will build a roadmap for a lot of our clients, but once they see that, then they're putting in requests on their own as well.

And we have two roles in the company that are client-facing. One is the strategist and the other is the AI engineer. The strategists are all, are mostly technical, and so we've have, we have former PMs, we have former engineers.

They are doing PM-type work, consulting-type work. They're the ones that are taking the product requirements and distilling that down with the client. Then they hand that over to the engineer, and the engineer puts together an architecture design document.

They spend a lot of time doing that. In fact, that is where most of our engineering time goes. Then they write code and they start implementing. That ar- that architecture design document includes tickets, and each ticket is graded on some number of story points.

This is a very traditional method of doing work, right?

And when that ticket is accepted, the engineer gets paid a f- a fee per story point that they complete. Our engineers have a flat base that they're paid, and then every quarter we round up based on the story points that they've completed.

And again, this has led to us being able to hire incredible people, but we've also been able to do incredible work. So I'm gonna walk through a couple of projects that we've done.

So this is one. This is a billboard company.

If you go to Times Square right now, you'll see some billboards that they've sold that inventory for.

They sell in two ways. One is you can call them up, traditional sales, you can buy that inventory. But the other is they have like an Uber for billboards type of product where you can go online, you can upload a PNG, you can choose where you want this to run and for how long.

Similar to like a Facebook or Google Ad, it's very similar to that experience. And they came to us and they said, "Hey, we think that there's some opportunities for AI in our product."

We did an analysis and we found a few. One of them is this. We found that when an image is uploaded to their system, it has to go through two rounds of moderation.

One is internal to the company and the other is with the billboard owner.

Internal to their company, they're spending money on that to actually hire the people to do that, and there's a lot of inaccuracy and it takes a lot of time.

So that costs them money and it costs them revenue because every moment that the billboard is not running, they're not making money. And so we found, what if we could build an AI model that can actually do this moderation for them?

We scoped that out. We built the architecture, uh, design doc. We broke it down into tickets, and we built this for them. We did it in two weeks, and we got to ninety-six percent accuracy when compared to the human moderator.

We've done a lot of other projects with this company as well.

This is another company. This is-- They work with retailers all around the world, and currently they have devices in these retailers, and they're low-power devices. And so because of this, they're able to run one AI model on device.

And what this model does is it does heat mapping. So imagine there's a camera in this room, looks down, and it can basically generate a heat map of where the traffic is throughout the day.

And for retailers, of course, this is very, very useful. But there's other things you can do too, right? If we just sit here for a few minutes, we can probably come up with a lot of ideas of if you have a camera with a chip, you can make a lot of money from that.

You can show really useful information. And so that's what we did. We, we came up with what are some of the things that we could do with this? If you put a little mo- little bit more power in that chip, if you make the models, if you quantize them so they can run in parallel, what could you

do? And so we gave them this report, and then we built them five models that can run in parallel. It does everything from heat mapping to queue detection to theft detection and more.

And again, we start with the product requirements doc. We break this down into architecture, then we build it, and then we pay engineers based on the output.

This is the big question: What are the risks, right? I just talked about dandelions and rainbows, right? Uh, uh, so I promised you that my goal is not to convince you to do this, and part of this is showing you what the potential risks are.

These are a few that come up One is, what if an engineer inflates the story points, right? What if an engineer says, "Okay, you want me to add a button?

Forty-five story points." Right? What if an engineer rushes and quality drops? You're saying that it took two weeks to do that? Well, was it good? Did it work?

And what if engineers get sharp-elbowed? I started this by saying that we compensate engineers like salespeople, [laughs] and it's, it's not a, it's not a culture that we necessarily wanna emulate in software engineering, right?

So how do we, how do we, uh, make sure that that's not happening?

First of all, I mentioned that we have two different roles, and we compensate like a counterbalance. So strategists are compensated based on NRR, which really is like customer happiness, and every single ticket has to be approved internally with multiple rounds of QA, of which the strategist is involved, but also by the client.

And so there's a counterbalance to every single ticket that is delivered.

Uh, I skipped to the second one. For the first one, inflating story points, the strategists are the ones who scope it, and again, we have to review all of that.

And for the third, how do you make sure that all of this is correct, and how do you make sure that there's no sharp elbows? How do you make sure that everybody is happy, and the dandelions and rainbows are, uh, continue throughout this parade of joy?

Well, you have to hire the right people. And this is what I tell everybody. We make hiring incredibly difficult for ourselves so that everything else is easy. And that is a principle that we all know and we all stand true to, and this is incredibly important with AI.

My co-founder Alex always says AI makes people look like one of those crazy mirrors, where any one of your attributes, it makes it 10 times larger. If you're a great engineer, AI makes you great.

If you're not, it makes you sloppier. And this is the case with all of these things. You have to start with hiring.

Our belief is that AI gives people superpowers, and it makes all of us smarter, faster, and better at what we do. But my belief is that the current way that we compensate people is actually holding them back.

And I would invite you to think about how can you compensate people on your team differently, whether it's software engineering or anything else.

If you wanna unlock your employees' potential, feel free to reach out at [REDACTED:email_address]. Thank you. [upbeat music]