No todo el mundo sabe o debe dar feedback

El pasado 23-24 de noviembre del 2018 tuve la suerte de disfrutar de un evento tecnológico llamado  Commit Conf. Una nueva conferencia por y para desarrolladores con nuevo front, pero con el mismo backend que sus orígenes, Codemotion. La organización decidió no seguir con el contrato de marca de Codemotion y ahora han hecho su propia conferencia.

9 tracks, 2 tracks de talleres, escaparates, networking. ¡Todo excepcional!

Desde hace varios años, la herramienta que utilizan para gestionar las entradas, charlas, panel, permite dar feedback. Algo muy importante para aprender, mejorar, perfeccionar o darse cuenta si se ha entendido bien lo que uno quería decir. ¿Genial no? ¡Es todo un lujo!

Comentario en una charla begginer

Charla mal estructurada, muy básica y que no deja conceptos claros

Fuente: Agenda commit conf

Detrás de cada charla hay una preparación, que puede ser mejor o peor, pero la hay. Hay insomnio el día de antes, nervios el mismo día y nervios después.

Una vez dada la charla, te das cuenta que hay cosas que al final no has dicho, cosas que has metido la pata por decir mucho, te has quedado con esa persona que no paraba de mirar el móvil o esa otra que se ha quedado dormida. Es decir, dispones de un pack de autofeedback para rayarse suficientemente un buen rato.

No estuvo bien explicada. Muy lioso todo

Fuente: Agenda commit conf

¿Y quien es el ponente? ¿Quién es el ponente medio de la commit?

Lo que hace que sea una conferencia excepcional es que son charlas reales de gente real que se ha pegado con las cosas que enseña. ¡Tiene un valor incalculable! Esa persona te va a contar lo bueno y lo malo de una herramienta. Esa persona no te va a vender.

Creo que ha faltado trabajo a nivel general tanto en el tema a presentar como en la elocución. No obstante, os animo a trabajarla por el titulo es atratictivo, un tema de moda y que lo presenteis dos perfiles tan diferentes son un gran base.

Fuente: Agenda commit conf

El ponente medio tiene perfil genérico de desarrollador o desarrolladora de software. Esa persona será un crack en hacer su trabajo. No obstante, eso no implica que disponga las mejores dotes comunicadoras del mundo o ser mega experto en lo que habla o ser dioses: son personas. El ponente (medio) invierte más de 5 días enteros en hacer, preparar y ensayar su charla. Si además implica crear un nuevo proyecto en github o hacer un piloto, puede ser el doble de tiempo.

Normalmente no conocemos a la persona que vamos a dar feedback. No sabemos cuánta experiencia tiene, cómo están sus nervios, cómo se lo va a tomar, cómo le va a afectar o cómo le va a ayudar lo que diga. No sabemos si ha tenido un buen o mal día o si tiene algún problema personal que le atormenta.

¿Cómo se comporta la organización con la persona? Esta persona no cobra y no gana dinero por dar la charla de 45 min. Con suerte, le pagan el viaje y alojamiento.

Para dar un buen feedback es importante:

  • Primero: agradecer el esfuerzo por la charla.
  • Segundo: resaltar algo positivo de ella.  Seguro que algo cumple.
    • Cómo se mueve en el escenario
    • Las manos
    • Las anécdotas que cuenta
    • El contexto inicial
    • El resumen final que dan ganas de dejarlo todo y hacer lo que dice
    • El diseño de las slides
    • El contenido que mete para argumentar a lo que quiere llegar.
    • La amenidad.
    • La historia de la charla.
    • La habilidad de empatizar y conectar con el público
    • Aquella feature o historia que no sabías
    • Comentar algo que vayas a hacer después de la charla.
  • Tercero: decir cómo mejorarías un aspecto
  • Último: volver a dar las gracias o decir una frase buena que motive.

Dar un mal feedback es muy fácil:

  • Primero: asistir a la charla
  • Segundo: cabrearse porque no es lo esperado y dudabas entre esa y otra charla
  • Tercero: decir lo que no te ha gustado sin rodeos. A poder ser, con cuenta anónima.
  • Cuarto: asumir cosas que no ha hecho al preparar la charla. “no ha hecho guión”, “se nota que no ha ensayado”, “es obvio que no ha preparado nada”. Sobretodo poner un no.
  • Quinto: si además dices algo faltoso o hiriente gana puntos.
  • Sexto: Utilizas esa tónica destructiva en todos.

Aquí me pregunto:

  • ¿Te leíste la descripción y el nivel de la charla?
  • ¿Pensaste en cómo podría afectarle a la persona tus palabras?
  • ¿Pensaste en lo que había preparado para dar su charla?

Me quedé con mal sabor de boca. Los ponentes se pisaban al hablar, los chistes no engancharon. Para mi gusto demasiado cliché. Se salvaron los últimos minutos cuando se habló de la evolución de la arquitectura. Os ánimo a que le deis una vuelta. Suerte!

Fuente: Agenda commit conf

Lo que parece que la gente no es consciente es de las consecuencias de un mal feedback:

  • No volver a dar una charla nunca más
  • No volver a compartir nada en ningún medio.
  • Síndrome del impostor nivel 5 de 5.

Y vamos a más:

  • Ansiedad
  • Depresión.
  • Frustración

Va más allá de charla “beginner”, un soporífero conjunto de obviedades

Fuente: Agenda commit conf

