Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

From ic to tech lead

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.

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to comment

  • Be the first to like this

From ic to tech lead

  1. 1. From IC to Tech Lead by Tatiana Mukhutdinova (kassalanche@gmail.com)
  2. 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. 3. 2013, Individual Contributor (IC)
  4. 4. 2017
  5. 5. … and there it started
  6. 6. Led 10 teams in the last 5 years
  7. 7. Learn from my mistakes, and… well... pain
  8. 8. Deepen your skills by looking from new angles
  9. 9. Tech lead is someone leading with tech focus. Also, team and product. Delivery,
  10. 10. Starting pain path
  11. 11. Expectation
  12. 12. Expectation Reality
  13. 13. What to do?
  14. 14. What should I be doing?
  15. 15. There were too many things
  16. 16. Or results were too general
  17. 17. So, I decided, that I will give a presentation when I figure out what to do!
  18. 18. I want this presentation to be as concrete as possible.
  19. 19. So, what I actually do * I tracked time for 2 consecutive weeks
  20. 20. “Responsibilities! I want them all” You Responsibilities You Responsibilities
  21. 21. Bad djinn: “Sure!” You Responsibilities You Responsibilities A Month Later...
  22. 22. Expectation Delegation is easy. Just say what to do
  23. 23. Expectation Reality Delegation… it’s like herding cats
  24. 24. 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.
  25. 25. System vision helps to drive tech direction and align the team ● Drives technical direction ● Aligns the team
  26. 26. “It’s the most important” “You should have it right away”
  27. 27. 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
  28. 28. Share your Big Idea or even small
  29. 29. Now, it’s time to share your ideas. Why not just say it?
  30. 30. and still... You sharing the vision Dev who designs a feature
  31. 31. Repeat, repeat, repeat
  32. 32. Repeat, repeat, repeat
  33. 33. Repeat, repeat, repeat
  34. 34. Repeat, repeat, repeat but a bit differently
  35. 35. Code review
  36. 36. Review code to share knowledge Code review is one of the most important processes. It is the process for SWEs to share knowledge.
  37. 37. Review code to improve quality
  38. 38. Review code to get insights in relationships
  39. 39. 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”
  40. 40. Prioritization of Tech Tickets
  41. 41. Is this resonating?
  42. 42. Deadlines are like time bombs
  43. 43. Prioritization Rule: Prioritize Deadlines to go first ● No last moment defusing ● No pretending “It’s fine” ● Total control
  44. 44. 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
  45. 45. Prioritization Rule: Strategic Project is the next. Pick one
  46. 46. Prioritization Rule: The “everything else” category won’t be done soon. Accept it
  47. 47. 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
  48. 48. 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
  49. 49. 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.
  50. 50. Leadership Team Struggle: my perspective is not representative anymore
  51. 51. Value first hand experience
  52. 52. 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.
  53. 53. Value first hand experience Prioritize what matters
  54. 54. 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
  55. 55. Learn all the roles in your team Lead by example
  56. 56. Let’s repeat what we’ve learned
  57. 57. 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
  58. 58. And the most important...
  59. 59. Thanks! Q&A by Tatiana Mukhutdinova (kassalanche@gmail.com)

×