La triste realidad de los eventos técnicos: el no-show

Desde hace unos años observo una tendencia en los eventos técnicos a los que asisto o los que colaboro a organizar. Esta tendencia es la creciente ausencia no notificada, o el temido no-show.

Se considera no-show cuando una persona registrada para un evento no asiste, sin cancelar su entrada. También es no-show cuando la persona avisa el mismo día o el día anterior, ya que deja muy poco márgen para poder reutilizar la entrada a reajustar la logística.

Un no-show individual no es un problema. Todo el mundo tiene alguna cosa que le surge en el último momento. El problema es cuando el no-show es masivo, como lo que le pasó a Luís Fraile no hace mucho.

Te voy a poner un ejemplo: si esperas 100 personas en un evento, siempre cuentas con un porcentaje de no-show de digamos 20%. Entonces, dejas que se apunten 120 contando que al final irán 100. Compras comida para 100, pides merchanidising para los 100, buscas un sitio para los 100…ya me entiendes. Al final vienen 20. De 120. Te sobran tres cuartos de todo. Los patrocinadores con cara de circunstancias. Y tú, con cara de tonto…

Evidencia empírica (y subjetiva) de los últimos eventos en los que estuve colaborando

  • SharePoint Saturday Barcelona 2017: creo recordar que se apuntaron 180 y vinieron 130. No-show: <30%. No está mal (y toco madera)
  • SharePoint Saturday Madrid 2018: apuntados 300. asistieron 270. No-show de 10%. ¡Para tirar cohetes!
  • Azure Bootcamp 2018 Barcelona: apuntados 150, asistieron 70. No-show de >50%
  • Insider Dev Tour 2018 Barcelona: apuntados 220, asistieron 70. No show de >65%. Suerte que pudimos llevar la comida sobrante a un comedor social.

Salvo los eventos de SharePoint, y creo que es porque la comunidad de SharePoint es especialmente cohesionada, los eventos técnicos acusan una tendencia a la alza de no-shows.

¿Por qué pasa esto? Causas del no-show

¡Ojalá lo supiera! Según he podido hablar con otros compañeros y compañeras en la comunidad, hay varios posibles factores en juego:

  • La fecha o el día de la semana el evento va mal a la gente
    • Pero entonces, ¿por qué se apuntan si les va mal?
  • El formato del evento ya no atrae
    • Hay un debate sobre si los eventos presenciales siguen teniendo validez hoy en día o si se tiene que reinventar el evento en un formato más virtual
    • Pero entoces, ¿por qué se apuntan?
  • La gente no valora lo que es gratis
    • Pero hay eventos gratuitos en los que esto no pasa
  • Cuesta poco apuntarse y no hay consecuencias por no asistir
    • Aquí estoy de acuerdo, pero no sé que proponer como alternativa

¿Se os ocurren más ideas sobre las posibles causas?

¿Qué podemos hacer para prevenir el no-show?

Si lo supiera…montaría una startup vendiendo la solución. De lo que he escuchado en la comunidad, hay dos posibles alternativas:

  • Poner un precio simbólico al evento (tipo 5-10 euros) para que no sea gratis
    • A Microsoft le funcionó bastante bien para la DotNetSpain hace unos años
    • Pero
      • Ya es una barrera para asistir, aunque sea más psicológica que real
      • Hay eventos que por la licencia de marca (como los “____ Saturdays”) que obligan a que el evento sea gratuito
      • Obliga a los organizadores a tener registro fiscal (que es un dolor de cabeza y sumidero de tiempo) y obligaciones con Hacienda
  • Llevar un registro de los no-shows pasados y poner un “baneo” a la persona reincidente
    • No me parece mal y sé que hay grupos de usuarios en Europa y EEUU que lo usan con éxito
    • Pero no sería una solución a corto plazo. Además, con el tema de GDPR esto de guardar los datos de los asistentes pasados es más peliagudo.

Hasta aquí mi granito de arena. Estoy esperando ver el debate sobre estas y otras propuestas.

 

How to Create a Graph Schema Extension using Graph Explorer

I’ve been doing a lot of SPFx, NET Core and Office 365 related development and I have several stories to share.

