Hacker News Reader

I’ve seen this a lot in the industry - sales people selling stuff they don’t really understand; engineering perf for example. Sales is simple. It requires very little knowledge - as reflected by your “GTFO”. Had there been knowledge involved people would have been treated differently. I’m not saying it’s easy, it’s just simple.

As it is such a meat grinder I can only hope it gets replaced with AI as I’ve seen many in sales not feeling well.

Trying to imprint sales principles on engineering or any other knowledge profession is what leads to horrible organizations filled with unhealthy practices and people.

To be fair, these "sales principles" leads to horrible sales organisations filled with unhealthy sales practises and people too. There's a huge difference between good salespeople and bad ones, and it's not just about closing deals. It's about finding prospects that challenge the organisation in the right way. The practises you speak of beat any salesperson into becoming a bad one focused only on closing deals.

Of course! There was a time when LOC was the measure of productivity just like the number of cold touches you make to convert to a discovery call. I've worked for public companies where you needed to make 300 cold calls a day and they are listed on NASDAQ. What I'm trying to say is that sales metrics has had time to evolve since 3500 BC. Meanwhile Comp Sci is still in it's infancy. The ironic part is that for an industry that is obsessed with data and metrics, engineers abhor any kind of metric to track performance because it's perceived more of an art. Meanwhile salespeople are under a microscope and are totally okay with it because if you're good, you're generally the highest paid person in the org.

There’s a body of work studying metrics and performance in software development/engineering.

The push for Lean (by way of Agile) has been more pronounced within IT/tech than any other non-manufacturing industry that I know. We’ve been collecting metrics for as long as I can remember, and reported them.

What is interesting here is that studies out there on knowledge work indicate that most of it is wasteful.

What you need to have for a team to perform is clarity, relevant competency and freedom to do the work - all of which are managements real job to put in place. This can be hard to grasp coming from sales; the value of flow, the detrimental effect deadlines and hard estimates have on team performance.

The individual team need to identify what they can do to become better and they should measure this. But not in any way should we put this relative to other teams metrics.

For example: one team might frequently end up in wait state due to a stakeholder or customer, when touching specific parts of the code/system. This usually leads to the team picking up new work while waiting, increasing WIP and context switching.

Another team have to deal with a lot of legacy code within their domain, that doesn’t build or test well. This have to be prioritized if this is important software or else this team will be a hog for eternity.

Measuring these things is important, and most definitely possible - you just have to understand the profession.

The way you describe a technical team is how high-performing sales teams operate. Millions of dollars are at stake, we will rape every angle till it's raw to make sure we close the deal. I know a customer's birthday, their children's sports, their hobbies, and what they give a fuck about in a non-invasive way because at the end of the day a customer buys because they trust that you will deliver and not because you have a bunch of PhDs in Comp Sci. I closed a multi-million dollar deal because my competitor didn't pick up his phone at 8pm when his car was towed after a day of talking to press. He left his wallet in his car and couldn't get it out of the impound lot. Luckily he had my number and I bailed out his car with my corp CC. Meanwhile, our competitor thought the deal was sealed, but I fucking snatched that from their mouth and ran the most successful campaigns in company history. Sondors e-bikes if anyone is curious.

This is good sales work, but far removed from knowledge work.

They need to be treated differently as your driver probably differs by miles from what drives my team of system developers. For someone in sales, maybe with compensation in the form of commission you have clear metrics every month. I can have guys sit around and think for a couple of months with the benefit of us staying agile and malleable two years from now. This is where the disciplines differ by a lot and must be treated and measured differently.

Totally agree - I'm challenging the sales dept over here to actually work with process goals instead of results. For example amount of meetings might be an interesting metric, but what makes for a GOOD meeting?

Can we identify a good meeting and "turn up the good"? Much harder, and requires actual leadership.

you can generally measure that with churn in the enterprise Saas world. But that's a lag indicator so it's tough to see into the future. To address what a good meeting is, I worked for a startup where a salesperson closed Netflix as an account, we all gave each other high fives but they never used the product due to security concerns and churned a year later. Meanwhile I understood that we were still in early stages of product development and closed winery clients and they are still customers after three years because what we had at the time is what they needed. Netflix wasn't a bad customer, but the salesperson set expectations too high and the eng team got crushed by the demands.

> If a salesperson does this, after 2 quarters of missing your quota, you’re fired. Doesn’t matter if you had monster quarters before that, if you’re not hitting your numbers, GTFO.

Did I get it right that you think this is the right approach for dealing with your salespeople, that it improves long-term productivity of the organisation?

It depends. But I'd challenge you to ask your own sales leader at your company what their policy is and their reasoning.

> A Pull Request is basically the same as an Opportunity in your JIRA/SFDC

What?

For an Opportunity, it's usually pretty clear and very very easy to measure, how much the company gains from that and when.

How do you measure the gains from a PR? If you can't than literally everything else is completely meaningless. Don't forget that PRs can also be net negative to the company.

It's a myth that it's "very very easy" to measure how much the company gains from a sale. The base revenue is clear as day, yes. But then there's publicity, word-of-mouth, usually extra revenue streams, and the cost of the customer is often not at all clear until they've been onboarded.

One of the big problems in most sales organisations I've seen is that they think that the base revenue is all that matters.

True, but still. Unless we talk about highly custom enterprise contracts or so, the unit economics is much easier. Maybe not very very easy, I take that one back, haha. But estimating the marketing impact per contract signed is still more or less a one time thing. Not so with PRs.

This is a good point. The sale is not equal to net present value. However, at least it is quantifiable in some way and somewhat easy to incentivize for. Much easier than attempting to assign net present value to a patch.

On this.

There are two major issues with "missing shipping"

1. More often than not the feature or the dev that holds thing back. It's the unknown, or didn't think of side effects. Like walking the coast of California in 2 weeks. If you don't hit a river or bit of beach that's been eroded away, or a cliff, you're good.

2. As you said metric take a while to figure out. Lets say we give Comp Sci a 10th of the time to figure out metrics as we've had at sales. So.. we should be all set in say 500 years :)