how to be an effective tech lead
DESCRIPTION
How to Effectively Work as a Tech Lead Tech leading is an art which turns the unique skills and talents of an engineering team into a well oiled machine. Many engineers eventually find themselves in a leadership position but without the experience to utilize it to the fullest extent. Developing tactics for how to route information and questions, use group-oriented communication style, developing delegation skills, product vision and working well with other teams can move a tech lead from good to great. During this discussion Derek Parham will talk about his lessons learned on tech leading Google Apps and provide tips to existing and future tech leads on how to play this role effectively. Speaker: Derek Parham Derek is an entrepreneur and technical leader with over twelve years of experience in software engineering. He is the founder of Google Apps for Businesses and served as its technical lead for nearly six years. He launched the project from scratch and helped grow the team to over one hundred engineers serving over 40 million customers today. The project utilized and developed some of the world’s largest scalable systems, along with shaping what is now referred to as "the cloud".TRANSCRIPT
How to be an effective Tech Lead
Derek Parham
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.
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
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
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
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
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
Meetings
● Remember the good old days...
● Not your imagination, meetings kill eng productivity
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
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
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.
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
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
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!
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
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
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
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
...but wait, there's more!
First though, any questions?
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.
Thanks for coming!
Any more questions?