3 ms·
It's painfully obvious you've never been on either end of this problem. In big orgs, if you have time to set up baby fences (or had them from the start) you ha
by flaminHotSpeedo 3y ago
It's painfully obvious you've never been on either end of this problem.
In big orgs, if you have time to set up baby fences (or had them from the start) you have enough free time to build the feature yourself.
No one who hosts an away team is prepared to do so
- pfannkuchen 3y agoI have successfully done this repeatedly in a very big org, though it wasn’t easy and it also wasn’t at Amazon.
- softwaredoug 3y agoYes I may be an idiot, though this has worked well at several places. For example, this worked really well for us at Shopifys Discovery team at for moving fast on search relevance and recommendation systems. To clarify how to build and test search experiments really fast. I would say it’s the default model/culture at Shopify. (Not away team per-se but more the “OS” model)
- flaminHotSpeedo 3y agoSorry, I was more aggressive than I should have been. I misunderstood your comment, I thought you were suggesting the home team build the guard rails in response to another team's request. I don't disagree that the pattern you're describing can be effective if the home team was always expecting other teams to work in their codebase. But that's not what the away team model is, the away team model is for unexpected cross team work. E.g. if the guard rails are too restrictive and the home team doesn't have time to expose the new functionality to "userland" code so the other team needs to work with "kernel" code to do so.
- softwaredoug 3y agoNo worries :). What I suggest I think is different than away team (which feels a bit like swoop in and crap on host teams codebase). Just saying I prefer it to away team. Fundamentally it’s just a hard problem most large orgs don’t do that well