Hay dos formas de trabajar. Y estoy seguro de que podrás identificar cuál tienes tú y cuál tienen las personas que te rodean.
Una de ellas consiste en perseguir a la gente para conseguir respuestas y responder a cada pregunta con otra pregunta.
Por ejemplo, sabes que tienes una dependencia y simplemente les estás pasando el trabajo. Me están bloqueando; les falta esto; les falta aquello.
En el caso de la segunda forma de trabajar, harías las cosas de otra manera. Sabes que tienes una dependencia y, en lugar de pasarles la pelota y esperar una respuesta, haces una propuesta. Estás avanzando en el trabajo, en vez de mover el trabajo de un lado a otro.
Piensa en trabajar con este segundo tipo de persona. Alguien que absorbe burocracia. Alguien que te protege de tener que lidiar con las complejidades de todo el equipo o incluso de toda la empresa. Alguien que entiende que, como ingeniero de software, tienes que centrarte en los detalles técnicos. Así que protege tu concentración en el desarrollo.
¿Qué forma de trabajar preferirías en tu equipo? ¿Cuál crees que es mejor?
En este artículo, exploraremos las dos formas de trabajar. También entenderemos los inconvenientes de esta segunda forma y cómo asegurarte de tener lo bueno sin tener lo malo. Si fuera perfecta, todo el mundo trabajaría así.
Hacerse responsable en el trabajo significa ayudar a resolver el problema
Hay una palabra clave que les gusta a todos los libros de liderazgo, que es ownership. Para mí, ownership significa tener algo en juego. No significa que hagas todo el trabajo tú solo, pero eres responsable de ese trabajo. Así que contribuyes donde puedes y conectas a las personas donde no puedes hacerlo tú solo.
Ownership consiste en querer avanzar en el problema. Estoy ayudando a cualquiera que esté avanzando en el problema. Se trata de pensar de verdad en cómo puedes avanzar en el problema en lugar de delegarlo en una IA o pasárselo a otra persona.
Por ejemplo, parte de hacer el esfuerzo de pensar consiste en no decir nunca «Esto no forma parte de mi tarea». Si alguien te pide algo que está fuera del alcance de tu tarea, al menos piensas un poco y propones algunas acciones, aunque no las lleves a cabo.
Vas a cambiar un test y, de repente, alguien dice que deberías echar un vistazo a todos los demás tests. Entonces echas un vistazo y dices: «Vale, veo que hacen falta más cambios. Déjame crear un ticket separado o tomar medidas en una nueva code review, ya que esta tenía el propósito X, y sigue siendo válida».
La mala forma de trabajar sería simplemente no hacer nada.
Lo que queda sin pensar se convierte en trabajo para otra persona
Hay un antipatrón en el mundo corporativo, que son los hilos. Ya sea en el correo electrónico o en cualquier otra herramienta como Slack, resulta muy tentador añadir a otra persona a un hilo y pasarle el problema.
Mi equipo usa Slack y me mencionan constantemente en cosas en las que es verdad que puedo contribuir, pero otras personas podrían haber avanzado, de modo que, cuando llego, simplemente… tenga menos trabajo que hacer.
Al menos, si añades a otra persona a una conversación, tienes que darle un breve contexto y también una acción clara que necesitas de ella.
Coordinación que le quita trabajo de encima a un ingeniero
Esta forma de trabajar es especialmente importante para los ingenieros de software. Somos personas que necesitan tiempo para pensar y concentrarse. Y ahora, con la IA haciendo toda la implementación, es más importante que nunca. Podemos avanzar muy rápido por el camino equivocado si no tenemos tiempo para pensar.
Ahora imagina la forma opuesta: alguien te añade a algo para lo que tiene una propuesta clara y necesita que respondas a cinco preguntas. Te resulta muy fácil responder a esas preguntas, afinar la propuesta con tu información y poneros de acuerdo muy rápido.
Esto es lo que en Amazon se llama internamente: hacer las preguntas de la manera correcta. No preguntas algo como «Oye, no lo entiendo». Haces tu investigación, te formas una opinión y haces preguntas concretas, dando el contexto adecuado.
No seas el ingeniero que solo retransmite el output de la IA
Ya escribí sobre este antipatrón, pero creo que es más importante que nunca.
El otro día vi este post en X sobre personas que trabajan en los mayores laboratorios de IA. Siguen escribiendo sus propios textos.
Y es verdad que escribir tiene un beneficio, porque escribir es pensar. Llevo un tiempo escribiendo un diario y es casi terapéutico poner por escrito tus pensamientos.
Hoy en día todo el mundo tiene herramientas de IA, así que no le estoy pidiendo a nadie que consiga un output de IA. Se lo preguntaré directamente a la IA.
Esta web de abajo es bastante graciosa. Me recuerda a los días de las otras webs sobre no hello (no digas hola y esperes; di hola y envía directamente lo que quieres).
https://dontpastetheai.com/angry/ (Sí, hay distintas versiones y comparto aquí la versión enfadada).
A estas alturas deberías estar convencido de que el motivo por el que estás contratado es pensar. No siempre se trató de escribir código; siempre se trató de pensar.
Así que necesitamos que apliques tu propio pensamiento allí donde se te necesite.
Haz el esfuerzo de pensar que haga útil tu siguiente acción
Así que ahora vamos a hacer práctico este artículo. Siempre que estés involucrado, haz al menos lo siguiente:
Aclara el resultado esperado (con las personas).
Comprueba los hechos relevantes (Aquí puedes usar IA; se le da bastante bien).
Identifica cualquier suposición o cualquier decisión que aún no esté resuelta.
Resuelve tantas como puedas según tus conocimientos o tus responsabilidades.
Para las que no puedas resolver, haz una sugerencia y encuentra a la persona adecuada, dándole el input preciso que necesita y las expectativas correctas.
Así que ahora, volviendo a mi ejemplo: estás cambiando un test y alguien pide que cambies alguna otra cosa en otros tests.
Como mínimo, lo que deberías hacer es comprobarlo. Al menos consigues una opinión informada para responder a esa persona.
También identificarás qué tipo de mejoras podemos hacer, aunque no hayas profundizado demasiado. Y responde con un enfoque, aunque no vayas a hacerlo en absoluto. Deberías tener claros los siguientes pasos.
Y puedes seguir usando IA en todo esto, pero tienes que formarte una opinión tú mismo. Reúne las pruebas con IA. Revisa tu opinión con IA para cuestionarla en una revisión adversarial. Pero sigues siendo tú el responsable de hacer el esfuerzo de pensar.
Es como si un manager, un director o un vicepresidente no hiciera nada por sí mismo porque simplemente retransmite a sus superiores lo que le dicen sus subordinados, esa persona sería despedida inmediatamente.
Esto no consiste solo en aportar valor al resto de la empresa. Esto te ayuda a ti mismo porque entenderás las cosas. Puedes consultar este artículo sobre Prompt-Engineering y Spec-Driven-Development. Cómo programar con IA como un ingeniero senior en Big Tech:
Conclusión
Recuerda una vez más que tu contribución es el pensamiento y el criterio.
Un reto que te propongo es revisar tus últimos mensajes y correos electrónicos enviados. ¿Estás simplemente moviendo el problema de un lado a otro o estás avanzando de verdad hacia su resolución?
Cuéntame en los comentarios cualquier ejemplo que quieras compartir, tuyo o de otra persona, que muestre los patrones de estos artículos.
Si has encontrado valor en este post:
❤️ Haz clic en el corazón para ayudar a que otros lo encuentren.
✉️ Suscríbete para recibir el siguiente en tu bandeja de entrada.
💬 Deja un comentario con lo más importante que te llevas
♻️ Compártelo con tus compañeros
