Archivo de la etiqueta: management

No tienes que convertirte en Manager después de ser Senior

El otro día, un amigo que ya estaba trabajando como programador cuando yo apenas iba en 6° de primaria, se sinceró conmigo.

A pesar de que en su trabajo le pagan bastante bien, y bajo todos los estándares, es un buen empleo, está extremadamente frustrado. “Ya estoy harto de hacer diario lo mismo.” Me platicó que su día a día se ha vuelto tan monótono, que hasta las ganas de programar se le están quitando.

“No hay nada interesante para hacer. Puros forms, maquetado, y resolver bugs de renderizado.”

Cuando le pregunté si había algo que pudiera hacer para cambiar su situación, su respuesta no me sorprendió en absoluto.

“Sí, ser manager. Pero me caga la gente.”

Algunas personas, cuando llegan a cierto nivel de seniority como desarrolladores, dejan de preocuparse por su carrera. Le dejan de prestar atención a su crecimiento profesional porque creen que el único paso que está delante es el convertirse en management. Algo que no quieren hacer.

Opino que esto viene de la idea de que únicamente existe un camino de crecimiento profesional. Como mencioné en la última Sesión Grupal de Soft Skills para Devs, esto es completamente erróneo.

Llegar a cierto nivel de seniority como desarrollador no significa que no puedes seguir avanzando en tu carrera. Después de convertirte en experto en tu tecnología, tendrás más oportunidades de aportar valor de una manera mucho más amplia. Si no te quieres convertir en manager, después de ser Senior, te podrás convertir en Staff Engineer. Y si quieres continuar por la ruta de contribuidor individual, es decir, sin tener que manejar personas, puedes incluso llegar a convertirte en Principal Engineer.

En la empresa correcta, una vez que eres Senior, convertirte en manager no es “lo que sigue”.

Pero hay una trampa: mientras más creces en tu carrera como contribuidor individual, menos se mide tu impacto en líneas de código. Habilitar a otros desarrolladores, aportar valor a otros equipos y áreas de negocio, dar visibilidad a problemas. Todas estas son competencias clave que vas a tener que desarrollar, sí o sí. Todas ellas, van a requerir que le pongas atención, de alguna u otra manera, a tus Soft Skills y a tus habilidades de colaboración con otras personas.

Está bien que no te guste (o te cague) la gente. No todas las personas somos sociales por naturaleza.

Pero la oportunidad de mejorar tu carrera ahí está. Si no quieres convertirte en manager, no tienes que hacerlo.

Lo que sí tienes que hacer, es asegurarte de estar en la empresa correcta para seguir creciendo sin tener que tomar tareas administrativas. Y trabajar en tus Soft Skills.

Convertirte en manager no es un ascenso. Es un cambio de carrera.

Si en tu empresa te quieren “promover” a manager porque eres la persona con mejores capacidades técnicas de tu equipo: felicidades. Acabas de ser víctima del Principio de Peter, que dice:

“En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia: la nata sube hasta cortarse.”

¿Hiciste un buen trabajo como Jr.? Felicidades, ahora eres Mid. ¿Seguiste haciendo un buen trabajo? Genial, ahora eres Sr. ¿Sigues siendo excelente en tu trabajo como desarrollador? Felicidades, ahora tienes un conjunto de responsabilidades para las que no estás preparado, y probablemente ni siquiera quieras tomar.

Las habilidades fundamentales que te hicieron tener éxito como contribuidor individual, no son las mismas que te harán tener éxito como manager.

Escribir “buen” código no se traduce en capacidad para analizar y resolver problemas organizacionales. Saber escoger el lenguaje de programación o framework adecuado para resolver un problema de arquitectura, no se traduce en saber entender las necesidades personales y aspiraciones profesionales de tu equipo, y alinearlas con las de la empresa.

