Lo importante, realmente y sin ninguna opción, es participar

Mi amigo Vicente Orjales me pasó hace un tiempo, pensando claramente en mí (y no sé si tomarmelo bien o mal :) ) un enlace sobre la historia de los CalTech Beavers, el equipo de baloncesto de la Instituto Tecnológico de California, lugar donde han estudiado o trabajado premios Nobel y que es uno de los institutos tecnológicos más afamados.

Pero resulta que es una de esas "raras" universidades (bueno, no es verdad, pero para qué vamos a acabar con el mito :) ) que no ofrecen becas deportivas a sus alumnos. Eso significa que todos los alumnos que van al CalTech es ¡PORQUE QUIEREN ESTUDIAR UNA CARRERA TÉCNICA! Sorprendente. Y claro, eso significa que sus equipos deportivos son mucho más amateur de lo que vemos normalmente cuando vemos un partido Duke - Stanford en los partidos del Marzo Loco de las finales de la NCAA.

Pero tan amateur, que desde 1996 hasta 2007, el equipo no ganó ni un sólo partido en la División III de la NCAA. Ni uno sólo. Y ningún partido de la conferencia en la que participan desde 1986. Ni uno tampoco.

Pero el equipo se lo toma con humor: por ejemplo, tienen un cartel lleno de fórmulas matemáticas y un mensaje a sus adversarios: "podréis ganarnos en la cancha, pero ¿sois capaces de resolver esta ecuación?"

Nos hemos acostumbrado tanto a que los equipos universitarios americanos se consideren la cantera de la NBA, NFL y demás asociaciones profesionales en Estados Unidos, que se nos olvida que la mayoría de las universidades e institutos tecnológicos en Estados Unidos le dan la misma relevancia a los deportes que las universidades en España: un entretenimiento para los estudiantes que le dan más importancia a lo que estudian que a lo que hay alrededor.

P.D. En otro orden de cosas, esto me recuerda a una discusión que tuve con Eugene Shteyn en su blog sobre cómo un equipo "David" podría ganar a un "Goliath".


El don de Dilbert

Oh, las grandes desgracias que esperan al que es diferente... ;)

"Estoy preocupada por mi pequeño Dilbert, no es como los otros niños...
-¿Qué quiere decir?
-Ayer lo dejé solo un minuto y me desmontó la tele, el reloj y el estéreo...
-Es completamente normal, los niños suelen desmontar las cosas...
-Lo que me preocupa es que usó las piezas para construir una radioestación!!
-Oh no...
-¿Es grave?
-Normalmente, le haría una prueba de encefalograma, pero la máquina no funciona...
(Dilbert lo arregla)
¡¡Es peor de lo que me temía!!
-¿Qué pasa?
-...Me temo que su hijo tiene... "el don"
-¿El don?
-El don... Es un estado raro caracterizado por una intuición extrema para todas los sistemas mecánicos y eléctricos, y... Otras inaptitudes sociales...
-¿¿¿Podrá llevar una vida normal???
-No. Será... INGENIERO."

P.D. Gracias a Mari Cruz por el enlace!


Una fábula más sobre el divertido mundo de la consultoría

Mario López de Ávila carga contra el maravilloso mundo de las relaciones entre consultores y clientes, esta vez de una manera simpática aunque real como la vida misma. A partir de aquí, se me ocurren muchas historias y fábulas que describir, cambiando simplemente algunos nombres aquí y allá.

¿Por qué los consultores perciben que los clientes no hacen más que forzar la máquina, y los clientes perciben que los consultores no hacen más que quitarles su dinero sin un valor añadido claro?

Será que si fuera de otra manera, no habría nada interesante que contar a la salida del trabajo.


Las Múltiples Caras de un Ingeniero de Preventa. Parte 3

(continuamos con la tercera parte de este serial sobre Preventas. Ahora le toca el turno a describir la categoría de producto)

2.1 Product Category

The first step is, obviously, having sound technical skills, both from a development and from a systems standpoint. Whatever product one might be selling, it will surely have one or more dependencies with the operating system, hardware, virtual machines, or whatever. Being able to struggle with AIX, Solaris or HP-UX, or create some code around the middleware product is sometimes nice to have, sometimes critical to handle.