During the implementation of one of the features in a custom API application, I had to create a schema extension in Microsoft Graph for a Group object, for the purposes of classification. As I stumbled upon a non-intuitive behaviour of the API in Graph Explorer, I hope to save you a couple of hours if you have to do the same.

I went to the extensive Graph documentation to see how to perform such a call to MS Graph. It didn’t seem particularly difficult, just a POST with JSON data on the schemaExtensions endpoint.

In Graph Explorer application that I was using, I kept getting “Request denied due to insufficient permissions”. I double and triple-checked that my Graph Explorer indeed had the needed permissions (Directory.AccessAsUser.All). No matter what I did, I kept getting the same error.

In the end, it seemed to be a limitation on Graph Explorer client. To overcome it, Microsoft added a workaround:

  • Register another Web / API application in Azure Active Directory
  • Add the required permissions to create schema extension to that application
  • In Graph Explorer, prepare a POST request to schemaExtensions endpoint
  • Add “owner” property in the JSON payload, with the value of the authorized application App ID
  • Voilà! The schema extension is created.

My schema creation request JSON payload was like this:

 

 

Back to Blog

It has been more than a year that I have written on this site.

I could bring all kind of excuses. The newly found paternity has taken a toll on my writing time. (By the way, my son is over a year now! The time really flies…)

Edin with Quim at children playground

Also, I changed jobs. I joined isolutions, a Swiss Microsoft partner company that’s specialized in Office 365, SharePoint, Azure and Dynamics CRM. I have found again the joy of building solutions with carefully crafted code.

After a long hiatus, I also started to speak on events again. I was speaking at European Collaboration Summit (hats down to Adis, Matthias and Toni) and soon will be speaking at TUGA IT in Lisbon. The preparations for SharePoint Saturday Barcelona are also underway.

Finally, I have a string of posts to publish regularly again on my newly found blog. Happy reading!

 

 

SharePoint Lookup Field Throttling Causes Missing Fields in CSOM Query

A very annoying bug appeared few weeks ago in one of our production environments with SharePoint 2013.

SYMPTOMS

You have a custom list with some lookup columns that refer to other lists. In our case the main list contained news and the lookup columns contained the classification of the news.

You add a new lookup column to the list, due to customer feedback.

Suddenly, you can’t get the list results any more by code. When you do a CSOM query, the lookup fields are lost. Only the non-lookup fields are retrieved.

CAUSE

SharePoint throttling also includes list item maximum lookup references. It is set to eight (8) lookup fields per list, by default.

Resource Throttling

This particular configuration is set on the web application throttling page in Central Administration, under the heading “List View Lookup Threshold”.

SOLUTION

If you don’t need all of the lookups at the same time, you can still make the query by choosing the fields you want to retrieve. However, in our case we needed all of the classification columns.

In this case you have two choices:

  • Increase the list lookup threshold limit to more than 8 (that’s what we did)
  • Establish a large query window, an interval during the day during which you can perform the queries

De buenos propósitos cara al 2017

Tenía la intención de escribir un post resumen del año 2016, pero los posts de los compañeros como Marc Rubiño o Yeray han tenido que ver en el contenido y enfoque del mismo. Más que un mero resumen, es además una carta de propósitos.

Mirando el 2016 en retrospectiva

Para mí, este pasado 2016 ha sido un año muy satisfactorio personal y profesionalmente.

He participado en varios eventos internacionales de SharePoint y Office 365, sobre todo en las comunidades técnicas portuguesa y belga, que conozco muy bien desde hace años y siempre me hace especial ilusión. Participé en el MVP Summit en Redmond, para poder aportar mi granito de arena a que Microsoft saque mejores productos para sus clientes, que son los nuestros también. Dentro de SUG.CAT, el grupo de usuarios de SharePoint de Catalunya, he impulsado el segundo SharePoint Saturday Barcelona (que salió mejor que el primero, así que algo habremos aprendido por el camino) y he colaborado en la organización del SharePoint Saturday Madrid.

New Year

Escribí un curso de Reactive Extensions en Pluralsight, que siempre es una experiencia gratificante.

Junto con otros compañeros en Sogeti, participé en una candidatura “atípica” de representación sindical (siendo no afiliados a ningún sindicato). Ganamos en Barcelona y nos pusimos a mejorar aquellas cosas que veíamos necesarias, democratizando la representación de los trabajadores y buscando ideas que ayuden a que Sogeti sea un buen sitio tanto para la empresa como para la plantilla.

