Las relaciones con los desarrolladores son cada vez más importantes, pero eso no significa que deba crear a ciegas su equipo para que parezca Google o Microsoft.
Lo que los desarrolladores necesitan saber para tener éxito en el futuro del desarrollo de tecnología empresarial de pila completa puede no ser el mejor camino para los desarrolladores. Jeffrey Hammond, de Forrester Research, explica por qué la especialización puede hacer que los desarrolladores sean más valiosos para su organización.
Usted puede ser perdonado por su precipitación loca en la contratación de un experto en relaciones con desarrolladores (DevRel. Después de todo, el software se está comiendo el mundo, los desarrolladores son los nuevos fabricantes, etc. etc. etc. Usted necesita que los desarrolladores construyan sobre su plataforma, y los necesita AHORA MISMO.
Pero, antes de sumergirse en las relaciones con los desarrolladores, podría valer la pena considerar con qué tipo de desarrollador necesita relacionarse y cómo hacerlo. Aunque el gobernador de Redmonk, James, tiene razón al alabar la racha de contratación de Microsoft de gente de DevRel para Azure, eso no significa que usted tenga que hacer lo mismo. No todos los desarrolladores y, por lo tanto, no todos los DevRel, son creados iguales.
Mientras tanto, en Kansas….
Este fue el mensaje que entregué en el reciente DevXcon en San Francisco. Sentado en las otras sesiones, me sentí un poco fuera de lugar, a pesar del hecho de que manejo las actividades del ecosistema de desarrolladores para un gran proveedor de software. No estoy interesado en reunir a millones de desarrolladores de front-end para construir widgets. Tampoco quiero hacer reuniones disfrazadas de hogueras repletas de malvaviscos y todo el mundo contento.
Esas son probablemente grandes ideas para diferentes compañías, con diferentes comunidades potenciales. Pero para mí (y probablemente para ti, si somos francos), estos no son los «droides que estás buscando».
VER: Descripción del puesto: Desarrollador de pilas completas (Tech Pro Research)
Después de todo, no eres GitHub. O Microsoft. O Google. O (inserte básicamente cualquier nombre de cualquier empresa tecnológica importante. Usted es (inserte el nombre de su empresa), y sus necesidades son diferentes a las de otras empresas.
Es un poco como el consejo de la analista de Gartner Svetlana Sicular a los CIOs frenéticos para contratar a científicos de datos: «Las organizaciones ya tienen gente que conoce sus propios datos mejor que los científicos místicos.» El truco es capacitar a estos candidatos internos con las herramientas para que asuman la ciencia de los datos.
O, en el caso de los desarrolladores, asumir las relaciones con los desarrolladores.
Su kilometraje puede variar
La definición general de un defensor del desarrollador es probablemente similar a la ilustración de Chris Aniszczyk, ejecutivo de la Cloud Native Computing Foundation: Alguien involucrado en «hablar en público, hacer demostraciones y la cuidadosa delicadeza de caminar en la línea entre la representación de su empresa y los desarrolladores que busca».
Lo que encontré para mi equipo, sin embargo, fue que el papel de defensor puede ser tanto interno como externo. Tal persona no necesita ser un candidato para la próxima conferencia principal de CES, pero debe ser capaz de trabajar en estrecha colaboración con diferentes equipos de productos para ayudarles a tener una mentalidad más orientada al desarrollo.
O simplemente escuchar, tanto a los desarrolladores internos como externos.
Lo que está de moda en ConsejoTecnologico.com
El primer paso es determinar a quiénes incluye su comunidad de desarrolladores. Según las estimaciones de SlashData, hay aproximadamente 13 millones de desarrolladores, pero eso no significa que haya 13 millones de desarrolladores interesados en su empresa/producto. Mientras que algunas empresas necesitan absolutamente desarrolladores aleatorios sentados en sus garajes para escribir aplicaciones que se ejecuten en sus plataformas, es probable que eso no describa su necesidad. En mi caso, nuestra principal audiencia de desarrolladores está empleada por integradores de sistemas u otros proveedores de software. No necesitan fogatas. Necesitan APIs, documentación, casos de uso y código de ejemplo para poder empezar a cumplir con las necesidades de los clientes.
Sin embargo, esto sólo se aprende si se les escucha.
Por ejemplo, cuando asumí mi papel en la gestión de nuestro ecosistema de desarrolladores, asumí que lo que se necesitaba eran más activos de desarrolladores (APIs, documentación, etc… Esta era una laguna, pero la prioridad de primer orden era en realidad arreglar el proceso de aprovisionamiento y autenticación para que un desarrollador externo pudiera empezar a trabajar con las API que proporcionamos sin problemas.
En cuanto a las necesidades internas, fue bueno que pudiera decirles a los equipos de productos que pusieran toda su documentación en un repositorio central, pero fue mejor saber que la razón por la que no lo hacían era que el sistema que teníamos en funcionamiento era demasiado engorroso.
En mi mundo, los defensores de los desarrolladores son menos útiles por su destreza en el escenario y más útiles por su capacidad para hablar con nuestra comunidad de desarrolladores, dentro y fuera de la empresa, y traducir esas conversaciones en una mejor «higiene». Esto no se refiere a los hábitos de baño, sino más bien a la calidad de los activos y procesos disponibles para los desarrolladores.
Por lo tanto, antes de contratar a un líder de DevRel en el molde de Kelsey Hightower (una barra muy alta de hecho), primero entienda la comunidad que espera tener. Puede ser que el candidato ideal se siente en el cubículo de al lado.
Boletín Semanal de Código Abierto
No se pierda nuestros consejos, tutoriales y comentarios sobre el sistema operativo Linux y las aplicaciones de código abierto. Entregado los martes