3 ms·

I much prefer an “operating system” model. The away teams should be writing “userland” code within the home teams well defined guardrails. The home teams act a

I much prefer an “operating system” model. The away teams should be writing “userland” code within the home teams well defined guardrails. The home teams act as OS devs for their service mostly write “kernel” code for their service that empower the away teams. Usually the “home team” are functional specialists. They are working on some piece of infrastructure or maintaining a service. The “away” team OTOH is building a feature and needs to touch a few dozen codebases It should be obvious which code is kernel and maintained by the service team, and which by the away “app” team. The away teams should be maintaining, on-call, and responsible for their code running within the context of the home teams service. Which hosts many such “apps” https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fail.html https://softwaredoug.com/blog/2023/07/08/why-search-orgs-fai...

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 ago
  I have successfully done this repeatedly in a very big org, though it wasn’t easy and it also wasn’t at Amazon.
- softwaredoug 3y ago
  Yes 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 ago
    Sorry, 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 ago
      No 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

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 ago
I have successfully done this repeatedly in a very big org, though it wasn’t easy and it also wasn’t at Amazon.
softwaredoug 3y ago
Yes 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 ago
  Sorry, 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 ago
    No 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