Hacker News Reader

It's always a bit disheartening when I see someone from the engineering, product, or marketing sides of the business not understand the most basic of principles that salespeople learn at the beginning of their careers... people mostly make decisions based on needs, and if you don't ask and understand their needs you won't make the sale. Also, the more painful the problem that drives a need the more likely you will make the sale.

I had the benefit of learning this before I ever went to University by working sales jobs while in High School, and boy has it made my life easier not only as a programmer but also in nearly any collaboration with co-workers.

Don't recite features and benefits, that's just lazily hoping the person you're trying to convince will do your job for you. Take the time to ask enough questions to know and understand their needs. If the thing you're pitching can at least fit, and preferably help solve, some of those needs then you have a good chance of getting them to buy in. If, on the other hand, it doesn't address a need they have then you're going to struggle to convince them... and perhaps that may also be a clue that your solution may not actually be the best way to go.

That's why I hate sales people. Give me all the info on your product, ideally, make it easy to compare to others and I will decide myself.

The idea that one can ask me a few questions and give good advice when buying a phone, a car, a house etc.. is just bizarre.

Maybe it is not like that in the general population, but it certainly is within technically-minded people.

I feel the same. I want to make decisions based on facts, not emotional Manipulation.

That isn't emotional manipulation. It is what would get called "good communication" or maybe even "empathy" on a slow day. If someone is talking to a salesperson it can't reasonably be seen as manipulation when they explain why said person should buy the thing. That is the point of the conversation.

How do you obtain objective facts about a product?

If I buy a washing machine, it has a fixed known volume, weight capacity, power consumption, noise level. These are objective facts, no? Do you think we can have different opinions on how many kilos of clothes it can take, and be both right?

They would come from the manufacturer manual or a spec sheet or something like that.

Windows has some objective, known, minimum hardware requirements. Are they open to interpretation?

What kind of products are you buying that make you wonder how to get objective facts about them?

I have feeling that this is quite an oversimplification. OS like Windows is times and times more complex than washing machine.

I don't think that it makes any sense to choose OS by minimum requirements.

It was just an example. Did you expect me to list all possible objective facts about windows in a HN comment?

Here is another objective fact about Windows: https://news.ycombinator.com/item?id=41818815

Your feelings however seem to be good arguments?

Give me the info by email. I hate it when they try to get me on the phone.

Absolutely, me too. They push hard for the phone because many of the sales tactics don't work with email because they're based on non-verbal cues and subtle detection/exploitation. For example, many salespeople are trained to closely watch the person's face and identify what lands and what doesn't and dynamically adapt.

They also want to be able to pressure you for "next steps" or the "follow up" meeting.

I get it, a call can be a lot more efficient for a discussion. There are certainly legitimate reasons to prefer a call to an email. But it reminds me a lot of big tech companies seizing to things like "security" as an ~excuse~ justification for doing things that benefit them. I know the motives aren't pure, and that bothers me.

Most people don’t operate this way. Choice is painful and induces anxiety. There’s a high chance of getting buyers remorse even if you chose the „objectively best” model.

A good salesperson will make sure the choice process is relatively quick and painless. You will feel good afterwards knowing that all the 125 aspects that differentiate this model from the other ones are not that important. The one you chose runs your favourite apps, integrates well with your car and your home entertainment system.

Understanding this and learning how to sell helps in life, incl. negotiating architectural changes with non technical decision makers.

I don’t understand why you’re downvoted. It’s absolutely true that most people don’t like making purchasing decisions by privately comparing spec dumps, even though many programmers enjoy that.

You're telling me some people out there don't create spreadsheets and a scoring system to compare 10 different ceiling fans before purchase?

Absolutely not. It should be abstracted out enough that it can be applied to all purchases and not just ceiling fans. Otherwise, you're going to be duplicating effort for the next purchase and you don't want to have to repeat yourself.

I was actually thinking of scaling to a site first, and then expand horizontally to all ceiling-mounted products. Because what's the point if I can't monetize my decision-making system?

> A good salesperson will make sure the choice process is relatively quick and painless.

