How to Drive Cross Team Techincal Changes
summary
Gives specific moves: test viability by documenting the historical context and what actually changed, run a workshop called riskstorming to list and rank likely failures, build a thin functional slice with just enough non‑functionals to prove production viability, and recruit both engineers with informal authority and quiet deep thinkers via managers for virtual breakout sessions where silent thinking and joint answers surface real feedback. Cites a 20‑year master data backbone and microservice boundary rework as concrete motivation and outcome.
AI-written summary · about
chapters (8)
- 0:00Driving technical change
- 1:26Why changing large organizations is hard
- 4:15Cross-team architecture example
- 7:43Engineering leaders' responsibilities
- 11:59Testing idea viability
- 15:51Building a compelling story
- 18:20Gathering engineering support
- 23:33Final thoughts
related talks
51mEffecting Change—The Art of Leading Teams
54mEffecting Change—The Art Of Leading Teams
01h 00mImproving Your Team(work)
20mWorking with Others and Delivering as a Team — Bridges Seen Through Human Relationships
43mThinking Architecturally
18mManaging Change: Implementing The UXDX Model
42mLeading Tech Teams in Uncertain Times
32mPanel discussion: The journey to building effective engineering teams