202512041518 Staff engineers should take a position

[A]t some point you’ll be the person in the room with the most context (or technical skill, or institutional power). At that point, you need to take a position, whether you feel particularly confident or not. [...] If you don’t, you’re forcing people with less technical context than you to figure it out themselves.¹

While many engineers don't want to commit to a specific course of action, it's actively harmful for a 202206112233 Staff-plus engineer to do so. There are times when other people are making the decision and you are actively delegating that, but we must be clear about that. If we simply don't commit to something because we don't feel entirely confident, then someone else will have to make that decision with less information, less confidence, and less organizational air cover. It is our jobs to make calls even on 50/50 decisions, own the result good or bad, and get to the place we need to go in the long run.

[Y]ou should force yourself to make commitments when you’re the person in the room best positioned to know the answer. When you’re talking to a technical peer - e.g. another engineer on your team - with your level of context, you can be as non-committal as you like. Still:

• If you don’t take a position, you’re tacitly endorsing the decision that eventually gets made
• In the extreme, this forces your manager to make hard technical decisions that are your responsibility
• The harder the decision, the more uncertainty you should be willing to accept
• I’m only talking about functional environments. If your manager will PIP you for a missed estimate, that sucks - I don’t have any criticism for people who stay silent in that situation
• It can be genuinely scary to make a claim that you’re not sure about. But you should still do it¹