The document outlines a guide for engineers aspiring to reach a staff-plus role by identifying and solving impactful problems within their organizations. It emphasizes the importance of building a business case, developing necessary technical and soft skills, and embracing challenges outside one’s comfort zone. In addition, it provides strategies for effective communication and collaboration to influence peers and leadership.

1. The secret to finding
impactful projects to
land a Staff-Plus
Engineer role
Akhilesh Gupta
Principal Software Engineer
1

2. How do I grow to
the next level?
Increase your scope
and impact
2

3. How do I have
more impact?
Work on more
impactful projects
3

4. 4

5. But impactful
projects
on my team are
already taken
5

6. My team has
limited scope.
Not large enough
for Staff-plus roles
6

7. And my manager
is unable to find
me the right
opportunities
7

8. You can be a
Staff-plus engineer
despite all these
reasons
8

9. How?
9

10. 10
Scenario 1

11. iOS -> Swift
Web -> React
GraphQL
11

12. The “Backend”
Built 5 years ago
12

13. C++??
30K lines
of code
Deployed once
in 2 months
I’m scared
to touch it
The “Backend”
13

14. Who has been in a situation like this?
14

15. The “Backend”
- Production issues
- 24x7 Oncall
- Customer impact
- Business impact
15

16. Join in on the complaints
Fix the problem
16

17. Join in on the complaints
Fix the problem
17

18. Solve hard problems
Listen to complaints Staff-plus role
18

19. 1. Recognizing impactful problems
- Tedious & challenging
- Many complaints
- Impact beyond team/org boundaries
- Negative impact on customers/business
19

20. Why?
Let’s refactor
the backend
20

21. 21

22. 2. Business case for solving the
problem
- Motivation (Why?)
- Problem Statement (What?)
- Technical solution (How?)
- LoE (Level of effort)
- RoI (Return on Investment)
22

23. 3a. What soft skills do I need?
- Connect to business impact
- Written communication
- Executive presentations
- Convince non-eng leaders
23

24. 3b. What technical skills do I
need?
- Understand the codebase
- Redefine models & interfaces
- Modularization
- Microservices
- Migrate clients to new API
24

25. 4. Should I pursue a solution?
- Does it energize me?
- Am I ready to see it through
roadblocks?
25

26. 5. Am I willing to learn?
- Embrace technical & non-
technical skills
- Outside my comfort zone
26

27. Client identification
tool
Data migration
tool
Refactoring tool
27

28. 6. Recognize patterns & build generic
solutions
- Build for leverage
- Solve for the organization
- Evangelize your solution
28

29. Six steps to a Staff-plus role
1. Seek & recognize impactful problems
2. Build a business case
3. Determine tech & soft skills needed
4. Ask yourself: Am I excited to pursue the
solution?
5. Embrace skills outside comfort zone
6. Recognize patterns & build generic
solutions
29

30. 30
Scenario 2

31. Technical Design Design review
meeting
31
Scenario 2

32. Welcome! Next open
slot is during the next
ice age!
32

33. C#
33

34. C#
Where is
Documentation?
I AM DOCUMENTATION!
34

35. C#
Agenda
- 50 min ppt
- 10 min Q&A
by tech lead
35

36. No feedback
I didn’t get
it, lol
I hate this
meeting
36

37. Recognize impactful problems
- Hard to change team review process
- No one is satisfied
- Impacts all of engineering
- Slows development -> slows business
37

38. Determine skills needed
- Inspire others through
vulnerability & authenticity
38

39. C#
Could you help clarify
the problem being solved?
39

40. C#
I have many
questions
40

41. Determine skills needed
- Inspire others
- vulnerability & authenticity
- Influence peers
- simple solutions to complex
problems
41

42. C#
Let’s discuss the design
using a short doc!
42

43. Determine skills needed
- Inspire others
- vulnerability & authenticity
- Influence peers
- simple solutions to complex
problems
- Propose a new model
- async reviews of design docs
43