The second step is to master the product portfolio the company is selling. As discussed above, this ability does not mean to just understand it or do the basic things, but to act as the best possible customer we might have. This means being able to install, configure and deploy the product under several circumstances (it also means being able to explain everything in a clear way, but let's defer this discussion to another category). Mrs. SE needs to be in control when a customer asks some tricky question, some "what if?" by either solving it or by using its inner knowledge base to find out the solution in the best, in the most efficient way possible.

Figure 2. Product Skills

In big product companies, where Sales Engineers are specialized in one or two tools, it is expected that they have at least a "sales-level" knowledge of the complete product portfolio, so they can detect opportunities when working with customers.

But, as you could expect, knowing about the product is not enough. A middleware product interacts with a variety of tools and standards and other products in an enterprise ecosystem. Knowing which tools there are for each related product category and being able to explain the best way all of them can interact to solve the problem of the customer is surely one of the main paths to success from a technical standpoint. A Sales Engineer has sometimes been defined as an Enterprise Architect with a sales approach, and this is one of the areas where both roles relate in the broadest way. It is very difficult to find a true enterprise architect with high communication skills and the willingness to go out and sell. But if you find it, don't ever let him go (does she want too much money, maybe even more than what you currently earn in the company? If you understand spanish, please read this other post from my blog -http://www.loscuentosdelabuelo.com/2009/04/contrata-gente-que-sea-mejor-que-tu.html- I have; even if you don't, just click on the first link of the post).

One additional area that I consider very important, though usually difficult to accomplish, is the ability to master not only our products and our ecosystem's products, but also our competitors'. It's tough because (1) we don't usually get access to all of those products, so the effort here is usually quite biased; (2) if it's already a challenge to master our own product...; (3) Mrs. SE might like it better than ours, and leave ;) Competitive Intelligence is itself a very complex area, but this has always worked for me:
  • Have a clear Competitive Landscape (where do my competitors fit in my own component architecture?). Start there. This landscape might have been created by your team, by Product Management or by Marketing. This forces you to understand your products, how they fit in different use cases, and how other tools can do what you do in other ways. This is an enlightening task, because it shows you, no matter how mature your product category is, that there are always a few workarounds in terms of using other products from other categories. While a deeper landscape belong more to the environment category, explained below, from a product perspective it is also required to have detailed information about how each product solves specific issues.
  • Start small. If it were for your Sales colleagues, you would need detailed comparative analysis and battlecards from day 1. But that's not the case. So start the simplest way possible: breadth approach. Find all public information from all of your possible competitors as you find them. Create "mini-reports" which are basically copy-and-paste parts of the things you found, plus some initial conclusions and comments.
  • Be critical. Everyone in the jungle might be a competitor... but should I worry about them all? Be critical, take the risk. Keep watch of small companies which might mean something in a few months, but don't spend all your resources tracking them down. Is IBM release a new tool? That's important, but... will it be move fast or slow? Those are decissions to take.

Now the question is, how to achieve this? I guess that, if I knew this 100%, I would be selling courses and consulting to many other companies, but this is my take, and this is how we're doing it.
  • Hire people with a very good technical background. This is the minimum. Real-world companies have *no time* to train people on basics such as Java, good software engineering, good testing background, and the like. How you do this is something for another article (or book), but in the meantime, I recommend reading Joel Spolsky's Smart and Get Things Done.
  • Have a predefined formal training kit. Formal does not mean "one teacher for three weeks". It might simply mean a wiki page with a set of mandatory and optional documents to read, demos to install, and so on. But the most important thing, mixing self-training with one-on-one meetings with other members of the team, plus frequent evaluations (again, not a test, but checkings to see that everything goes well enough). Another thing we do here is to have weekly or biweekly meetings to discuss different aspects of the product, ecosystem, and so on. These meetings should be clearly focused towards "learning what there is". There can be other sessions for product enhancements and the like. Don't mix both, you could spend the whole session discussing about better ways to do X, instead of learning how you can do it now!!!
  • Let communication lines open. Let the team know that teamwork and communication is key. Nobody should feel weird for asking a question, requesting a meeting with a colleague, ... And be the first one to be honest about the team's expectations. If you "sell" openness, be open yourself.

The next post of this series will describe the Environment category, very related to this one.