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?

15.
There were too
many things

16.
Or results were
too general

17.
So, I decided, that I will give a presentation
when I figure out what to do!

18.
I want this presentation to be as concrete
as possible.

19.
So, what I actually do
* I tracked time for 2 consecutive weeks

20.
“Responsibilities! I want them all”
You
Responsibilities
You
Responsibilities

21.
Bad djinn: “Sure!”
You
Responsibilities
You
Responsibilities
A Month Later...

22.
Expectation
Delegation is easy. Just say what to do

23.
Expectation Reality
Delegation… it’s like herding cats

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.
System vision helps to drive tech direction and align the team
● Drives technical direction
● Aligns the team

26.
“It’s the most important”
“You should have it right away”

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.
Share your Big Idea
or even small

29.
Now, it’s time to share your ideas.
Why not just say it?

30.
and still...
You sharing the vision
Dev who
designs a
feature

31.
Repeat, repeat, repeat

32.
Repeat, repeat, repeat

33.
Repeat, repeat, repeat

34.
Repeat, repeat, repeat but a bit differently

35.
Code review

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.
Review code to improve quality

38.
Review code to get insights in relationships

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.
Prioritization of Tech Tickets

41.
Is this resonating?

42.
Deadlines are like time bombs

43.
Prioritization Rule:
Prioritize Deadlines to go first
● No last moment
defusing
● No pretending “It’s fine” ● Total control

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.
Prioritization Rule:
Strategic Project is the next. Pick one

46.
Prioritization Rule:
The “everything else” category won’t be done soon. Accept it

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.
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.
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.
Leadership Team
Struggle: my perspective is not representative anymore

51.
Value first hand experience

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.
Value first hand experience
Prioritize what
matters

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.
Learn all the roles in your team
Lead by
example

56.
Let’s repeat what
we’ve learned

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.
And the most
important...

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