En Sogeti he podido impulsar algunas medidas de cambio, tanto tecnológicas como culturales. No son muchas, ya que hacer cambios en una empresa tan grande es más lento, pero me dan la satisfacción de poder pensar en otras más ambiciosas. He hecho de mentor de otros compañeros con excelentes capacidades técnicas pero poco recorrido en el mundo de la comunidad técnica. Incluso he tenido que hacer algún que otro “chantaje” para poder sacar a la palestra aquellas personas que creo que se merecen explicar sus experiencias y de las que todos podemos aprender.

Inner circles y demás “bestias”

Le robo el título a Yeray Smile espero que no le importe.

Es precisamente en este aspecto de hacer el esfuerzo a sacar nuevos talentos en la comunidad donde empecé a notar cierta resistencia por una parte de la comunidad de los ponentes establecidos. Para que nos entendamos, con “ponentes establecidos” me refiero a la gente de la talla de Yeray, de Marc, de Eduard, de Lluís, por poner un ejemplo.

El hecho es que algunos de los ponentes establecidos no creen que tengamos que hacer nada para que se vaya renovando el cartel de los ponentes en la comunidad. Sostienen que la gente buena ya se abrirá el camino, lo que es yo también creo, y que no hay que hacer nada especial que no estemos haciendo ya. Aquí es donde discrepo. En mi opinión, podemos hacer mucho más y lo iré explicando en otros posts.

Nota para navegantes: el cacareado y malentendido “inner circle” para mí es la comunidad de los ponentes establecidos, dentro de los cuales me incluyo.

La misma opinión sale a relucir en los comentarios respecto a la falta de diversidad en los eventos tecnológicos. Todavía somos una minoría los que pensamos que este es un problema grave. La gran mayoría de la comunidad ya está cómoda con que la audiencia y el cartel de speakers sean hombres blancos mayoritariamente “frikis”. Yo he decidido luchar por cambiar esta situación. ¿Utópico? Puede que sí. Por mi parte prefiero compartir la misma utopía con gente como Jon Skeet y hacer acciones tangibles para no participar en la perpetuación de la falta de diversidad como para participar en la búsqueda de maneras de inclusión de voces minoritarias en el debate técnico general.

Igual que los “development evangelists” que se dedican a convencer a su público sobre la necesidad del cambio (tecnológico), yo me dedico a convencer a mi público en la comunidad sobre las cosas que tenemos que cambiar. No voy a pedir perdón por ello.

MVPs, las empresas y las comunidades

Entrando de lleno al espinoso tema de los MVPs (de los que formo parte) y de la relación de empresas con la comunidad, voy a exponer mi opinión.

El programa MVP de Microsoft tiene su parte positiva y su parte negativa. La positiva la conocemos: ayuda en la marca personal, el prestigio del profesional (y por extensión de la empresa en la que está), la comunidad de otros MVPs y la interacción con el equipo de producto. Ah, ¡y la suscripción MSDN complementaria, por supuesto!

La parte negativa: la opacidad en el proceso de selección es quizás la más importante. Donde falta luz siempre se forman cuentos, leyendas y fábulas sobre quién está “en el bombo”, con qué criterios y con qué “padrinos”. También cada MVP es un mundo y los hay que siguen siendo los mismos tipos alegres y accesibles de siempre y los hay que se endiosan y se piensan que están más allá del bien y del mal. La riqueza humana es lo que tiene.

Las empresas que tienen en su nómina a un MVP o varios, tienen un activo de branding y de marketing muy útil para vender de cara a los clientes y los futuros empleados. No hay nada de malo en ello. Lo malo es poner objetivos de ser MVP, ya que estaríamos pervirtiendo el modelo, tal como bien expone Yeray en su post.

Y si soy una empresa, ¿cómo podría colaborar con la comunidad? Yo creo que hay muchos modelos de colaboración posibles: patrocinio de las comunidades locales donde esté ubicada la empresa, liberar partes de su código como open-source, la cesión de espacios para charlas (que siempre nos faltan en los grupos de usuarios), dejar tiempo a sus empleados a que asistan a los eventos durante las horas de trabajo (que hay pocas empresas que lo hacen). Para mí esto es ayudar a la comunidad como empresa.

