Defining the Role of Distinguished Engineers

Clarke Rodgers (00:11):
Paul, muchas gracias por acompañarnos hoy.

Paul Vixie (00:13):
Me alegro de estar aquí.

Clarke Rodgers (00:15):
Si fueras tan amable, ¿podrías hablarnos un poco sobre tu trayectoria? Es el ilustre innovador y líder intelectual que, en cierta medida, ayudó a inventar Internet en el DNS. Por favor, cuéntanos un poco sobre eso.

Paul Vixie (00:30):
Desempeñé un papel en las primera etapas, pero no soy Al Gore. No lo inventé. Respecto al DNS, al principio intentaba arreglarlo para mí. Trabajé en una empresa de minicomputadoras a finales de los ochenta en la que el software era terrible y el protocolo no se entendía muy bien. Así que, fue en defensa propia. Luego, gustó bastante y fundé una empresa para mantenerlo. Cuando dejé de trabajar en esa empresa, creé una startup en el espacio de seguridad.

En medio de todo eso, me incluyeron en el Salón de la Fama de Internet y obtuve un doctorado en la Universidad de Keio en Japón, lo que resultó extraño, ya que todo empezó cuando dejé la escuela secundaria en 1980.

Clarke Rodgers (01:18):
Impresionante. Ahondemos un poco en eso. ¿Cuál fue la causa de que abandonaras la escuela secundaria y cambies de rumbo hacia el espacio tecnológico?

Paul Vixie (01:28):
En ese momento, trabajaba a tiempo parcial en pequeños trabajos en el sector de las minicomputadoras. Así que, cuando mi consejero escolar me dijo: “Sí, volverás a ser estudiante de tercero el año que viene”, fue porque había pasado todo mi tiempo en el laboratorio de computación.

Clarke Rodgers (01:43):
Impresionante.

Paul Vixie (01:44):
Me di cuenta de que probablemente no iba a mejorar y que lo mejor era irme de allí. Más tarde, dejé ese trabajo, como inevitablemente lo hacemos a esa edad. Pero sí, todo se debía a que era un mal estudiante porque pasaba demasiado tiempo programando.

Clarke Rodgers (02:00):
Bueno, creo que al final salió todo bien.

Paul Vixie (02:03):
Estoy contento con todas las decisiones raras que tomé.

Clarke Rodgers (02:08):
Cuéntanos un poco sobre tu función aquí en AWS.

Paul Vixie (02:13):
Desempeño dos funciones, quizás tres. Me contrataron como Vice President, Distinguished Engineer. Se trata de un grupo muy reducido de personas con mucha experiencia. Así que es una función bastante autodirigida. Para ser Vice President, Distinguished Engineer, la descripción de tu trabajo es encontrar problemas e investigarlos. Es muy raro que alguien diga: “Paul, realmente necesitamos que hagas esto”. Por lo tanto, es un gran honor para una empresa de este tamaño tener libertad, sobre todo cuando se cumplen veinticinco años de los hechos y sin saber cómo hemos llegado hasta aquí. Ha sido una locura.

Durante el verano, me nombraron Deputy CISO de AWS y, casualmente, me pidieron que dirigiera la Oficina del CISO. Pueden comparar la Oficina del CISO con arquitectos de soluciones de alto nivel. Si hay una conversación con el cliente en la que va a estar presente un directivo de alto nivel, normalmente queremos que nuestro CISO esté en esa sala. El problema es que solo tenemos un CISO y tenemos muchas salas, así que somos una especie de banda de respaldo para dicha función. Somos como media docena de personas con el nivel más alto, expertos en el área. He estado trabajando con ellos, de hecho, me incorporé al equipo para ponerme en contacto con los clientes. Y creo que por eso me eligieron para dirigir ese equipo.

Clarke Rodgers (03:44):
¿Hubo algo que realmente te atrajo a AWS?

