(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.

Edited:    |       |    Search Twitter for discussion