Ya es una buena respuesta de Vijay Venkatesh.
Sugeriría hacer algún tipo de diligencia debida pero desde un punto de vista tecnológico.
Aprenda cómo los inversores harían un DD, aquí hay algunas buenas lecturas:
Due Diligence Tech en una Startup – Taller
Crea una lista de verificación y comunica abiertamente a todos tus compañeros qué vas a hacer.
Puede publicar su lista de verificación en el wiki de la empresa, por ejemplo.
- ¿Cuáles son las métricas de ingeniería que un gerente de programa debe rastrear en un inicio de software?
- ¿Debo alquilar una oficina para mi compañía de software o puedo comenzarla en casa?
- ¿Dónde encuentro un desarrollador de software (individual) con el que formar equipo para desarrollar un proyecto?
- ¿Cuál es su experiencia con el desarrollo de un producto mínimo viable (MVP)?
- Cómo iniciar una empresa robótica
- Aprende todo lo que puedas sobre tu equipo
– Lea los CV de todos sus futuros empleados
– Verifique los salarios de sus futuros empleados, si tiene algunas personas mal pagadas o pagadas en exceso, mire más profundamente por qué.
– Busque problemas abiertos en sus equipos
– Pregúnteles a las personas qué proyectos van bien, ¿qué los enorgullece?
¡No intentes cambiar las cosas de las que la gente está orgullosa!
– Intenta descubrir qué está yendo en una dirección incorrecta y pregunta por los motivos. - Conozca la compañía y sus colegas de otros departamentos.
– ¿Cuáles son actualmente el mayor desafío para TI / Ingeniería desde la perspectiva de otros?
– ¿Que necesitan? Intente descubrir cómo puede ayudar a mejorar los negocios e intente implementar una relación saludable con los departamentos no tecnológicos
– Intenta leer tanto como sea posible de la documentación interna o wiki. - Aprenda acerca de la tecnología que actualmente está en su lugar, obtenga root en todas partes.
– Tenga cuidado con la raíz, a veces las personas tienen miedo si el nuevo CTO contratado solicita acceso completo.
Necesitan confiar en ti primero, así que convéncelos primero, de que puedes manejar cosas de operación y no quieres hacer una locura que mantiene despiertos a los DevOps toda la noche 😉
Tenga cuidado con esto, no demasiado pronto, pero hágalo en algún momento porque necesita mirar debajo del capó.
Quizás solicite primero acceso de solo lectura.
Pero generalmente es importante en las startups, usted como CTO será responsable de todo tipo de problemas operativos y, después de algunas semanas, el CEO lo señalará si algo sale mal y en este punto ya debería poder obtener las soluciones adecuadas que a veces necesita alguna mirada de primera mano debajo del capó.
– Mire debajo del capó tan pronto como tenga acceso
– Haga una infraestructura profunda y codifique DD, revise todo, revise las revisiones.
– Obtenga un historial de incidentes y eche un vistazo a lo que salió mal en el pasado.
– Revise el código con sus ingenieros para comprender lo que están haciendo.
– ¡Pentest todo!
Ejecute metasploit contra su infraestructura, realmente, pentest, todo, también pentest de los empleados.
Realmente necesita averiguar qué tan seguras son sus cosas, qué tan educados están los empleados con respecto a las contraseñas y la seguridad de TI.
Esto es realmente muy importante.
Siempre hacía pruebas de phishing con empleados importantes y educaba educadamente si fallaban. No intentes culpar, solo intenta arreglarlo.
El administrador del sistema siempre debe comunicarse de manera segura con usted. Proporcione su clave PGP. - Conozca sus objetivos comerciales y empresariales.
– ¿Cómo gana dinero tu empresa?
– ¿Qué necesita la empresa para ser más exitosa en el mercado con respecto a TI / tecnología?
– pregunte a todos los departamentos qué necesitan de TI para realizar más trabajo, ser más eficientes, etc.
– obtenga un resumen estratégico de este punto que necesita alinear con sus departamentos.
Sé siempre amable y educado.
El problema en la tecnología es que todos los CTO, desarrolladores, gerentes de producto, lo que sea, tienen su propio favor para las herramientas y procesos y, por lo general, a las personas no les gusta el cambio del entorno actual.
Así que nunca forces el cambio de cosas en los primeros días.
No te muevas de SVN go GIT en los primeros días, por ejemplo, solo porque tienes más experiencia con GIT.