Otro mundo aparte son los eventos comerciales donde se cobra entrada y el organizador de turno decide sobre quién habla y quién no. Allí cada empresa es libre de patrocinar lo que le parezca adecuado en términos de beneficio esperado. Y cada ponente es libre de aceptar los términos o no.

Organizando los eventos como los SharePoint Saturday de Madrid y Barcelona sí que me he encontrado con situaciones en las que un patrocinador suponía que su patrocinio incluye un charla. Mi opinión es que hay sitio para charlas de patrocinadores, debidamente separadas de las charlas de la comunidad (como p.ej. poniéndolas en una hora dedicada o durante la hora de comer).

De cara al 2017

Vale, ya he dicho lo que quería decir sobre la comunidad y los temas candentes. Ahora voy a explicar lo que serán mis propósitos de este año 2017.

Igual que Marc Rubiño, continuaré siendo selectivo con los eventos en los que me involucro. Me centraré en aquellos que son realmente para la comunidad y que cuentan con medidas para tener asistentes y ponentes diversos.

Seguiré creando espacios para otras personas: montar eventos, ayudar a comunidades y mentorizando a las personas valiosas que pueden aportar su voz al debate.

Seguiré buscando ideas de mejora personal y profesional, compartiéndolas con todo el mundo que esté interesado en mejorar.

Y, finalmente, dedicaré el máximo tiempo a mi prioridad número 1: mi mujer Vanessa y nuestro/a futuro/a niño/a que está en camino.

Programar para SharePoint hoy (I): el legado

En esta serie de posts intentaré hacer un resumen de las posibles opciones que tiene un desarrollador (o desarrolladora) para programar una aplicación que tenga que comunicarse de algún modo con SharePoint, en cualquiera de sus variantes.

<ModoAbueloCebolleta>
En los tiempos en los que los dinosaurios vagaban por la Tierra, el ser humano vivía en cuevas y SharePoint era novedad todavía, para programar tenías dos opciones. Cada nueva versión de SharePoint traía algún modo nuevo, así que hoy en día tenemos bastante elección y a veces se hace difícil saber que enfoque es el mejor para una situación dada. Por favor…que viejo me siento contando batallas. ¡Que alguien me sacrifiqueeeee!
</ModoAbueloCebolleta>

El legado

Desde que SharePoint corre sobre .NET Framework (es decir desde su versión 2003), hay dos métodos de desarrollo que están todavía presentes sin muchos cambios. Son el “full-trust code” (FTC) y los servicios web SOAP (o ASMX).

Legacy rusty chain and padlock

Full-Trust Code o SSOM (Server-Side Object Model)

Full-Trust Code o SSOM es el modelo de programación de SharePoint donde nuestro código se ejecuta dentro de los procesos de SharePoint (IIS y/o servicios Windows), como una parte adicional al propio código de Microsoft, para lo bueno (la velocidad) y lo malo (hundir el rendimiento de SharePoint mismo).

Este es el modelo “clásico” de los programadores SharePoint “de los de antes”. Si eres uno de ellos, tengo una mala noticia y otra buena.

La mala es que este modelo es cada vez menos relevante en los desarrollos de SharePoint. Así que si tu idea de especialización era focalizarte en código de SharePoint y te memorizabas las listas de los objetos que empiezan por SP*, tendrás que reciclarte, ¡y pronto!

La noticia buena es que FTC no desaparecerá. Siempre habrá alguna funcionalidad que es necesaria para los desarrollos de SharePoint on-premises, y no habrá otra solución tan elegante y eficiente que el código de SharePoint en el mismo servidor de SharePoint. Vaya..que saber SSOM será el equivalente de programadores COBOL en el siglo XXI.

Las limitaciones serias de este modelo son tener que desplegar en los servidores de SharePoint (y dar ataques al corazón a los administradores de sistemas cuando les explicas que necesitas un Visual Studio en el servidor), usar autenticación implícita (tu código se ejecutará con los permisos del usuario actual) y que no es compatible de ninguna manera con SharePoint Online de Office 365.

Los servicios web SOAP

Evidentemente, alguien siempre ha tenido la necesidad de integrar SharePoint con otros sistemas (¿qué otros sistemas hay? diría algún SharePointero “de los de antes”). En los tiempos en los que nació SharePoint, eso significaba usar el lenguaje universal de la web: los servicios web SOAP (o ASMX, por la extensión del fichero ASP.NET en los que se programan).

