FDE vs solutions engineer : avant et après la signature
Les deux métiers passent leurs journées chez des clients, écrivent du code que personne ne relira, et expliquent la même technologie à des gens qui ne l’ont pas demandée. La différence tient en une date : celle de la signature. Le solutions engineer travaille avant, et sa réussite se mesure au fait que le contrat existe. Le forward deployed engineer travaille après, et sa réussite se mesure au fait que l’organisation cliente fasse désormais son travail autrement. Cela change tout ce qui suit. L’un construit pour convaincre, et une maquette qui tombe en panne après la démonstration a rempli son office. L’autre construit pour durer, et ce qu’il laisse doit survivre à son départ, aux mises à jour du client, et au départ de la personne qui avait porté le projet en interne. Les deux sont des métiers d’ingénieur exigeants. Ils optimisent simplement deux choses différentes, et confondre les deux est la cause la plus fréquente d’un déploiement qui déraille.
| Forward deployed engineer | Solutions engineer | |
|---|---|---|
| En une phrase | Un ingénieur employé par l’éditeur, qui travaille dans l’organisation du client pour que le produit règle le vrai problème de ce client. | Un vendeur technique qui prouve, devant un prospect, que le produit peut faire ce que ce compte demande. |
| Jugé sur | Le fait que le travail du client ait changé, et que le changement ait survécu à son départ. | La signature du contrat, et le fait que ce qui a été promis en démonstration était vrai. |
| Travaille dans | Les systèmes, les données et les réunions du client, souvent dans ses locaux. | Les environnements de démonstration, les maquettes, les questionnaires de sécurité et le cycle de vente. |
| Mène le plus souvent à | Diriger une équipe de déploiement, ou le management produit avec une crédibilité terrain rare. | Diriger une organisation d’avant-vente, ou passer au produit ou au déploiement après la vente. |
| Temps passé chez le client La part de la semaine passée avec ceux qui emploieront la chose. | Élevé | Élevé |
| Profondeur technique Jusqu’où va l’ingénierie attendue du poste. | Élevé | Moyen |
| Profondeur métier À quel point le poste doit comprendre le métier du client lui-même. | Élevé | Élevé |
| Écriture de code La part du travail qui consiste réellement à écrire et intégrer du logiciel. | Élevé | Moyen |
| Responsable du résultat Si le poste est jugé sur la livraison, ou sur ce que la livraison a changé. | Élevé | Faible |
Ces niveaux décrivent le centre de gravité d’un poste, pas une règle. Les intitulés ne sont normalisés nulle part : une offre donnée peut se situer loin de sa colonne. Lisez ce qu’elle dit que la personne va construire plutôt que son titre.
Deux définitions du succès
Un solutions engineer est jugé, directement ou non, sur le taux de transformation des affaires qu’il accompagne. Son travail consiste à retirer les obstacles techniques qui empêchent un acheteur de dire oui : répondre au questionnaire de sécurité, prouver que l’intégration au système existant est possible, montrer que la performance tient sur des données proches des siennes.
Un forward deployed engineer est jugé sur l’usage, et l’usage est une mesure beaucoup plus lente et plus ingrate. Un client peut avoir signé, être enthousiaste, avoir communiqué en interne, et malgré tout ne rien avoir changé à sa façon de travailler six mois plus tard. Cette situation compte comme un échec pour le second métier et comme une réussite pour le premier, ce qui explique pourquoi les deux populations racontent parfois le même projet de deux manières irréconciliables.
Il n’y a pas de malhonnêteté là-dedans. Chacun répond à la question qu’on lui pose. Le problème naît lorsqu’une entreprise n’a que le premier métier et croit avoir couvert le second.
La qualité du code n’a pas le même sens
La maquette d’un solutions engineer a une durée de vie de deux semaines. Elle doit fonctionner une fois, devant des gens, sur des données choisies. Coder proprement pour ce besoin serait du gaspillage, et un solutions engineer expérimenté coupe délibérément : pas de gestion d’erreur, pas de tests, des identifiants en dur, une donnée préparée la veille.
Ce que laisse un forward deployed engineer sera exécuté chaque nuit pendant deux ans, par une équipe qui n’a pas son numéro. Il doit donc échouer bruyamment quand une source d’entrée change de format, être lisible par l’ingénieur interne qui en héritera, et fonctionner un mardi de novembre quand le système amont sera en maintenance.
C’est la raison pour laquelle la reprise directe d’une maquette d’avant-vente est presque toujours une erreur. Elle a été écrite pour répondre à une autre question. La réécrire coûte moins cher que de la durcir, et le seul élément qu’il faut vraiment en conserver est la liste de ce qui a été montré au client, parce que c’est cela qu’il croit avoir acheté.
Le passage de relais, et pourquoi il rate
Dans une entreprise qui possède les deux métiers, le moment le plus fragile du cycle est la transmission du compte à la signature. Trois défauts reviennent.
Le premier est l’écart entre ce qui a été montré et ce qui a été écrit. Une démonstration laisse une impression, un contrat liste des livrables, et les deux divergent presque toujours d’au moins un point important. Le forward deployed engineer découvre cet écart en semaine un, face à un client persuadé d’avoir déjà payé pour cela.
Le deuxième est la perte du contexte humain. Le solutions engineer sait qui, chez le client, soutenait vraiment le projet, qui l’a combattu en réunion, et quelle direction a imposé le calendrier. Rien de tout cela ne figure dans un dossier d’opportunité, et rien de tout cela n’est redécouvrable en moins d’un mois.
Le troisième est le calendrier. La vente s’est conclue sur un délai annoncé, et ce délai a été construit pour lever une objection, pas à partir d’une estimation. Le remettre en cause en semaine deux est douloureux, mais infiniment moins qu’en semaine dix.
Les organisations qui traitent ces trois points par un rituel écrit, plutôt que par un appel de trente minutes, gagnent des mois sur chaque déploiement. C’est un gain de processus et non de talent, ce qui le rend reproductible.
Choisir entre les deux
Le critère le plus utile n’est pas technique. Il porte sur le type de satisfaction que vous cherchez, et sur le rythme auquel vous voulez l’obtenir.
L’avant-vente donne des cycles courts et des retours nets. Vous saurez en quelques semaines si l’affaire a été gagnée, vous changerez souvent de secteur, et vous ne porterez presque jamais les conséquences d’un système mal conçu. En contrepartie, vous construirez rarement quelque chose qui existe encore un an plus tard.
Le déploiement donne des cycles longs et des retours ambigus. Vous passerez des mois sur un même compte, vous connaîtrez son métier mieux que certains de ses cadres, et vous vivrez avec les décisions que vous avez prises au premier mois. En contrepartie, quand cela fonctionne, quelqu’un travaille autrement à cause de vous, et cela reste vrai après votre départ.
Les ingénieurs qui regrettent leur choix se trompent presque toujours sur ce point plutôt que sur la technique.
