Hacker News Reader

Comment by kqr | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com