[jacurtis]

> sometimes your job as a BDFL may be to say "no" to your most ardent supporters. This also happens a lot for staff level platform work.

You hit the nail on the head. You've heard of a "yesman" (i recognize the sexism in that phrase, but it is the colloquial term), people that simply say yes to everything. I always joke that I am a "no-man". My job is literally to say "no" to probably 12-15 people a day. I say "yes" maybe once a week. It is actually exhausting and frustrating to be in this position.

I can't talk too much about what I do, but I am a staff level platform engineer and run a platform that no one has heard of, and no one has used directly, but it affects most people reading this. Because of how important the security and infrastructure is, my job is to field requests all day long, say "no" to almost all of them, and accept 1-3 things a month that our team actually works on.

Saying "no" so often and being "the bad guy" that no one wants to give ideas to is frustrating and difficult. It is the hardest part of the job, far more than the technical component. I actually discuss it with my therapist nearly weekly, it takes that significant of a toll on me. I enjoy the core of the work, but these externalities of the job wear me thin and I often fantasize of going back to the time when I just showed up in a daily standup, took a ticket, and went away to work on it. Essentially what I am saying is "the grass is always greener", remember that.

[hgsgm]

Why are your people asking so many bad questions?

Good questions are "how can we X?" And good answers are "here's how: Y"

Then the asker decides if they are willing and able to Y.

[grepLeigh]

Most of these kinds of questions have to do with feasibility, where the question asker doesn't have all the context needed to:

1) Decide: is this worth it for the business? NOW?

2) Delegate: ok, we've decided it's worth it NOW. Who is best equipped to execute?

So, that's not a "bad question."

Most of the time, saying "no" also comes with helping the requester de-scope to meet the crux of their obligations, save face on any commitments they won't be able to meet.

Saying "yes" means figuring out what the work will displace.

A significant part of my job as a staff infrastructure engineer was carrying this kind context between planning rituals with various time horizons, ranging from weekly to quarterly to annually.

Occasionally I would drop down into execution mode myself to knock out something particularly gnarly, or set up some pins for someone else to knock down (e.g. promo season).

[suchire]

Because most questions are not bad questions. In isolation, if you have good teammates, ideas and questions are good. It’s just that you have to say “No” in the broader context, because you always have a limited budget of time and money

[pitched]

If the constraint is time and money, maybe that could be the answer instead of a hard no? Like, “the project you’re currently on is making X dollars per day and the new idea has to at least match that.” You might start getting more interesting proposals if you train your people to pitch them properly.