Paul Vixie (03:47):
La descripción del trabajo. En otras palabras, si me hubieran pedido que viniera aquí y fuera VP de una cosa u otra y que estuviera a cargo de una función determinada, habría dicho: “Sí, ya he pasado por eso”. Sin embargo, se trata principalmente de un puesto en tecnología, al menos la parte de ingeniero distinguido de mi trabajo es básicamente ser un colaborador individual de nivel ejecutivo. Para entender por qué fue emocionante, la última vez que usé la palabra “ingeniero” en mi título fue también la última vez que alguien que no fuera yo me escribió una carta de oferta, y eso terminó en 1993. Simplemente he sido CEO de startups y sí, siempre fui un CEO que programaba, pero todavía no era un ingeniero profesional. Ese no era mi trabajo principal en ninguna de las empresas.

Por lo tanto, poder volver a la trayectoria original en la que habría estado sin todas esas startups y simplemente ser un ingeniero que contribuye de forma individual fue halagador. No creí que aún pudiera hacerlo. De cierto modo, tuvieron que convencerme. Pero una vez que describieron el puesto, se quedó grabado en mi cerebro y pensé: “Sí, realmente quieres volver a eso”. No lo sabía. No tenía ni idea de que podía trabajar porque soy una figura pública menor en las industrias de Internet y la seguridad, y se me conoce un poco como una persona disruptiva. Por lo tanto, me habría considerado demasiado controvertido para este trabajo. Ellos pensaron lo contrario. Hasta ahora, han tenido razón.

Clarke Rodgers (05:22):
Llevas aquí un tiempo. Has podido husmear un poco. ¿Cuáles han sido tus impresiones sobre la cultura de seguridad específica de AWS?

Paul Vixie (05:32):
En mis diversas startups, vendía a empresas como esta. La gobernanza corporativa es prácticamente igual en todas partes, excepto que nuestro equipo de seguridad lleva tanto tiempo aquí que podemos afirmar de manera justificada que la seguridad es el trabajo cero, y eso no es solo una afirmación. Se refleja en todo el organigrama, en los planes operativos y en las prioridades presupuestarias.

En otras palabras, por supuesto que estamos aquí para atender a los clientes, como es de esperar que cualquier empresa esté ahí para sus clientes. La diferencia es que no haremos nada que haga sentir inseguros a nuestros clientes. Nunca dejamos de lado la seguridad. Eso es lo que nos diferencia.

Clarke Rodgers (06:20):
Al trabajar de manera ardua en un equipo de servicio, por ejemplo, en esta función de Distinguished Engineer, ¿podrías revelarnos si hay algún conflicto cuando debaten sobre el lanzamiento de una característica frente a una solución de seguridad? O es simplemente: “No, se debe llevar a cabo una solución de seguridad”. ¿Cómo son esos debates?

Paul Vixie (06:42):
No recibimos quejas del tipo: “Caramba, si bloqueas este lanzamiento por el resultado de alguna prueba de seguridad de la aplicación, nos retrasará mucho. Perderemos nuestra oportunidad, y eso ya está en marcha”. Eso no sucede. No está permitido de manera deliberada y explícita. Lo que sí ocurre a veces es que, cuando se trata realmente de algo que “debe hacerse” pero no es “absolutamente necesario”, yo u otra persona que representa a AWS Security decimos: “Esto va a causar problemas y va a ser mucho más caro solucionarlo más adelante”. Nuestros equipos de servicio tienen autonomía a ese nivel.

Pueden decidir qué es importante, pero saben que si hay un problema de seguridad, el hecho de que hablemos con ellos al respecto va a quedar registrado. Van a tener que dar algunas explicaciones. Y sí, a veces hay tensión porque obviamente todo el mundo tiene un jefe y si el jefe dice que debemos entregar algo para una fecha determinada, entonces uno avanza y responde a ello. No queremos hacer estallar nada. Sin embargo, entendemos que las personas con las que trabajamos tienen el objetivo principal de cumplir con sus métricas y nosotros somos la segunda directiva principal.

