Ask HN: Resources for introverted devs to learn workplace politics?

Be careful, this can go sooooo badly!

“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.

I found it interesting that you phrased your interest as "learn workplace politics." From what you describe, it sounds more like this is more an issue of communications and process. I work in the consulting industry, where communications and process are often both critical to successful outcomes.

When I was starting out, I found Gerry Weinberg's books Becoming a Technical Leader, Secrets of Consulting, and The Psychology of Computer Programming to be very interesting and helpful. In fact, in one of them (I think it's Becoming a Technical Leader), Weinberg talks about how an "introvert" may actually turn out to be the more effective technical leader because they focus on solving problems instead of talking about them.

Weinberg also talks about not saying "no" (suggested in another comment), and this is something I've found to be very valuable in consulting. Rather than just telling someone their request can't be done, or accepting it mutely, tell them how much it will cost to do it (Weinberg explains this as the "Orange Juice Test" in Secrets of Consulting).

I do agree with the comment about using wireframes to confirm your understanding/spec with your users. There are other techniques that can also work (e.g., creating user stories with your stakeholders), but the common element is that you must communicate clearly, concisely, and cooperatively with others.

Sorry this comment is a little scattershot, but best of luck with your efforts.

1. I agree with the others who said it's a thing you need to practice. While talking to people can be stressful, talking to people about things you're interested in is much less stressful. Find something in common and talk about that.

The connection doesn't need to be done entirely in person. For example, if you and your coworker share an interest in some area (space flight; unit testing; a particular video game; etc.), and you come across an interesting article, write a quick note to that person saying "Hey, saw this, thought you might find it interesting. I like how..." Then when you see that person, there's a good chance they'll say "thanks for sending me the article on Topic X that we both enjoy!" and a relatively low-stress conversation will follow.

2. On the other hand, it helps to set limits. If the sales people you work with tend to be more challenging, see if you can involve your boss, a product manager, or someone like that as a filter. Set-up time on your calendar blocking off meetings. Meet people half way, certainly, but also make it clear what you need to be successful.