Categoría: Empresario

  • Por qué equipos capaces entregan resultados mediocres

    Por qué equipos capaces entregan resultados mediocres

    En muchos proyectos, cuando algo no sale como se esperaba, la reacción natural es pensar que el problema fue técnico. Que faltó experiencia, que faltó atención al detalle o que simplemente el resultado no estuvo a la altura. Sin embargo, muchas veces el problema no está en el código. Está en la comunicación.

    He visto equipos muy capaces generar retrabajo innecesario simplemente porque hubo pequeños vacíos de claridad al inicio. No mala intención. No falta de talento. Solo suposiciones distintas sobre lo que se quería lograr.

    Un cambio simple es explicar el “por qué”, no solo el “qué”. Decir “agreguemos este campo al formulario” es muy distinto a decir “agreguemos este campo porque el equipo de ventas necesita esta información para cerrar contratos más rápido”. Cuando un developer entiende el impacto en el negocio, empieza a tomar decisiones distintas. Puede anticipar casos que nadie mencionó, detectar inconsistencias o incluso proponer una solución mejor. Sin contexto, ejecuta. Con contexto, piensa.

    Otra cosa que ayuda es definir qué significa realmente “terminado”. Muchos problemas no surgen de mala ejecución, sino de expectativas diferentes. Para alguien, terminado significa que la feature funciona en su máquina. Para otro, implica validaciones, manejo de errores, pruebas básicas y comportamiento correcto en móvil. Si esa definición no se conversa antes de empezar, el retrabajo es muy probable. Definirlo con claridad previene esos malentendidos.

    También ayuda confirmar que se haya entendido bien antes de que se escriba el código. Un hábito simple es pedir que el requerimiento se explique de vuelta, no como examen, sino como alineación. “Solo para asegurarnos de que estamos entendiendo lo mismo…” Esa conversación temprana suele revelar detalles que parecían obvios, pero no lo eran. Detectar un malentendido antes de construir es más barato que corregirlo después.

    El feedback también cambia los resultados cuando se enfoca en mejorar y no en culpar. No es lo mismo decir “esto no era lo que pedí” que explicar qué necesidad del usuario no se está resolviendo todavía. Cuando el feedback es específico y está conectado al resultado esperado, el equipo sabe exactamente qué ajustar. Además, se mantiene la conversación en un nivel profesional, no personal.

    Finalmente, crear espacio para preguntas es más importante de lo que parece. A veces el silencio no significa claridad, sino suposición. Frases como “¿qué podría salir mal aquí?” o “¿ves algún riesgo en esto?” invitan a pensar. Cuando los developers participan activamente en la definición y no solo en la ejecución, el nivel de ownership cambia.

    Pequeños ajustes en la forma en que definimos, explicamos y damos seguimiento a los requerimientos pueden reducir retrabajo, mejorar la velocidad y elevar el nivel del resultado final.

    A veces ni así se logra. Pero ese ya es tema para otro post.

  • Aceptar que pueden sin mí

    Aceptar que pueden sin mí

    Cuando empecé a trabajar por mi cuenta tenía claro que quería construir una empresa y no solamente ser freelancer o una compañía de una sola persona. Por eso desde muy temprano contraté a personas que me ayudaran con el trabajo.

    Lo primero que delegué fue justamente lo que mejor sabía hacer: desarrollo de software, escribir código. Siempre me ha parecido curioso eso, porque si era lo que mejor hacía, ¿por qué soltar eso primero y no las tareas en las que no era tan bueno?

    Creo que fue porque quería involucrarme, revisar a detalle lo que hacían, cuidar la calidad y dar instrucciones muy específicas. Sabía cómo debía verse el resultado final y eso me daba tranquilidad.

    Mientras tanto yo iba aprendiendo otras áreas del negocio, como administración, finanzas e impuestos. En esas sí me daba miedo delegar porque todavía no tenía claro cómo quería que se hicieran las cosas.

    Con el tiempo fui entendiendo mejor esa parte del negocio y cuando por fin sentí que ya podía delegar también la administración, me encontré otra vez con la necesidad de seguir revisando a detalle.

    Revisar todo se siente responsable. Te hace pensar que estás cuidando el negocio. Te da la sensación de control. Pero cuando revisas cada detalle también mandas un mensaje: que la última palabra sigue siendo tuya y que la responsabilidad nunca es completamente de quien ejecuta.

    Si siempre estoy en medio, nunca sabré si realmente pueden hacerlo sin mí.

    También he tenido que aceptar algo que no siempre es cómodo reconocer: apagar incendios se siente bien. Resolver algo rápido, entrar a una conversación y ordenar todo, corregir antes de que algo escale, da una sensación inmediata de impacto. Es visible y concreto.

    El problema es que si siempre soy el que entra a resolver, el sistema nunca aprende a sostenerse solo. El equipo se acostumbra a que hay alguien más mirando y validando al final. Y cuando alguien más valida, la responsabilidad cambia.

    Aceptar que pueden sin mí no significa desentenderme. Significa definir expectativas, resultados y límites claros. Después de eso, dar espacio. Espacio para decidir, para equivocarse y para mejorar.

    Si intervengo en cada decisión imperfecta, elimino la posibilidad de que desarrollen criterio. Y sin criterio no hay crecimiento real. Solo hay ejecución supervisada.

    Ser indispensable puede sonar como algo positivo, pero en realidad es una señal de fragilidad. Si todo depende de mí, entonces la empresa es tan fuerte como mi tiempo, mi energía y mi capacidad de revisar. Eso no escala.

    Cuando empecé quería construir una empresa, no un autoempleo donde todo pasa por mí. Hoy el reto es aprender a no meterme en todo.

    No porque no pueda. Sino porque si quiero que esto funcione de verdad, tengo que aceptar que pueden sin mí.

  • ¿Durmiendo en mis laureles?

    ¿Durmiendo en mis laureles?

    Hubo una etapa en la que avanzar significaba decir que sí a todo.
    No porque todo fuera una buena idea, sino porque no había margen para elegir.
    Hace ya varios años que inicié mi propia empresa. Tenía muchas ganas de hacer algo por mi cuenta y, cuando por fin me animé, lo hice con la mentalidad clásica del inicio: hacer de todo.
    Había una presión constante para que el negocio funcionara. En esa etapa, decir que sí a lo que cayera era casi automático. No porque todas las oportunidades fueran buenas, sino porque necesitábamos el flujo de trabajo para seguir vivos.
    Ese empuje tenía algo poderoso. Me mantenía en movimiento.
    Me obligaba a aprender rápido, sobre la marcha. A adaptarme y asumir responsabilidades nuevas. A resolver problemas sin excusas. A trabajar con urgencia, tomar decisiones rápidas, pero también a aceptar proyectos mal definidos porque “algo es algo”.
    Hoy el escenario es distinto.
    El negocio ya no depende de correr detrás de cualquier oportunidad. Ahora se trata más de administrarlo, de tomar mejores decisiones, ya no tengo que aceptar cualquier proyecto. Ya no todo es urgente.
    Desde que empecé a delegar más, tengo tiempo libre. A veces, demasiado. Puedo elegir en qué trabajar o incluso no trabajar por un rato. Y la verdad es que se disfruta.
    Pero junto con esa calma aparece la duda incómoda.
    ¿Me estoy durmiendo en mis laureles o simplemente cambié el ritmo?
    La necesidad y urgencia te empuja, pero también te desgasta.
    La calma, en cambio, te da espacio. Y en ese espacio, la duda se vuelve más difícil de ignorar.
    Intento no romantizar la urgencia de antes, pero tampoco quiero confiarme demasiado con la comodidad de ahora. A veces no sé si esta pausa es una decisión consciente, producto de un negocio más maduro o si simplemente dejé de exigirme como antes.
    Supongo que cada etapa tiene su propio costo.