[jsmeaton]

I often give similar advice to colleagues that ask me for pointers on getting their recommendations approved.

"Make it as easy as possible for them to say yes"

Don't dump 14 paragraphs in front of someone expecting them to get onto the same level that you've been after many hours of studying a problem. If you're confident in your approach (and you should be, if you want an easy yes!), then be succinct, briefly describe the problem and why your solution is correct. Optionally link to a document that has more information if a reader wants to go deeper. Make sure you've already gained "approval" from your other team mates or product owners.

"We're going to solve X by doing Y. Team are all onboard. Proposal document is at [link] if you want the detail. Going to begin on Tuesday unless there's any more feedback we need to address."

Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.

[whoknowsidont]

>Managers etc don't have time to get into the detail of every little thing, and appreciate when you've done the work, including gaining support from the wider team, so if they need to approve, they can just approve.

This is how popularity contests start lol. Managers that work this way are ineffective / pointless.

[nlitened]

A manager that organized their team so that each team member makes concrete thought-out proposals with all details covered, so that it's their only job left is to give approvals and do nothing else? I'd say that's a brilliant manager

[andrei_says_]

I agree and that’s how I often get things greenlit.

Pro tip: have a quick conversation with a manager and have them make a decision on a $noncriticaldetail before the announcement.

[silvestrov]

And for some managers you really need to make it obvious what $noncriticaldetail is so they don't change something important: https://museumjorn.dk/wp-content/uploads/2021/05/48s-1.jpg

[andrei_says_]

So yes, in this example - add a tower to the house and paint it like a sugar cane.

[hnthrow90348765]

Maybe I should be a developer that just tries to get everything pushed off to someone else, or just reject the work for reasons so that's my only job.

[nlitened]

You can! The job is called VP of Engineering

[dheera]

> If you're confident in your approach

That's the thing. I'm not a narcissist, and my confidence in my approaches is driven by the objective statistics and uncertainties of the approach and NOT my ego.

If I think there's a 90% chance something will fail but there's a good reason to try it for the 10% scenario in which it succeeds, that's exactly my confidence and I'm not going to coat it in some bullshit pitch about how I'm confident it is going to work. If there's an 80% chance it is going to work, I will not lie about the 20%. And if I say 98%, it's actually pretty damn near that. The 2% accounts for my typical sick days per year.

Your job as a manager is to deal with these statistics and hedge the risks. Hedge funds do it with money, you do it with people and resources.

Unfortunately it's the people who say it's going to work 100% and actually fail 50% of the time that get the love of typical corporate managers.

[jldugger]

While I doubt most people have sufficient "objective statistics" to truly remove ego from the equation, there's a middleground here.

Write up your detailed proposal as typical, but before you click send, put an "executive summary" at the top, with maybe two sentences. One to describe the problem and one to describe the solution. You can put all the detail you want in the rest of the document. But the onus remains on you the engineer to make a recommendation, not just list options. If you genuinely believe yourself to be a probabilities it should be easy!

[jsmeaton]

Agree. Rounding most of the advice to providing an executive summary is about right.

If you’re not fully confident and think an experiment is worth while, lead with that, and provide assurances there are mitigations in place or a decision is easy to back out of. That’s still doing the work.

If you want an easy decision, you need to do the work. Not expect others to get into all the detail you did. There’s still room for those decisions - they’re just not as quick/easy.