Recently my team has been working more closely with another team at Jana, sharing the development of several components and libraries. While this collaboration has presented some unique challenges in communication and division of work, it has also taught me a great deal about communicating design decisions early on and with as much breadth as possible. Normally, my team members and I are reasonably well informed of each other’s work through daily standup and comments on the tasks we are working on. In a cross-team situation it is harder to ensure that your work is clearly communicated to all who are impacted by it. I learned this the hard way when I was charged with choosing an HTTP client to handle requests from our Android app. I initially chose Retrofit which leverages OKHttp to make requests. I chose Retrofit because the API can be very simply defined as a Java interface. What I later learned is that in exchange for this simplicity, you give up easy access to some cutomization such as signing requests for security and subclassing requests containing common parameters. While it is still possible to do both of these things with Retrofit the result is not as clean as implementing them with the underlying OKHttp. We eventually chose to remove Retrofit and implement the API directly in OKHttp, which took extra engineering time. Had I been more clear about my choice, maybe by attending another standup, engineers working on related tasks could have forseen these problems earlier on and we would have saved time in changing the implementation.