SharePoint incluye una capa de servicios web SOAP, accesibles a cualquier plataforma que sepa hacer una llamada SOAP (y que pueda autenticar el usuario correctamente, claro está). Las operaciones que expone son bastante de bajo nivel, y con muchos parámetros obligatorios, y para muestra sólo hay que mirar la documentación de los estándares. Hablando en claro, son prehistóricas.

Hoy en día han quedado bastante en desuso ya que el modelo de REST API los hace casi obsoletos. Sin embargo, es posible que todavía haya cosas que se pueden hacer con los servicios web y con la API REST no, así que es posible (pero no probable) que tengas que recurrir a ellos.

En el siguiente post expondré las opciones modernas de desarrollo con SharePoint.

Las mujeres, la informática, la diversidad….

Después de “liarla” un poco parda este verano con las opiniones incómodas sobre la diversidad en la comunidad técnica y el “círculo interno” de ponentes MVP en las conferencias, vuelvo a estar en el ojo del huracán del Twitter. Y no sólo Twitter, hasta el gran @noradrex me menciona en su blog.

Woman in Tech

¿La razón? Mi comentario en Twitter el viernes pasado después de ver la agenda de Codemotion, donde las mujeres representan sólo un 7% de los ponentes. Me sorprendió que en un evento organizado por un grupo tan diverso saliera una agenda tan poco diversa. Este comentario derivó en una batalla dialéctica via Twitter y otros medios. Después de que haya pasado el fragor de la discusión, voy a poner algunas opiniones mías por escrito para que no haya malentendidos.

Primero: la organización de Codemotion no tiene la culpa. Después de leer sobre su proceso de selección y las iniciativas que han hecho, está claro que el resultado es un síntoma de una situación de todo el sector. Supongo que si ellos no hubieran hecho nada, la agenda estaría aún más desequilibrada.

Segundo: tenemos una seria falta de diversidad en las actividades visibles de las comunidades técnicas. No sólo la crónica falta de visibilidad de las mujeres técnicas, sino también de minorías o LGBT.

Tercero: hay un desconocimiento del problema, de su dimensión, sus causas y sus síntomas. Por ejemplo: no es lo mismo diversidad que igualdad. Pero para la mayoría, me atrevería a decir que lo ignoran por completo. El concepto de sesgo inconsciente es una interesante lectura y a unos cuantos les puede abrir los ojos. Otro problema intrínsecamente ligado con la falta de diversidad es el micromachismo latente, del que no se libra ni el gran Uncle Bob.

Cuarto: las causas de esta situación son diversas y complejas, y no admiten soluciones simplistas. En el debate de Twitter había mensajes del tipo “…que propongan ellas…”. No es tan sencillo porque es un tema estructural y que los cambios son muy lentos. De nada sirve hacer un evento diverso un día y olvidarnos el resto del año.

Quinto: por lo que a mí me toca, seguiré aportando mi granito de arena. Rechazaré ir a los eventos en los que no se empuja por la diversidad. Seguiré invitando a más ponentes de sectores demográficos menos representados, para que aporten su charla y su voz a la comunidad. Me esforzaré para que los eventos que esté organizando sean lo más inclusivos posible. En SharePoint Saturday Barcelona de este año he conseguido que casi un cuarto de ponentes sean mujeres, más de acuerdo con la media del sector.

¿Qué hacemos con todo esto?

Para los que quieran profundizar sobre como hacer una comunidad técnica más diversa, hay mucho escrito en Internet. Aunque algunos temas son más representativos de un país subdesarrollado socialmente como EEUU, la mayoría de los consejos son igualmente aplicables aquí en España. Os dejo unos cuantos ejemplos:

Y tú, estimado lector,  ¿qué opinas? Deja un comentario si quieres aportar tu voz a esta conversación.

 

 

 

 

SharePoint Saturday Barcelona 2016

Después de organizar el primer SharePoint Saturday Barcelona el año pasado, y colaborar en la organización del SharePoint Saturday Madrid este año, los miembros de SUG.CAT volvemos a la carga con el segundo SharePoint Saturday en Barcelona. Se ve que esto de masoquismo organización de eventos nos va.