No creo que haya que decir que todo es magnífico porque entonces no aprendes. Creo que hay formas y formas de dar feedback. Si un feedback es bien dado el efecto es muy bueno. De hecho un buen feedback es un regalo de un experto para mejorar.

Otra forma de dar feedback es acercándote después de la charla al ponente y si tras preguntarle si quiere recibir feedback, comentarle tus opiniones. La cara y reacciones de la persona te ayudarán a redirigir mejor tu discurso. Tienes que entender que hay muchas veces que el ponente no quiere recibir feedback, ya sea porque ya lo ha recibido por su círculo de confianza o porque tus sensaciones (malas) post-charla le han generado una gran inseguridad. ‏

Otra forma de dar feedback es hacer una pregunta de algo que no te hayas enterado. Ahí el ponente te está resolviendo una duda y además está percibiendo que su discurso no se ha enterado bien.

En caso que la forma de dar feedback sea escrito, voy a dar unos ejemplos de transformación de feedback sacados de ejemplos reales.

Ejemplo 1:

Charla mal estructurada, muy básica y que no deja conceptos claros

Gracias por compartir, has hecho un repaso por los conceptos básicos que viene muy bien para un begginer como está catalogada esta charla. Estaría genial que antes de explicar los contextos pusieras un contexto o un ejemplo real para seguir un hilo de historia. ¡Muchas gracias!

Fuente: Agenda commit conf

Ejemplo 2:

No estuvo bien explicada. Muy lioso todo

Gracias por compartir. Está genial el formado live coding. Me quedé con estas dudas, ¿cómo puedo hacer un evento? ¿cómo bla blabla? Desde mi punto de vista, como remate para el 5 sería hacer un resumen final para revisar los conceptos que dijiste durante la charla. ¡Me pondré a trastear con tus consejos!

Fuente: Agenda commit conf

Ejemplo 3:

Charla muy básica y bastante desafortunada. Me ha dado la sensación de que estaba sin preparar.

Fuente: Agenda commit conf

Gracias por compartir. La charla ha tenido toques de humor que la ha hecho amena. En mis charlas suelo hacer un ensayo con mi propio equipo para que me ayude a mejorar. ¡Os lo recomiendo! Gracias

Ejemplo 4:

La presentación no estaba trabajada. Ni siquiera se veía bien el ppt. Debería estar mejor preparada

Fuente: Agenda commit conf

Gracias por compartir. Normalmente el tipo de aula de ese escenario es proyector, por lo tanto de normal hace difícil leer las slides. En estos casos lo que hago es o poner dos slides en vez de una o en vez de código hago un esquema para que al menos se entiendan los conceptos.  ¡La siguiente lo petáis!

Ejemplo 5:

Muy densa y con un tono muy lineal. Contenido interesante

Fuente: Agenda commit conf

Gracias! El contenido muy interesante. Se nota que el ponente domina la materia porque ha metido mucho contenido. Para la próxima charla recomiendo algo menos de contenido con algún ejemplo, seguro que estarás más cómodo! Por último está genial hacer cambios de voz para engancharnos más aún! Muy bien!!

Ojalá entre todos creemos una cultura social que evitemos el sufrimiento con nuestros comentarios ofensivos y destructivos. Lamentablemente, ahora la solución la veo lejos de una sociedad educada. Por lo tanto, desde mi punto de vista, la solución recaería en la organización del evento y cómo quiere hacer llegar el feedback al ponente.

Cuando algo tan importante y de tanto valor como es el feedback, es un privilegio para todo el mundo, tenemos un problema. 

En Stack Overflow no puedes puntuar un comentario si no tienes x puntos. Se llama Gamificación. El una herramienta de feedback podría ser similar . No todo el mundo sabe dar feedback por lo tanto no debería todo el mundo dar feedback.

Alguien que ya haya dado charla en una conferencia sería un buen punto de partida. Creo que vivir el duro proceso te aporta de unos conocimientos para poder compartir con el resto de ponentes.

Sí, este año también he tenido muy malas críticas. Cosa que no les voy a quitar la razón, se podría haber hecho mucho mejor. Gracias a las veces que se podría haber hecho mejor, he ido aprendiendo y mejorando, hasta llegar a una charla que por fin estoy orgullosa.

Por suerte todos estos años he contado con mis amigos/amigas que han estado a mi lado para no darme más mal del necesario. He aprendido a saber leer lo que esté bien comunicado e ignorar el resto. También he aprendido a no leer ningún comentario (como me ha pasado en Xataka). Todo ello hace que mantenga las ganas de seguir haciendo lo que me gusta.

Me pregunto cuánta gente se habrá quedado por el camino porque no tenía a esos amiguis. Cuánta gente habrá tirado la toalla. Cuanta gente ya pasa de dar charlas por la frustración innecesaria que genera.

Quería dar mi opinión personal y seguro que es diferente a la tuya. Al menos, todos deberíamos darle una vuelta a esto: cuando damos nuestra opinión a un ponente, youtuber, tuitero, instagramer, detrás hay una persona que piensa, siente y sufre.   

Si te gusta comparte, si quieres dar tu opinión, espero tus comentarios. Gracias

** Los comentarios han sido tomados de la web pública de commit conf.

** Se ha omitido el nombre de la fuente por respeto y evitar bulling hacia ellos.

** Si alguien considera una falta que no aparezca su nombre en su comentario, me lo comunique por comentario para cambiarlo.