(2022-05-12) Chicago CTO Summit

Went to the Chicago CTO Summit, run by Peter Bell

Bryan Helmcamp, CodeClimate, CEO alignment

• secret is Great Reporting, to create opportunities for shared fact-based understanding
  • including qualitative
  • so this serves you: set agenda
• every other department is already reporting, focused on their KPI/OKR
• predictable interval, with context (pairs of offsetting metrics)
• more details for you, not all shared

David Subar (Interna): Product/Engineering alignment

• 2 culture clashes
  • between Eng and Product
  • between "Biz" and "Tech" - stop thinking that way, they're not 2 separate things!
• tools
  • alignment
  • measurement
  • review
  • transparency (honesty, self eval)
  • iteration
• "efficiency" as goal is team-local-focused, creates more silos
• align both with (external/real) customer, re what they value, the change you create with them
• don't report efficiency/output metrics up/out
• need outcome metrics, esp customer outcome/change
• Epic Statements clarify Why
• retro your bets re outcome (thinking in bets)

Bjorn Freeman-Benson: Debugging

• esp Debugging in Production, because users have problems
• reality is cruel
• don't be clever (with code that's hard to read)
• be unique (user error msgs, even if sneaky via punctuation)
• Tracing: Open Telemetry. Incl customer id, transaction id https://opentelemetry.io/
• Cloud Logging is Expensive, keep most local, stream last bits to cloud only when something goes wrong
• pre-build your debugging tools (tell customer state, system state)
• pre-build your rollbacks
• separate control plane
• debug in production: telepresence (adds your laptop to production cluster) https://www.telepresence.io/

Charity Majors, Honeycomb.io, fulfilling the promise of Continuous Delivery

• developer sustainability
• DORA metrics
  • now 25% of teams are Elite
• great teams make great engineers
• feedback loop, sociotech
• Continuous Deployment, automatic (within 15min) upon Commit
• feature toggles key (but then deployed code doesn't actually run until toggle switched)
• fast deploy maintains mental context (flow)
• observability tooling
• this (shortening feedback loop) doubles your output

Emad Khazraee, turing.com, Science the Product

• data-driven hypothesis testing
• reproducible, peer review

Eleanor Saitta, Security starting from Zero

• think about user risk
• smart language choice ("don't use C for webapps")
• let someone else do auth (for internal access)
• think about where data goes (beware putting PII into logs)
• next level can wait until 10 devs
• every 3rd party SaaS service is a technical debt, try to stay under 50
• real test-restore backups
• use Google SSO and Yubikeys
• avoid Windows/Office
• Jamf laptop mgmt
• Thinkst Canaries for your VPNs https://canary.tools/
• basic log centralization
• governance: fractional CSO to push back on CTO

Lauren Nagel, StackHawk: security service

• DevSecOps: integrate security into DevOps flow, make more continuous
• prioritize fixes
• automated code fixes can break builds, be prepared, make sure changes are traceable

Aaron Beda, Cumberland, Synthesizing Failure

• beware overengineering to prevent failure
• instead design to fail gracefully
• business impact
• temporary: retry
  • queues are liberating
• semantic
• patch/fix and move forward
• terminal
  • shut down
• most system can settle for Eventual consistency
  • reconciliation

Ann Lewis, Next Street, Buy vs Build at Scale

• keeps changing as components become commodities
• overthink framework/architecture decisions because they'll change rarely
• build where you have to control
• build only what you can't buy
• focus on core user needs
• use boring tech

Jay Zeschin, Engineering Superpowers via Serverless

• time is the one thing you can't buy
• to Build is to Bet: we can do cheaper, better, faster than anyone else (buy vs build)
• Focus is the Superpower that improves our Luck
• Serverless isn't about the tech, it's about the mindset (build as little as possible)
  • infrastructure, app features (doc mgmt), tooling (Ci/Cd service)
• key practices
  • event-driven architecture
  • business logic (domain) as glue
  • shifting left

Mercedes Bernard (consultant), Trust at Scale

• priority changes are stressful
• John Gottman: small moments
• start hard conversations from curiosity: why are our perceptions different?
• start from Caring

Jonathan Moore, RowdyOrbit, criminal background makes excellent dev

• building neighborhood mesh networks, and local services (air quality) on top of them
• some neighborhoods have 90% incarceration, so local biz has to hire some
• and criminals are often resourceful (reality hacker)
• if you want to hire a convict, work with community organization that supports that person, so that doesn't become your job

Aaron Erickson, OrgSpace, Bad Reorgs

• most reorgs are negative
• some reorgs are necessary
• smaller adjustments are generally better
• what's the goal? So what's the metric? What's the expected change?
  • likewise architecture changes
• see Dynamic Reteaming book, Team Topologies

Trace Wax, Artium, the API of your team

• stakeholder, inputs/outputs
• RACI
• API design metaphors:
• networks, not hierarchies
• cell membranes
• simple, discoverable, flexible
• domain-driven design
• (feels like this doesn't solve the macro incoherence)

Joseph de Castelnau, Chief Data Officer & Founder, Syncresia, You've become a tech leader now what?

• balanced scorecard for professional satisfaction

Mike Stahnke, CircleCI, Beyond the DORA four key metrics

• are we really elite?
• DORA focuses on primary app
• what is elite? "moving fast with confidence"
• what's next?
• deploys/dev/week
• % of work thats unplanned
• narrow (customer value) vs wide (infrastructure)
• are systems easy to work on? (k8s means no)
• normalization/standardization (easy to work on new service): % of code using standard/platform; onboarding days until 5th PR
• my take: if dev is at Elite, next step of improvement probably best driven by product-team integration, rather than getting even better at pure-dev.