Notes: Effective One on Ones

http://www.meetup.com/ctoschool/events/222013916/
John @Yodle

@Yodle attempt to keep the flattest structure possible
1/1s key to this

"what expectations do you need to share that you haven't yet expressed or 
 haven't clearly expressed? what opporunities do you have to clarify your 
 expecations?"
every one on one is a opporunity to address this

one on ones have to happen and not get pushed on calendar
30min/week is min
can't miss 2x row

go for a change of scenery, go for coffee, etc, shake it up
bring notebook/plan
turn off phone/notifications/chat

1/1s:
bad:
* minimize status updates in 1/1

good:
* coach/mentor on things happened recently
** i'm not actually growing, where is this going, what is the vision
** get above JIRA
* ask open-ended questions
** how are you going to approach this
** tell me about your week
** where do you think i can be the most helpful
** what worries you
* engagement questions
** are you feeling challenged
** are you feeling motivated
** are you feeling supported
** are you feeling connected
** are you happy

* listen
** when speaking more than reports it is a code smell

* ask for feedback
** do you have any feedback for me
** what can I do better
** what do you see as my strengths
** what are areas I could improve
** if you were me, what would you do differently

* end with a purpose
** here is your homework
*** not: merge that pull request

Questions
Q: How do 1/1s relate to perf?
A: Should be no surprises at review time. if so, 1/1s were going incorrectly.
Guilds are for growth, a bit different from Spotify. 
there is a manager guild. discuss manager change.

Q: How do you ensure 1/1 quality?
A: In a way it enforces itself, but not in a helpful way. 
folks who don't get this will find another place where they will have it.
skip level 1/1s do check in on how these are going with intermediate manager

Q: How do you get feedback responses from reports? they usually pass.
A: I make lots of mistakes. Let everyone feel human.
Relationship build does take time.
Maybe ask for feedback on something very specific

Notes: Servant Leadership at Scale

http://www.meetup.com/ctoschool/events/222013916/
Jude Allred, CTO at FogCreek.

How big is engineering at fog creek now? looks like ~30 from the photo

## "Rapport doesn't scale"
* giving context at every decision point and helping with interpretation / 
 outcomes is not possible
* therefore scaled servant leadership is indirect (ie culture)

## What is Servant Leadership?
* comes from Joel
* the most capable people are making decisions
* management, if any, is minimal - what does exist is for obstacle removal
* every manager has a different flavor of Servant Leadership
* speakers version
** most informed decision makes
** leaders remove obstacles, provide context
** individuals given high autonomy, organization depends on them to use it and 
 take initiative

### structures which assume success (lead with habits)
* model of success: lots of trying small experiments and occasionally get a 
 rocket.
* incubate a product (pitch, execute for a week)
* lots of failures but did build habit of taking initiative

#### Teams by initiative (fight goal creep)
* large team on maint with a dozen goals
results:
** lots of incoming reqs
** unable to focus on "MRR increase"
* solution: two teams sharing codebase/clients/etc
** defensive team (uptime, support, sales team guaranteed bets)
** change revenue (speculative features)
** Outcome: two small teams out performed a large team.

### diminishing returns to consensus
* expectation that all qs will come to full consensus answers
** not true
* small teams do lend well to this
* sometimes go with 80% consensus - cost of getting that last 20% is more 
 expensive than being wrong
** "people should not say i told you so"

### decision-making as a service
* a problem: sticking points that don't matter to org or clients
** if someone is hedging on making decision because they are nervous / afraid 
 of being wrong
* speaker offers a way to help "hey, what do you think you should do? that? 
 yeah that sounds like what you should do."

### creative space for empathy workers (ie support folks)
* emotional labor is hard work
* typically viewed as a cost center
* see Rich Armstrong talk
* give these folks autonomy and creative space - they are thinking about your 
 customers all day
** their impl: 1 day a week outside out queue allowed to do devwork
*** reduce burnout, allow invest in self, put forward feature prototypes/etc

### default remote (dogfood your culture)
* like Zach Homan article - https://zachholman.com/posts/remote-first/
* when channels of communication are different it is a trap
* assume remote for interactions

## overall theme
* communication and structures
* facilitate people to take initative, being ambitious, following practices 
 you want

### servant leadership is more of a constraint
* say you want to turn everything to AWS, mandate this?
* communicate with context? hard to scale.
* if want this action, create structures that may indicate that action. if that 
 doesn't happen, maybe the hypthesis was wrong to begin with?

## wrap up
* what is it to be a CTO w/o giving orders
* how do you enable them to do that

spectrum: command and control --to-- servant leadership

to move to servant leadership
* give context over conclusions
* build structures and culture to support initiative
* let your expert players emerge

# Questions
How to deal with low performance?
* small enough to not be a big issue
* initiative fizzle is indicator
* pay attention when there is rumbling

When to not use servant leadership?
* sales team is not
* servant leadership most valuable in creative things
* it is a spectrum

Firing people?
* performance improvement plan (1 mo)
* if you want to leave, get extra 1 mo severance

Remote team is very far apart in timezone?
* team leads bless people with big timezone differences
* site reliability team has largest gaps which is good for that team

Communicate Close To The Work

When you are communicating about work, do it as close as possible to the work. I’ve learned this a few times now so I’m writing it down.

• Can it be a code review comment? Do that
• Can it be a JIRA ticket and/or mention? Do that
• Can it be in a Google Doc and/or mention? Do that
• Is it open ended/discovery? Chat in a public relevant public chat channel

Danger-land for communication:

• Private chats (can be lost forever, not discover-able)
• Email (not discover-able to people not on orig chain)
• Call a meeting (well, if necessary, but can we not?)

Benefits:

• Lower cognitive inertia to communication. If you say to me in real life “well I think that design is ZZZ” – I have to figure out what design you’re talking about. If this is a comment on the relevant code review or ticket, there is no such question.
• Reduced duplication. If you say to me in real life “did you consider design ZZZ?” and we hash it out, then reviewer #2 then says “did you consider design ZZZ?” then I have to repeat myself.
• Increases learning. Having the discussion about “did you consider design ZZZ?” allows less experienced reviewers to witness this discussion and hopefully learn from it, or add to the discussion.
• Leaves an archaeological history. If I dig back into annotations and can associate a commit with a code review and jira ticket, I’ll be able to piece together what a primitive person I was a year ago when I created this code.

Always wanted to travel back in time to try fighting a younger version of yourself? Software development is the career for you!

— Elliot Loh (@Loh) December 12, 2013

• Puts work in best shape to be handed off if necessary. Hand-offs are not the best, but occasionally they need to happen. Communicating near the work allows someone else to take over with the least amount of overhead.
• Allows knowledgeable people to opt in.  By doing discovery in public chat this allows other folks, who may know things you don’t know, to jump in if they would like to contribute.  This is superior to private chats/in real life talks.

Meta benefit: this is a generally easy heuristic to apply once you get the hang of it.

Cons/caveats:

• Requires “putting oneself out there” to be wrong in front of lots of people.  Solutions: Read Mindset.  Have a HRT (“Humility, Respect, Trust”) culture.
• Sometimes IRL is far more productive.  Just do it and write down what happened.

This is a first draft – I would love input – comments, not email ;)