SPSBCN logo

Este año el SPS Barcelona se hará el sábado día 1 de octubre y volvemos a contar con Institut Químic de Sarrià para el espacio del evento.

¿Qué es un SharePoint Saturday?

Los SharePoint Saturday (o SPS) son eventos tipo conferencia, gratuitos y celebrados siempre en un sábado. Suelen tener varios “tracks” en paralelo y ponentes de gran nivel, con preferencia para los ponentes locales y personas destacadas en la comunidad que lo organiza.

SPSBCN 2015

¿Os he dicho que es totalmente gratuito? Hay conferencias de SharePoint con una agenda como la de SharePoint Saturday y que cobran entradas de 200-300 €.

¿Por qué debería asistir?

Depende de tu rol.

Si eres un técnico, administrador o desarrollador de SharePoint/Office 365 lo deberías tener claro: para aprender de otros compañeros, compartir historias e ideas y socializar.

Si eres un jefe de proyecto o de unidad de SharePoint, puedes ver lo que se ha hecho en otros sitios y coger ideas.

Si eres un usuario de SharePoint, principiante o avanzado, seguro que habrá sesiones en las que aprenderás que más se puede hacer. También tendrás un sitio donde preguntar tus dudas y aprender.

Si estás buscando gente de SharePoint/Office 365 para tu empresa o tu cliente, estás de suerte: todos los que te interesa van a estar allí.

¡No te lo pienses tanto y apúntate ya! Te esperamos el día 1 de octubre.

¿Qué hemos aprendido del año pasado?

La ventaja de haber pasado por el primer SharePoint Saturday el año pasado es que ya tenemos experiencia y sabemos que esperar. Este año hemos hecho una serie de mejoras:

  • Evitar que coincida con un partido del Barça o con un megapuente de vacaciones
  • Mejorar la logística para los sponsors
  • Reservar un espacio en la agenda para invitar a ponentes que no se suelen ver en eventos, para mejorar la representatividad y diversidad

Eso sí, seguro que este año volveremos a hacer algunas cosas mal (sin intención, claro), para mejorarlas el año que viene.

Más detalles sobre el evento

Playing with NDepend

Few days ago I used NDepend tool to analyze the code of one of our bigger projects in Sogeti. Here are my thoughts on the tool.

NDepend is a static dependency analyzer tool. It scans your compiled code, the PDBs and the source code and produces a “map” of your code dependencies, metrics and structures. It has been around for several years now, and it has kept beeing better in every new edition.

The default view of NDepend is the so-called “Report” that highlights all the potential issues with your code. It gives you a trove of information to optimize your code, in a HTML format that’s easy to share. The report contains the summary of all the main features of the tool: rule violations, dependency cycles, complex code and so on.

NDepend Report

The next feature that I used is the dependency visualization. There are two “flavours” to it: the dependency graph and the dependency matrix.

The dependency graph is easy to grasp but it can only be meaningfully used with a handful of classes and namespaces. It quickly becomes a mess with more than a couple of dozen objects.

NDepend Dependency Graph

The dependency matrix is a much more powerful tool. It can be used to spot dependency cycles, infrastructure classes, “god” classes, cohesion and coupling and so on. However, it’s not as intuitive to analyze as the graph, it takes some time playing with it to grasp the information without consulting the help windows.

NDepend Dependency Matrix

NDepend has a full set of code complexity and maintainibility rules. It can quickly highlight the most important issues so that you can concentrate on fixing the most critical parts of your code.

NDepend Code Rules

But it’s just the surface of it. NDepend has a full-blown language called CQLinq, akin to SQL, that allows you to query your code. You can find classes that have high coupling, methods that are too complex, nested structures in the code and a myriad of other code patterns.

NDepend CQLinq

In my opinion, NDepend is an invaluable tool if you’re concerned about your code quality (and you should be). It takes some time to grasp and master all the power of it, as it can be an overwhelming experience for a first-time user, but it’s a time well invested.

Thanks to Patrick Smacchia (the main force behind NDepend) for the NDepend license for MVPs, that allowed me to fully evaluate the tool.

 

The “Inner Circle” syndrome and MVP Program

After an overwhelming response to my last week post about the lack of diversity and inclusion in the technical communities, I wanted to speak about a specific diversity problem in more detail.

