Class about time effectiveness, Acceleration of one's career growth and turning efforts into impacts, based on the book "Effective Engineer" by author Edmond Lau, and prepared by Symphony's Software Engineer Benjamin Kapetanovic

1. The Effective
Engineer

2. Are we effective?
How can we perform better?

3. Time
The most limited resource
Cannot be stored, extended or replaced
Inescapable, regardless of our goals

4. Impact
Increasing impact
Getting things done
Producing more value & have better results

5. Efficiency
Get more things done
without increasing number of working hours

6. Leverage
Use leverage to measure your engineering
effectiveness
Focus on what generates the highest return on
investment for your time spent.

7. Leverage
Impact produced
Time invested
Leverage =

8. Leverage
Systematically increase the leverage of your time
Find ways to get an activity done more quickly, to
increase the impact of an activity, or to shift to
activities with higher leverage.

9. Prioritizing
80 - 20
80% impact comes from 20% of work

10. Prioritizing
Write TODOs
Brain can actively hold 7 +/- 2 items
(in working memory)
Let it do more important stuff

11. Prioritizing
Do what matters - first
What matters - produces value
Focus on important, not urgent

12. Prioritizing
Urgent Not Urgent
Important
Crises
Deadlines
Planning
Building relationships
New opportunities
Personal
development
Not
Important
Interruptions
Most meetings
Most emails & calls
Surfing Web
Time wasters
1 2
3 4

13. Learning
Grow by 1% daily
Dedicate Time on and out of the Job to
Develop New Skills
Yearly: 37x better
(not 365% → 3.65x)

14. Learning
Facebook:
MOVE FAST AND BREAK THINGS
Move fast to learn fast

15. Maker’s Schedule
Productivity increases when we can maintain periods
of what (Hungarian) psychologist
Mihály Csíkszentmihályi calls:
The Flow

16. Maker’s Schedule
The Flow
...is a state of effortless concentration so deep that
they lose their sense of time, of themselves, of their
problems.

17. Maker’s Schedule
Makers (programmers, writers,..) should use time in
units of half a day at least.
A program can’t be written in 30min units

18. Maker’s Schedule
Microsoft Research:
Employee needs at least 15 minutes to recover/ return
to focused activity after handling email or other IM
interruption

19. Maker’s Schedule
Protect your Maker’s Schedule
Preserve large blocks of focused time
Schedule meetings and other interruptions at the
beginning or end of the work day

21. Multitasking
“Your Brain at Work” (by David Rock):
Brain’s prefrontal cortex handles our planning, decision-
making, and goal setting has limited space for 7 +/- 2
items.
In order to make decision, brain must simultaneously
bring up and process all items - wastes mental energy

22. Multitasking
Avoid doing multitasking
Reduce context switching

23. Time - Saving Tools
If you have to do something manually more than
twice - write a tool to do it third time
30 minutes of investment might return in days or
weeks within a year

24. Track Progress
Choose a metric to track your progress
If you can’t measure it - you can’t improve it

25. Track Progress
Hours worked
vs
productivity per week

26. Track Progress
Google Search Metric:
Click-through
vs
Long click-through

27. Track Progress
Bugs fixed (Adobe)
vs
Bugs outstanding

28. Track Progress
Total number of registered users
vs
Weekly growth of registered users

29. Improve
Establish a sustainable Code Review Process
Manage Complexity through Abstraction and
Libraries
Automate Testing

30. Code Review
Catching bugs or bad design early
Increasing accountability for code changes
Sharing working knowledge of the codebase

31. Invest in your Team’s Growth
Focus on making everyone around you succeed
You get more credit than you deserve just for
being part of a successful company, and less
than you deserve for being part of unsuccessful
company.

32. Invest in your Team’s Growth
Hire smart
Ramp up new engineers quickly
Socially integrate new engineers

33. Invest in your Team’s Growth
Share Ownership of Code
Avoid one-person teams
Present tech talks on software decisions and
architecture