Lo que los líderes de ingeniería deben saber sobre DevRel (pero estaban demasiado ocupados para preguntar)

Hola a todos. En la conferencia de líderes tecnológicos. Es un gran placer estar aquí y compartir algunas cosas que sé o he aprendido en mi career sobre dev rel.

Lo primero que voy a compartir es una pequeña historia o un ejercicio de reflexión. Básicamente, tenemos a dos personas, Sally y Ben. Una es una defensora del desarrollador, la otra es una gerente de ingeniería, y es tu trabajo identificar quién es quién. Entonces, el trabajo de Sally es mejorar la vida de los desarrolladores. Le encanta facilitarles la vida y hacer que los desarrolladores sean más productivos. Realmente encuentra alegría en ayudar a otros a hacer su mejor trabajo. Trabaja en un entorno realmente dinámico, donde ninguno de sus dos días es realmente igual. Así que tal vez el lunes, está hablando con varios ingenieros de plataforma e infraestructura de manera individual, obteniendo comentarios de ellos, aprendiendo sobre sus problemas, ayudándolos si puede. El martes, se supone que debe hacer una presentación para un grupo de interesados, para un gran grupo de personas. Y, se ve arrastrada a apagar incendios en su lugar. Básicamente, pospone lo que debía hacer el miércoles, como escribir una publicación de blog para la empresa. Así que eso obviamente se pospone, y el viernes no sabe dónde ha ido la semana, y no tiene oportunidad de aprender sobre las nuevas APIs que Amazon AWS acaba de lanzar o anunciar. Así que sí, esa es Sally. ¿Qué crees que es? ¿Defensora del desarrollador o gerente de ingeniería? Te ayudaré un poco, porque te diré qué hace Ben. Entonces, Ben es un defensor del desarrollador. Así que sí, si pensaste que Sally era una defensora del desarrollador, obviamente porque te atraje hacia esa dirección. Si sabías a dónde iba, felicidades para ti. Soy tan bueno construyendo suspense. De todos modos, escribí de esa manera a propósito, solo para hacerte pensar que nuestros trabajos, defensor del desarrollador aquí, líderes tecnológicos, gerentes allá, podrían ser muy similares. Y lo son. De eso trata esta charla.

Así que sí, hablando de trabajos, trabajo como defensor del desarrollador en CircleCI. Mi nombre es Zan o Zan como quieras pronunciarlo. Con sede en Londres. Y sí, me metí de lleno en las relaciones con desarrolladores, haciéndolo por dinero básicamente, hace unos seis años después de encontrar mi propia startup, ser desarrollador en una enterprise, ser desarrollador en otra startup y simplemente adquirir nuevas habilidades a medida que avanzaba. Así que cuando tenía mi startup, estaba haciendo mucho desarrollo de productos, estaba haciendo mucho manejo de interesados como se hace, todo el marketing, todo, realmente, porque las pequeñas startups, en fin. Cuando trabajaba en una corporación, estábamos pasando por esta especie de transformación digital, que es un buen momento para experimentar con cosas nuevas, porque estas organizaciones tienden a tener mucha capacidad para permitirte experimentar.

Sí, descubrí que había una clara falta de habilidades en los graduados que ingresaban a nuestro programa de graduados, así que comencé este programa de bootcamp para ellos, donde podían aprender en sesiones prácticas, talleres prácticos sobre cosas como git, dominio de la línea de comandos como Bash y cosas de POSIX, desarrollo guiado por pruebas, etc.

También recluté a varios ingenieros senior de la empresa para que vinieran y ayudaran, y también comencé a escribir blogs y a hablar en eventos, meetups y conferencias en Europa y el Reino Unido, y un par de años después, cuando trabajaba en una startup en el espacio de herramientas para desarrolladores, tuvimos una vacante para defensores o evangelistas de desarrolladores, y lo acepté, y fue una transición muy, muy fácil.

También descubrí algo, que los ingenieros que me conocían como ingeniero anteriormente, ellos interactuaban conmigo de una manera completamente diferente. Me veían como uno de sus pares, mientras que los ingenieros y líderes de ingeniería que llegaron después de que me trasladé a las relaciones con desarrolladores, no me veían exactamente como un par, y tuve que demostrar mucho más mi valía ante ellos. Y esa es parte de la razón por la que estoy dando esta charla hoy, para darte esta idea de por qué y cómo debes confiar en tus equipos de DevRel, ellos son tus pares, y sí, cómo puedes colaborar mejor con ellos.