Clarke Rodgers (08:09):
Pasemos a tu otro trabajo diario. Al dirigir la Oficina del CISO, tienes mucho contacto con nuestros clientes e interactúas con ellos en todo el mundo, ya sea en persona o de forma virtual. Uno de los vehículos en los que has participado en AWS es AWS CISO Circles. ¿Podrías hablarnos un poco de esto y de tu experiencia?

Paul Vixie (08:30):
Mi incorporación a CISO Circles fue así: “Paul, ¿podrías ir a...”, en este caso fue Madrid, “y participar en un CISO Circle?” Tuve que decir: “¿Qué es eso y cómo sería mi participación?” En ese momento solo llevaba un año aquí. Es posible que esto requiera a alguien con más experiencia de la que yo tengo sobre quiénes somos y cómo hemos llegado hasta aquí. Fui y fue fantástico porque era una reunión de un grupo de CISO de una industria en particular. Todo está bajo una especie de acuerdo de confidencialidad, se espera que puedas hablar libremente porque las demás personas en la sala no van a repetir lo que has dicho.

Clarke Rodgers (09:20):
La Regla de Chatham House.

Paul Vixie (09:21):
La Regla de Chatham House prevalece, y estas personas son, en algunos casos, competidores. Son CISO de empresas que pertenecen al mismo sector o a la misma región y, normalmente, no comparten ideas ni experiencias. Pero estaban en nuestra casa y nosotros moderamos e iniciamos el debate con algunas presentaciones sobre varios aspectos de la tecnología y luego alentamos el debate, alentamos los desafíos y alentamos, en última instancia, lo que resultó ser un debate entre ellos.

Fue hermoso verlo, porque esa es una de las cosas que toda empresa mediana o grande tiene que ser capaz de hacer: beneficiarse de las experiencias de sus competidores. Y no deberíamos intentar competir en función de quién es más seguro, porque si tú y yo estamos en la misma industria y te matan, me duele de todas maneras y probablemente signifique que soy el siguiente. Es decir...

Clarke Rodgers (10:24):
O sea que comparten información y mejores prácticas...

Paul Vixie (10:26):
Sí, necesitamos permanecer unidos en algunas áreas, incluso mientras competimos en otras. Terminaron conociéndose, descubriendo cuánta confianza podían extender sin arriesgar los secretos de su empresa, etc. La intención es que mantengan el contacto después del evento. Y, por supuesto, inevitablemente eso significa que alguien dirá: “Oh, bueno, ese día tuve una terrible experiencia con una API en la nube”, y alguien más dirá: “Bueno, a mí me funciona”, y si terminan quejándose de nosotros, bueno, si nos lo merecemos, entonces también deberíamos aceptarlo.

No vamos a poder mejorar el servicio a nuestros clientes si no sabemos qué es lo que funciona mal. Por lo tanto, resulta ser una enorme fuente de inteligencia empresarial para nosotros. “Ojalá hubiera...”. A veces puedes decir: “En realidad, eso existe”. Somos una empresa muy grande e innovamos mucho, y creamos características o tecnologías nuevas a un ritmo que ningún cliente podría seguir. Quiero decir, es mi trabajo hacerlo, y me cuesta mantenerme al día.

Por lo tanto, debemos tener una interfaz de cliente en la que alguien reconozca cuáles son los problemas de los clientes y cuáles son los problemas de la industria, qué están haciendo y cómo lo hacen, cuáles son sus puntos débiles. Resulta que tenemos personas que hacen eso y los clientes no saben que deberían destinar tiempo a reunirse con regularidad. Y si CISO Circle ayuda a que eso suceda, una o dos veces, espero que se pase la voz y se convierta en un movimiento.

Clarke Rodgers (11:59):
Fantástico. Paul, gracias por acompañarnos hoy.

Paul Vixie (12:02):
Ha sido genial. Gracias de nuevo por invitarme.