Team and Software: Making an Impact as an Architect
summary
Argues that technical skill alone doesn’t move systems: architects must convert technical quality goals into decisions teams actually implement, so communication and alignment matter more than coding. Recommends concrete tactics: run socio-technical architecture reviews that focus on team structure, use Fearless Change tokens and local sponsors to seed ideas, prioritize autonomy versus decision quality for things like JavaScript frameworks, and measure assumptions with a small survey (run on Blue Sky and Mastodon). Emphasizes frequent failure in communication and learning from it.
AI-written summary · about
chapters (19)
- 0:00Introduction
- 1:58Hard skills in architecture
- 6:41Communication is key
- 8:25Architecture challenges
- 10:08Making an impact
- 12:36Architects vs managers
- 14:43Feedback to management
- 17:59Introducing new ideas
- 20:04Architecture in business terms
- 21:47Supporting developers
- 23:11Different perspectives
- 27:28Empathy in architecture
- 29:36Balancing decisions and autonomy
- 32:52Framework decisions
- 34:16Team self-organization
- 37:03Socio-technical reviews
- 38:29Communication failures
- 40:16Conclusion and key takeaways
- 41:42Q&A
related talks
02mHigh-performance teams
46mTHE too MANY FACES OF ARCHITECTURE
45mArchitecture: The Stuff That's Hard to Change
49mWhy software architects fail: and what to do about it
46mArchitecture Transformation Challenges
37mSoftware Architecture for Humans!
01h 02mThinking Like an Architect
41mSoftware architecture as a contributor to high performing teams