It would be great to see some actual design docs in a blog post versus a summary article with zero primary references. (A postmortem of some design docs would be incredible!).
One of the hardest things about introducing a design doc process to a team of engineers is providing concrete examples as seeds and ensuring feedback to make the process actually work. It can be really jarring to introduce the design doc philosophy to a larger team if all they've been doing is Scrum every week. Moreover, typically design docs happen at a quarterly rhythm and feedback periods can take weeks-- this slow cycle is a major impediment to consensus and learning.
All this calls for material that speaks to differentiated learning. Extolling "we do this at Google" is a leaf in the wind.
One of the hardest things about introducing a design doc process to a team of engineers is providing concrete examples as seeds and ensuring feedback to make the process actually work. It can be really jarring to introduce the design doc philosophy to a larger team if all they've been doing is Scrum every week. Moreover, typically design docs happen at a quarterly rhythm and feedback periods can take weeks-- this slow cycle is a major impediment to consensus and learning.
All this calls for material that speaks to differentiated learning. Extolling "we do this at Google" is a leaf in the wind.