The best salesperson isn't the one whose customers are leaving the shop smiling just like a TV advert where buying X or Y will solve every problem in life, but rather the one whose customers leave the shop angry after having purchased this or that product or service, because that is an indicator they were squeezed until just before the point they tell the seller to stick their product somewhere and leave for the competition. Not that I like it, but that is how I see it.

what makes you think that this is the best way to obtain loyal and more customers?

Prisoners Dilemma vs Iterated Prisoners Dilemma.

Low trust == maximize mechanical power and optimization

Higher trust == invest time, relationship-building and lower individual transaction profit over a larger volume of profit

Few consumer sales interactions fall into the second category.

prisoner’s dilemma is a dilemma for a reason: it optimizes the total outcome badly. maybe this is why the pessimization of the modern business cycle everyone loves to cry about always works out that way — we’re all interacting in a commons where trying to screw everyone else as hard as possible is the rule, not the exception.

Depends on the market of course, but scarcity, either natural or artificial, can do wonders.

This isn’t zero sum.

OK but don't you hate it when you're trying to sign up for internet service and they're like "what sorts of things do you do on the computer?"

I know what I need just gimme the 100 MBPs plan!

"give all the info on your product"

Exactly except:

If you're a CEO, the info you care about is one set of info.

If you're a user, the info you care about is different.

If you're some other influencer, the info you care about is different again.

Everyone wants different sets of info. Good sales is figuring out what that is and giving it to you.

Why have we developed a system of organizing engineering work that is based on engineers having to sell ideas to their colleagues?

Economics.

In a way, but I have a feeling the conquest of work-life by people who don’t understand the directly-productive work the company does is a result of economics operating in the 1980s—present era of unshackled M&A. It’s a regulatory outcome.

are you trying to suggest that Darwinian selection is the most efficient way to organize a collective to achieve a goal?

Because their work impacts other people and therefore requires other people to be on board with it?

Unless you're a 1 person company, nothing you do ever only impacts you.

The fact that you have to explain this is somewhat concerning.

Usually people say that people skills are as important for having lots of impact as technical skills, but the bar for people skills is really low sometimes I guess.

It’s really weird to me that people have such a hard time imagining a world without “scaled agile” and debate over duplo-scale priorities between product managers and nerds every two weeks. In a sane world, these kinds of decisions would not be a pseudo-democratic negotiation.

What about the comment you replied to involves "scaled agile"? I may have missed this.

They are simply saying that any system involving multiple people will also involve people convincing other people to do things.

Do you have a system which doesn't involve that? Does it involve cybernetic implants and hive minds?

Even a 1 person company has customers.

The key word here is “colleagues”.

I feel this. The situation would be more obvious if it was framed as "how to make the organization give a shit about the organization's architectural proposals"

> One of the most valuable life lessons is you can't get anyone else to care about what you want them to care about basically ever.

And, just to echo this, it is quite common to see people go down in flames because of issues they knew about, were told about repeatedly and simply didn't (couldn't?) take an interest in. A situation being important isn't normally enough to get people to change their methods. They generally just do what they always do come hell or high water.

A lot of people seem to struggle with this and put it down to stupidity - which is correct, but it is more useful to see that one of the mechanisms is people not being able to do things differently based on how urgent circumstances outside their immediate concerns are.

Urgency isn't a good metric in the corporate world because basically everything is called urgent all the time (spoiler: most of the time it's not).

Hence the urgent/important matrix: https://todoist.com/productivity-methods/eisenhower-matrix

I am slowly and sadly learning this lesson. My customers are devs, and I want so badly for them to care as deeply as I do about RDBMS optimization, normalization, and referential integrity, but by and large it’s a fool’s errand.

What has worked to some extent is patiently walking them down the path of what happens if those things don’t happen, e.g. “so no one uses lookup tables or enums, so now every row has X unnecessary bytes, which puts pressure on the buffer pool, and then everyone’s queries slow down, and everyone’s SLOs trend down…”

