Bis bald! Nos vemos en Berlín

Estábamos a punto de colaborar con una empresa alemana para distribuir un juego en aquel país. Gigames, la empresa para la que yo trabajaba en aquel 2007, ponía el juego y Bally Wulff, una empresa alemana con sede en Berlín, ponían la marca y los conocimientos del mercado alemán.

Como parte de ese proceso de colaboración, un compañero y yo tuvimos que viajar a Berlín durante cuatro días, en abril del 2007, para visitar sus oficinas y así poder obtener toda la información necesaria para saber qué adaptaciones hacer a nuestro juego. No estuvimos muchos días, ni tampoco dispusimos de mucho tiempo para visitar la ciudad, pero el poco que tuvimos fue suficiente para que Berlín me fascinase y me cautivase.

Si me preguntáis porqué aquel amor a primera vista con Berlín, no os sabría decir porqué, no tengo respuesta. Semanas después, el viaje se tornó y los de Berlín vinieron a visitarnos a nuestras oficinas en St. Cugat. Uno de los días tuve que llevar, en coche, a uno de ellos hasta Barcelona y me dijo: "hay dos tipos de ciudades, las que se visitan y las que se respiran. Berlín y Barcelona son de las del segundo grupo". Nunca he olvidado esa frase y en Amsterdam también la apliqué. Supongo que fue eso lo que me cautivó de Berlín.

Desde el preciso momento en que volví a casa no paré de decirle a mi mujer cómo me había fascinado Berlín y que teníamos que ir. No está tan lejos y una escapada de fin de semana era factible. No fue hasta tres años más tarde cuando, aprovechando que vivíamos en Haarlem, hicimos una escapada de cuatro días. Otros cuatro días que me sirvieron para reforzar mi fascinación por aquella ciudad. Sin saber ponerlo con palabras, Berlín era ya (junto con Amsterdam y Barcelona) una de mis ciudades favoritas.

Ahora, diez años más tarde de aquella primera visita a la ciudad de Berlín, estamos preparando nuestra mudanza. Nos vamos a vivir a Berlín. Ha surgido la posibilidad con mi actual empresa, King, de ir a trabajar al estudio que tenemos en la capital alemana y la he aceptado sin ningún tipo de duda. Diez años más tarde de haber pisado esa ciudad que tanto me cautivó podré vivir en primera persona esas sensaciones y poder comprobar si estaba en lo cierto. En una semanas nos vemos en Berlín. A partir del 1 de Mayo nos podéis encontrar allí.

Bis bald!

Creativity, Inc: A Master class in Leadership

Estábamos dando una vuelta por Valencia, donde fuimos unos días a visitar unos amigos, cuando mi buen amigo David Navarro (el Director Creativo) me recomendó leerme el libro del CEO de Pixar, Ed Catmull: Creativity, Inc.

"A mi me moló mucho. Explica la cultura de Pixar, cómo hacían para mantenerla y, sobre todo, cuando los compró Disney, cómo trabajaron para que no afectase la compra a su cultura. Tú que trabajas en King y ahora que os acaban de comprar seguro que te parecerá interesante", me dijo.

Así que le hice caso. Busqué el libro y lo leí.

Ed Catmull explica, en primera persona, su experiencia profesional, desde que era un estudiante de la Universidad de Utah, trabajar en la misma universidad en investigación de computación gráfica, hasta conseguir su sueño de que Pixar sea uno de los gigantes de la animación a nivel mundial y ser comprados por Disney.

Ahora soy yo quien os recomiendo este libro. No sólo por conocer, contado en primera persona, cómo fundar uno de los gigantes de la animación, si no en cómo, mientras nos explica todo su esfuerzo en montar una cultura de trabajo en Pixar, nos da una clase magistral en Liderazgo y fomento de la creatividad en el ámbito laboral.

Seguramente me haya olvidado alguna, seguramente que vosotros destacaríais otras, pero en este post he querido destacar alguna de las frases que me parecieron más importantes y destacables de su libro:

• Siempre contrata gente mejor y más inteligente que tú.

• Con todo el cuidado que pongas en el arte, la mejora visual normalmente no importa si no tienes la historia adecuada.

