Hacker News new | ask | show | jobs
by sopooneo 2768 days ago
I absolutely sympathise and struggled with this myself to some extent. One thing that has worked for me is one-by-one adopting particular tactics that I see socially successful people using. And I mean I consciously note and incorporate them individually into my interactions. Eventually they get almost automatic. That may sound crazy and that it would look contrived. But I have never been called on it, no one has ever accused me of imitating another, and as far as I can tell it has been strictly beneficial. Of course, the tactics that work for me might not be the ones that would fit for you. So shop around! Watch other people and try some on.

Just for some examples of what I've adopted:

(1) When you first enter into a conversation, whether with a single person, or a group at a meeting, come in with a big smile. And actually, the worse the situation, the bigger the smile should be. I got that from my boss's boss. Likely does no apply at funerals.

(2) When listening to someone explain something, when they pause, repeat the last few words they said and nod. Like if they say, "We can't add more labor to the Jennings account, because that would pull from the Labowski project and THAT just can't happen!". You (nodding understandingly): "can't happen."

(3) When talking to non-technical people, never say the word "no". Get the idea across, and be just as clear as needed that something is not possible, but do not actually use that ego bruising two-letter word. This grates like hell against my technical mind that prefers clarity and actual reality. But I've found "no" sets business people off like startled chickens.

3 comments

But I've found "no" sets business people off like startled chickens.

Maybe because they have a more holistic view of the purpose that you’re all there for.

As a developer, your job isn’t to say yes or no. It’s to understand the problem and solve it. If no solution is available within the constraints laid out, your job is not to deliver the bad news like a robot. It’s to understand the priority of the constraints and figure out which one(s) to break so you can solve the problem.

Not picking on you, but many developers lose sight of the purpose of what they do. No business wants or needs any code or developers to write and maintain it. It’s a means to an end, and a flat “no” betrays an inversion of priorities in the developer’s mind.

I write all this as a self-employee developer by the way. It’s one reason I make a lot more than my peers who could code circles around me.

Whenever you want to say, "no", just substitute "it will cost more to do it that way, because....<endless technobabble>"

You will get interrupted somewhere in your explanation. When asked for a less costly alternative, pitch anything you would be interested in doing, and make that explanation more opaque to outsiders than the original technobabble. They don't really care to hear what you have to say; they just need to know that there is a technical cover (that only the tech employees can really understand) for choosing the status quo.

Nothing sells quite like an excuse to never change.

I've spent my career dealing with non-technical decision makers, so I understand where you're coming from, but this kind of cynicism and condescension is exactly what I'm talking about.
If you are being asked yes or no questions, the decision has already been reached. Politically, it is best to figure out what the decision is and then support it by whatever argument or rhetoric that seems plausible.

If the question is "can you do X?" then the important part of the conversation, defining what X is, has already taken place. You're just there to support the decision that has already been made. Sometimes your job as an employee is telling the boss what all their options are, and sometimes it is telling the boss that what they are already doing is correct.

If you are your own boss, you are necessarily one step removed from the politics. You can do your customer relationship management directly. Customers that ask "Can you do X?" without first asking "Can you help us decide what X should be for us?" can be refused, or quoted a higher price. Self-employed contracting is in some ways a wholesale rejection of politics, rather than learning how to play better. your main concern is "How do I pay my bills?" rather than "How do I avoid getting fired, and possibly get promoted?" As long as you have enough paying customers, you can more safely uphold your professional ethics.

Politics isn't about doing the right thing. It's about picking the least-wrong thing from a restricted list of bad options.

Not an accurate representation of the type of consulting I do.
These comments kind of reminded me of the comedy sketch, “The Expert” [1]. When nobody else will say no to an idea your meeting might end up sounding like that. I agree though that you should let people know the constraints and alternatives if you want to help forge a path ahead for their ideas.

[1]: https://youtu.be/BKorP55Aqvg

Frequently they are also fishing, and will be thrown onto a different track if you say no. Code can be made to do most anything, but just because you can doesn't mean it's worth doing. Frequently I find that people bend over and overpromise shit that isn't built, isn't scoped, and is of questionable use, because prospective customers mention something in passing. Then you are on the hook for that ill-conceived feature forever.
#3 I would go further: any time your instinct is to say no, ask yourself two questions:

“Is this really impossible, or am I prejudging the acceptability to the questioner of the cost/effort needed?” and

“Is it likely that the questioner has prejudged a solution to their actual problem, and how can I get them to step back to the real problem, which may have a more-viable solution than the one they seem to be asking about?” (A lot of time, if you are familiar with the business domain, you can see the likely underlying problem yourself and just get them to confirm it, but otherwise you can try to walk them back to it.)

“Yes, it is possible, but it will take X, Y, and Z,” from which the client can decide it is not worth it is usually more honest, as well as more socially acceptable, than “no”.

And, “That would be difficult—but if you want to acheive X, A would provide the same benefit and be much easier to implement.” Can be better than both “no” and explaining the difficulty in th suggested course without exploring alternatives.

Never say 'no', is one of the staple rules of doing improv.

https://under30ceo.com/never-say-innovation-4-lessons-improv...

I've noticed that conversations tend to go in interesting directions when you try to make it a habit of not fighting the premises that conversation partners lay out.