adeleinr/Principles for building a great engineering culture

## Principles for building a great engineering culture
Principles for building a great engineering team culture by Adelein Ro
=======================================================================
0) The first line of code you should write for any feature is "What are we building, why are we building it, and why now?",
Eg start with a Tech design or a Spike
1) Dig deep and wide into the functional and non functional requirements of what you are building, disambiguate with product
   or stakeholders, spell out what they have not been able to. Spill out details as part of tech design, get agreement
   from product and stakeholders.
2) Engineers need to be able to find indirect or direct mentors, people they can learn best tech and
   people practices from on a day to day basis.
3) Need challenging work that is transferable outside the company.
4) Remove IT barriers, reduce tech debt and add peer collaboration for engineers to feel productive daily.
5) People need to feel their work is seen via demos or blog posts, encourage short demos of progress, rather than demos of
   fully baked features.
6) Encourage collaboration and reaching individual potential as opposed to competition among colleagues.
   Comparisons are not helpful unless used for inspiration and brought up by the engineer.
7) Form teams with skills that complement each other but encourange cross mentoring and
   idea bouncing between different teams. Encourage engineers to develop their own network of people within the company they
   can ask for second opinions on code and designs.
8) Team activities that are not focusing on competition, ego or intellect, instead foster bonding and collaboration
   where people get to know other dimensions of each other, Eg outdoor activities, cooking, collaboratibe board games, art.
9) Code base quality, readability and predictability is essential to bringing comfort, reducing anxiety when coding.
   Spend good time on code reviews until the code is nothing but great.
10) Nurture a sense of trust, vulnerability is allowed, blend of personal and work life is a reality, not a taboo.
11)To encourage a good retrospective use a cynical approach where you bring up some cynical blunt statements like "There were
   no infrastructure challenges this week", or "There was very a streamline communication for project X this sprint"
12) Interleave challenging but interesting work with easier tasks, equally interleave new features and tackling technical debt.
13) Leave code better than you found it.
14) If code needs heavy documentation then it is probably not readable.
15) Code debt is like a kitchen sink, if you leave one dirty plate in the sink it encourages others to do the same.
16) Wording is important: RCAs instead of post-mortems, flow instead of grind (what other war inspired word needs renaming?)

Team Rules by Jenny Wood
========================
1) One pizza rule: all working groups should be able to feed by one pizza. 3 people vs 7.
2) The humble two: The most powerful statements as a leader you can make as a leader "I dont know" and "I was wrong".
3) Reply always: reply to your direct reports.
4) Hop happy: Be available to hop on calls with direct reports.
5) Support suffic: end meetings with "how can I support you this week?".
	Principles for building a great engineering team culture by Adelein Ro
	=======================================================================
	0) The first line of code you should write for any feature is "What are we building, why are we building it, and why now?",
	Eg start with a Tech design or a Spike
	1) Dig deep and wide into the functional and non functional requirements of what you are building, disambiguate with product
	or stakeholders, spell out what they have not been able to. Spill out details as part of tech design, get agreement
	from product and stakeholders.
	2) Engineers need to be able to find indirect or direct mentors, people they can learn best tech and
	people practices from on a day to day basis.
	3) Need challenging work that is transferable outside the company.
	4) Remove IT barriers, reduce tech debt and add peer collaboration for engineers to feel productive daily.
	5) People need to feel their work is seen via demos or blog posts, encourage short demos of progress, rather than demos of
	fully baked features.
	6) Encourage collaboration and reaching individual potential as opposed to competition among colleagues.
	Comparisons are not helpful unless used for inspiration and brought up by the engineer.
	7) Form teams with skills that complement each other but encourange cross mentoring and
	idea bouncing between different teams. Encourage engineers to develop their own network of people within the company they
	can ask for second opinions on code and designs.
	8) Team activities that are not focusing on competition, ego or intellect, instead foster bonding and collaboration
	where people get to know other dimensions of each other, Eg outdoor activities, cooking, collaboratibe board games, art.
	9) Code base quality, readability and predictability is essential to bringing comfort, reducing anxiety when coding.
	Spend good time on code reviews until the code is nothing but great.
	10) Nurture a sense of trust, vulnerability is allowed, blend of personal and work life is a reality, not a taboo.
	11)To encourage a good retrospective use a cynical approach where you bring up some cynical blunt statements like "There were
	no infrastructure challenges this week", or "There was very a streamline communication for project X this sprint"
	12) Interleave challenging but interesting work with easier tasks, equally interleave new features and tackling technical debt.
	13) Leave code better than you found it.
	14) If code needs heavy documentation then it is probably not readable.
	15) Code debt is like a kitchen sink, if you leave one dirty plate in the sink it encourages others to do the same.
	16) Wording is important: RCAs instead of post-mortems, flow instead of grind (what other war inspired word needs renaming?)

	Team Rules by Jenny Wood
	========================
	1) One pizza rule: all working groups should be able to feed by one pizza. 3 people vs 7.
	2) The humble two: The most powerful statements as a leader you can make as a leader "I dont know" and "I was wrong".
	3) Reply always: reply to your direct reports.
	4) Hop happy: Be available to hop on calls with direct reports.
	5) Support suffic: end meetings with "how can I support you this week?".