44. Commonly needed skills
- Write a proposal
- Get it reviewed
- Gain consensus
- Influence leaders
44

45. Recognize patterns & build generic
solutions
- Vet new process in own team
- Pilot new process in other teams
45

46. I’m an engineer…do I really need
to do all this non-technical stuff?
So weird & uncomfortable!
46

47. 47
© 2020 dinosandcomics

48. 48
Scenario 3

49. 49

50. 50

51. 51

52. 52

53. 53

54. Slow replication
54

55. Slow replication
55

56. Slow replication
Live video events
Audio rooms
56

57. Recognize impactful problems
- Hard technical problem
- Many teams complaining, no obvious strategy
- Wasteful to solve for each product
independently
- Direct impact to interactive products
57

58. Determine technical skills needed
- Cross-DC request routing
- Cross-DC data replication
- Atomic commit protocols
- Latency-cost tradeoffs
- Evaluate in-house vs open-source
58

59. Determine soft skills needed
- Gathering requirements
- Estimating business impact across
product lines
- LoE and RoI tradeoffs
- Alignment with storage infra leads
- Written technical communication
59

60. Recognize patterns & build generic
solutions
- Common remote-DC write APIs
- Common libs to route traffic to
entities pinned to a DC
60

61. 61
Scenario 4

62. 62

63. 63
Persist Message
Operation

64. 64
Challenge: “Persist” operation can fail.
Cannot expect client to retry for server failures.
Persist Message
Operation

65. 65

66. 66

67. 67
Durable Retry Queue
A generic solution for reliable processing

68. 68
Determine technical skills needed
- Evaluate in-house vs open-source
- Async operation queue
- Job processor
- Exponential backoff with retries
- Durability across deployments and
failures

69. 69
Recognize patterns & build generic
solutions
- Reliable notifications delivery
- Reliable payment processing
- Bulk operations like GDPR data
export

70. 70
What can I do
as a leader?

71. 71
1. Encourage constructive criticism

72. 72
1. Encourage constructive criticism
2. Create forums for engineers to
express non-technical challenges

73. 73
1. Encourage constructive criticism
2. Create forums for engineers to
express non-technical challenges
3. Coach your engineers to sell their
ideas and proposals.

74. 74
We should move
to GraphQL!!

75. 75
We should move
to GraphQL!! Why?

76. 76
Why is it better than
REST APIs “for us”?
It’s so much better
than REST APIs

77. 77
What is the advantage “for us”
Migration strategy?
Level of effort?
Return on investment?

78. 78
Let’s write a proposal
and drive consensus
Hmmm, let me get
back to you

79. 79
1. Encourage constructive criticism
2. Create forums for engineers to
express non-technical challenges
3. Coach your engineers to sell their
ideas and proposals.
4. Training programs

80. 80
Design doc workshop
5 things you didn’t know about documentation
Persuasive speaking
How do we make money as a business?
Presenting to executives

81. 2 BIG TAKEAWAYS
81

82. Listen to complaints
Recognize impactful problems
Solve at scale
82

83. Lose your fear
Embrace skills that make
you uncomfortable
83

84. Important Staff-plus skills
- Write great proposals: why? what? how?
- Influence peers & gain consensus
- Understand the business & RoI
- Present to executives & cross-functional
leaders
84

85. #*$@!!
85
Our food is
inedible!
Documentation
doesn’t exist!
Builds are so
slow!
My PM doesn’t
understand tech
limitations
Our debugging
tools are useless
Code reviews
take days!
Dep management
is hard!

86. #*$@!!
86
Our food is
inedible!
Documentation
doesn’t exist!
Builds are so
slow!
My PM doesn’t
understand tech
limitations
Our debugging
tools are useless
Code reviews
take days!
Dep management
is hard!

87. Akhilesh Gupta
Principal Software Engineer
@agupta03
Panel discussion at 4.10pm (Seacliff ABC)
87