It doesn’t always work; I’ve also had people respond that “they’ll fix it later,” (lolol sure) but it’s had better results than simply explaining why their schema is technically sub-optimal.

The absolute worst to deal with have been those who seem to completely lack empathy, and respond flatly with, “fixing that isn’t on our roadmap, and isn’t likely to be,” even when I explain that in X months, my team will be suffering from their decisions.

Maybe you already do, but I've had this exact challenge in the past as well and what has worked best is to send them some SQL queries that do it the "right" way. Often times I think they just don't want to deal with the problem: it's hard, it's uncomfortable, and nobody "up the chain" will care about it. There's plenty of reason not to want to do it.

But giving them the query, or writing the migration for them, often takes care of both one and two. I've even seen this approach ignite a passion for query optimization as it "clicked" for them!

I do this when I can, certainly, but there are only so many hours in a day, and I have larger tasks to deal with much of the time.

What I’d love is for devs to treat SQL the same as they would their primary language, instead of some mysterious and arcane artifact to be abstracted away and ignored. If I refused to use any data structure other than a dict / hashmap because “it’s good enough,” how do you think that would go over?

Of the items you listed, I only care about referential integrity (or rather, I don't want things to be wrong). Unless we are adding millions of rows on a daily basis, microoptimizations don't make a meaningful impact.

Of all the optimizations I have meassured (and I have meassured a fair number), only two types have really moved the needle: do less, and use a better algorithm.

If we need to shave a few percentage of the database access, it is more cost effective for us to get a more powerful database server. Assuming that we already have a cache and aren't doing something stupid like not using an index.

> Unless we are adding millions of rows on a daily basis, microoptimizations don't make a meaningful impact.

At toy scale (if your entire dataset can easily fit into memory on a small instance; probably < 100,000,000 rows total), then some things don’t matter as much. I disagree that they aren’t meaningful, though. Especially with Aurora, and its “what if we added even more latency to queries” model of splitting compute and storage. Go make a table with a few million rows; one column with a sequential ID, the other with UUIDv4. Index them both (in MySQL, you’d need to swap PKs between tests since it clusters), then do any kind of aggregation query, like COUNT, MAX, etc. That’s not a small difference.

A micro-optimization for an RDBMS would be something like switching a MySQL column from VARCHAR to CHAR if you’re positive that the length is fixed, to save the 1-2 bytes/row overhead. It matters at scale (thousands of tables * millions of rows can add up), but not for most.

> If we need to shave a few percentage of the database access, it is more cost effective for us to get a more powerful database server.

People always say this as though it’s fact, but I’ve yet to see any studies on it, and frankly I doubt its veracity. Take the current RDS pricing for on-demand Postgres, r7g.large vs. r7g.xlarge: in us-east-1, it’s $0.239/hr vs. $0.478/hr. That difference works out to about $2000/yr, for a single-AZ DB of the smallest non-burstable type they have. Since microservices remain all the rage, multiply that by N. You’re telling me it’s not worth the money to spend a few hours reading docs and applying the knowledge? I don’t buy it. Moreover, as someone who enjoys the craft of SWE, it’s physically painful to watch people say “eh, let’s just throw money at it” instead of understanding where their code is slow, and solving it.

Generally, I've found more success in professional interactions if I approach them not with the intent of convincing the other person of something, but with the intent of learning about their fears, concerns, and desires.

It takes a little longer and gets to my desires only obliquely, but I still tend to like the outcome more.

Indeed. Things I've used before are: "product speed is declining, see this chart. We must make these optimization to stay acceptable." And for example "We must migrate to this hosting model to keep compute costs down."

> product speed is declining, see this chart.

How do you measure product speed in a useful manner?

I'd disqualify metrics such as number of tickets, lines of code, and "story points", because they either have an undefined relationship with product velocity (e.g. LOC per week), can vary in size too much to be useful (e.g. number of tickets per week), or they're tautological (e.g. story points per week).

What's left?

I took it to mean the speed of the product, not developer velocity.

I've noticed no one seems to look at number of PRs per week or average length of time and MR is open. Those seems like they should be good metrics for both how well a team is collaborating and how fast they're moving (perhaps normalized by LOC in the MR, but then again smaller MRs tend to go through faster so maybe LOC is already reflected in the metric).

Thanks for that nugget of advice! I probably already know it deep down inside, but seldom remember it, and seldom act with that mindset. But yeah, so true. Don't try to make someone give a shit about something that they have no reason to give a shit about. Instead, tell them what's in it for them, then negotiate so there's still something in it for you.

This is small-p politics.

In a hierarchical organization, you can give directions to your direct reports. You cannot give directions sideways. You certainly cannot give directions upwards, unless it's for something legally binding like safety.

This means you need to ask nicely, to persuade, invite, and probably compromise. It's a very different set of skills.

(a "non hierarchical" organization has a hierarchy too, but it's more fluid and hard to see)

Also, for anyone who's new to this, hierarchical organizations have an informal/shadow hierarchy too, usually an extension of the de jure one.

Nah. All organisations have relationships, and the ones that appear on the org chart are usually a small subset of them. Actual hierarchies are extremely rare, e.g. even in an officially very hierarchical company there will usually be loops because someone nominally low actually controls someone nominally high.

One of the few strategies that I've seen works is "I'm going to do it this way, and I'll take all responsibility for it failing." and then if it fails, actually take responsibility for the failure.

You have to have a certain confidence in your opinion, and you have to be prepared to destroy yourself mentally and physically to deliver if things go off the rails. But once your deliver something that matches your vision, usually worth it.

Doctor, it hurts when I do that.

In certain adversarial workplaces this basically gives the other party a perpetual license to blame you and your work for any failures, no matter how circumstantial the link.

depending on how much weight their voice has it might well worth the risk. (as you gain naysayers but you also deliver results, and that might make certain important folks happy, or at least it will look good on your resume, etc..)

I don't think that destroying yourself mentally and physically should be part of your toolbox.

.. why would you do that? Martyrdom complex?

Having watched nearly all my work ever basically be thrown away, usually way before it actually provides enough benefits to have been worth the cost, and for reasons that have nothing to do with the quality of the work: yeah, I definitely don’t care enough about anything I make at work to stick my neck out quite that far. There’s professional, then there’s unhealthy.

This! It's the basis for fruitful negotiations to understand what the other person needs (which is not always what they say at first). Sometimes you can give them something that's cheap for you but valuable for them or vice versa. I can recommend the book "Getting More" by Stuart Diamond for valuable insights on how to do this.

There’s at least overlap with needs but also what their biggest pain points are currently. One way I’ve often heard it put is sell aspirin not vitamins.

And one thing that usually is cheap - as an architect - is putting yourself into the other's shoes. understand them, their lingo, their model their immediate context (cash flows, promotion, trends, cultural signifiers, business vision, their own career dreams) ... it's the interface you need to be able to actually model the problem.

Worth adding that managers have to report upwards. So you not only have to be able to generate sympathy for someone who presumably knows your product & team well, you have to arm your manager to go upwards with a good story about where your team is spending its efforts that even less technical less intimately connected business operators will need to at least check off on.

I agree with this. I want to add a product perspective here too. If your product partner routinely tries to understand your suggestions and translate them into the things that matter to themselves and the broader organization, that's a good partner.

And on the subject of things that are good to learn early in your career, everyone should know that every business is barely good enough for what it is. If it was materially better at something else that mattered, for example to its market or its economics, it would be a different business. For profit businesses are pretty effective equilibrium finding entities. I used to get really frustrated that people didn't care about improving things that I wanted to improve, until I realized that in most instances those things wouldn't really change any outcome in the business. In the cases where it would really change the business outcome, I realized the company couldn't prioritize effectively.

There's also the Bernays approach: sell your design as filling some emotional need and convince the stakeholders that they have that need.

Automobiles will make you free! This kind if free software is "free as in beer" and who doesn't want more beer? My queuing system will make you virile and attractive! Whatever works.

I think of this as empathy. Step into their frame, look around, and then come back.