Probablemente, dentro de tu organización, el convertirte en manager venga con aumentos salariales o mayores prestaciones. Pero ten en cuenta que es un trabajo completamente diferente. Convertirte en manager no es un ascenso. Es un cambio de carrera completo. Puede que estés trabajando en tu misma industria; incluso hasta con el mismo equipo. Pero tus responsabilidades ahora son completamente diferentes.

Antes de aceptar el “ascenso”, pregúntate: ¿sabes a qué te estás metiendo? ¿Estás consciente de las implicaciones del nuevo rol? Y más importante aún, ¿quieres hacerlo?

No tener claras las respuestas a estas preguntas te pone en riesgo de sufrir burnout.

Estarás jugando otro juego. Uno que no conoces. ¿Cómo vas a ganar?

Video: El costo de especializarte

Otro clip tomado de la participación que tuve en The Dojo, el canal de mi amigo Héctor, hace unos meses. En este, hablo sobre lo que tuve que sacrificar para especializarme como desarrollador de iOS, y las implicaciones que eso tuvo en mi vida. El artículo de Paul Graham que menciono se llama Bus ticket theory of genius.

Los mejores Product Managers tienen las peores ideas

Lane Wagner, en qvault.io:

De acuerdo con failory, la razón #1 por la que fallan los startups es porque nunca encontraron product-market fit. 34 % de los emprendimientos fallidos son un resultado de no haber identificardo el problema correcto a resolver. Las segunda y tercera razón, marketing y problemas de administración del personal, representan el 22 % y 18 %, respectivamente.

En otras palabras, en 34 % de los startups que fallan, los Product Managers fallaron en

  • identificar un problema crítico de sus usuarios
  • y diseñar un producto que lo arregle

Si bien el rol de Product Manager existe porque no se puede esperar que todo mundo tenga visión de producto, eso no significa que ellos son los únicos que pueden aportar a la evolución y dirección del mismo. Y es ahí donde todos tenemos que poner de nuestra parte: los contribuidores individuales (diseñadores, programadores, etc.) aportando sus ideas basadas en la construcción del día a día del producto, y los Product Managers tomando esas ideas y convirtiéndolas en hipótesis comprobables.

Lane menciona:

En mi experiencia, las ideas basadas en asunciones que vienen de gente de producto, rara vez son mucho mejores que las que vienen de ingenieros. La diferencia es que un buen Product Manager tiene una necesidad imparable de validar o recahzar cada idea que llega a su cabeza.

De acuerdo.

Creo que el rol del Product Manager no es dictar hacia donde debería de ir el producto, sino funcionar como un catalizador de ideas — moldearlas en hipótesis y validarlas en función de la misión y visión que guían la construcción del producto.

Manual de Swanros

¡Hola, $NOMBRE!

Hey, es un gusto tenerte por acá. ¡Vamos a trabajar juntos! Me quise tomar el tiempo de escribir este documento para explicarte un poco cómo funciono, me conozcas y sepas qué es lo que puedes esperar de mí como tu manager. Hago esto porque creo fielmente en el trabajo con personas, y sinceramente me hubiera gustado saber qué era lo que motivaba a algunos managers que he tenido en el pasado. Espero te sea de utilidad.

Durante las próximas semanas vamos a conocernos y a aprender cómo nos gusta trabajar. Por lo pronto, aquí está una radiografía de una semana trabajando en equipo.

Nuestra semana típica

Una semana típica colaborando es bastante relajada desde el punto de vista de comunicación entre nosotros. El micromanagement es la antítesis de cómo trabajo y es lo último que puedes esperar de mí. Habiendo dicho esto, me gusta estar cerca del equipo para saber cómo puedo apoyar, así que nos mantendremos en contacto constante.

Tendremos una llamada semanal para ponernos al día. Durante esta llamada discutiremos cosas importantes o de visión general — no es un standup — y no necesariamente debes de traer algo preparado. Solamente quiero saber cómo vas y establecer una rutina en la que podamos colaborar más allá de tareas puntuales. El objetivo de esta llamada será resolver la siguiente pregunta: ¿cómo podemos potenciar nuestro trabajo?

