Estos días he leído el libro DevRel, recientemente publicado en https://www.amazon.es/DevRel-Puzzle-Esos-detalles-cuentan/dp/B0BW2KJMTQ/ref=cm_cr_arp_d_pb_opt?ie=UTF8
La verdad es que la simple existencia del libro y su lectura me ha hecho plantearme mi propia visión sobre el tema, ya que muchas veces no sabes siquiera lo que piensas sobre algo hasta que no haces un esfuerzo consciente.
Paso a destacar las ideas que he marcado doblando hojas:
- DevRel puede no ser solamente un perfil sino un equipo.
- Normalmente no se distingue entre fama, popularidad, notoriedad y relevancia.
- Muchas personas hacen gratis una función de relación con la comunidad pero luego pasan a cobrar por ello por lo que tienen que tomar autoconciencia.
- Hay distintos términos relacionados debajo de Developer Relations: developer evangelist, developer advocate, developer experience…
- Ante la demanda tan importante de perfiles de desarrollo, el ritmo de incorporación de nuevas personas con poca o nula experiencia es mayor que el ritmo al que los desarrolladores ganan experiencia. Por eso nos encontramos con los mensajes “las empresas no encuentran talento”. Se multiplican los contenidos no diferenciados para perfiles de entrada.
- Habla de la confusión entre marca persona y reputación.
- Describe la función de producción que mide la relación entre el comportamiento individual y los resultados grupales obtenidos.
- Describe desincentivos por parte de los participantes en una red (como stackOverflow) donde nuevos usuarios crean contenido de baja calidad (help vampires, noobs, reputation seekers) haciendo que bajen los usuarios expertos que buscan calidad (care taker) debilitando el valor de la red.
- Hay comunidades que nacen con fines activistas y usan la tecnología como un medio y no como un fin. La posición de activistas minoritarios puede hacer que se perciban erróneamente como mayoritarios. Estos activistas suelen provocar miedo a expresar opiniones por posible rechazo de gente con visibilidad (me recuerda a la comunidad ágil).
- Los resultados de los DevRel son a medio/largo plazo y los de las empresas/startups y fondos a corto. Como muchas organizaciones están financiadas por capital riesgo pueden hacer grandes inversiones en eventos y comunidades en un plazo muy corto y defraudarse por no alcanzar resultados a corto (KPIs mal enfocados).
- Se pueden crear fácilmente problemas de “agencia” donde los intereses de DevRel y la empresa sean diferentes.
- Las últimas semanas he estado escuchando, como parece que también ha hecho Jorge, los podcast Kaizen, Polímatas y Heavy Mental (Recuenco y amigos). Estos podcast hablan de un conjunto de conceptos que ha integrado: la falacia de McNamara, la ley de Conway, la ley de Goodhart, efecto Dunning-Kruger, efecto anclaje, efecto de verdad ilusoria, referencias a Taleb, efecto Cobra, el libro Good Strategy Bad Strategy…
Bueno, todas estas ideas y a donde te llevan ya hacen que merezca la pena leer el libro y dan para pensar un rato.
A nivel global tengo que decir que el libro me ha parecido “que se moja muy poco”. Lo advierte el autor varias veces diciendo que no cree en recetas y que cada uno tiene que encontrar su camino. Me hubiera gustado que el libro respondiera (aunque fuera entre lineas) a algunas preguntas aunque fuera con opciones.
¿Cómo explico a mis jefes que es un DevRel?
¿Cómo justifico mi aportación en este perfíl?
¿Por dónde empiezo si quiero seguir este camino? ¿A quién puedo seguir que lo esté haciendo bien?
¿Estrategias en base al tipo de DevRel que creo ser?
¿Uso de redes sociales y herramientas de comunidad?
¿Errores comunes?
A mí me gustan las recetas aunque sean simplemente inspiraciones.
Tampoco entiendo que el autor no ponga vectores a sus redes sociales ni cuente un poco su vida ¿el libro no forma parte de una estrategia global?
Bueno, como digo siempre, ni tengo que llevar razón ni nadie me tiene que hacer caso por lo que os recomiendo leer el libro y obtener un criterio propio 🙂
