I genuinely curious here, if you are the trusted decision person, is it not accepted if you say “the decision is we do not have enough information at this time to make a decision, thus we need to [research x/do a timeboxed poc/drill down on y part of system/etc]”?

> is it not accepted

I haven't been fired, if that's what you mean.

But I also just read an article calling out my non-committal cowardice.

I'm OK-enough at managing up these days that you could weasel word around and say it doesn't apply to me. But it's a failure pattern of management that I've seen happen to more than just myself.

I’ve been in your shoes. I found three options to work (in worst to best order): 1) I become an “overnight expert” at the expense of my work life balance and frankly the system architecture long term 2) Pushed back on management with tangible risks: a rough estimate to implement is XX and we are not confident in the solution so that could result in rework cost or worse long term scalability/maintenance cost. We propose outside (could be another expert on another team) consultation to close the risk gap. 3) We need to reassign resource X who is our most knowledgeable in adjacent tech, this takes them off feature Y and we will do a spike of duration Z to verify our approach.

When you do #3 enough your management will appreciate you using existing resources, providing the trade-offs, and you will also up skill that person.

> Telling me to just be as useful as a generalist doesn't work when it was the specialization that made me worth listening to. It's a setup for failure.

True, you will fail to make the correct decision occasionally. But you and the article are making the same mistake. You are thinking failure is the end of the story. It's not.

As a senior engineer, you're goal isn't to make perfect decisions. Your goal is to learn how to make better designs over the long term. There is really only one way to do that. Make lots of design decisions, and find out which are best. The remainder (the bulk) will be failures. So if you aren't failing often you aren't moving forward.

Or to put if another way, if you refuse to commit because of fear of failure, you are refusing to move forward at the speed you should be moving.

A lot of things flow from that. Mistakes are costly, so you have to weed them out quickly (and consequently you learn from them rapidly). That means lots of visibility, it means finding ways to test ideas on small projects and not make one large "make or break" bet, it means change control so you aren't overwhelmed by your failures.

Ultimately it means engineering leadership, which is what a senior engineer should be doing is about knowing how many mistakes you should be making and how fast you can be making them. The answer isn't 0.

He will make many errors outside his area of knowledge. As many as anyone else. They won't be better in the long term. He is senior in his area. And just like anyone else, he is junior outside of his area.

It is just magical thinking to expect some long term benefit from insisting on him bullshitting his way through something he don't understand much.

> As a senior engineer

Who? I described a SME.

There is a difference between a manager mentoring a SME's career into becoming a well rounded senior, and just expecting a talented engineer to immediately operate as a fully developed senior because that manager doesn't have anyone else to rely on today.

Now, I'm smurfing here a bit by describing a position I was at earlier in my career. I guess I appreciate the attempt to give advice, but recalling back to that time in my life you've also written with way too much management-speak for someone in a place that deserves real communication.