This problem is the “inner circle” syndrome.

As I mentioned in the previous post:

Even in the Spanish community, I’ve been mostly involved with the people I know well, mainly the Spanish MVPs and user group leaders. We know each other as we always hang around the same events, and thus unintentionally we create an “inner circle” in the community that makes it difficult for new people to come inside. It’s not that there aren’t any new community members, but it’s more of a mental barrier of always having “the usual suspects”. I have heard several comments lately from bright technical people that don’t submit to events because “there are always the same guys” speaking there.

The “syndrome” is the feeling or an opinion, backed by some evidence, that in technical communities there is a small core of people who share a disproportionally large amount of the “spotlight”, this being sessions in technical events, articles, publications. I have received many, many comments of technically proficient people that don’t bother to propose a talk because “it’s always going to be the same people chosen for the sessions“.

Let’s go deep into the problem, shall we?

It’s a small community

The technical communities are usually led by a small group of people, who are motivated enough to invest their time and efforts into providing value for the rest of the members of the community. By its own nature, this is something altruistic and we can’t expect everyone to be a community leader. So, the number of the people actively leading a community is low and there’s no problem with that.

pasta-composition-1-1543750-639x958

At the same moment, the fact of being a leader in a technical community also shapes another community of sorts: the community of community leaders. I suspect that there is a natural disposition to mingle with those who are like us. It’s not a problem, per se. I benefit from interacting with other community leaders, for example, sharing strategies and tips on how to have a more successful community or how to drive attendance and awareness for our events. That’s the good part.

The bad part is that, if left unchecked, it’s easy to mistake the community of our peers (community leaders) for the community at large. It can lead to the “inner circle” syndrome if we do nothing to include checks and balances against it.

How you get accepted to speak at events?

If there’s one measure of the public perception of an “expert” in a technical community, that’s speaking at technical events. Those people are usually recognized or taken by the rest of the technical audience as the ones who excel on something in their respective domain of knowledge.

However, there are many more people knowledgeable about something than speakers at the events. It’s a matter of combining several characteristics:

  1. Being knowledgeable about something
  2. Having sufficient skill (and bravery) to speak in public
  3. Being aware of an event where your contribution can be welcome
  4. Actually submitting a proposal to talk at the event
  5. Having been accepted to speak at the event

In a 100% meritocratic world, this would be a pure number’s game. However, in the real world there are unseen obstacles to this straightforward process.

Once you fulfill the condition 1, you have to acquire skills about speaking in public. Many people don’t come forward at this step, as public speaking is something very stressful for mostly an introvert population. (Introversion is highly correlated with abstract thinking capacity we need to understand computers, so our technical communities are necessarily skewed to the introvert half of the population).

Let’s say you have the skills to speak. How do you become aware of a prospective event (the condition number 3)? In many cases, it’s a random thing. Usually, you read it on Twitter or a technical blog you follow. The “inner circle” members have an advantage here, because if you are already in the community “inner circle”, chances are that you already know about the event either because it’s organized by your peers or because somebody mentions in the conversation.

The condition number 4 requires you to choose a topic and craft a cohesive and appealing proposal for your talk. You need some marketing advice in order to find that what’s unique about your talk and you have to “sell” it to the event decision board. This is another skill in which the most of the technical audience are not well-versed.

Finally, the last barrier is getting accepted to speak. If you have a good proposal, your chances are better. But the sad truth is that if you are part of the “inner circle”, your chances are SO much greater. Sad but true.

Why is that?

The people choosing your talk are probably the people who are your acquaintances or friends. It’s a small community we are talking about, and we mostly know each other. When you have a talk from someone you know (and trust) as opposed to a talk by someone you haven’t heard of, then it’s just natural to lend more credibility to your friends. It’s our human nature. And it’s detrimental to our community diversity.

Also, the number of speaking slots is usually always much less than the number of prospective speakers. Due to this pressure, the selection board tries to “stick to the well-known” and minimize the risk.

We have to tread carefully not to close the doors on the any prospective contribution, and the fact of not being “known” in the community is such a huge handicap. The mere fact of having someone in the “inner circle” to rely on and to ask for advice is the most frequent way I’ve seen for the people to become speakers. I’ve done it, a couple of times. But, that’s not the way I’d want it to be in the future.

