Pourquoi nos ingénieurs s'assoient avec les clients et ce qu'ils ne sont pas là pour faire

Chaque entreprise de plateforme propose éventuellement une version de celui-ci. Un ingénieur travaille avec un client pendant un certain temps, et quelque chose est construit plus rapidement qu'il ne le serait autrement.

La question est de savoir dans quel état se trouve le client lorsque cet ingénieur part, et cela dépend entièrement de ce pour quoi l'ingénieur optimisait.

Le mode d'échec

L'ingénieur construit la chose. Cela fonctionne, le client est satisfait et la connaissance de son fonctionnement revient à l'ingénieur.

Six mois plus tard, l'agent doit être changé, personne en interne ne comprend les critères d'évaluation et le client ouvre un ticket de support pour modifier son propre système. C’est ça la dépendance, et cela peut être présenté comme un engagement réussi pendant assez longtemps.

C’est également commercialement tentant à court terme, c’est pourquoi cela se produit si souvent sans que personne ne le décide.

Ce que nous sommes réellement là pour faire

Enseignez les quatre choses qui font que les opérations des agents fonctionnent, en les faisant ensemble plutôt que pour eux.

Comment décider ce qu'il faut automatiser en premier, ce qui est généralement un choix plus restreint que l'instinct du client.

Comment rédiger des critères d'évaluation pour leur propre travail, qui est la compétence qui se transmet le plus loin et celle avec laquelle personne n'arrive.

Comment instrumenter les coûts et la propriété afin que le deuxième agent ne répète pas les erreurs du premier agent.

Comment définir une limite et la faire respecter au moment de l'action plutôt que de la décrire dans une invite.

Si nous faisons bien ces quatre agents, le premier agent est plus lent à expédier et le cinquième leur appartient entièrement.

La mesure que nous utilisons

Pas d'agents livrés. Si le client a construit le prochain sans nous.

Il s’agit d’une mesure délibérément délicate, car elle fait d’un engagement réussi un engagement qui se termine. Nous pensons que c'est le bon test et c'est le test que nous appliquerions à un fournisseur travaillant avec nous.

Ce que les ingénieurs apprennent

Cela va dans les deux sens et ce n’est pas une courtoisie. Presque tout ce que nous avons changé dans la plateforme est venu du fait de voir une équipe frapper quelque chose que nous n'avions pas prévu.

L'attribution par agent est utilisée comme un outil d'inventaire plutôt que comme un outil de coûts. Des budgets serrés et utilisés comme un signal. Des critères d’évaluation écrits à rebours d’un échec plutôt que conçus à l’avance. Aucun de ceux-ci ne provenait d’une feuille de route. Ils venaient d'être assis à côté de quelqu'un.

Ce à quoi nous dirons non

Construire quelque chose qui, selon nous, ne devrait pas être construit. Un agent placé dans un chemin de décision où se tromper coûte cher et où il n'y a pas d'étape de révision n'est pas une question de portée, c'est une objection de conception, et nous préférons la soulever plutôt que de la livrer.

Nous refusons également d'être le propriétaire permanent des agents d'un client. Un agent a besoin d’un propriétaire nommé au sein de l’organisation qui en dépend.

Comment travailler avec nous

L'engagement est limité et l'objectif est énoncé dès le départ : votre équipe le gère sans nous. Si vous souhaitez parler d'un programme spécifique plutôt que d'une offre générale, réservez une démo et apportez les contraintes.

Suivant

Les pages du système d'orchestration d'agent couvrent les couches autour desquelles ce travail est construit. Carrières explique à quoi ressemblent ces rôles de l’intérieur.