From ic to tech lead
•
1 like•113 views
In this talk, Tatiana will take you on a journey from IC to Tech Lead. She had a lot of struggles and unknowns along the way for years, but she decided to share those experiences as well as the efficient way to go about the role. She will give actionable ideas and provide a reference point on how Tech Leading could look like in practice.
Report
Share
From ic to tech lead
- 1. From IC to Tech Lead by Tatiana Mukhutdinova (kassalanche@gmail.com)
- 2. About me ● Yandex, Moscow, 2013 - 2015 ● Teaching Assistant, HSE, 2014 - 2015 ○ Programming ○ Algorithms and Data Structures ● Indeed, Tokyo, 2015 - now ○ Worked on Company pages ○ Indeed University, 3 months. Mentored 2 teams of new grad joiners ○ Worked on Experimentation Platform ● University mentorship program ○ Mentor of 2 student teams, at 2020, spring
- 3. 2013, Individual Contributor (IC)
- 4. 2017
- 5. … and there it started
- 6. Led 10 teams in the last 5 years
- 7. Learn from my mistakes, and… well... pain
- 8. Deepen your skills by looking from new angles
- 9. Tech lead is someone leading with tech focus. Also, team and product. Delivery,
- 11. Expectation
- 13. What to do?
- 14. What should I be doing?
- 16. There were too many things
- 17. Or results were too general
- 18. So, I decided, that I will give a presentation when I figure out what to do!
- 19. I want this presentation to be as concrete as possible.
- 22. So, what I actually do * I tracked time for 2 consecutive weeks
- 23. “Responsibilities! I want them all” You Responsibilities You Responsibilities
- 24. Bad djinn: “Sure!” You Responsibilities You Responsibilities A Month Later...
- 26. Expectation Delegation is easy. Just say what to do
- 27. Expectation Reality Delegation… it’s like herding cats
- 28. Create a system vision ● System vision answers “how should it work if we have infinite resources?” ● Define what problems are solved by the system, and not solved. ● Clearly define interfaces between the system and other systems.
- 29. System vision helps to drive tech direction and align the team ● Drives technical direction ● Aligns the team
- 30. “It’s the most important” “You should have it right away”
- 31. System vision requires constant iterations Reference point: it took a year to get a crystal clear picture of how things should [not] work. ● It’s different if your are working on a new product or new team
- 32. Share your Big Idea or even small
- 33. Now, it’s time to share your ideas. Why not just say it?
- 34. and still... You sharing the vision Dev who designs a feature
- 39. Repeat, repeat, repeat but a bit differently
- 40. Code review
- 41. Review code to share knowledge Code review is one of the most important processes. It is the process for SWEs to share knowledge.
- 42. Review code to improve quality
- 43. Review code to get insights in relationships
- 44. Code review ● Review the code. I’m leaving 350-400 comments per quarter ● Have a checklist of what you review. ● Tips for being a better reviewer: “How to Do Code Reviews Like a Human”
- 45. Prioritization of Tech Tickets
- 47. Deadlines are like time bombs
- 48. Prioritization Rule: Prioritize Deadlines to go first ● No last moment defusing ● No pretending “It’s fine” ● Total control
- 49. Tech priorities: Where do you go next? Unit tests Push on green Improve alerts 0 bugs policy Split a repo Migrate to a better storage Build an API
- 50. Prioritization Rule: Strategic Project is the next. Pick one
- 51. Prioritization Rule: The “everything else” category won’t be done soon. Accept it
- 52. Defer what doesn’t matter to find treasures In 2 quarters closed/deferred 253 tickets (almost half of all tickets). ● received many thanks ● and no complaints
- 53. Defer what doesn’t matter to find treasures In 2 quarters I closed/deferred 253 tickets (almost half of all tickets). ● received many thanks ● and no complaints
- 54. Own tech backlog ● It’s important to have somebody advocating for technical backlog ● Biweekly prioritize tech tickets. ● Regularly review and defer. ● I was a tech backlog owner for 2 years, before delegating it.
- 55. Leadership Team Struggle: my perspective is not representative anymore
- 56. Value first hand experience
- 57. Value first hand experience Try to do yourself the same tasks that your team does: ● coding ● code review ● first responding ● design doc writing & reviewing ● deploying ● writing integration tests ● updating configs ● contributing in various codebases etc.
- 58. Value first hand experience Prioritize what matters
- 59. Learn all the roles in your team So, you can ● onboard a new person ● be a sounding board for anyone ● replace any teammate when they are on vacation
- 60. Learn all the roles in your team Lead by example
- 61. Let’s repeat what we’ve learned
- 62. Repeat, repeat, repeat ● Learn all the roles in your team ● Value first hand experience ● Priorities: ○ Deadline ○ Strategic project ○ Everything else ● Create system vision and iterate ● Repeat your Big Idea ● Code (or design) review are good places to share Big Ideas