With something like a job offer, if you don't get the job you're no worse off than you were before. There's really only an upside potential. That has got to be less stressful.
A lot of times in the engineering situation we have to make these critical decisions which have a large impact on how the rest of some project goes. But the attitude generally seems to be about mitigating negative consequences, and not really hoping for or working toward some very positive outcome.
There is a similar analog in a lot of human behavior. Part of how I characterize it to myself is whether I feel that I'm, "digging myself out of a hole" or just striving for the highest gain possible (while lower gain is also fine). They two create vastly different experiences, the latter being far more positive.
In other words, finding a way to deal with low certainty situations might be key, compared to just dealing with huge amounts of rote work.
- Cultivating a slight bias for making a decision; I remind myself that sometimes any decision is way better than no decision. Especially when a) time is a factor, b) managing people who want leadership.
- Prune the decision tree. When no option seems good, I switch modes and look for decisions that seem bad. Like SATs: rule out the bad answers and then guess.
- Calibrate expectations of information. Like Poker: Care about (and attach judgement mostly to) making the right call given the cards on the table, as opposed to winning any one pot.
* make a list of pros and cons
* give each item an importance score from 0 to 10
* if the sum of pros is at least twice that of the cons: do it
I believe you can do this for small decisions as well, without creating a list. Because most of the time you have a sense about the pros being twice as valuable as the cons.Edit: Sorry, this comment is a little unrelated because the parent talked about making a choice. My comment is more about 'should I progress'.
This is very obvious situation. But what if sum is not twice larger? Or if you are not confident in your importance score? This is where game becomes harder.
Changing contexts fast whilst taking decisions on these different contexts.
I was the only tech guy in this startup and I would handle basically everything on the tech side, working daily in three different languages and various "services". After a while as long as I had planned what I had to do for the day/week things were fine, but somedays I might be tackling this hard backend problem and I get asked to fix a frontend bug right now, I fix the bug, deploy it and go back to the backend stuff, couple hours later, I get a technical support call, again I must stop what I am doing to fix whatever needs to be fixed.
So, this thing of going back and forth between the areas in which I was responsible for would really take it's toll on my work, not necessarily in my productivity/hour, but in the amount of hours really worked, amount of sleep needed(which I found quite curious) and the chance of having some small anxiety crisis(which is something I kinda have to coupe with).
"I'm just here to ask the right questions".
You ain't getting paid 2 million to ask the right questions. You're here to find the answer. I can have any person off the street ask me the right questions.
I doubt that. "Asking the right question" really means being able to identify which problems exist. From the anecdotes I read on HN about dysfunctional companies, this is sorely lacking.
backlog on deck doing waiting impeded done
This has reduced my stress and gives me a place to put things to do as they come up.
I read Personal Kanban: Mapping Work | Navigating Life by Jim Benson & Tonianne DeMaria Barry first. I found the book a bit overdone in explaining and justifying why. But maybe that is just me. I'm a scrum coach with 11 years experience as a scrum coach and 2 years as a product owner so I get the backlog, planned, doing, done thing.
These managerial decisions have, by their very functional nature, a heavier body load.
- No code reads easier than linear code.
- Linear reads easier than branched code.
- Branched reads easier than polymorphic code.
„You know what the right thing to do is. Possibly due to experiene in the task and ecpected outcomes.“
If I start the day by knowing what to do, then I don't really feel the burnout. For example, if I'm designing either a piece of hardware or firmware, and I know how to tackle the problem and it is just the matter of implementing it, I can code/design for 10 hours straight and when the workday ends, I still feel full of energy.
However, if the day is full of "decisions" (engineering or managerial), at the end of the day, I feel exhausted (and irritable, according to my family)