• Conseguir el equipo adecuado es el precursor necesario para conseguir las ideas correctas.

• La forma en la que un equipo interacciona entre sus miembros es la clave real, no qué talentosa es la gente.

• Conseguir la gente adecuada y la química adecuada es más importante que conseguir la idea correcta.

• Si das una buena idea a un equipo mediocre, la estropearán. Si das una idea mediocre a un equipo brillante, la mejorarán o la tirarán y vendrán con algo mejor.

• Refuerza tus ideas y mantras con hechos.

• La creatividad empieza en alguna parte, y somos verdaderos creyentes del poder del positivismo, feedback sincero y proceso iterativo.

• La gente necesita equivocarse lo más rápido posible. Fallar pronto y fallar rápido.

• Si no has experimentado el fallo, entonces estás haciendo un error mucho peor: Estás siendo dirigido por el deseo de evitarlo.

• Los errores no son un mal necesario. No son un mal en absoluto. Son una inevitable consecuencia de hacer algo nuevo.

• Hacer el proceso mejor, más fácil y más barato es una aspiración importante (...) pero no es el objetivo. Hacer algo grande es el objetivo.

• El calendario dirige el resultado, no la fuerza de las ideas.

• El cambio va a suceder, tanto te guste como no.

• En mi experiencia, la gente creativa descubre y alcanza sus visiones con el tiempo y a través del dedicado y prolongado esfuerzo.

• La creatividad es más como una maratón que como un sprint.

• Todo está cambiando. Continuamente. Y no puedes pararlo. Y tus intentos por pararlo te ponen en mal lugar. 

We were having a walk around Valencia, where we were visiting some friends, when my good friend David Navarro (the Creative Director) recommend me to read the book of the CEO of Pixar, Ed Catmull: Creativity, Inc.

"I liked a lot. It explains the Pixar culture, how they worked to keep it and, specially, when they got acquired by Disney, how they worked hard to not be affected by the acquisition. You work at King and, since you got acquired recently, you might find it interesting", he told me.

I did what he said. I looked for the book and read it.

Ed Catmull explains, in first person, his profesional experience, since he was an student in the University of Utah, his work in the same university in research of graphical computation, until he reached his dream of Pixar becoming one of the biggest animation companies worldwide and got acquired by Disney.

Now, I am who recommends the book. Not only to know, explained in first person, how to found one of the biggest company in the animation industry, but how while he explains all the hard work they did establishing a good culture in Pixar he gives us a master class in leadership and fostering the creativity in the workplace.

For sure, I forgot something, you see some others, but in this post I wanted to remark some of the sentences I found more interesting and remarkable from the book:

• Always hire people better and smarter than you.

• For all the care you put into artistry, visual polish frequently doesn't matter if you are getting the story right.

• Getting the right team is the necessary precursor to getting the ideas right.

• The way a team interact among the members is the real key, not how talented the people are.

• Getting the right people and right chemistry is more important than getting the right idea.

• If you give a good idea to a mediocre team, they will screw it up. If you give a mediocre idea to a brilliant team, they will either fix it or throw it away and come up with something better.

• Reinforce the ideas and mantras with facts.

• Creativity has to start somewhere, and we are true believers in the power of bracing, candid feedback and the iterative process.

• People need to be wrong as fast as they can. Fail early and fail fast.

• If you aren't experiencing failure, then you are making a far worse mistake: You are being driven by the desire to avoid it.

• Mistakes aren’t a necessary evil. They aren’t evil at all. They are an inevitable consequence of doing something new.

• Making the process better, easier and cheaper is an important aspiration (...) but it is not the goal. Making something great is the goal.

• The schedule drives the output, not the strength of the ideas.

• Change is going to happen, whether we like it or not.

• In my experience, creative people discover and realize their visions over the time and through dedicated, protracted struggle.

• Creativity is more like a marathon than a sprint.

• Everything is changing. All the time. And you can't stop it. And your attempts to stop it actually put you in bad place. 

Mob programming

Hace unos días leí un artículo que hablaba sobre Mob Programming, lo que atrajo mi atención ya que era la primera vez que leía algo sobre algo llamado así. ¿Y qué es eso? ¿Una nueva metodología? ¿Una nueva técnica?

