Cf http://www.google.com/corporate/execs.html qui liste leurs VP et Exec VP.

Sur le 2): certes pour le commercial, mais dans les SSII, on commence ‘ingénieur d’affaires’, puis on est ‘gestionnaire de grand-compte’ (ex. responsable des ventes Carrefour), puis directeur d’agence, puis…Le titre en était presque devenu un moyen de rétribution. Chez Google, du junior sales au VP Sales, tout le monde est Sales Engineer sans passer par les cases junior ou VP. Et je trouve ça plutôt sain, mais ce n’est que mon humble avis.

Et oui, le fait que les ingénieurs travaillent sans lien direct avec le client ou approche marketing peut choquer. Ceci étant, ils sont directement reliés aux clients et peuvent tester en temps réel leur approche. Il serait bon de creuser le modèle d’évaluation des collaborateurs de Google pour mieux comprendre cela.

Ce qui me tracasse, et il y a un “pattern” voisin à celui de Microsoft, c’est effectivement la capacité à lancer des projets indépendamment de toute logique économique. L’ensemble étant financé par la ou les vaches à lait de la société. Ce n’est pas forcément une bonne discipline d’un point de vue business. Mais comme le nom de la R&D de Google l’indique (Google Labs), Google est peut-être le premier laboratoire de R&D directement connecté à son marché et largement autofinancé qui existe en informatique!

Sur le 2), le titre de “Sales Engineer” semble aligné sur “Sofware Engineer”, fine. Mais en France, dans les boites d’informatique qui font du btob, on dit bien “Ingénieur d’Affaire” au lieu de “Commercial”. C’est du pareil au même! Et ces commerciaux sont sommes toutes assez classiques :q ils vendent de l’espace au kilo à des annonceurs.

Bravo et merci d’avoir eu le courage de retranscrire cette session très intéressante. Avoir accès à des gens de Google qui parlent de Google est suffisamment rare pour être souligné, voire fêté.

J’ai beaucoup aimé la dernière phrase de votre “L’éclatement géographique du développement répond à une logique de recrutement assez simple consistant à chercher les talents là où ils sont au lieu de leur proposer tous de déménager à Mountain View. Au passage, cela permet de contourner les limitations du nombre de visas pour l’entrée de travailleurs aux USA. C’est donc bien vu! Et certains éditeurs de logiciels pourraient s’en inspirer!”));

Si vous le permettez, je souhaiterais compléter votre très exhaustif compte-rendu par deux points qui m’ont paru importants:

1) le fait que les équipes projets soient formées d’ingénieurs purs et durs; sans ‘project manager’, sans réelle hiérarchisation. C’est à mon avis très bénéfique pour le nombre de projets en incubation, et ça favorise certainement l’homogénéisation vers le haut des pratiques de développement logiciel. Maintenant, j’y vois un élément négatif majeur: combien y a-t-il de projets appelés pour combien d’élus? Si Google s’est inspiré des méthodes d’autres éditeurs de logiciels, alors ce n’était pas une best practice à retirer. Il faut bien à un moment que le client dicte sa loi, que les ingénieurs répondent à un réel besoin de niche ou de masse. Sinon la plupart des projets sont condamnés à rester dans des placards, ou à devenir des logiciels de geeks pour geeks.

2) ça peut paraître complètement symbolique et futile, mais chez Google, les marketeurs sont tous “Sales Engineers” et les ingénieurs tous “Software Engineers”. Ca me fait toujours marrer, par exemple dans les banques de voir les titres des gens dans les sociétés. Au moins chez Google, et je trouve ça vraiment très positif, tout le monde est logé à la même enseigne et l’entreprise peut vraiment se proclamer méritocratiques.

Voilà, c’était ma maigre contribution à votre magnifique post. Et puis j’oubliais: le t-shirt Google éveille pas mal la curiosité (j’ai eu l’occasion de le porter en jouant au foot, je ne vous raconte pas les plaisanteries à chaque fois que mes passes ne trouvaient pas preneur).