Pasé ~ 2.5 años como ingeniero de software en dos organizaciones diferentes, y después de un descanso de 2 años para la escuela de posgrado, pasé ~ 2.5 años en McKinsey & Company como Asociado y Asociado de Verano. Me fui antes de convertirme en Gerente de Compromiso.
Respuesta corta:
Desde una perspectiva de habilidad / habilidad , la transición me pareció una extensión y aplicación muy natural de algunas de las habilidades que desarrolla la ingeniería de software: capacidad de resolución de problemas, trabajo en equipo. Sin embargo, también expuso la necesidad de construir en otras áreas: habilidades orientadas al cliente / blandas; capacidad de adquirir rápidamente un conocimiento de dominio amplio pero superficial; análisis cuantitativo; habilidades de presentación verbal y escrita : que la ingeniería de software no suele desarrollarse. Para tener éxito en la consultoría de gestión, creo que un ex ingeniero de software ya debe ser bueno o aprender rápidamente estas cosas y aplicarlas en una variedad de entornos.
- Cómo llenar mis calificaciones faltantes en el fútbol rápidamente
- Cómo evitar trabajar muchas horas solo para terminar pagando demasiado por el cuidado de la salud cuando estás trabajando para intentar costear la formación universitaria o profesional
- Si los republicanos creen que reducir los impuestos para las corporaciones produce más empleos, ¿por qué el rescate continuo no ha producido una cantidad significativa de empleos?
- Cómo usar Twitter para el crecimiento de mi carrera
- ¿Qué tan bueno es 1 año MBA en EE.UU. para el empleo?
Desde una perspectiva experiencial más amplia , la transición de estar en un grupo de personas relativamente talentosas pero algo nerd y a menudo tranquilas, a estar en un grupo de “triunfadores inseguros” extremadamente talentosos, expuso mis propias inseguridades y resultó ser mucho de diversion. Raramente era el tipo más listo en la sala de McKinsey, lo que me ayudó a aprender mucho, pero a veces también me sentí como un despertar grosero porque mis ideas enfrentaban un grado de desafío mucho mayor que el que tenían en situaciones anteriores donde las personas tendían a ir con lo que dije porque ya me consideraban inteligente. (No quiere decir que no haya organizaciones de ingeniería con personas tan inteligentes, en promedio, como las de McKinsey; pero la ingeniería de software como disciplina está mucho más fragmentada y diversa desde una perspectiva de talento que el grupo central de “nivel superior” “empresas de consultoría de gestión).
Hay mucho que decir sobre cómo fue la experiencia para mí, pero dado que gran parte de eso me parece circunstancial, enfocaré mi respuesta más larga en la perspectiva de habilidades / habilidades.
Respuesta más larga:
Algunas de las mismas habilidades clave son esenciales para el éxito en ambas disciplinas; la ingeniería de software lo prepara bien en estas áreas y eso facilita la transición en algunos aspectos
Siempre he pensado que algunos de los procesos cognitivos y de trabajo más comunes en los que uno se involucra como ingeniero de software son bastante similares a dos áreas en las que los consultores de gestión generalmente necesitan ser fuertes para tener éxito: la resolución de problemas y el trabajo en equipo . En ese sentido, el tiempo como ingeniero de software me preparó bien para la consultoría e hizo que la transición se sintiera relativamente natural, al menos para mí.
Formas en que la ingeniería de software es similar o lo prepara para la consultoría de gestión
En empresas como McKinsey, el éxito a largo plazo requiere muchas habilidades diferentes, que no intentaré enumerar aquí; pero especialmente en los niveles junior, dos de estos son esenciales: resolución de problemas y trabajo en equipo.
La resolución de problemas , como lo describiría en este contexto, es el proceso de tomar una pregunta complicada y dividirla en un conjunto de preguntas constituyentes más manejables y simples, haciendo esto de manera recursiva hasta que tenga un conjunto de tareas atómicas manejables para trabajar y revisando constantemente el problema general y el alcance del proyecto hasta que tenga una respuesta completa validada.
Como ingeniero de software (y arquitecto), pasas por un proceso muy similar. Primero, debe definir y determinar el problema, luego comprender cuáles son los requisitos que limitan la solución aceptable, identificar las áreas clave de funcionalidad, desarrollar una perspectiva de cada uno de los módulos necesarios y describir las formas en que estas cosas interactúan con cada uno otro.
Para cada uno de los módulos / áreas de productos clave, hay un proceso recursivo e iterativo por el cual ese problema un poco menos complejo se divide en un conjunto más simple de problemas, hasta que finalmente se llega a un nivel de unidad y línea de código. Mientras desarrolla la solución, verifica que su trabajo se mantenga dentro de los límites de las especificaciones, y que lo que está presentando constituirá una solución completa.
Tenga en cuenta una diferencia clave: la consultoría de gestión tiene una tolerancia mucho mayor para ignorar ciertas “ramas” del problema que la ingeniería de software, porque en la consultoría de gestión, un problema que se considera de baja prioridad a menudo simplemente no se resuelve, pero en la ingeniería de software todavía debe ser totalmente explorado, construido y probado. Esta es un área que los ingenieros convertidos en consultores deben tener en cuenta. Puede ser difícil acostumbrarse al pensamiento “80-20” … a menos que usted fuera un ingeniero algo impaciente o flojo, como yo.
El trabajo en equipo, por otro lado, se trata de comprender claramente los objetivos de su equipo, conocer su rol individual y usar sus fortalezas junto con los otros miembros del equipo para hacer que todo el equipo sea mejor y más exitoso para alcanzar la meta.
Como ingeniero, usted es responsable de un determinado rol y se le asigna una parte del diseño / funcionalidad completa para implementar, de la misma manera que es responsable de un flujo de trabajo específico como miembro de un equipo de consultoría. Arruine su trabajo en su sección del problema, y no solo es probable que el trabajo de otra persona también se vea afectado, sino que el trabajo de todo el equipo puede verse comprometido. En la consultoría, los flujos de trabajo generalmente se brindan a los miembros del equipo que muestran aptitud para esa área (por ejemplo, el mejor modelador financiero del equipo), o alternativamente que tienen un “área de desarrollo” en el que necesitan oportunidades para trabajar. En ingeniería de software, los roles a menudo están integrados en trabajos (p. Ej., Ingeniero de control de calidad) o alineados, de manera similar, con las habilidades y la experiencia previa del miembro del equipo en cuestión.
En ambos ámbitos, ser capaz de comprender cómo encaja su trabajo dentro del contexto más amplio del trabajo del equipo es esencial para el éxito, al igual que la capacidad de cumplir con los plazos; participar de manera constructiva en las discusiones con otros miembros del equipo para ayudar a avanzar el pensamiento sobre un elemento difícil del problema; y asegúrese de cumplir con los requisitos en su área de responsabilidad.
Sin embargo, hay una serie de áreas de habilidades que la ingeniería de software no desarrolla y que necesitará para consultar. Si no tiene estos, su experiencia de transición puede ser mucho más difícil.
Dejando de lado la resolución de problemas y el trabajo en equipo, creo que de varias maneras la ingeniería de software no lo prepara bien para la consultoría de gestión, por lo que debe ser capaz de ser naturalmente bueno en estas cosas, aprender rápidamente en el trabajo o encontrar otras formas de desarrollando las habilidades necesarias (tutoría, capacitación externa, etc.). De lo contrario, se incendiará rápidamente como consultor o logrará patinar por un tiempo en una combinación de suerte y compensar las debilidades en estas áreas mediante la brillantez extrema en la resolución de problemas.
Formas en que la ingeniería de software es diferente o no lo prepara para la consultoría de gestión
Habilidades de cara al cliente / blandas : en muchos sentidos, creo que este es el mayor desafío para los ingenieros que realizan la transición a la consultoría de gestión. Especialmente en las empresas donde los clientes a menudo incluyen miembros de alto nivel de grandes organizaciones, el nivel de equilibrio, la presencia de la mente y la capacidad de “decir lo correcto en el momento adecuado” requerido para evitar avergonzarse a uno mismo, al equipo y a la empresa no lo es. algo que normalmente desarrolla un trabajo de ingeniería.
En las organizaciones de desarrollo de software, rara vez el ingeniero se encuentra en una situación en la que el pensamiento sobre el terreno y la toma de decisiones sobre cómo dar cuenta de las emociones, el intelecto y las prioridades de las personas al mismo tiempo tienen consecuencias significativas asociadas con él. La mayoría de los casos en los que los ingenieros individuales necesitan tener en cuenta las necesidades y los deseos de los demás están dentro de los límites de su equipo, donde el costo de los errores generalmente se limita a un poco de burla. No es así como consultor, donde un comentario erróneo, una suposición injustificada o un error social, por no hablar de errores de cálculo, correos electrónicos mal enviados, etc., frente a la persona equivocada en el momento equivocado puede dañar rápidamente la credibilidad del equipo y efectividad en hacer su trabajo.
Capacidad para desarrollar y aplicar rápidamente una base de conocimiento amplia pero delgada : los ingenieros de software pasan años perfeccionando sus habilidades de ciertos idiomas, tecnologías y sistemas. Debido a que necesitan ser capaces de construir sistemas altamente predecibles y completamente verificados y probados que funcionen bajo una variedad de condiciones operativas, necesitan un conocimiento tópico profundo y tienden a especializarse un poco con el tiempo, adquiriendo nuevos conocimientos que son complementarios, pero típicamente no reemplaza sus habilidades existentes.
En contraste, como consultor, a menudo dejará una industria determinada y una combinación funcional, por ejemplo, operaciones de semiconductores, después de un proyecto de 2-3 meses, e irá al día siguiente a un compromiso totalmente diferente en una industria y función diferente: un marketing y compromiso de ventas para un gran minorista. Se espera que esté al tanto de la industria, la empresa cliente y los problemas clave que enfrenta el grupo o equipo del cliente en cuestión de días u horas, y que pueda hablar de manera inteligente sin hacer el ridículo frente a las personas que tienen trabajó en esa industria durante años o décadas. Esto genera no poca cantidad de BS (otra habilidad que quizás debería poner en algún lugar de la lista), pero no obstante se requiere una cierta flexibilidad que puede hacer que un ex ingeniero que esté acostumbrado a aplicar un cuerpo de conocimiento de dominio más acumulativo, incómodo.
Por supuesto, durante años en consultoría, los consultores individuales generalmente desarrollan sus áreas de especialidad (finanzas corporativas u operaciones mineras, etc.), pero los conjuntos de habilidades centrales reales son la resolución de problemas, las habilidades del cliente y las otras que se mencionan aquí. El conocimiento del dominio es valioso, pero a menudo es algo que simplemente se obtiene de un equipo de expertos y se pone en manos de los solucionadores de problemas correctos en el momento adecuado y se aplica a un problema en esa área.
Análisis cuantitativo : al menos en mi experiencia en ingeniería de software, aunque se requiere una gran cantidad de pensamiento lógico, hubo muy pocas matemáticas o modelos. Por otro lado, en consultoría, casi todos los analistas / asociados contarán con al menos un proyecto en el que un modelo financiero u operativo detallado es el núcleo de su flujo de trabajo. Desde la perspectiva del diseño de la estructura del modelo y de aprender a usar Excel, con sus múltiples teclas de acceso rápido, funciones y capacidades, esto puede ser desalentador. Por lo general, alcanzar una competencia básica en esta área requiere capacitación especial y cierto nivel de prueba de fuego en tus primeros compromisos, cada vez que descubres cuán limitadas son tus habilidades de Excel.
Por último, las habilidades de presentación verbal y escrita , aunque algunos equipos de ingeniería y metodologías de desarrollo son más fuertes que otros para desarrollar estas habilidades, el ingeniero promedio no tendrá que crear o presentar documentación o ideas que tengan una exposición significativa más allá de la organización de ingeniería. Escribir o editar documentos de diseño, planes de prueba y documentación de código es una disciplina que requiere precisión y conocimiento técnico, pero no los elementos de narración de cuentos o las señales estilísticas, herramientas visuales y trucos, y la creación de palabras que se utilizan para producir un mazo de consultoría típico y entregar el Presentación que comunica las respuestas y el contenido a los clientes o al equipo de consultoría.
Para aquellos que hacen la transición de la ingeniería a la consultoría de gestión, la buena noticia es que la mayoría de las empresas gastarán una gran cantidad de tiempo y dinero para enseñarle todas estas cosas, tanto al ponerlo a través de programas de capacitación formalizados como al comenzar a desempeñar funciones. donde debería tener la oportunidad de aprender de los demás, en un entorno que ofrezca cierto nivel de protección y seguridad en caso de falla. Hay todos los incentivos para que tenga éxito, y muchos ingenieros de software (y otros ingenieros) son buenos consultores, aplicando las mismas habilidades de resolución de problemas y trabajo en equipo que son esenciales para hacer el trabajo para aprender los otros aspectos de lo que hace que un consultor sea bueno en su trabajo