Dealing with drag
summary
Argues that measuring team-level performance not individual productivity is the right move and that “drag” is concrete: manual deployments, flaky docs, repeated incidents, overly complex configs and technical debt that actually increases a product’s software metabolism as features accumulate. Recommends making debt visible and quantified, putting it on the backlog with the visible/invisible × positive/negative axes, using value stream mapping and simple data to find the biggest bottlenecks, and deleting unused features to free capacity.
AI-written summary · about
chapters (6)
- 0:00Introduction
- 6:06Drag in team performance
- 10:02Technical depth as drag
- 16:22Software metabolism impact
- 21:41Reducing drag in development
- 24:10Key takeaways and closing remarks
related talks
17mHow to deal with technical debt in fast-paced environment
26mTackling tech debt
44mDependencies; Devil or Darling?
52mWithout Simplicity, There's Just No Agility
33mTaming The Chaos: After The Quick Wins
30mHow to Visualize Impacts to Your Workflow & Metrics
43mBacklogs – the good the bad and the ugly
46mMeet The Social Side of Your Architecture