Photo by Hendrik Kespohl on Unsplash
Shifting the discussion left causes outside contributions to have a higher acceptance rate.
The main benefit of organizing teams around domains is they should be able to move faster due to fewer dependencies on other teams. But the main drawback is if you do depend on another team, getting them to prioritize functionality or fixes you need can be a battle. If your company has a culture of innersourcing, then providing outside contributions can help you keep your velocity.
Pull Requests Welcome™
Feb 15, 2020 · 5 min read
Developers like to complain. We'll complain about lack of documentation, lack of tests, choice of framework, choice of linter settings, and so on. My response to it? Pull requests welcome.
But you have to be a good neighbor. You have to put in the work to understand if your gift will be accepted or not. If the first time that another team hears about your project is when you submit a pull request that changes their code's behavior, performance, or dependencies—then it's probably going to be rejected, and it could be relationship damaging.
Think about it this way: offering to buy a friend a concert ticket for a band you both like is a nice gesture, but buying them a concert ticket without knowing what they like (or even if they like live music) could be a burdensome gift.
So how can you know if your gift of code will be received well? Start a conversation. You may not know what the other team's goals are, what migration they might be in the middle of, or what their team norms are unless you talk.
Starting the conversation
I like written artifacts, I blog about the importance of them a lot.
I think an artifact that engineers under-utilize is a problem statement document. The goal of the document is to get people to agree on the outcome you want to achieve, and it also helps open the door to discussing how to achieve it. The documents are typically lightweight to write & read (1-2 pages max), so they shouldn't be burdensome to anyone.
In the context of outside contributions, I believe that writing and presenting a problem statement document conveys to the other party two things:
- You've put in the work to understand that a change is important and truly necessary.
- You're inviting discussion and feedback.
A pull request is not an invitation for discussion or feedback.
Even though Boehm's Law is typically referenced in the context of fixing software defects, the same idea holds true for pivoting technical design. It's a lot less expensive (in terms of time, but also emotions) to pivot a design earlier in a project's lifecycle than it is later. It's frustrating to both sides when an outside contribution gets rejected. The submitter is frustrated that their effort has gone to waste, and the owner is frustrated from being blindsided.
Start the conversation and gain buy-in well before implementation starts to save time, money, and emotions.
