kevinmeredith · May 6, 2019 14:34
diff --git a/a.txt b/a.txt
 (1) Creating an Engineering Career Ladder 

 * he rolled out two career ladders in his experience
 * he disputes that any company truly has a "flat org"
 * notes that Senior Level Engineer is the anchor
 * messaging is critical, e.g. important to announce promotions since it indicates importance of career ladder
 * comments that general feedback, "you're doing great" isn't worth much. He suggests giving specific feedback on positives or needs-improvement
 * Talked about 3 ladders: 
  - simple
  - snowflake
  - spreadsheet

 (2) monolith -> modular monolith talk

 * good for new companies/startups to use monoliths
 * pro and cons:
  - latency between microservices
   - KMM: Luke mentioned, in our data center, propagation delay is a few milliseconds
  - microservices require coordinated deployments
   - KMM: not sure I follow this one - maybe they were deploying endpoints that broke their contracts?
  - separate PRs causes problems
   - KMM: I didn't understand this issue. Smaller code-bases make them easier to understand, I'd say.
 
 (3) Liz of HoneyComb
  - Production Excellence
    - coding, testing, and maintaining code in production, with a focus on the maintenance in prod part
  - alert on Service Level Objectives (SLO)
    - Perfect SLO > Good SLO >>> No SLO
  - don't have a hero culture - share knowledge
  - address risks that threaten SLO

 (4) Communication and Documenting Architectural Decision
 (a) 
   - Mike Nygard coined Architecture Design Records, ADRs.
    - Basically it's a way to keep track of decisions, i.e. explain why a choice was made. It's helpful to do so so that others, who weren't part of the project earlier in its life-cycle, can understand (and challenge) decisions
    - Example ADR: https://github.com/davidaayers/ea-talk/blob/master/adr/0001-use-markdown-for-adrs.md
 (b) guilds
  - create Special Interest Groups (SIG) to discuss issues within a company
   - language choice was one at his company, namely adding Go 
   - SIG offered everyone an opportunity to voice their thoughts
     - David, as an Architect, had vetoed power over SIG decisions. However, he never issued one
 (c) Reference Implementation
    - basically he suggests what we already have in the template-service

 (5) Kotlin Multiplatform
 - talk focused on Kotlin Multiplatform, which, as I incompletely understand, targets a range of platforms, e.g. Android, Native, iOS
  - The speaker moved quickly, and I know little about Kotlin/Mobile, so I didn't take too much away

 (6) Burnout
 - emotional exhaustion (also can occur if person doesn't find value in their work)
 - depersonalization
 - reduced personal accomplishment
 - trouble at work may come from trouble at home

 (7) Being Right is Half the Work
  1. How to Read People's Minds
    - ask them questions!
  2. How to see the Future
    - socialize/discuss ideas with people before a big meeting
  
 Discussed the value of "even over" mission statements. Examples:

 * Sustainability even over profitability
 * Innovation even over predictability

 It also talked about not using "blur" words, i.e. words that are ambiguous. Use precise, explicit language.

 (8) Glue 

 - defined it, in my words, as non-technical collaboration work that's critical for a project's success
 - example from talk: Senior Developer was stuck trying to understand an email chain over 3 weeks. A Junior Developer acted as glue in scheduling a meeting with the Senior Dev and other team to get the Sr Dev un-stuck.
  - problem with being glue, the talk mentioned, is that sometimes a company does not consider it to be promotable work
 - author noted that glue assignments should be shared by the team so one person doesn't get stuck as the "glue person"

 (9) Myths 

 - didn't take too many notes

 (10) Remote Teams

 - one note, since Banno does remote so well, is having a moderator during a meeting so everyone gets to speak
  - it's easy for a few folks, given their outspokenness, to take over a meeting; that's to the detriment of not having quiet folks' opinions

 (11) Leading Engineering Teams through Rapid Change

 - no notes

 (12) Crucial Career Discussions

 - managers/leaders should show their weakness/that they're people too
 - ask direct reports about what they'd like to do - are they happy?

 (13) Mental Models

 - Multiple levels of thinking:

  (1) Event - low impact, i.e. fix a defect affecting 1 user
  (2) Trend - still low impact, but greater than an Event
  (3) System Thinking 
  (4) Mental Model

 - Use 5 Why's when investigating an incident

 (14) Senior Director of Infra at Slack

 - Former CTO twice, needed a job since her company was bought
 - worked at Slack from 1M Daily Active Users to 10M
 (1) write well and quickly
 (2) stories are very powerful
 (3) have a communication plan for everything
 (4) know your audience
 (5) too many meetings
   - organizational drift can occur
 (6) Create structure and process around things
 (7) Know who the decision maker is
   - "Decision Purgatory"
 (8) Credit always flows to most visible/senior
   - always assign and share credit
	(1) Creating an Engineering Career Ladder

	* he rolled out two career ladders in his experience
	* he disputes that any company truly has a "flat org"
	* notes that Senior Level Engineer is the anchor
	* messaging is critical, e.g. important to announce promotions since it indicates importance of career ladder
	* comments that general feedback, "you're doing great" isn't worth much. He suggests giving specific feedback on positives or needs-improvement
	* Talked about 3 ladders:
	- simple
	- snowflake
	- spreadsheet

	(2) monolith -> modular monolith talk

	* good for new companies/startups to use monoliths
	* pro and cons:
	- latency between microservices
	- KMM: Luke mentioned, in our data center, propagation delay is a few milliseconds
	- microservices require coordinated deployments
	- KMM: not sure I follow this one - maybe they were deploying endpoints that broke their contracts?
	- separate PRs causes problems
	- KMM: I didn't understand this issue. Smaller code-bases make them easier to understand, I'd say.

	(3) Liz of HoneyComb
	- Production Excellence
	- coding, testing, and maintaining code in production, with a focus on the maintenance in prod part
	- alert on Service Level Objectives (SLO)
	- Perfect SLO > Good SLO >>> No SLO
	- don't have a hero culture - share knowledge
	- address risks that threaten SLO

	(4) Communication and Documenting Architectural Decision
	(a)
	- Mike Nygard coined Architecture Design Records, ADRs.
	- Basically it's a way to keep track of decisions, i.e. explain why a choice was made. It's helpful to do so so that others, who weren't part of the project earlier in its life-cycle, can understand (and challenge) decisions
	- Example ADR: https://github.com/davidaayers/ea-talk/blob/master/adr/0001-use-markdown-for-adrs.md
	(b) guilds
	- create Special Interest Groups (SIG) to discuss issues within a company
	- language choice was one at his company, namely adding Go
	- SIG offered everyone an opportunity to voice their thoughts
	- David, as an Architect, had vetoed power over SIG decisions. However, he never issued one
	(c) Reference Implementation
	- basically he suggests what we already have in the template-service

	(5) Kotlin Multiplatform
	- talk focused on Kotlin Multiplatform, which, as I incompletely understand, targets a range of platforms, e.g. Android, Native, iOS
	- The speaker moved quickly, and I know little about Kotlin/Mobile, so I didn't take too much away

	(6) Burnout
	- emotional exhaustion (also can occur if person doesn't find value in their work)
	- depersonalization
	- reduced personal accomplishment
	- trouble at work may come from trouble at home

	(7) Being Right is Half the Work
	1. How to Read People's Minds
	- ask them questions!
	2. How to see the Future
	- socialize/discuss ideas with people before a big meeting

	Discussed the value of "even over" mission statements. Examples:

	* Sustainability even over profitability
	* Innovation even over predictability

	It also talked about not using "blur" words, i.e. words that are ambiguous. Use precise, explicit language.

	(8) Glue

	- defined it, in my words, as non-technical collaboration work that's critical for a project's success
	- example from talk: Senior Developer was stuck trying to understand an email chain over 3 weeks. A Junior Developer acted as glue in scheduling a meeting with the Senior Dev and other team to get the Sr Dev un-stuck.
	- problem with being glue, the talk mentioned, is that sometimes a company does not consider it to be promotable work
	- author noted that glue assignments should be shared by the team so one person doesn't get stuck as the "glue person"

	(9) Myths

	- didn't take too many notes

	(10) Remote Teams

	- one note, since Banno does remote so well, is having a moderator during a meeting so everyone gets to speak
	- it's easy for a few folks, given their outspokenness, to take over a meeting; that's to the detriment of not having quiet folks' opinions

	(11) Leading Engineering Teams through Rapid Change

	- no notes

	(12) Crucial Career Discussions

	- managers/leaders should show their weakness/that they're people too
	- ask direct reports about what they'd like to do - are they happy?

	(13) Mental Models

	- Multiple levels of thinking:

	(1) Event - low impact, i.e. fix a defect affecting 1 user
	(2) Trend - still low impact, but greater than an Event
	(3) System Thinking
	(4) Mental Model

	- Use 5 Why's when investigating an incident

	(14) Senior Director of Infra at Slack

	- Former CTO twice, needed a job since her company was bought
	- worked at Slack from 1M Daily Active Users to 10M
	(1) write well and quickly
	(2) stories are very powerful
	(3) have a communication plan for everything
	(4) know your audience
	(5) too many meetings
	- organizational drift can occur
	(6) Create structure and process around things
	(7) Know who the decision maker is
	- "Decision Purgatory"
	(8) Credit always flows to most visible/senior
	- always assign and share credit