Mob Programming es el hecho de que un grupo de programadores se sientan juntos, preferentemente en una habitación, con un único ordenador y un trozo de código. Así todo el grupo junto puede discutir, diseñar, programar un trozo de código del proyecto. Y, por lo tanto, todo el equipo está concentrado en solucionar el mismo problema. Sería algo así como el pair programming pero con más de dos personas involucradas.

A simple vista podría parecer que es una de las formas de trabajo más ineficientes. Todo el equipo trabajando sólo en una tarea, perdiendo su tiempo en sólo una cosa cuando podría estar trabajando en tareas diferentes (como de costumbre). Pero, por el contrario, es una forma muy útil y eficiente de trabajo. Naturalmente, usada con moderación.

En mi días trabajando en Papa Pear, solíamos usar esta técnica, aunque nosotros lo llamábamos PapaDojo (Papa de Papa Pear y Dojo por los Coding Dojos). Solíamos hacerlo una vez por semana, todo el equipo de desarrolladores en una sala de reuniones, un único ordenador y un único problema a discutir. Unos cuantos días antes se escogía un tema, una persona lo preparaba y avisaba al resto del equipo, así la gente interesada podía decidir si asistir o no y prepararse el tema.

¿Qué tenía esto de interesante? Nuestra idea era, una vez por semana, todo el equipo compartía código y tecnologías que se usaban. Con varios objetivos: conseguir conocimiento compartido de las tareas que se estaban implementando, ser capaces de conocer otras tecnologías o lenguajes con los que no tratabas en tu día a día (IoC, C++, Action Script, Unit Testing,...), afrontar todos juntos un refactor de código importante,... Y, así, a largo plazo conseguir beneficios como: todo el equipo tener conocimiento (en profundidad o superficial) de todo el proyecto (no sólo de la parte en la que cada uno estaba trabajando), todas las tecnologías y lenguajes usados en el proyecto (facilitando el cross-development de nuevas implementaciones), afrontar un refactor/mejora importante de código que podría ser grande para sólo una persona,... y, naturalmente, team building.

No pienses que Mob Programming es algo ineficiente ya que, a largo plazo, es una técnica que ofrece grandes beneficios tanto para el equipo como para el proyecto.