Entonces, con DevRel, al igual que con todo, se trata de las personas que tienes en la audiencia. ¿Cuál es la audiencia de tu empresa? ¿A quién se dirige tu empresa? ¿Podría ser que tu empresa se dirige a los desarrolladores? En mi caso, trabajo para CircleCI, somos una plataforma de CI/CD. Nuestros clientes, nuestros usuarios son todos desarrolladores, desde ingenieros de plataforma hasta ingenieros de infraestructura hasta ingenieros de desarrollo y equipos de desarrollo. Todos son desarrolladores, todos son técnicos. Y es muy obvio ver que, obviamente, personas como yo que traen comentarios, traen ideas de la comunidad de desarrolladores de vuelta a la empresa, tienden a ser escuchadas con frecuencia, y así es como DevRel realmente comenzó en este tipo de empresas. Luego tienes diferentes tipos de empresas que son como desarrolladores adyacentes o desarrolladores plus, donde pueden tener un aspecto, como una API o un SDK que proporcionan a sus clientes que no necesariamente son desarrolladores, pero los desarrolladores pueden usarlo para integrarse con sus herramientas, sus productos, y demás para ampliar su funcionalidad, y ese es el objetivo del equipo de relaciones con desarrolladores. Es como una porción mucho más pequeña de todo el pastel. El último grupo de empresas, probablemente el más grande de todos, por cierto, son empresas que realmente no trabajan con desarrolladores externos porque solo tienen equipos internos y realmente no venden productos para desarrolladores. No tienen una API que consideren un producto, pero aún pueden tener cientos, si no miles de desarrolladores propios. Pero necesitan mejorar sus habilidades, necesitan mantenerse actualizados con las últimas tecnologías, y ahí es donde entran las relaciones con desarrolladores, asegurándose de que todos estén en la misma página y todos puedan contribuir al máximo de sus capacidades. Ahí es donde estamos con la audiencia, pero también podemos ver DevRel desde donde estamos dentro de la empresa. Podemos estar en muchos departamentos diferentes, desde marketing, ingeniería de productos, menos ventas solo porque los incentivos son un poco diferentes con las ventas y sus objetivos de venta en comparación con nuestros objetivos de involucrar a las comunidades de desarrolladores de una manera más auténtica.

Yo, personalmente, trabajo en marketing, así que voy a comenzar con esto. Esta es una de nuestras cabinas en uno de nuestros eventos, lo que hacemos es construir la marca. Creamos conciencia. Estamos en la cabina, hablamos con las personas que vienen a conocernos, aprendemos qué tipo de herramientas utilizan, etc. También doy charlas, también doy talleres, participo en podcasts, escribo publicaciones de blog, escribo tutoriales, etc. Muchas cosas están orientadas a la adquisición de usuarios, la participación de usuarios, llevar comentarios de las comunidades de vuelta a nuestros equipos, desde nuestro equipo de marketing.

Por ejemplo, hay una nueva tecnología sobre la que necesitamos escribir, hay una nueva forma de pensar que necesitamos adoptar, o incluso toda la organización realmente. También somos un terreno de prueba para ideas en el equipo de marketing. Alguien puede venir y decir, oye, tengo esta idea. ¿Crees que funcionará? Y decir, sí. Podrías hacerlo aún mejor si lo redactas de manera ligeramente diferente, lo abordas mejor, te conectas mejor con tu audiencia, ese tipo de cosas que podemos hacer porque estamos trabajando en cosas de ingeniería en el equipo de marketing. Así que estamos más cerca de ellos.

El producto es bastante obvio. Quieres asegurarte de que lo que llega a los usuarios sea lo mejor para los propios usuarios. Así que ayudamos con la ideación rápida y la obtención de comentarios. Ya sea prototipando nosotros mismos, yendo a los propios usuarios, demostrando cosas y obteniendo esos comentarios para actuar de inmediato, ese tipo de cosas a través de la investigación de usuarios, a través de entrevistas, etc. Eso podría ser gestión de productos. Nuevamente, muchos documentos, mucho contenido, probablemente se escribirá. Y ese es el hilo común aquí, que es el contenido. Y con contenido no me refiero solo a lo escrito, puede ser videos, charlas, podcasts, muchas formas de crear contenido.

Y luego tenemos la ingeniería. Obviamente, habrá algo de desarrollo involucrado, puede haber algún desarrollo involucrado, como tener una API que alguien necesita mantener, alguien necesita escribir para ejecutar la comunidad de GitHub de código abierto que tenemos, administrar a todos los colaboradores, ese tipo de cosas que ocurren dentro de la ingeniería. También hay contratación de personal, obviamente quieres que alguien hable con las audiencias en varios eventos, etc., y actúe como enlace. Y eso es lo que a veces hacen las personas de DevRel. En algunos casos, no muy a menudo, no muchas veces, pero de todos modos, hemos establecido que DevRel es muchas cosas para muchas empresas, muchas personas diferentes. Las técnicas cambian, los enfoques cambian, las tácticas, las estrategias, cambian, pero el objetivo principal es el mismo, estamos allí para actuar como enlace entre las comunidades de desarrolladores, presentamos la empresa a las comunidades de desarrolladores, presentamos las comunidades de desarrolladores a la empresa, y sí, trabajamos en un horario muy agitado, no hay dos días iguales, necesitamos priorizar sin piedad, tenemos que lidiar con un montón de partes interesadas, y sí, en realidad suena como liderazgo tecnológico, para ser honesto, volviendo a mi historia original, siempre hay muchas cosas, pero también lo es la ingeniería, y especialmente el liderazgo en ingeniería, estás trabajando en este horario extraño, las personas son mucho más importantes que los resultados técnicos puros, y sí, somos dos caras de la misma moneda, se podría decir. Ese es el único gif que tenía, por cierto. De todos modos, veamos ejemplos. En esta parte de la charla, voy a hablar sobre algunas áreas en las que podrías colaborar con DevRel, donde podrías obtener el máximo valor de nosotros, y viceversa, donde podrías proporcionar el mayor valor al equipo de DevRel. Así que sí, pongámonos técnicos, porque créeme, somos técnicos.

