Thanks again for Dan for writing up notes.

1. Naming is hard (how to)
   • “2 hard problems in CSc: naming & cache invalidation”
   • very important
   • names that are wrong are like an itch you can’t scratch
   • naming conventions
   • language conventions
   • help you things if names are good
   • happy collisions
   • project glossaries
2. organizing iterations when team has multiple responsibilities
   • operations
   • support
   • dev
   • multiple projects
   • individual may not have anough info to prioritize
   • protocols to deal with unexpected incidents (prod)
   • different colors on the task board
   • fudge factor in estimating
   • being able to deal with this is a sign of maturity
3. Ageism
   • larger companies tend to have a bigger spread
   • some people devalue older coders who don’t know the lates/greatest
   • maybe pair younger coders with older experienced ones
   • “don’t type as much, but get stuff done”
   • some older people can be set in their ways
   • broader toolkit
   • younger consultants, don’t say no for themselves
   • “how important is that work?”
   • sometimes it’s good to step back
   • is capacity for work changing with age?
4. Where innovation happens?
   • tech, edu
   • startups, small companies, garages
   • education is socially very conservative
   • lots of regulation around schools
   • charter schools – not very different from a conventional school
   • tweaking the classic formula
   • technology in schools isn’t disruptive by itself
   • khan academy
   • still doing the same basic formula: tests, homework, course materials
   • locus of control is far away from the classroom, has different goals
5. Retrospectives
   • what makes a retrospective good?
   • post-mortem is different, after a large project ends
   • “teachrospective”
   • recognition, prime decision making
   • why do things go wrong?
   • ask the right questions
   • retrospective is a steering activity
   • followup on past issues
   • not just a bitch session
6. Dealing with a dominant team member
   • might be very good
   • might just be pushy
   • needs to be a team solution
   • peer pressure
   • they may think that they are doing what is best for the team
   • need to have that “a ha” moment when they realize that they are hurting the team
   • PM with good facilitation skills can help
   • behavior profiles, analagous to Meyers-Briggs
   • strengths-finder
7. Dealing with a weak team member
   • not getting work done, passive
   • what motivates them?
   • they do have strengths, find them!
   • how does the team approach it?
   • give them a mentor
   • career level may not be the same as their skill level
   • autonomy, mastery, purpose
   • let them pick first
8. Group size
   • past 12 or so you can’t make a decision
   • 5-6 can get a lot done, larger needs more coordination
   • how fungible are the tasks
   • “moving a house” works well with big groups
   • making a decision
   • spread ownership
   • optimum team sizes from the group?
   • 5 ish for software
   • larger teams work well if they know each other well and collaborate well
9. Burnout
   • it can grow
   • can’t sustain work at a high level
   • getting tired a few times a year can be good. More than that can wear you out.
   • Not enough “no”
   • beating your head against the wall
   • get fresh ideas, read more
   • “the progress principle” book
   • “frustration is the opposite of progress”

Special Thanks to Dan for creating these notes.

Meetings/punctuality/etiquette
– Meetings need to have a purpose/agenda
– some cultures punish tardiness, could be shaming, could be financial
– Some cultures treat being overbooked as a sign of status

Use of automation/macros
– machine setup
– machine activities (shutdown at a certain time, etc)
– tech support (standard text responses)
– how much do you customize your environment?

What is Agile?
Definition proposed was about helping teams work faster, we disagreed with that but couldn’t stabilize on what it is

Human Systems Dynamics
– Method of managing interaction between people
– know what you know, what you can potentially know, what you can’t know
– US Navy submarine control room anecdote: Discussions happen in public, everybody participates, Captain makes a decision
– All information is visible to everybody in the discussion
– No holding back
– Helps bring new people up to speed
– Helps spread institutional knowledge

Dogfooding
– Is it useful? Can be if the people dogfooding the product are the ones who build it
– Can show confidence in your product

Finding Tech talent in PDX
– Not enough talent
– Paying relocation costs to bring in talent can be a sticking point
– People outside of the PDX area don’t necessarily know what the job market is like in PDX
– People churning around locally costs everybody time and money