The image in the reading complementing the idea of building shared understanding felt all too real. This summer, as I worked as a software engineering intern, I often got on a call with my manager, who worked remotely, to discuss technical concepts. How should we design this architecture? In what ways can we drop attention tokens to reduce computation in our transformer model? For each of these types of questions that I had, my manager would respond briefly through our chat and then set up a quick 1:1 to discuss. In these zoom calls, we would agree upon an approach, and I would get to thinking about how to implement the concept. However, there were a few times when I implemented something and requested a code review, and it turned out that what he had in mind and what I had in mind were totally different even though we had previously come to a “consensus.” I remember thinking “dang, what went wrong? Did I not ask enough questions? I wasted a week of work implementing something that was different from what my manager expected…” I learned my lesson of how important it is to have in-person meetings (and how intentional it is to have them in-person when possible), especially when describing abstract concepts. Had we been able to draw out the model architectures or scribbled down our ideas separately, the outcome might have been different. Thus, this reading made it clear that the design approach discussed here applies even outside of purely design roles, i.e. that it is something that can be really great to leverage even as an engineer (when we think about our different PM, designer, engineer roles in our projects). Shared documents (our even shared conversations) aren’t (necessarily) shared understanding.
“The goal should never be to build it all. The goal is to minimize the amount we build.” I thought this quote was really interesting. It really gets to the heart of prioritization in a way that is super clear. I think that in my design processes, I tend to follow the MoSCoW prioritization technique, which breaks down into must-haves, should-haves, could-haves, and won’t haves (or won’t have right now). Instead, the author simplifies it as “it was either in or out”, with “we cannot go live without this” and everything else. It’s definitely a much more strict process of deciding what to do, and I believe that it can really facilitate and streamline the design process, especially in conversations with large groups of people (or when things are indecisive). I think that having the sticky-note design process can also complement the document approach because documents can definitely be a good place to write out details or other things that come to mind (but that may not have a good place on the board at the moment).
