Derek Parham gives a talk on how to be an effective tech lead based on his experience leading large engineering teams at Google. He outlines key responsibilities of a tech lead including communicating with different stakeholders, building up the team, and looking for unaddressed problems. Parham emphasizes limiting meetings to protect engineering time, using design reviews to spread knowledge, and delegating tasks to empty one's plate and develop other leaders. He encourages tech leads to teach their engineers, build more tech leads as the team grows, and make team success a higher priority than personal success.

1. How to be an effective Tech
Lead
Derek Parham

2. About Me
● Grew up in Boston
● Went to CMU
● Started at Google in 2005
● Started Google Apps for Businesses
● Grew to over 100 engineers on the Enterprise Apps team
and over 30 million active users.

3. About this talk
● Culminated from many TLs over many years
○ This talk even given in multiple countries
● Not talking about:
○ Coding, Design, Product
● We are talking about:
○ Being an effective TL
○ Process
○ Team building
● Being a TL is a role, not a rank

4. Responsibilities of a TL
● You are the router
● Communicate up, down, and all around
● Build up your team
● Look for what's not being worked on

5. You are the router
● Sorry, you are not necessarily the coder anymore
○ But don't stop coding all together, stay knowledgeable
and teach!
○ You should be doing lots of code reviews
● Answer lots questions
○ Important: Always be available to answer questions
● When possible, have other people answer the questions
● For common questions, document the answers

6. Communicate up, down, and all around
● Communicate up to superiors
○ Do the presentations and get to be known
○ Pro-tip: Avoid live demos, or have ready backup
● Communicate down to your team
○ Explain the thought and discussion behind decisions
● Communicate all around to other teams
● Building connections will allow your team to go faster
○ Have lots of lunches with your team but also other leads

7. Group-aware Language
● Individualize success
● Group-ize failure
● We, us, our
"Billy's bug messed up the launch"
vs
"We hit a bug that messed up our launch"
● Refer to ideas by a label, not a name

8. Meetings
● Remember the good old days...
● Not your imagination, meetings kill eng productivity

9. Limit meetings for your team
● Consider the cost of each meeting
○ # eng * length of meeting * 2
● Turn down meetings and defend your team
● Batch meetings next to each other, on one day
● Use email to communicate about meetings
○ Before: send around agenda
○ After: send around notes
● Target communications to the right groups
● No laptops

10. Design Reviews
Goals:
● Spread knowledge about projects to team members
● Let junior eng get mental time of senior eng
● Document decisions for the future
● Give everyone the chance to give feedback
● Spread best practices of a team

11. Design Reviews
Google Apps design review process:
Prep:
● Design doc finished and sent out 3-7 days ahead of time
● "Questions document" is also sent out which people add to
● Do not answer questions in the Questions document
Actual Review:
● Have a rotating Sr Eng mediator
● All people who talk should have read the design doc
● No laptops except to display or take notes.
● Display the "Questions document" and add the
answer/decision to the document live.

12. During a review
● Voice of the TL
● Pauses
● Ask more questions than give answers
● All ideas are welcome, but focus
● Again: Refer to ideas by a label, not a name

13. Building up your team
● Build up more TLs as your team grows
● Teach your engineers
● Team success is more important than personal success
● Work smarter, not harder: replicate yourself

14. Build up more TLs
● Well defined responsibilities
● Teams of 3-5 are most effective for one TL
● Encourage and force leadership experience
● Let them make mistakes
● Delegation!

15. Delegation
● Make them the full owner, no halfsies
● Stop answering questions for new TLs, route them!
○ But be extra available to answer their questions
● Delegate but verify
● Don't be afraid to make changes
● For yourself: Always have a #2

16. Teach your engineers
● TLs have the most context, share it
● Teach them how you think and act
○ Pair programming
○ "Is anyone using this anymore..."
○ "Here is how I would do this..."
● Show how to fix bugs instead of doing it yourself

17. For eng to become TL
● Ask questions, lots of questions
○ Makes TL feel smarter
○ You're not the only one with question
○ Spread knowledge
● Work with different teams and disciplines
● Take on responsibilities, become the go-to person
○ Doesn't have to be eng related
● Deliver

18. Look for what's not being worked on
"Everyone else on your team has a list of things to do, but who
is the one looking around for what's not being worked on?"
● Delegate everything.
● Yes, everything...even that.
● Empty plate is a good thing
● Look for problems big and small

19. ...but wait, there's more!
First though, any questions?

20. Today's exercise
● Break into groups of 2-3
● Take turns each being the tech lead.
● Ask the tech lead what is on his/her plate this week
● Then for each thing, ask how they will get it off their plate
○ Who will they delegate to?
○ What needs to be done to hand off knowledge
○ What kind of follow up would be necessary
○ What will you do with this new empty plate
● Nobody to delegate to? No problem, imagine you just got
one.

21. Thanks for coming!
Any more questions?