Además de nuestra llamada 1:1, tendremos una llamada con tu equipo para integrarnos más. Otra vez, no es un standup, sino una oportunidad para mejorar la dinámica que tenemos como equipo. Para estas reuniones crearemos un documento compartido al cual todos tendrán acceso. En él, cualquier miembro del equipo podrá agregar los temas de los que les gustaría hablar, así como las notas de los acuerdos a los que llegamos en la llamada.

Algunos puntos generales que debes de tomar en cuenta sobre nuestro día a día como colaboradores:

  • No es necesario que me pidas permiso para salir si es que lo necesitas. Confío en que tu manejo del tiempo es el mejor posible, y estoy consciente de que hay ocasiones en que la vida se va a interponer en nuestros días. Está bien — lo único que te pido es que no dejes el trabajo tirado.
  • El tiempo personal es primero que el trabajo. Todo mi esfuerzo está en fomentar una dinámica de trabajo que nos permita cerrar la computadora sin preocupaciones al final de un día de trabajo.
  • Procuro responder de manera oportuna a los mensajes. No siempre se logra, pero puedes esperar una respuesta de mi parte.

Principios

Los siguientes son los principios cardinales que guían mi trabajo. Te los comparto de manera únicamente informativa. 

Personas antes que números. Un OKR cumplido, una entrega a tiempo, etc., son efectos secundarios de un equipo contento, motivado y retado lo suficientemente para que el trabajo se mantenga interesante. Mi manera de trabajo está enfocada en optimizar para que tú puedas hacer tu mejor trabajo sin complicaciones.

Tu principal responsabilidad es decir que no. No hay nada que valore más en un equipo que las opiniones propias. Mi rol se trata de crear un ambiente para que tú puedas hacer tu mejor trabajo — pero, al final, el trabajo lo harás tú. Esto significa que tú te podrás llevar los éxitos, pero también el aprendizaje y la responsabilidad de solucionar los problemas cuando algo salga mal. Es por eso que lo mínimo que espero de ti es que puedas defender tu punto de vista cuando no estés de cuerdo con algo que yo u otra persona del equipo proponga.

La honestidad es lo más importante.

Procuro entender por qué llegamos al problema, y resolver eso. Encontrar soluciones parciales o incompletas no es como me gusta hacer mi trabajo. Estoy consciente de que hay situaciones en las que vamos a tener que comprometer la calidad del producto, pero estas deberían ser las excepciones.

Es primordial para mí que las personas que trabajan conmigo se conduzcan con respeto.

Mi calendario es tuyo. Te repito, mi rol dentro de la organización es crear un ambiente favorable para ti. Esto significa que a veces vamos a necesitar sentarnos a discutir un tema en particular — puede ser algo que sientas que no está funcionando como debería, o una idea que te gustaría implementar. No tienes que preguntarme si puedes hablar conmigo — simplemente usa el enlace que te pasé para agendar una llamada y listo.

El tiempo es sagrado, y procuro usarlo responsablemente. Te invitaría a hacer lo mismo, pero esta ese una decisión personal. Mi regla es esta: si voy a poner un evento de 1 hr en el calendario, más vale que sea la hora más productiva del día — y asumo esa responsabilidad con seriedad.

No me gusta usar metodologías que tienen un nombre. “A X empresa le funcionó Y” no es un argumento que me emocione para intentar aplicar Y en nuestra organización. Por el contrario, si vamos a analizar por qué funcionó, y lo vamos a intentar adaptar a nuestro caso particular, ahora tienes mi atención.

Trabajo por algo, no en algo. Afortunadamente en nuestra industria hay miles de oportunidades para hacer software, manejar gente, o diseñar cosas. Cuando trabajo en algún lugar en particular, lo estoy haciendo por algo.

Comunicación

