it's a farce. Interesting idea in theory, terrible in practice. The away team incentive is "launch as fast as possible at all costs" and that goes about as well as you'd expect.
We constantly deal with shit code and loose rules. Given that many away teams work in different time zones AND Amazon gives them carte blanche to get their work done, the host team can't manage them effectively.
So yeah. On one hand management is like "push back! Make them follow your standards!" while also saying "Don't dedicate time to away teams, you have your own deliverables."
It's a major drain on the home team and can cause a lot of unnecessary stress.
These opinions are my own, obviously, lol.
The worse case scenario is when the scenario you given: the "pet project," where a team goes nuts on a codebase they aren't maintaining, in which case it's effectively out-sourcing maintenance and tech debt.
Ideally, the home team leadership has a lot of leverage to push back on work by the away team, which means away team work is slow but at least it gets done.
* You have to work with an, at best, passive team, at worst, actively hostile team. * You need to work against very tight deadlines and a lot of pressure in a codebase that you know nothing about, and need to ramp up in quickly.
* You spent weeks (months?) developing expertise in a system you will probably never work again.
It is a terrible idea, but to be honest I can't think of another way to deal with the problem that it is trying to solve (mismatch between agendas of different teams).
Since away teaming is an accepted technique, it's usually considered as a way to solve these issues.
I guess we would need to completely give away the concept, and just accept that some thing won't get done unless they are important enough to keep two distant teams aligned (in other words, they are important enough for someone high in the hierarchy).
Open-source model works for libraries, or small changes in service code (where the maintenance burden is trivial). But it doesn’t work for complex services with high maintenance burdens
This comes at the cost of much slower progress.
I saw no sign at all of the away team compromising on quality to meet deadlines.
It's worked for the last year or two semi-effectively, but I am loving this discussion for reminding me of the downsides/risks.
- Use as much as you can of what they already have.
- Talk to them, but don't waste their time.
- Follow their patterns.
- Understand at the end of the day its their domain.
- Choose your advice carefully.
- Try to throw a little extra gratitude their way. Organizational visibility, code reviews, documentation, mentorship, whatever feels appropriate and not over-stepping.
- Put extra effort into handoff documentation.