3 ms·

Have worked for the A to Z company. Away teams as a concept exists because teams that are overworked and understaffed can't do everything asked of them (includi

by NBJack 3y ago

Have worked for the A to Z company. Away teams as a concept exists because teams that are overworked and understaffed can't do everything asked of them (including things you can't say no to, like S-Team goals). The Search team was especially famous/infamous for using this, due to the sheer volume of asks (i.e. can we do a twister on fabric types for clothing and see if it improves dress sales?). Your team makes the ask, search says "sure we'll support you as you make the changes to it," and the asking team provides the brave souls diving into a strange codebase. Does it work? Technically, yes. Is it sustainable for the engineers on both sides? Not in my eexperience. >> An away team is a self-sufficient engineering team that works on code owned by another team (the host team) to deliver features they are dependent on. This is fundamentally wrong. The point of the away team is to get support from the host team as they work. It is not self sufficient by nature. Otherwise, this is just a team randomly contributing to a codebase you own.

canttestthis 3y ago
> brave souls diving into a strange codebase As someone who made a career out of being loaned out to other teams as an 'away resource' at Amazon, I've struggled to find a similar level of mental stimulation after leaving for other Big 4 companies. Being a loaner engineer meant something new to work on every few months, no maintenance or oncall burden, making lots of new connections, and just generally there being always something interesting/intense to do.
- NBJack 3y ago
  I won't dispute your level of enjoyment from it, but I'd have to ask: did your fellow engineers feel the same way about it? What was your time commitment like to deliver? Also, if you're looking for a thrill, I would highly recommend going after cloud-based infra providers. There's never a shortage of unique problems there.
  - canttestthis 3y ago
    Time commitments were generally aggressive but reasonable with a 10-20% buffer to account for ramp up (realistically closer to 10 than 20). The reasonable-ness of most things eng-culture related at Amazon is probably a function of the competence of your management chain. As for my fellow engineers- I don’t know anyone else who did this regularly so I’m not sure

by NBJack 3y ago

canttestthis 3y ago

> brave souls diving into a strange codebase As someone who made a career out of being loaned out to other teams as an 'away resource' at Amazon, I've struggled to find a similar level of mental stimulation after leaving for other Big 4 companies. Being a loaner engineer meant something new to work on every few months, no maintenance or oncall burden, making lots of new connections, and just generally there being always something interesting/intense to do.

NBJack 3y ago
I won't dispute your level of enjoyment from it, but I'd have to ask: did your fellow engineers feel the same way about it? What was your time commitment like to deliver? Also, if you're looking for a thrill, I would highly recommend going after cloud-based infra providers. There's never a shortage of unique problems there.
- canttestthis 3y ago
  Time commitments were generally aggressive but reasonable with a 10-20% buffer to account for ramp up (realistically closer to 10 than 20). The reasonable-ness of most things eng-culture related at Amazon is probably a function of the competence of your management chain. As for my fellow engineers- I don’t know anyone else who did this regularly so I’m not sure