A few days ago I read this article regarding Mob Programming (sorry, it's in spanish) which get my interest because it was the first time I read about a thing with that name. What was that about? A new methodology? a new technique?

Mob Programming is the fact that a group of programmers sit all together, preferably in a room, with only one computer, with only one piece of code. All the group can discuss, can design, can program a piece of code of the project. Therefore, everybody is completely focused in solving the same problem. Something like pair programming but with more than two people involved.

One first impression might be that it is one of the most inefficient ways of work. All the team working in the same task, wasting their times in only one thing while they could be working in different tasks (as usual). But, on the contrary, it's a very useful and efficient (in long term) way of work. Used with moderation, of course.

In my days in Papa Pear we used to use this thing but we called it PapaDojo (Papa for Papa Pear, and Dojo because of the Coding Dojos). We used to do it once a week, the whole developers team in a meeting room, one computer and only one problem to discuss. A few days in advance we picked one topic, one person prepared it, notify to the rest of the team so the people interested could decide to attend or not and prepare the topic.

And, why was this very interesting? Our idea was to, once a week, all the team shared the code and the technologies to use. The aims were multiple: reach share knowledge of the tasks being implemented, being able to know other technologies or languages you don't deal with in your daily basis (IoC, C++, Action Script, Unit Testing, ...), face all together an important refactor to do, ... And in a long term the benefits are multiple, as well: the team may have a knowledge (in deep or superficial) of all the project (not only the parts each one is working on), all the technologies and languages used in the project (easing the cross-development of features), face a refactor/improvement of code that for only one person can be huge,... and, of course, team building.

Don't think Mob Programming is inefficient, in long term will provide you lot of benefits for the team and the project.

Plus Plus

Los pasados 2 y 3 de Noviembre tuve la suerte de poder asistir (a través de King) a un curso de public speaking con Florian Mueck. Dos días muy intensos, dos días muy interesantes. Con dos carreras, dos Masters y algún que otro curso a mis espaldas, puedo decir que estos "sólo" dos días han sido el mejor curso que he tenido nunca hasta el momento.

Pero en este post mi intención no es hablar de lo gran motivador que es Florian y cómo consigue sacar lo mejor de tí y hacer que salgas de tu zona de confort. Ni cómo en dos días lo mucho que aprendí y cómo el segundo día era capaz de hacer cosas que 48 horas antes me parecía incapaz. O de cómo me hicieron esos días despertar dentro de mí algo que no sabía que tenía, que me gustaba esto del Public speaking. Si no que quiero hablar sobre una de las técnicas de motivación y aprendizaje que Florian usa para empujar a la gente a dar un paso adelante: ++

Cada vez que salíamos al "escenario" y hacíamos una presentación/charla, el grupo nos evaluaba. Florian escribía dos columnas, una con las cosas positivas que había hecho la persona y otra con las cosas que tenía que mejorar para dar un paso adelante (la columna ++). Algo tan simple, alto tan obvio, pero tan poco usado. En una sociedad donde predomina la crítica destructiva, las opiniones negativas, las opiniones que no llevan a nada y que no sirven para nada.

La crítica destructiva y/o negativa no sirve para nada. Si alguien dice lo mal que haces una cosa, lo más probable, es que la persona que recibe la crítica se lo pueda tomar como un ataque personal, le haga sentir mal y no seguir avanzando, ponga un muro y sea todo lo contrario a estar receptivo. Y, en el mejor de los casos, no serviría para nada porque es una crítica que no aporta nada a nadie.

La columna ++ no es más que una crítica constructiva. Se olvida de qué has hecho mal, de en qué te has equivocado, lo reenfoca y te dice qué tienes que hacer para mejorar algo. En el fondo puede parecer lo mismo, pero está enfocado desde un punto más positivo, de añadir, de ayudar, que no como algo negativo. Con la columna ++ se ayuda a la gente a mejorar y a progresar, por eso la gente es más receptiva a este tipo de críticas.

No es tan difícil aplicarlo, sólo hace falta un cambio de mentalidad y se puede aplicar tanto en el aspecto profesional, como en el personal. Y con ello, en vez de tener gente con miedo a probar y realizar cosas, lo que se consigue es gente que no sólo no tiene miedo, si no que tiene pautas para seguir mejorando.

Yo lo he vivido y experimentado, por eso tengo claro que a partir de ahora aplicaré mucho más a menudo la columna ++.

The last 2nd and 3rd of November I could attend (thanks to King) to a public speaking training with Florian Mueck. Two intensive but very interesting days. With two degrees, two Masters and several other courses behind me, I can say that these "only" two days have been the most interesting and exciting course I have ever had so far.

But, in this post, I had no intention to explain how good is Florian motivating people and getting out the best of you to get you out of your comfort zone. And neither how much I learned during those days and how the second day I was able to do things I couldn't imagine only 48 hours before. Or how I felt something starting to grow up inside me I didn't know, since I liked that thing called public speaking. What I want to talk is about the motivating and learning techniques Florian uses to push people to step forward and get out of the comfort zone: ++

Everytime we were on the stage and made a presentation/speech, the group evaluated us. Florian drew two columns on a board, one with all the good things the speecher did during the presentation and another one with all the things the person had to improve to step forward and keep improving the skills (the ++ column). So simple, so obvious but, at the same time, so few times used. In a society, like ours, where bad comments and destructive criticism, which are completely useless,  takes precedence over good and positive reviews.

Bad and negative criticism is totally useless. If someone points out how bad you are doing something, most likely, the person who receives the criticism may think is a personal attack, making that person feeling bad, and making her/him being anything but receptive. And, in the best of the cases, it wouldn't help at all because a bad criticism doesn't provide anything to the person who is receiving it.

The ++ column is a positive and good review. It doesn't take into account what you did wrong and it focuses on what you have to do to improve. In the end it can seem the same but it's more focused from the bright side, helping, adding, providing. With the ++ column you are helping people to progress and get better, that's why people are more receptive. And, apart from that, people improve and learn quite quicker.

But it's not that difficult to use, only a change of mindset is needed and it can be used either on the professional side and the personal. With that, people won't be afraid of trying and do new things. And not only that, people will have ways and paths to keep improving, learning and growing.

I've experienced it on my own, that's why I know that, from now on, I'll use much more often the ++ column.

Product Owners vs. Product Executors

Van a ser casi dos años desde que empecé a trabajar en King y en todo este tiempo he aprendido muchas cosas. Una de ellas ha sido poder experimentar otra forma de trabajar, de organizarse y de gestionar equipos. Parte, probablemente, facilitado por usar una metodología de trabajo agile, parte promovido por la filosofía de la empresa.

Hasta el momento, en todas las empresas que había trabajado, tenían una organización y métodos de trabajo clásicos. Con estructuras piramidales, donde hay jefes y donde los miembros de un equipo eran Product Executors. Es decir, miembros que se dedican a ejecutar órdenes en el desarrollo y evolución del producto, sólo ejecutan decisiones tomadas. El jefe o departamento de turno deciden el qué, el cuándo y el para cuándo y el equipo, en general, sólo tiene poder para decidir el cómo. Poco margen de decisión le puede quedar al equipo, más allá de cómo se desarrollará tecnológicamente el producto/proyecto (a veces ni eso)

Ahora, no es que tengamos jefes, que los tenemos. No es que no tengamos organigrama, que también lo tenemos. Y no es que nadie tome decisiones, que se toman. Pero el equipo tiene mucho peso en las decisiones y cada miembro del equipo de desarrollo es, en parte, también un Product Owner. El equipo tiene la figura de Product Owner que es el responsable de marcar la ruta de trabajo, de estudiar al cliente final, de conocer qué se quiere. Pero al final es el propio equipo quien decide qué se implementa (todo el mundo tiene la libertad de convocar reuniones para definir nuevas cosas), el cuándo se implementa algo (se hacen reuniones regulares donde el equipo planifica qué se hace y qué no), para cuándo estará cada cosa implementada (si el equipo decide que no estará para la fecha esperada se acepta la decisión del equipo o se negocia un menor alcance del producto) y el cómo.

Esto redunda en muchos beneficios para el equipo y, por consiguiente, para la empresa. Porque los miembros del equipo trabajan más motivados y sienten al producto como suyo propio. No son meros ejecutores de órdenes, si no que se involucran en las decisiones y, principalmente, se respeta cualquier decisión que sale desde el equipo. Los miembros están más implicados en el desarrollo y éxito del producto/proyecto.

Pero, obviamente, esto no es tan fácil de implementar. Para su éxito, se requiere una alta dosis de confianza de la empresa en el equipo, en su trabajo y en sus decisiones. Característica que no siempre (y, especialmente, en este país) se suele dar.

It's almost two years since I started working at King, and during all this time I've learned lot of things. One of them, being able to experience another way of working, organising and managing teams. Most likely, provided by using an agile methodology, but also promoted by the company culture.

All the companies I've worked for so far had a classic organisation and work methods. Pyramidal hierarchies, with typical bosses and where the team members were Product Executors. I mean, the members could only execute commands, already taken and agreed decisions. The boss or corresponding department decided the what, when, by when and, usually, the team could only decide how.

I don't mean we don't have bosses now, because we do have. I don't mean we don't have hierarchy, because we do have as well, or nobody takes decisions, because they are taken. But the team has too much to say when taking decisions and each team member is, kind of, a Product Owner. The role of Product Owner exists within the team, who is the person responsible of making the roadmap, study the final user, know what he/she wants. But, in the end, it's the own team who decides what is going to be implemented (everybody in the team has the freedom to organise meetings in order to specify and define new features), the when it's implemented (there are often meetings where the team plans what to do and what not to do), by when a feature is to be implemented (if the team decides that something can't happen for an expected date, the team decision is accepted or a smaller product scope is negotiated) and the how.

This results in many benefits for the team and, therefore, for the company. Because the team members will be working much more motivated and feeling the product as their own. They are not just command executors, but they are involved in the decision taking flow and, specially, any decision taken by them is respected. Resulting in a team totally get involved in the development and success of the product/project.

But, obviously, not everything is too easy to implement. For its success, this requires a high amount of trust from the company in the team, in its work and decisions. Something that usually (specially in Spain) doesn't happen.