Mi método preferido de comunicación es escrito. Creo que escribir algo es la mejor manera de asegurarme de que entiendo de manera clara lo que quiero comunicar. Reconozco que eventualmente será necesario tener una llamada para resolver algún problema en particular, y sigo algunos lineamientos en estos casos.

Procuro no tomar ni buscar llamadas que no estén en el calendario con por lo menos 24 horas de anticipación. Lo último que alguien necesita es una llamada de imprevisto, y estoy consciente de ello. Si necesito tener una llamada contigo, tendrás por lo menos un día completo para prepararte. Esperaría que tuvieras la misma consideración conmigo.

Nunca te enviaré invitaciones a llamadas que no tengan un objetivo claro. Tanto el título del evento en el calendario, como la descripción del mismo, tendrán toda la información que debes saber para llegar preparado a la llamada. En caso de que vaya a pedirte actualización de algún proyecto, por ejemplo, sabrás exactamente qué espero de ti.

El calendario tiene la opción para rechazar invitaciones a eventos. Úsala. Como dije antes, las llamadas para mí son un último recurso para colaborar. Si algún día te envío una invitación a una llamada, pero crees que sería mejor simplemente mandarme la información escrita, siéntete con la libertad de rechazarla. El tiempo es lo más importante y no me lo tomaré a mal si prefieres no tenerla. Si de verdad es crucial que tengamos la llamada, ya sea porque algo urge, o estamos en una situación de alerta, te lo haré saber.

Aprecio cuando todos los participantes de la llamada tenemos la cámara prendida. Trabajamos de manera remota, y es fundamental para mí establecer una relación con las personas que son parte de mi equipo. Vernos la cara es primordial para este propósito. Te pido que, dentro de lo posible, también prendas tu cámara cuando entres a una llamada conmigo — sobre todo si vamos a estar hablando sobre temas valiosos, como tu desarrollo dentro del equipo.

Respeto mi tiempo y el de los otros. Siempre procuro estar ya en la llamada uno o dos minutos antes de que de la hora pactada. Si tengo varias llamadas seguidas, es probable que me pueda demorar unos minutos en entrar a la siguiente. Si esto pasa, y tú eres mi siguiente llamada, te haré saber con anticipación que llegaré unos minutos tarde. No es normal que esto suceda.

Desarrollo profesional

Vamos a establecer objetivos de crecimiento para ti, y vamos a procurar que estos se encuentren en la intersección de lo que tú quieres para tu carrera y lo que la empresa necesita. Tendremos un documento compartido donde colaboraremos en la creación de tu plan de acción, al cual le daremos seguimiento cada 3 meses.

Debes de saber que nuestra relación no será de una sola vía. Es decir, no solamente se trata de pedirte cosas o que llegues a ciertas metas, sino de que entre los dos lleguemos a un acuerdo sobre qué es lo que tú quieres hacer, lo que la empresa necesita, y cómo yo te puedo apoyar.

También debes de tomar en cuenta que las revisiones de este documento no serán las únicas ocasiones en las que podemos compartir retroalimentación. Soy fiel proponente de la comunicación asertiva, y si hay algo que corregir me aseguraré de hacértelo saber en tiempo y forma, y espero que hagas lo mismo conmigo.

Notas extras

Uso muchas analogías cuando explico cosas. Sobre todo cuando algo me gusta demasiado. No te asustes si de repente quiero explicar cómo funciona un sistema literalmente con perros y gatos.

Soy fanático de trabajar por las mañanas, mi día comienza antes de las 6 am regularmente. Te pido que no sientas la presión de estar disponible en mis mismos horarios, y si te mando un mensaje temprano no tienes que contestarme de inmediato.

Soy muy celoso de mis tardes, y procuro no tener compromisos de trabajo después de las 4 pm. Sin embargo, soy flexible, y si hay algo que se necesita hacer a esa hora, estaré ahí. Pero todo mi día y forma de trabajo se centra en poder tener mis tardes libres.