Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Engineering Excellence

August 27, 2022

Engineering Excellence

A good engineering team writes code that lives through time, people & scale. At most companies engineering excellence takes a back seat because of various reasons. This talk will show how to maintain engineering standards at all phases of the project to build great teams and deliver great software.


August 27, 2022

More Decks by Naren

Other Decks in Technology


  1. 🐺 Full time adventurer with Tensoon 👨💻 Software Consultant 🛠

    Engineering Lead @ Arcana.Network ☕ Chief Co ff ee O ff i cer @ La Vita Cafe 🐦 @DudeWhoCode About
  2. • E ffi ciently delivering to customers and taking pride

    and satisfaction from the work • Non functional requirements that keep the system running • Improves the daily work and productivity of the engineers • It’s a journey, not the end goal Engineering Excellence
  3. • Ship prototypes and prove your product to gain early

    adopters • No early users? • Get back to the whiteboard • Pivot • Repeat until you fi nd your PMF or shut down • Until you get your early adopters, engineering excellence doesn’t matter Pre-PMF
  4. • Go from early adopters to early majority - more

    users in short time • Add new features from early adopters’ feedback • Fix screw ups from prototypes - product and engineering • Refactor the prototype or rewrite the prototype in rare cases • All these while catering the existing users and expanding the team PMF
  5. • Gain late stage adaptors • Expand the business by

    building di ff erent product verticals • By this time if there is no engineering excellence, then either product will be miserable or team will be miserable Post-PMF
  6. • Engineering excellence will take back seat sometimes • A

    long living cash cow product - a.k.a Legacy Code • Fight for survival - Product or business is at risk because of runway, funding or competitors Exceptions
  7. • CHANGE - product, code and team • Nothing’s gonna

    change is a risky bet • Unstoppable change inducers: • Passage of time • Entropy Common factor
  8. • “Move fast and break things” happens if you are

    able to undo the broken things • Change is the only option for any product • Faster the change is undoable, more con fi dent the team is to make mistakes Why engineering excellence?
  9. • Real world is messy and chaotic • 80% of

    the engineering problems you (will) face would be solved by fi xing 20% of the problems Minimum Viable Process
  10. • You take decisions and tradeo ff s on daily

    basis • Should we have cake cutting for everyone’s birthday? • 10 people • 30 people • 300 people CD - Continuous Decisions
  11. • Measurable • Quanti fi able inputs • Ex. CPU

    cycles • Measurable outputs • Direct costs • Immeasurable • Unquanti fi able inputs • Ex. Lack of tests, docs or API contracts • Immeasurable outcomes and impacts • Indirect costs Decision I/O
  12. • Ways to handle change • Find the change ASAP

    • Undo previous change • Find change by reducing the feedback loop Detect and Undo
  13. • Policy is easy, changing minds are di ff i

    cult • Policy = Extrinsic. Mindset = Intrinsic • Examples • Documentation - needs writing habit • Remote team - needs e ff ective communication • Change brings resistance and people develop immunity to change • Retrospect how team embraces the change Mindset over policies
  14. • Form writing habit. One pagers and meeting notes are

    good start • Deliberately refer the written docs • Helps mitigating all or nothing expertise • Internal talks helps to avoid information islands Knowledge sharing
  15. • Constantly encourage to communicate • Silent team is a

    dangerous team • Encourage proactive learning • Eliminates parroting Proactiveness
  16. • Individual productivity, prioritization, time and energy management are unlisted

    part of • Prioritize heavily to reduce the streams of work. So that anyone can have a mental model of the work • Create psychological safety for the team • Don’t measure lines of code or number of issues closed, evaluate the impact of the team on the product or release Productivity
  17. • Let the team believe in expertise • If there

    is no ability to take continuous tradeo ff s, then team copies patterns without understanding them • Incentivize for long term e ff orts • A stretched team will put engineering to back seat Dynamics
  18. • Time and entropy makes sure the process you put

    degrades • Slip ups which aren’t addressed will be propagated and it will become a norm • Leave no broken windows • Stay vigilant about slip ups Process decay
  19. Keep It Simple and Stupid GREAT ADVICE… HURTS MY FEELINGS

  20. • Helps to grow in your career. Either to get

    promoted inside the company or get more opportunities outside • Product mindset and collaboration > Churning code • In fl uence without authority • Natural leadership Why it’s important for engineer
  21. • Few of my talks and writings for reference: •

    Becoming pragmatic • What’s next • Software craftmanship How to show excellence
  22. • Catchy terms and analogies are inspired from books •

    “Pragmatic Engineer” Newsletter by Gergely Orosz • “Build” book by Tony Fadell • “Software Engineering at Google” book by Winters, Manshreck & Wright • “Leaders Eat Last” by Simon Sinek • “Cute pictures” from Tensoon 🐺 Reference & Credits