¿Cómo podemos mejorar la situación de un equipo técnico, sin un CTO?

Nuestra empresa ejecuta una aplicación para compartir fotos en línea, que permite a los usuarios editar imágenes, crear presentaciones de diapositivas, compartirlas en blogs y redes sociales, etc. La empresa es pequeña, aproximadamente 15 personas, con un personal técnico de 5, 3 seniors y 2 internos, con otro interno próximamente. Nuestro CEO es también el jefe del equipo de marketing.

Tuvimos un CTO hasta agosto de 2009. Cuando nuestro CTO se fue, la empresa estaba teniendo problemas financieros y se decidió no contratar a otro CTO de inmediato. El cuerpo técnico (solo los 3 seniors en ese momento) decidió, entre ellos, qué hacer.

Sin un CTO, tenemos problemas para que el CEO tome algunas decisiones. Esto ha creado algunos problemas a nivel técnico, como problemas de calidad en la infraestructura y el código base.

Mi pregunta es: ¿cómo mejoramos esta situación? ¿Deberíamos insistir en contratar a otro CTO que tendría dificultades para integrarse y ganar legitimidad (yo diseñé y creé toda la aplicación del servidor. No dejaré que nadie me explique cómo tengo que hacer mi trabajo)?

¿Por qué necesita el CEO para tomar las decisiones?
Alguien tendrá que decidir gastar el tiempo y el dinero. Más bien el CEO o un CTO.
Si tuviera la autorización para gastar tiempo y dinero, ¿podría su equipo llegar a una decisión por consenso?
De joelonsoftware.com/articles/fog0000000072.html , "- cada decisión la toma la persona con más información". La empresa debe dejar que el equipo tome decisiones a nivel técnico, como problemas de calidad en la infraestructura y el código base como mencionaste.
@Mark Philips: sí, claro.
@johnny: artículo interesante y pensamiento interesante. ¡Gracias!
Si tiene problemas para integrarse y ganar legitimidad, no es material para CTO.
Necesita a alguien , independientemente del título, que se responsabilice de la calidad e integridad general del sistema. Necesitas un capitán en un barco. es.wikipedia.org/wiki/…

Respuestas (4)

  • Promociónate a ti mismo, o a alguien de tu equipo, para que tome las decisiones.
  • Pida a su CEO que tenga un presupuesto definido para TI (puede ser anual, trimestral, etc.)
  • Tome algunas decisiones, gaste en consecuencia y asuma la propiedad de las decisiones y los resultados.
Promocionar a uno de los mayores, a mí oa uno de los otros dos, es una de las cosas que me gustaría evitar. El equilibrio entre nosotros está bien tal como está, y mi miedo es empeorar las cosas tratando de mejorarlas. Pienso que tener a nuestro CEO para definir un presupuesto para TI es una buena idea. Le daré algunas ideas y lo discutiré con los demás para tener una propuesta organizada para nuestro CEO.
Entiendo tu inquietud al alterar el equilibrio. Pero este parece uno de esos casos en los que hay un vacío de liderazgo que debe llenarse, ya que obstaculiza la capacidad de la empresa para avanzar.

Un CTO de tiempo completo podría ser excesivo, pero la realidad es que no ha podido comunicar sus necesidades de manera efectiva al CEO. No ha proporcionado detalles sobre lo que se le ha proporcionado al CEO, pero mi primer instinto es que no le ha dado una razón comercial por la que desea realizar una mejora. Según lo que ha dicho, es probable que haya callejones sin salida en el código que deben remediarse y esto evitará que su empresa pueda expandirse. Este suele ser el tipo de información que debe comunicarse a C-Level. Dígales lo que les está costando en tiempo y dinero, lo que ahorrarían al hacer los cambios y/o lo que no pueden hacer, pero que podrían hacer si hicieran el cambio.

Un CTO debe tener un pie en el negocio y ser capaz de comprender y convertir sus necesidades a un lenguaje que obtenga los recursos. Por otro lado, un buen CTO también podrá explicar POR QUÉ (por ejemplo, no hay dinero disponible) es posible que no obtenga los recursos que cree que necesita.

Los líderes no necesitan títulos. No necesitas un CTO. CTO es solo un término elegante que generalmente se le da al fundador de una empresa que tiene experiencia técnica. La persona tiene habilidades y lo más probable es que haya construido la mitad de la infraestructura sin ayuda de nadie, pero si esa persona se va, entonces nadie puede desempeñar ese papel. No se puede crear otro fundador de empresa en una empresa ya fundada. Puede darle ese título a alguien, si realmente lo desea, pero no será el CTO anterior.

EHow tiene una descripción del trabajo, pero el puesto varía mucho de una empresa a otra. Esta descripción del trabajo de CTO le dará una idea del rol del CTO.

Además, lea Cómo convertirse en director de tecnología. Tenga en cuenta que las responsabilidades clave incluyen las palabras "estratégico".

¿Dices que el problema está en el código? Eso no es un problema de CTO. El CTO no dicta la calidad del código ni participa en problemas de tan bajo nivel. Ese es el dominio de los equipos. Eso implica una gestión "táctica".

Necesita un líder, simplemente no necesita ser un ejecutivo bien pagado de 6 cifras. ¿Por qué no intentas asumir ese papel? Sin embargo, no se dé a sí mismo el título, solo satisfaga la necesidad. Los líderes no necesitan títulos.

No dejaré que nadie me explique cómo tengo que hacer mi trabajo.

Si un CTO lo dice, rescindir su contrato de inmediato.

Además de eso, sugeriría centrarse en documentos, no en personas (CTO o quien sea). Su problema es que no tiene una arquitectura clara/documentación de diseño y requisitos de calidad del código fuente. Para retomar el rumbo, debe invertir su tiempo (o el tiempo de otra persona, tal vez un CTO a tiempo parcial) en la documentación técnica.

Tengo claro lo que hay que hacer (más bien un proceso de integración continua que la documentación técnica, en este punto), pero es más difícil cruzar la mesa con el CEO. Ahí es donde un CTO podría ser útil, en mi humilde opinión.
La integración continua (junto con el análisis de código estático adecuado) siempre es mejor que la documentación estática, tiene razón. Estoy de acuerdo en que un CTO podría desempeñar un papel importante como "entregador de mensajes". Pero, como puede ver, no puede reemplazar CI y documentación.
Sí, estoy probando algunas herramientas de análisis estático como Sonar, CodePro, PMD, FindBugs y otras. ¡Es bastante bueno encontrar errores potenciales sin buscarlos! Pero nos salimos del tema, creo...