No todos somos ingenieros. Personalmente, tengo formación en ingeniería. Muchos defensores de desarrolladores también tienen formación en ingeniería, pero muchos otros no. Y eso está completamente bien, porque nuestro trabajo es esencialmente poder tener una conversación técnica con las personas, pero no necesitamos escribir código a diario.

Entonces sí, somos técnicos. Puedo tener una conversación sobre cualquier tecnología que desees. También puedo ayudarte a simplificarla para una audiencia ligeramente menos técnica o un poco más técnica o una audiencia diferente. De todos modos, eso es en lo que somos realmente buenos. Y sí, también podrías decir que estamos construyendo puentes. Así que construyendo puentes entre áreas.

Por ejemplo, tú estás en ingeniería, yo estoy en marketing. Quieres saber cómo funcionan las cosas. Quieres cambiar algo en el sitio web que viste, puedo ponerte en contacto con la persona correcta. O quieres que alguien escriba una publicación de blog sobre una tecnología, tal vez para contratar personal. Puedo ponerte en contacto con la persona adecuada o puedo ayudarte a escribirla. Eso está completamente bien. Eso es lo que hacemos al construir puentes. También obviamente el puente de la community. Quieres saber lo que la gente realmente está diciendo sobre tu producto. Quieres saber de qué están hablando en las calles, en los pasillos de las conferencias o en las salas de reuniones de los grupos de usuarios o como quieras llamarlo. Podemos proporcionarte eso porque estamos ahí fuera.

También podemos probar las cosas por nosotros mismos. Si tienes una versión previa de una API que estás construyendo o un producto que estamos construyendo, con gusto lo probaremos primero, te daremos algunos comentarios, te diremos: `Oye, tu documentación tiene algunas cosas que faltan aquí, algunas cosas allá`. Estas cosas están mal, estas cosas están desactualizadas. Porque obviamente, si las detectamos antes que la community, no tenemos que lidiar con ello. Así que sí, se trata de obtener esa retroalimentación de las calles y de las personas que realmente lo usan. Y no solo a nivel de base, sino también a nivel de la industria. Podemos proporcionarte retroalimentación sobre las nuevas tendencias que estamos viendo en la industria. Eso es lo que hacemos en marketing, por ejemplo. Si decimos: `Oh, la ingeniería de plataformas ha sido una tendencia en los últimos dos o tres años`.

Ha estado creciendo constantemente. Tal vez podríamos hablar de ello. Podríamos ver cómo estamos abordando a esta audiencia. Y para ti, tal vez sea como, oh, hay nuevas API de IA que salen a diario. ¿Podríamos usarlas de alguna manera? Tal vez investiguemos un poco. Veamos. Hagamos algo. Te digo, antes de que algo llegue a este nivel de conocimiento público, como las herramientas de IA hoy en día, ha habido personas escribiendo publicaciones de blog, dando charlas en conferencias sobre ellas durante uno o dos años. Y eso es constantemente una tendencia.

Y por último, podemos ayudarte a elevar el perfil de tu equipo. Tu perfil personal, como ingeniero o líder, o el de tu equipo. Por ejemplo, si quieres contratar más personas, quieres que tu cara se vea, ¿verdad? Ya sea hablando en una reunión, presentando una charla en una conferencia o escribiendo una publicación de blog, podemos ayudarte a editarlo, podemos ayudarte a destilar la idea para que se lea mejor. Podemos ayudarte a participar en un podcast, por ejemplo, porque probablemente tengamos colegas haciendo algo similar. Podemos ayudarte a escribir resúmenes para conferencias, reuniones, etc. Así que todo tipo de cosas para que tú y tu equipo se den a conocer mejor. Y siendo honesto, si alguien está dando una charla en nuestro nombre como organización, estás haciendo mi trabajo. Y te estaré agradecido por ello. Si necesito asistir a algunas pruebas y leer algunos resúmenes, sí, aceptaré gustosamente ese intercambio.

En resumen, hemos establecido lo que realmente es DevRel, al menos para mí y para algunas organizaciones diferentes. Es muchas cosas, hacemos un montón de cosas. De todos modos, tenemos varios enfoques. Pero nuestro objetivo esencialmente es hacer que los ingenieros y desarrolladores tengan éxito, exactamente como el liderazgo en ingeniería. Un equipo exitoso, un equipo más productivo, tú eres más exitoso. Así que en eso somos prácticamente iguales, en alineación. Y hemos establecido algunas formas y medios para establecer la colaboración. Y eso es todo lo que tengo tiempo por el momento. Pero te invito a que me hagas más preguntas en la sesión de preguntas y respuestas. Estaré en el chat durante media hora más o menos. Muchas gracias. Espero que lo hayas disfrutado. Que tengas un buen día. Y espero escuchar algunas preguntas.