The trouble with MVP program in the technical community

And here I explicitly mention the Microsoft MVP (Most Valuable Professional) program as a factor in this imbalance of speaking sessions. I’m a current MVP, and I speak out of the knowledge of how things are run in our local community (Spain and Europe).

MVP Logo

The MVP program is an award (not a certification, not an entitlement) for past year contributions (posts, articles, speaking sessions, open-source contributions etc) in the technical community that aligns with one or more Microsoft products or technologies. It’s awarded every year.

That’s the good part.

However, MVPs represent only a portion of the valuable community leaders and contributors (I suppose that’s why it’s called “Most Valued” though). For starters, there is a limited number of MVPs per category and per region. The evaluation criteria are opaque (even though you can nominate yourself or other people) and there is no formula that let’s you know if or why you are accepted or rejected as an MVP. If I’d change one thing in the MVP program, I’d make the criteria and the nomination process more transparent. I don’t think that it should be totally objective (because it could be gamed), but I’d like to see the explanations about the selection results for each MVP. Until then, the rest of the community can only take educated guesses and fuel rumours about how the whole process works. More transparency will bring more accountability to the program, in my opinion.

Additionally, the MVP Award in the Microsoft technical community is almost a guarantee that you are in the “inner circle”. Your sessions proposals are going to weigh more in the event selection boards, you are going to be in contact with other MVPs and you’ll be aware of more community engagements. However, now you have a vested interest to keep being an MVP so you will submit to those events, knowing that your MVP status makes it easier to keep it. It’s much more easier to keep your MVP status than to get one. It’s not that the entry barrier is high (which is true) but the fact that the advantage the renewing MVPs have over you is so much greater.

Don’t get me wrong. I think that MVP program is very valuable, both to the community and to Microsoft, but it’s easy to misrepresent it and to mistake the MVP community for “the whole community”. You’re going to think of the fellow MVPs as your “inner circle” in the community and you’re going to reap the benefits. It’s not fair, but it’s real.

Ok, how should we fix it?

I wish I knew!

Notwitstanding that, I can suggest some possible actions.

First and foremost, the community leaders should be less of a rock star and more of a servant leader. It means serving the community and getting out of the way of others. You don’t brag about you, you don’t abuse the advantage you have as a community leader by grabbing more spotlight. You consciously move out of the spotlight to let the others be illuminated.

Our role as the community leaders is more to the people that are still outside the community than it is to the people already inside. We should focus on expanding the numbers and diversity of the community, not our own numbers.

Don't be a rock star

We can also help the prospective new members. As leaders, we are exposed to potential valuable contributors more than the average community member. We should act as a benevolent gatekeeper that brings people in instead of letting them out. The feeling of “not being one of us” that trickles down in the technical community, is a very strong barrier to entry. I don’t think that it’s something we do on purpose, but it has a real effect. We should be aware of it and correct for it. How?

  • Mentor other community members that show potential value
  • Teach soft skills such as public speaking, personal branding and community engagement, not only technical stuff
  • Spread the word about potential speaking and engagement opportunities. Make a goal to bring in one new speaker for every event in your expertise domain. Help them writing their proposal and help them with the session preparation if you can.
  • Make the proposal selection a blind process. Strip the biography from the submission and let a board of peers rank the proposals for their merit, not for the speaker.
  • Be conscious about your unfair advantage as a community leader. Concentrate your contributions to non-competitive channels (your own blog, GitHub, magazines and selected events) and resist the urge to cover all possible outlets. Don’t be a rock star! If you really have something to tell, help organize your own event 😉
  • If you are organizing an event, reserve a sizable portion of the agenda for first-time speakers and traditionally underrepresented communities. Don’t let the “same old faces” steal the show. Even if it feels lowering the quality of the agenda, it’s the other way round. You are strengthening it.

Microsoft can also do a lot about fixing the “inner circle” syndrome:

  • Make the MVP nomination process more transparent and accountable. Not everyone who applies should be an MVP, but we really need more transparency around the process to make the “inner circle” dissappear. Explain why someone is awarded and someone else is not.
  • Reserve slots for first-time speakers and underrepresented communities at your events

I’m really looking forward for comments on this issue. Am I being right? Wrong? Misled? Please use the form below to contribute to the discussion.