The Zoom link for today's discussion will be: https://excella.zoom.us/j/91040918326?pwd=SVZEaktBd1BON3RrUWJrMUtYcFkvUT09&from=msft See you all in about 10 minutes!

Friendly reminder we are operating today's discussion using Chatham House Rules - When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed. If you'd like to post your thoughts in this Slack channel… remember they should be non-attributable (per the Chatham House Rule).

Fantastic conversation today! Here are my notes and of course, feel free to share any further thoughts here. Thanks for all the great input!

• Coaching Teams
    o How to take Agile principles and apply them in a technical way
    o Encourage teams to deliver early and frequently, gaining trust from the customer, then you can
      have the conversation about technical debt
• Topic # 1: Do developers actually like coding?
    o Unless you have a group of people who like to code, technical excellence always just sounds
      like more rules
    o How would you wind up in this job if you don't like it?
         Pays well
         Might enjoy helping others
         Might enjoy being a part of a team
         Coding has turned into "pop culture"
    o Whether someone likes it or not, they would at a minimum have to like analytical thinking and
      problem-solving
    o Observation: SREs are prevalent and a lot of them did not enjoy pure coding but are anchors in
      other ways
• Topic # 2: What is technical excellence?
    o Coding skills (e.g. how good of a Java programmer you are)
    o Design – TDD
    o Anything that allows you to deliver faster
         Faster, but not rushed
    o Anything that makes technical solutions keep up with the business
    o More than just coding standards
    o If code is not solving a business problem, it is of no use
    o Constant improvement – what was excellent today will not be excellent tomorrow; adapting to new
      best practices
    o "Technical excellence" is a term of conflict
         Good definition is going beyond regular practices
         Innovation, originality, special attention to some details
         Question is how do we distinguish "the basics" from what is above and beyond?
    o Leave code cleaner than you found it
    o When you have surgery, you don't get two different bills – one for the surgery and one for the
      surgeon washing their hands…sanitation is PART of the surgery
         In the same way, your code is not done until it is technically excellent
• Topic # 3: Challenges
    o Trade-off between maintaining technical excellence and speedy delivery
    o Business won't be asking you for keeping up your product's "health"
    o (see topic 1) – people not passionate about their work
    o Balance is a difficult art – how to bring team motivation and other softer areas (individuals
      and interactions) into the fold
    o Can't get so into "technical excellence" that you lose track of the product – letting perfect
      be the enemy of good enough
    o Motivation – what demotivates people?
         When a company takes a "blame" attitude – "why do you even have technical debt? Why didn't
          you do it right the first time?"
         Unreasonable expectations
         Not feeling rewarded/appreciated
         Culture has an influence – when the rest of the company is not focused on excellence, why
          should I?
• Topic # 4: Mindset of one who might ignore technical excellence
    o Unpredictability
    o Understanding perhaps the good impacts of rushing a feature to market
    o Perhaps just facing reality
    o Deployments require big efforts and the mindset is let's do it quickly and soon
    o Lack of trust – a great quote: "we don't cut corners, we cut stories"
    o Ways around it
         Frequent deployments – show the business deploying is easy
         Encourage well-designed small stories rather than rushed mammoths
• Topic # 5: Attention to healthy practices
    o Test coverage, consistency
    o Agility of process in regards to understanding of business product
    o What do metrics tell us? You could have 100% test coverage but are they the right tests?
    o Think in the tests, solve problem in the test, not in the code
    o TDD is more important than test coverage
    o TDD however is not necessarily the only answer

Overall thoughts – it is a philosophy not a specific practice and it is about OUTCOMES not process