Larson - An Elegant Puzzle: Systems of Engineering Management

one of the hardest things is to know when to quit a process that’s not working
- model, document, share/mandate
how do you scale consistency within a team?
- often times architecture and product groups begin to arise
presenting:
- start with the conclusion!
- from topic and narration
- prepare a lot, practice a little
- value, narrate, ask, diagnosis, principles, what’s next, ask <- general plan of attack
work the policy
- ask, but know from the policy where you can ask
velocity context for alerts
- how likely is something to be escaled to an outage scenario?
you have to know when to say no -> often withholding consent leads to a devaluation of saying no
speficing quotas makes things obvious and convicing, often times its good to set a quota when asking for something
double down on problems
relationship to company size curve
ask in interviews
- what problems I’m trying to solve
- what I’m making progress on
- what I want to work on
- How busy I am
- what my goals are
- How I believe I’m being measured
feedback is harder as it becomes increasingly specialized
half life of code
- your context is a week long for code, but realistically the half life of code is 2-3 years