L'équilibre entre vie professionnelle et vie privée chez Amazon dépend de l'équipe dont vous faites partie.
Amazon pratique ce que l'on appelle dans le secteur "You build it, you own it". Cela signifie qu'une équipe de service qui construit un service possède chaque aspect du service. L'équipe est responsable de sa mise en œuvre et de sa maintenance. Chaque équipe doit établir une rotation d'astreinte. Au moins une personne de l'équipe est d'astreinte. Si le service tombe en panne, s'il déclenche une alarme ou si, pour quelque raison que ce soit, il ne fonctionne pas comme il le devrait, la personne d'astreinte est bipée... même si c'est à 3 heures du matin
Ceci est fait pour encourager l'équipe de service à construire le service de manière à le rendre facile à maintenir et à réduire la charge opérationnelle. C'est surprenant, mais le reste de l'industrie ne procède pas ainsi. Dans la plupart des entreprises, une équipe d'ingénieurs construit un produit, puis le transmet à une équipe opérationnelle. L'équipe opérationnelle est responsable de se lever à 3 heures du matin. Le résultat final est que les corrections des problèmes opérationnels ne sont pas prioritaires, et la charge opérationnelle augmente jusqu'à devenir insupportable. Amazon a appris que lorsque les ingénieurs qui écrivent le code du service sont responsables de l'exploitation du service, soit ils l'écrivent de manière à réduire la charge opérationnelle, soit ils automatisent complètement les opérations. Cela crée une forte culture DevOps
Le problème est que lorsque vous avez une équipe qui ne rend pas son service opérationnel correctement, elle finit par prendre toute la charge opérationnelle, et l'équilibre travail-vie privée s'effondre. Tout le monde doit mettre la main à la pâte pour régler le problème. Dans les entreprises plus traditionnelles, les Ops auraient pris cette charge. Les Ops sont en quelque sorte habitués à cela, et ont tendance à ne pas s'en plaindre autant que le Dev
Dans un monde idéal, l'équipe qui crée des problèmes opérationnels serait forcée de s'approprier le problème jusqu'à ce que les problèmes de base soient résolus, et la charge opérationnelle. La réalité est que les gens changent de travail, et ils doivent être remplacés par d'autres personnes. En particulier, si une équipe a d'horribles problèmes opérationnels, toute l'équipe peut partir. Cela signifie que les managers engagent d'autres personnes pour les remplacer. Et le nouvel ensemble de personnes hérite des problèmes. C'est un défi pour un service ayant des problèmes opérationnels d'être redressé. Certainement pas impossible, mais difficile.
Si vous êtes embauché chez Amazon, votre perception de l'entreprise va dépendre fortement de l'équipe que vous rejoignez. Malheureusement, Amazon ne fait pas ce que font certaines entreprises technologiques : faire tourner les nouveaux employés au sein de deux ou trois équipes pendant les 6 premiers mois. J'ai essayé de défendre discrètement cette idée en interne.
La meilleure chose à faire est d'être franc avec votre responsable du recrutement, et de lui demander de vous parler de sa charge opérationnelle. Le responsable du recrutement est la meilleure personne à qui poser cette question
.