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.

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,

10. Starting pain path

11. Expectation

12. Expectation Reality

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

36. Repeat, repeat, repeat

37. Repeat, repeat, repeat

38. Repeat, repeat, repeat

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

46. Is this resonating?

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

63. And the most
important...

65. Thanks!
Q&A
by Tatiana Mukhutdinova
(kassalanche@gmail.com)